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.

The latest release of Coldbox 2.6.0 RC1 is like every other Coldbox release...Filled with goodies.

For now, I am keying in on the Environment Interceptor. It allows you to specify a different set of configuration settings based on the environment your application is running in. You are no longer limited to a single config file and the settings bound to it.

By default, Luis uses URLS specified in the environments.xml and looks for them in the cgi.http_host. While it is effective, I have always liked the flexibility of regular expressions.

I have updated the code to accept a PATTERNS attribute from the config xml file and use the pattern as a regular expression against the cgi.http_host.

It extends the environmentControl interceptor that is distributed with CB, and is completely backward compatible.

Get the CODE - EnvironmentControl.zip

If you want to use the PATTERNS leave the URLS empty.

I thought about using both URLS and PATTERNS together, but with regEx you can pretty much capture any URL.

The environments.xml.cfm would look like:

The interceptor in the config.xml.cfm would look like:
(only difference here is the class path - no longer points to coldbox.system.interceptors)

For more on the latest release, check out What's New in Coldbox 2.6.0