ColdSpring 2 Documentation Competition - Win a Copy of CFBuilder!

With the rewrite of ColdSpring , a whole load of documentation also needed to be ported, and in some cases, actually written for the first time, for existing functionality as well as new functionality.

Unfortunately it became a real sticking point with getting a release of ColdSpring 2 out of the door.

While the documentation isn’t quite complete, there is enough there to get people started, and it can be fleshed out on a case by case basis.

That being said - to help make the documentation complete as quickly as possible, there is now a competition to win a copy of ColdFusion Builder, and the way to enter is to write documentation for ColdSpring 2.

The rules are very simple:

• To enter, you have to write a page of documentation for ColdSpring 2.
• You can write multiple pages, for more chances to win.
• Entries can be submitted directly to the Trac Wiki, in Word or OpenOffice format and emailed to me directly (email below), or to the ColdSpring Google Group.
• Some pages are easier than others, so best to get in early (some are just ports/extensions from the existing documentation).
• Possible pages are the pages that are empty on the Wiki (unless you come up with some new section that is deemed to be an missing item).
• A documentation page must be approved on completion to be an entry (i.e. no 2 line entries, etc trying to game the system).
• The competition closes on the 31st of November (Australia time!), and the winner will be randomly selected from the entries, and a copy of ColdFusion Builder will be sent to the winner!

To make this more enticing, and also a whole lot easier, I’m offering each person who wants to enter my Skype and IM details.

Skype: mark_mandel
Gtalk & MSN: mark.mandel@gmail.com

I’m happy to have a 10-15 minute voice chat with potential entrants explaining a feature if they are new to it and/or guiding them in what I had in mind for the documentation page, and give whatever other advice they need via IM and email to help them complete their documentation page.

So not only is this a chance to help out the ColdSpring and ColdFusion community, it’s a chance to win FREE copy of ColdFusion Builder, and also it’s a great opportunity to pick my brain on ColdSpring 2 (which should hopefully be worth something as well  :) ).

ColdSpring 2 Alpha 1 Released

After a long 2 years of development, ColdSpring 2, Alpha 1 is ready for release!

It’s been a long road getting here, but with the rewrite of ColdSpring, means that ColdSpring 2 comes with a stack of new functionality that should help you out with all your dependency injection needs, and then some!!!

To give you a quick overview of some of the major new functionality that comes with ColdSpring 2:

XML Schema For ColdSpring

No more needing to guess what XML to write with ColdSpring, or use a not-quite-right-fit Spring.dtd or XSD to give you code completion and hinting with your XML.

Now with a XML editor that supports XML Schemas (Eclipse Web Tools Project jumps to mind) and a quick XML schema declaration at the top of your XML, you now get total code-completion, and built in help with your XML elements. Makes life much easier!

AOP Custom XML Namespace and AOP Expressions

This is one of my favourite features, as it just make Aspect Oriented Programming with ColdSpring and absolute breeze.

Gone are the days of ProxyBeanFactories and NamedMethodAdvisors. Now you have a simple scripting language for defining where you want Aspects to be applied, and what you want them to do.

For example, if I had the following XML:

<beans xmlns="http://www.coldspringframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:aop="http://www.coldspringframework.org/schema/aop"
   xsi:schemaLocation="http://www.coldspringframework.org/schema/beans http://coldspringframework.org/schema/coldspring-beans-2.0.xsd
   http://www.coldspringframework.org/schema/aop http://www.coldspringframework.org/schema/coldspring-aop-2.0.xsd"
   >

   <!-- AOP configuration -->
   <aop:config>
      <aop:aspect ref="timer">
         <aop:around method="timeMethod" pointcut="execution(public * *(..))"/>
      </aop:aspect>
   </aop:config>

   <bean name="timer" class="com.Timer" />

   <bean name="fooService" class="com.FooService" />

</beans>

What this says is, for the given pointcut, execution(public * *(..)), which translates to any method execution, which is public, and returns any variable, with any method name, and any number of arguments (i.e. every method), call the method timeMethod on bean timer around that method.

So when do call fooService.doSomething(). Our Timer Component, will be able to log how long it took, and as you can see, no need for complicated ProxyBeanFactories, target beans or anything of the sort. All nice and clean and concise.

This is by far, just the surface of what is possible with the AOP XML namespace and AOP expressions in ColdSpring. There are more configuration options, and many more different types of expressions that are possible.

ColdFusion 9 ORM Integration

Injecting other objects into your ORM Entities can be a tricky prospect, but ColdSpring 2 comes bundled with a stack of utility objects that make this much easier, as well providing you with additional functionality to help you out with common ORM tasks as well.

ColdSpring 2 comes with a BeanInjectorEventHandler, whose job is to intercept when Entities are loaded, and inject them with whatever dependencies are loaded.

To intercept when new Entities are created, ColdSpring 2 has a SessionWrapper object that provides an interface to the underlying Hibernate Session, from which you can request new Entities, list, save, delete Entites and much more.

The SessionWrapper also enables some more advanced configuration options above and beyond ColdFusion’s basic settings, including being able to set a default Hibernate Session Flush Mode, and implementing a strict transaction mode as well.

This is just a start to the ORM integration, there is plenty more bundled into ColdSpring 2!

Multiple Bean Scope Support

ColdSpring 2 has a totally new and reworked bean creation process, so that not only can it create transient and singleton beans, but it can also tie beans to request and session scopes as well. To do this, it has a new scope attribute which replaces the old singleton attribute on beans.

