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 .
Toby Tremayne has (finally? ;o) ) released an
Alpha version of his Flex to Transfer bridge Bender.
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.
The
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.
There
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
it.
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!
Enjoy!
Toby Tremayne has started doing some work on developing a bridge between
Flex and
Transfer
called 'Bender', which is meant to automate the process of translating
TransferObjects into Actionscript Value Objects and back again within a
Flex Application.
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
Transfer.
This one updates some documentation, and implements a workaround for the CFMX
memory bug with URLClassLoaders described
here. Other than
that, nothing that exciting to report.
Mind you, the new tBlog example application has been updated to instead use
TQL
to do it's gateway queries, rather than using regular ol' SQL, and a
Decorator
example is also shown, so it may be worth re-downloading it if you already have it, and take a peek.
Since the
last
release candidate 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
option.
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 directly.
Enjoy!
This is a bug in ColdFusion that can cause memory leaks when using a
java.net.URLClassLoader
to load external jar files. Thus, this can cause memory leaks in
JavaLoader,
Transfer
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
and 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
memory leak.
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 of
course!
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.
