Blog

Luis Majano

December 15, 2008

Spread the word


Share your thoughts

The new Transfer Loader interceptor in the up-coming ColdBox 2.6.2 will provide you with a very easy way to configure Transfer ORM in your application and use it from ColdSpring or LightWire. How easy? This easy? Open your coldbox configuration file and try to add the following, of course season to your own taste: /${Setting: AppMapping not found}/config/transfer.xml.cfm /${Setting: AppMapping not found}/config/definitions blogDSN For those who are wondering what ${Setting: AppMapping not found} means, it means that in ColdBox 2.6.2 you can re-use ANY setting within other settings and interceptor properties, much like how you do ${} replacements in ColdSpring and Lightwire, but on the coldbox.xml. This will create the transfer factory, transfer and the transfer transaction objects in the ColdBox Cache with the following case SENSITIVE keys:

  • Transfer
  • TransferFactory
  • TransferTransaction

That's it, you know can use Transfer in your application by autowiring your objects with it: Now, what happens if you want to also use coldspring or lightwire in your application for all your model objects instead of the ColdBox's default model integration (2.6.2)? Well, you still can, by using factory beans.  What are factory beans? Factory beans are objects you define in your coldspring or lightwire definitions that can produce objects for you.  So we can declare a bean to be a CarFactory that can produce different types of cars for you.  This way, coldpsring or lightwire do NOT create these objects, but they only request them.  These factories take care of creating them for you.  This is incrediblly useful, for use cases such as the one presented here, where Transfer has already been produced and is just waiting to be used. So let's start with the global XML declaration that both coldspring and lightwire can use: Transfer TransferTransaction WOW!! That simple, we just declare the ColdBox Cache Manager to be a factory bean and then we declare beans by calling methods on it with arguments, which in our case is the key to the objects in the cache. How cool is that!! You can basically wire up anything from the ColdBox Cache into any coldspring or ligthwire managed bean. The equivalent of the XML notation in LightWire's configuration object is the following (Please note that this uses the ColdBox version of Lightwire): //Define the ColdBox Factory addSingleton("coldbox.system.extras.ColdboxFactory","ColdBoxFactory"); //Define the ColdBox Cache as a Bean addSingletonFromFactory("ColdBoxFactory","getColdBoxOCM","ColdBoxCache"); //Define Transfer addSingletonFromFactory("ColdBoxCache","get","transfer"); addConstructorProperty("transfer","objectKey","Transfer"); //Define The TransferTransaction addSingletonFromFactory("ColdBoxCache","get","TransferTransaction"); addConstructorProperty("TransferTransaction","objectKey","TransferTransaction"); There you go, a programmatic approach of defining beans. So to finalize, we where able to use ANY coldbox cached element in our coldspring or lightwire object factories by leveraging factory beans. An the best use case was using the Trasnfer Loader interceptor. Enjoy!

Add Your Comment

(2)

Dec 15, 2008 19:59:39 UTC

by Aaron

I am using this approach and I love it!!!!! Thanks Luis

Jan 05, 2009 11:40:36 UTC

by Daniel

In a handler I don't find transfer in the instance scope.... I folowed your example with coldspring

Recent Entries

FIU Students Build AI Applications and Contribute to the BoxLang Ecosystem

FIU Students Build AI Applications and Contribute to the BoxLang Ecosystem

Florida International University students are gaining hands-on software development experience through an ongoing collaboration with Ortus Solutions, building applications with BoxLang and BoxLang AI while exploring opportunities to contribute to the technologies themselves.

Maria Jose Herrera
Maria Jose Herrera
November 02, 2026
Coming Soon:  Version 4 Docker CommandBox Images with Enhanced Performance

Coming Soon: Version 4 Docker CommandBox Images with Enhanced Performance

CommandBox Docker images were the first CFML docker images and have nearly 2 million pulls, since their inception, to date. It's been a source of pride at Ortus that these images have been the most popular and reliable way to run CFML in containers and we are so very pleased to announce the next evolution, which will be the v4 images which run entirely on the BoxLang CLI and represent a significant overhaul of the image architecture.

These images are now available to test by appending -snapshot to your existing version tags and wil be released as stable, once CommandBox v6 emerges from release candidate status and is published as stable.

Jon Clausen
Jon Clausen
October 30, 2026