I'm no novice when it comes to Coldbox, but I've also never had the opportunity to sit and go thru the system with the author himself. That alone had me looking forward to the seminar.

The course kicked off with a nice breakfast and a goody bag loaded with training materials, a t-shirt, cheat sheets, candy and snacks, not to mention the bag itself is pretty nice.

The training manual has to be around 300+ pages, and that doesn't include the exercises. That's a separate booklet 100+ pages thick. Both are as rich in content as they are in size.

The lecture began with an intro to Design Patterns, Object Oriented methodology, and the vocabulary needed to comprehend the framework's architecture. He also went over some Best Practices not specific to Coldbox. A good lesson for those migrating from spaghetti or even well structured procedural code.

The highlight for me came when he mentioned a few things to be aware of when using ColdFusion. Years of CF and I guess a few things had slipped by me.

Did you know:

1. Variables of type string, array, number, and date all pass in and out of components by value. But structures, queries, and all other 'complex' objects including CFCs get passed by reference. May seem obvious to some, but to me, the ARRAY type seemed liked it should of been grouped with the complex types and passed by reference. Apparently, its a CF thing. Don't know how I feel about that, your thoughts?

2. ColdFusion creates java inner classes for each method in a CFC. So on top of the classes it uses to build CFC objects, it also has to instantiate these inner classes for each method. So consider the overhead of bloating objects with simple getter and setters, is it worth it?

Definitely, got me thinking...

From there we jumped into framework itself. Luis went over how to get it installed, configured, and how to tweak your IDE (eclipse and dw snippets and dictionaries).

The focus with Coldbox has always been the developer. If you don't know, there are lots of features that you wont find in other frameworks that make coding easier, and more fun. Luis touched on the development tools such as, the dashboard, debugger, cache monitor, and even the SideBar, to name a few.

Things started getting pretty advanced when we got into the Coldbox architecture and hierarchy. A great way to really understand the power and the functionality you have available from within the framework. I don't want to spoil it for those attending the seminar at CFUnited, so I wont go in to much more detail. I will say there are lots of details and knowledge to be absorbed, even for a veteran like myself.

Looking forward to Day 2's lesson. We still have half of the training manual to go.

A minor update with a major fix.

0.4 -CHANGE LOG- 11/13/2008 - enhancement - logging improvements and toggle setting/property added - enhancement - improved caching - enhancement - added getKeyMap method - enhancement - added argument to definition file - enhancement - changed definition file extension to .transfer - fix - added double lock to prevent concurrency issues with duplicate method creation

And for those using Coldbox there is an optimized version of the gateway in the package.

Grab a copy at: TransferSync @ riaForge

Coldbox and Coldspring have a lot to offer when it comes to development. However, loading time is the price we pay.

There are a number of settings in Coldbox to optimize performance based on environment, but developing locally with nothing cached can drag between requests. Especially, if you are using a large number of beans with Coldspring.

If you want to trigger a reload it's as simple as:

Where and how you use this is up to you.

May be we can get it integrated into the Coldbox Sidebar.

The second release of TransferSync, didn't see any bug fixes. Instead, this edition includes some optimizations for those using Coldbox. There are no major changes to the methodology or function. Everything works the same. However, a few things have been updated to take advantage of the Coldbox cache and features to provide better performance.

Grab the latest version at RIAForge.org

I was using the Coldbox SES interceptor and the built in Coldcourse integration, and ran into a little snag the other day. Our production boxes are clustered behind a load balancer using sticky sessions. In order to, reinitialize the framework, I had to access each host by ip and port.

This causes an issue with the current integration with Coldcourse and the SES interceptor. What happens is your BaseURL gets set to 'http://localhost:1234'. Which is no good for those rewrites, since the address will not resolve.

The answer...

Use the config or environments.xml to specify a new setting 'BaseHostName'.

config.xml

environments.xml

While you are in the config, make sure you check the order of your interceptors. You will want the environment interceptor to come before the SES. Be sure to set the FireOnInit property to TRUE. This means that the load up of settings occurs once the interceptor get's created and NOT on the execution point.

Then, modify the routes.cfm to accept the new setting.

That's it. Now whether you are clustered or not, you have control over the host name. Maybe this will make it into a future release of Coldbox.

Thanks to Oscar and Rob for the quick feedback. Both pointed out flaws that needed addressing immediately. I made the appropriate updates, and after a quick review with Luis, even more.

This release should be as optimized as it gets.

Oscar, indicated the importance of getting the accurate hostname when in a clustered environment. He suggested doing so with:

