Yesterday morning (well, it was my morning, most other people's
afternoon), I did a short, 20 minute preview of one of the talks I am
doing at cf.Objective()
If you managed to miss it, and want to have a listen, or are looking for a real quick overview of Transfer
, you can see the recording here
I have about three seconds to write this - but I'm doing a preview of my Developing Applications with Transfer ORM presentation for cf.Objective() at 3pm EST, on Friday the 27th of April (my tomorrow).
Please show up if you are interested, as I'm getting up at 5am to come talk to you lot ;o)
More details can be found at the ColdFusion Meetup Group .
has (finally? ;o) ) released an Alpha version of his Flex to Transfer bridge Bender
looks to be a very interesting project, in that it generates the AS for you that mirrors the generated TransferObjects that come our of Transfer
It also handles passing data back and forth between Transfer and Flex
, and back again, without you having to do any of the translation between.
neat thing about Bender as well, is that you can set up mappings, such
that when you call Bender.save() on the AS side, it can either call
Transfer directly, or, you can send the save() request to a completely
different mapped CFC and/or method! This gives you complete
flexibility over your architecture.
I'm really liking the work that Toby is doing on Bender, and I think it's going to be a real asset to the Transfer library.
After a good Release Candidate phase, Transfer
0.6.3 is ready for release.
is nothing huge to report in the change from RC2 to Final, except for a
few small code cleanups and some more documentation, and that is about
For the big spiel about what is new in 0.6.3, check out the RC1 release post
Now it's just a case of seeing what I can manage to fit in before cf.Objective()
, which is in two weeks!
has started doing some work on developing a bridge between Flex
called 'Bender', which is meant to automate the process of translating
TransferObjects into Actionscript Value Objects and back again within a
We are yet to see any code samples yet, but he tells me that progress
on it is running along nicely, and he already has a series of blog
posts on the progress he has made already.
I'm really looking forward to seeing the product in action, I think it is going to be really interesting! Have a read of it here
This is something that Nick Tong
, of cfframeworks.com
fame wrote a while ago, but I totally forgot to blog.
Nick wrote up a great little tutorial on how to set up Transfer when using Fusebox
with Fusebox Lexicons.
You can have a look at the tutorial here
Another release candidate for
This one updates some documentation, and implements a workaround for the CFMX
memory bug with URLClassLoaders described
. Other than
that, nothing that exciting to report.
Mind you, the new tBlog example application has been updated to instead use
to do it's gateway queries, rather than using regular ol' SQL, and a
example is also shown, so it may be worth re-downloading it if you already have it, and take a peek.
didn't show up any bugs, assuming I don't hear anything
about this one, v0.6.3 final will be ready to go in a week or so. Which is
really great, as no one has discovered any glaring holes in TQL yet.
After that, it's time to start developing Composite Key support. Cool!
One thing that I always gets complaints about with JavaLoader
is that you can't delete or rename a .jar file once it is use by
ColdFusion, you either have to restart CF, or name the .jar file
something funky like 'myOwnJar-10042007.jar', so it has a unique name. Now with this version of JavaLoader, that issue is no more!
While the .jar file that JavaLoader uses itself does get locked down (I know.. I can't do anything about that one), but
.jar files that you use with JavaLoader no longer are locked by the system!
To note, the JavaLoader cfc has had one of its arguments removed - 'loadedClassPathBias',
simply because it was more difficult to implement with the new code
base, and there didn't seem to be a case for it. By default,JavaLoader
will load the specified jar files before it loads the parent's, if it
has one. Honestly, I don't think this is going to affect a single
person, because I would be shocked if anyone actually ever used the
Please note there are some issues with memory and JavaLoader, so make sure you put your JavaLoaders in the Server scope. See here
for more details.
If you find any issues, please post to the forums
, or contact me
This is a bug in ColdFusion that can cause memory leaks when using a
to load external jar files. Thus, this can cause memory leaks in
and any other system that uses this technology. However there is a
workaround for the issue.
To explain the problem, first we need to look at some key issues with a
URLClassLoader. URLClassLoaders are notorious for causing memory leaks,
because, for them to be garbage collected, all instances to themselves
the classes that they have created
need to be garbage collectible.
This means that if you access a class from a URLClassLoader and hold it
somewhere in memory, then the URLClassLoader can
never be garbage collected
This is exactly what happens with ColdFusion.
When ColdFusion does some introspection and resolution of ColdFusion code
against a Java object, somewhere, deep inside its hidden internals, it keeps a
strong reference to the Class object that refers to that Java object. This
means that when the JVM comes along to garbage collect the instance of the
URLClassLoader, it can't do it, because ColdFusion has a reference to a class
that it loaded somewhere inside.
So, the memory leak only ever actually happens when an instance of a
URLClassLoader is no longer available to ColdFusion, as it is never then garbage
collected by the JVM.
How does this translate to using JavaLoader? Well, a perfect example of this is
where you put an instance of JavaLoader in the application scope, because
generally it is used as a singleton. JavaLoader (and anything that
subsequently uses JavaLoader) has an instance of a URLClassLoader inside
it. However, when the application scope times out, the JavaLoader CFC may
well be garbage collected, but the URLClassLoader isn't, which can cause a
To note however, in production systems the leak is minimised in situations like
this, as it is often very rare that the application scope will ever time out.
So what is the workaround for this issue? To note, I have been pushing at Adobe
to get a hotfix out for CFMX to resolve this issue, but we can definitely still
use this technique now, without having to worry about memory leaks.
Essentially, the memory leak only happens when the URLClassLoader is no longer
available to CF, i.e. an application scope times out, or something similar - so
we just need to make sure that it never, ever, times out. How can we do
that? why, put it in the Server scope
Since variables in the Server scope never time out, we don't need to worry about
the URLClassLoader (or JavaLoader) being lost and then recreated, as it always
exists. As long as you put it in the Server scope under a key no one will
ever need to utilise (I like a hard coded UUID myself)! Hence we beat the
memory leak monster!
I have just committed a fix for Transfer that automatically puts the JavaLoader
it uses into the Server scope, so even if your TransferFactory times out, the
JavaLoader never will, which means there is no leak, and the RC2 for 0.6.3 will
have this as well.
Hopefully Adobe will put out a hotfix for this issue, but until then, put your
JavaLoaders in the Server scope.