Therefore to define a bean as a singleton, you not define:
<bean id=”fooService” class=”com.FooService” scope=”singleton”>

To define a  transient bean:
<bean id=”fooService” class=”com.FooService” scope=”prototype”>

To define a request scoped bean:
<bean id=”fooService” class=”com.FooService” scope=”request”>

(And I’m sure you have the pattern by now) To define a session scoped bean:
<bean id=”fooService” class=”com.FooService” scope=”session”>

This gives us even more control over the life-cycle of our beans, to enable some very powerful capabilities in our applications!


There is a lot more to ColdSpring 2 than just the above, but hopefully that will give you enough of a view to entice you to take the framework for spin.

More details can be found in the Release Notes, ColdSpring website, and Trac site.

Also, if you are interested in going into the running for winning a copy of ColdFusion Builder, check out the ColdSpring documentation competition currently running to aid in fleshing out the rest of the documentation for ColdSpring

How I Configure ColdFusion ORM and Why

I’ve been reading quite a few mailing list posts on ColdFusion based ORM, and I find that I’m seeing a lot of repeats on what configuration settings people are generally using when setting up ORM in their Applicaiton.cfc, and why they should use certain settings.

I figured it would be useful if I wrote down how I like to have my base configuration of my Application.cfc in regards to ORM, and also take a step by step look through why I set things up the way I do.  Hopefully this will help out a few people when they first start out with ORM, and are looking at all the different options for ORM in ColdFusion.

<cfscript>
   this.datasource = “mydatasource”;

   //orm settings
   this.ormEnabled = true;
   this.ormSettings.cfclocation = expandPath("/model");

   this.ormSettings.automanageSession = false;
   this.ormSettings.flushatrequestend = false;

   this.ormSettings.useDBForMapping = false;

   this.ormSettings.autogenmap = false;

   if(isDevEnvironment())
   {
      this.ormSettings.dbcreate = "dropcreate";
      this.ormSettings.sqlscript = expandPath("/import.sql");
   }
</cfscript>

So breaking this down line by line.

this.datasource = "mydatasource";

This isn’t specifically an ORM setting, but I love how in CF9, we can set a default datasource across the application in one place. Also like that ORM picks this up too, although it can be overwritten with ormSettings.

this.ormEnabled = true;

Again, nothing special. We turn on ORM. Without this line, nothing happens.

this.ormSettings.cfclocation = expandPath("/model");

When ORM is enabled, by default, ColdFusion will scan from your web root, looking for any CFC’s that are marked as persistent. As a performance enhancement, it’s useful to tell it specifically what folder to look at.  Also, if you have your components stored in a mapped directory, this is the only way it can be done.

I’ve seen this set a few ways (dot notation, relative paths), and seen a fair few people have issues with this. Personally, I’ve never had an issue when using the expandPath(), so I stick with that as the way to go.

this.ormSettings.automanageSession = false;
this.ormSettings.flushatrequestend = false;

I bundle these two together because they are quite related in what they do. They basically control how the Hibernate session works in ColdFusion ORM. This combination of settings does the following:

• Turns off the Hibernate session being flushed at the end of the request
• Stops the Hibernate session being flushed at the beginning of a transaction
• Stops the Hibernate session being cleared when a transaction is rolled back

For me, this is very, very, very important. The default setting of having these both on for ORM makes doing basic things with ORM very easy, but when you start getting into more complex scenarios, in which issues like object validation or concurrency arise, these default settings can throw some fun Hibernate exceptions on your screen super fast.

By setting the above to false, you have complete control over when a session will flush (only when a transaction commits), and you know it will only be cleared when you request it to be. This makes it a lot easier to manage your Hibernate object states in those more tricky scenarios.

(You can use ormFlush() with the above settings, but please don’t do that. Please use transactions. Your database will thank you.)

this.ormSettings.useDBForMapping = false;

This is primarily a performance setting. By turning this off, it stops ColdFusion from going out to your database and looking at what tables and columns you have and attempting to generate it’s object mappings from there. Personally I can’t stand this functionality, as your DB then drives you model (not an ideal scenario), and also because, if you are using annotations / HBMXML config files, there is absolutely no reason to do this (and I’ve read of people on Oracle having crazy issues with having this enabled by default as well).

this.ormSettings.autogenmap = false;

This setting is most definitely a personal preference thing. When I work with ORM I use the HBMXML mapping files, as every time I use the annotations, I find it doesn’t default the way I would expect/want, or I am looking to use some Hibernate functionality that isn’t exposed through annotations. Then I have to go back and move all my configuration from annotations to a HBMXML file. It’s far easier to me to start with a HBMXL file, and never look back. Since I also have a CFBuilder extension to help generate the stub files, it makes it an easy decision.

Setting autogenmap to false, means that even if someone were to come along and use annotations, they wouldn’t work, so it makes sure I don’t have that "Just this once I’ll do annotations..." thought which inevitably leads me back to rewriting annotations into HBMXML again.

this.ormSettings.dbcreate = "dropcreate";
this.ormSettings.sqlscript = expandPath("/import.sql");

This setting is more for greenfield projects. On legacy projects, I find that they tend to frown on having all their development data dropped, for obvious reasons, and it can be a large project to write an import script for it all.  However, when starting from scratch, it’s really nice to have a clean data set on every reload, especially from a unit testing perspective.

There are many more settings that can be used, that are generally more application specific, such as the SQL dialect, or whether or not you enable the second level cache, but this is generally speaking, the base configuration I start most project from.