Which from my research, is the best approach. However, as Rob mentioned in his comment, the idea of creating an object on every exception could create a nasty performance drain. Well, we all know Luis has packed Coldbox with all kinds of goodies, and of course in his 'utilities' plugin he already had a method to getInetHost(), which does exactly what Oscar suggested. Except, since its a CB plugin, its already loaded and cached for us. So I now call a cached object's method when the BugLog plugin initializes and I store it in the instance data.

Next, had to get rid of the CFINVOKE, and not by replacing it with a CreateObject. The best way to do this is with lazy loading. You don't want to create and stash the webservice object in the plugin instance at creation, because CB plugins are initialized with the framework. Lazy loading will create the object the first time it is needed, and will persist as long as the plugin itself exists. Which you can define with the CACHE settings in the plugin metadata.

This is what the latest version looks like:

If you didn't notice, I now allow for you to pass in the Message, and Severity Code, along with the Exception Bean. The code in your exception handler should look something like this:

Hope this helps out, I will be updating the original post. Be sure to check that out if you haven't it contains useful information for those who are just getting this setup.

I recently posted about the Coldbox 2.6 environment interceptor and how it allows you to set different config settings for your app. Then, I released a BugLogHQ plugin for Coldbox. After taking in some feedback, and chatting with Luis, I have made some modifications. This post will discuss the updated Webservice Plugin. I will post another to go over the updates to the BugLog plugin.

Currently the native Webservice support for Coldbox expects 2 WSDL URLs for each service, one for DEV and one for PROD. Looks like:

Well, with the new environment specific settings, it defeats the purpose of defining them like this any longer. You can now set them in your environemnts.xml. Like so:

Luis plans to deprecate the current method, but not sure as to when. So implementing this can be done in a number of ways in the meantime.

First option: Overwrite existing Webservice plugin distributed with Coldbox and move your Webservice declarations out of the coldbox config file and into your environments.xml. ** You will not have to modify any application code **

Second Option: Place the updated version into your plugins folder, and call it by using getPlugin('webservices',true). This is for those who need some time to update for the deprecation. You can continue to use your existing Webservices from the coldbox config. Allowing you to add new ones to your environments.xml but remember to use the ',true' when calling the webserivce plugin.

Honestly, I recommend the first option, as it shouldn't take much effort to transfer Webservice WSDLs to the environments.xml, and you wont create a mesh of syntax with getPlugin() calls.

If you have heard of BugLogHQ, a nice centralized bug reporting application, written by Oscar Arevalo, and you want to integrate it with your Coldbox apps, then this article is for you.

Let's get started...

Be sure to set the Exception Handler in either the Coldbox config or your Environments.xml. For reference, 'main' is my handler and 'onException' is the method or event. By default, the value is blank in the config.

Next, you need to add the WSDL URL to your Coldbox config file or your Environments.xml.

@UPDATE - ** WEBSERVICE PLUGIN UPDATED **

Now, go to that Exception Handler method we defined in the first step. Copy and paste this in there.

@UPDATE - UPDATED CODE HERE

Finally, create the BugLog.cfc and place it in your Plugins directory ('plugins' by default unless you specified otherwise in your CONVENTIONS).

Here's the code.

@UPDATE - UPDATED CODE HERE

That's it.

Now, Coldbox will deliver Bug Reports to the BugLog system, in addition to the internal Bug Reporting setting. If you don't want to use CB to deliver Email Reports then be sure to define that in your config or environments.xml.

We know how to use the Coldbox environment interceptor to load different values for datasources. We know how to circumvent datasource.xml files with Transfer by using a datasource bean. Now, how can we use ColdSpring to put it all together for us.

That's what my coldspring.xml file would look like. There are a few things to note. I use Coldbox to get the Datasource information I need because it has already been defined in the Coldbox config or environment file. This is the reason I wanted to avoid a datasource.xml file for Transfer. Otherwise, I'd have the same DSN info repeated all over the place.

I also point to model.TransferConfig. A simple extension of the Transfer Configuration bean. You can learn more about that from my previous post.

If you notice, there is a Transfer_DSNAlias argument being passed into the Coldbox getDatasource method. This tells CB which DSN you want to load up and pass on to Transfer. Coldbox allows for multiple datasources to be stored for use in your App. But Transfer only connects to one at a time. So I made it a setting in the config/environment.

Here's a peak at my environements.xml file.

That's it.

I talked previously about the abilities of the new Environment Interceptor in Coldbox. The next step was to wire it up so I could automate the initialization of Transfer using ColdSpring and these environment specific values from Coldbox.

Before I get into that I needed to know how to overwrite complex values, like Datasources, set in the Coldbox config file with those from the environments.xml.

Luis was kind enough to point me in the right direction, and said dump the ConfigSettings struct and Transverse whatever you want. That I did, using JSON notation. Just substitute single quotes for double quotes maintaining valid XML format.