Now my name is officially on the list of speakers , I can happily announce that I am talking at the 2007 WebDU conference in Sydney, Australia .
I'm very excited about this, as this is my first time presenting at a conference, and I think this is going to be lots of fun.
Un-surprisingly, I will be presenting on Developing Applictions with Transfer ORM , so please come down and hear me speak, I think you will find it interesting.
But even if you don't hear me speak, come down to the conference. I've been in previous years, and it's always a great time.
Hope to see you there!
After a bit of time in a release candidate, version 0.6 of
Transfer is ready to be released.
There is nothing very exciting to report, other than the fact that release candidate saw
some critical fixes , so I'm very happy with the choice to do that, and we will see a release pattern much like that in the future.
See the
Release Candidate post and full
changelog for the new features found in 0.6.
Transfer 0.6 Download
Next on the road map is:
- Composite Keys
- Multiple Configuration files
- Syntax in *where() methods to utilise cfqueryparam
- ...and some more stuff
Much thanks to all of those that tested out the Release Candidate, it was very much appreciated!!!
Please remember, there is a mailing list , and a forum , so if you have any feedback, please don't hesitate to send it in.
I realised something today, I've been telling something about the JavaLoader that isn't true.
By default, JavaLoader loads the ColdFusion class path as its parent when loading in custom Java libraries.
This means that if JavaLoader can't find a class that you are loading through it via the Jars that you have loaded, it will look to what ColdFusion has loaded to see if it can find it there.
I had always assumed that if you loaded something, say for example, the newer version of log4j with JavaLoader, for the Jars loaded with JavaLoader, they would see the newer version, rather than the older version of log4j with ColdFusion.
This is actually, completely and utterly false. I apologise for all the frustration I probably incurred on people for making this statement.
Reading the Java docs it explicitly says : 'When requested to find a class or resource, a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself.'
So this means that when looking for log4j - the one in ColdFusion actually takes precedence!
This makes sense in the Java world, as it allows for less confusion from the Java engine to be able to resolve classes - but from a ColdFusion perspective it makes life very difficult as we don't have the ability to modify what is loaded at application startup as we would if we had written a Java application from scratch.
A workaround for this is to pass Java null into the JavaLoader as a second variable like so:
loader = createObject("component", "JavaLoader").init(paths, JavaCast("null", ""));
This will create a JavaLoader that is not set with ColdFusion as the parent.
I am currently working on JavaLoader 0.3, that will make the precedence on the loaded classes that will solve this problem all up, as well as some parameters to avoid loading the ColdFusion classpath altogether, but I thought I would give people a heads up now to avoid frustration down the road.
