ColdSpring - Using the Parent attribute to specify configuration settings like DSN

I am doing a bit of re factoring in our product, and starting to do a cleaner job of having configuration settings available to each Manager object that needs it (in the typical Manager/Gateway/DAO scenario).

I am looking at the undocumented (at this point) 'parent' attribute that can be specified on a Bean, which will then have the configuration settings injected into it, without the need to explicitly specify the config dependency. Here's an example as I've implemented it:

coldspring.xml definitions...

<!-- Regular Bean in need of some config settings (and specifies the
configGateway as the parent) -->
<bean id="regularBean" class="com.regularBean" parent="configGateway">

<property name="configSettings">
<ref bean="configSettings">
</property>
</bean>
<!-- Configuration Bean which holds config settings -->
<bean id="configSettings" class="com.configSettings">
<constructor-arg name="dsn">
<value>odbcdsn</value>
</constructor-arg>
</bean>
<bean id="nextBean" class="com.nextBean">
<property name="configSettings">
<ref bean="configSettings">
</property>
</bean>

Then in my 'RegularBean' I need the methods for configSettings i.e.:
<!--- Author: penny - Date: 7/30/2008 --->
<!--- getter and setter for configSettings --->
<cffunction name="getconfigSettings" access="public" output="false" returntype="com.configSettings">
<cfreturn>
</cfreturn>
<cffunction name="setconfigSettings" access="public" output="false" returntype="void">
<cfargument name="configSettings" type="com.configSettings" required="true">
<cfset configsettings="arguments.configSettings/">
</cfset>
</cfargument></cffunction></cffunction>

When calling Regular Bean -
application.serviceFactory.getBean('regularBean').getConfigSettings().getDSN()

This technique still requires the 'stubbed' getter/setter for the configSettings bean, but is less xml in the coldspring xml file. Here is an example of the alternative:

(BAD)
coldspring.xml file

<property name="configSettings">
<ref bean="configSettings">
</ref>
</property>
<!-- Configuration Bean which holds config settings -->
<bean id="configSettings" class="com.configSettings">
<constructor-arg name="dsn">
<value>odbcdsn</value>
</constructor-arg>
</bean>
<bean id="nextBean" class="com.nextBean">
</bean> <property name="configSettings">
<ref bean="configSettings">
</ref>
</property>

.. etc.

This will be very nice to use, and extend when new configuration settings are needed to be added to the application like 'verityroot' 'rootdirectory' or 'write_dsn' or 'read_dsn' or whatever other application configuration settings are needed for your application.

They say the documentation of this should be out soon at the coldspringframework.org/docs documentation site, so stay tuned for that.

Verity Separate Server Install Collections Fail to Create

Verity sucks some days, and today is one of those days.

We had another episode with Verity where we had a collection disappear. I am not sure where or why, but I was tasked with getting it back online. This is not the first time this has happened, but the solution should be easy: Re-Create the Index, however this is where things got UGLY.

I looked in the CFadmin to see if the collection was listed, which it was not. So I proceeded to attempt to create it and received:

Unable to create collection companyX.
An error occurred while creating the collection: com.verity.api.administration.ConfigurationException: Index exists. Cannot insert entry. (-6065)

So it isn't listing the collection, and yet it says it exists?? OK, so that's problem one.

Problem 2 is that when i execute a 'reindex' which does a
<cfcollection action="create" ..>
I received no errors from the application (things looked like they were successful)

However when I look into CFADMIN again, in Verity Collections, the collection was once again not listed.

Here's what I did to fix it:

In our installation we have the Verity Installer (ColdFusion 7) installed on a separate box from the web server. I told the web1 to use the Verity K2Server at the web1 address, instead of the web2 address that it was using. Then I recreated and populated the collection using the same server the application was using (Verity was installed on both servers, but is typically not running on web1). Once done, I specified the web2 IP address again in cfadmin and copied the collection directory of the collection that I wanted from the web1 to web2.

When I go into cfadmin I should NOT see the collection listed - but after I executed a <cfcollection action="create"> with that collection name, something behind the scenes worked that time, and the collection showed up in cfadmin WITH the correct amount of data in it.

This is strange for a number of reasons, but I had to repeat this process for another collection just after this, so I know this process works. Executing a 'action="create"' typically kills any data that is in the collection, which didn't happen when I used this approach.

Anyway, hope this helps, and I know it will help me again the next time it happens....because it WILL!

XML - XSL Stylesheet references another URL Access Denied

I just ran accross an interesting issue.

When generating an XML file in ColdFusion with an associated xsl style sheet reference in the xml head -= in Internet Explorer 7 I was getting this Error:
<link href="http://careers.jobs2web.com/view/xsl/job.xsl" type="text/xsl" rel="stylesheet">

The XML page cannot be displayed

Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.

---

Access is denied.

The href attribute was pointing to a generic URL that was not the same URL as the file was being served up from. IE did not like this.

Once I changed this to be cgi.server_name instead - it worked as expected.

Firefox didn't care one way or the other - it rendered the file just fine, regardless of whether the xsl was on a different URL that the XML file was being served up on.

Wonder if this is deemed as some security breach?? Strange indeed.