Dynamic cfapplication name - Don't do it!

What happens if you use a dynamic name for your cfapplication tag
name=X, is especially if you are using frameworks of any kind, the
more sites you load on top, the memory needs increase X fold. i.e.
coldspring's memory needs + fusebox memory needs + others = Mass
Memory when you have lots of these apps running. Simple right -

It wasn't until we started piling apps on it that this came to life -
the good news is the fix is not complex and doesn't have to mean HIGH
impact changes to your application.

1.) change your cfapplication name value to something static i.e. 'sitex'
2.) I created my site Object that holds the invividual settings for
each client (that was previously stored as it's own application data
object) and used coldspring to wire up that to a siteFactory object
that gives me site Beans based on the domain.
3.) on application start, the siteFactory creates a large structure of
all active site objects 1 time only. Then when the app asks for say
application.site.getName() - it will call the siteFactory, the site
factory gets the data by the domain matching the current domain, and
returns the site object.

With this in place - there was ZERO code changes in the application and the memory requirements have gone WAY down.

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.