There were some changes in RJB between 1.2.5 and 1.3.3 related to classloading. In particular, RJB now uses a URLClassLoader instead of the JVM's system classloader.
https://github.com/arton/rjb/blob/master/ChangeLog <https://github.com/arton/rjb/blob/master/ChangeLog>Not sure it causes the issue you're seeing but I thought it worth mentioning. alex On Wed, Nov 17, 2010 at 8:59 AM, Ed Smiley <[email protected]> wrote: > In the aftermath of changing over to getting Buildr to work with the new > JVM, I am seeing yet another issue, this one a tad obscure. > It's a little complicated to explain so bear with me. > > In code (that is essentially the same and was working before) I had a step > where I set up a Java classpath early on in the build process which > included > my (not yet existing) package jar file products. I calculate where they > would end up and what they would be called to avoid a circular dependency > on > package object, and also to set the classpath for RJB early on (as it lets > you set it later, but does not honor the new value). I then have a > validation step where a list of Java classes and their expected subclasses > are instantiated (using > > Java.java.lang.Class.forName(dep.class).asSubclass(Java.java.lang.Class.forName(dep.subclass))). > As odd as it sounds this worked correctly, and have been using this for > the > last six weeks until I hit this snag. > > Now (and I put in debugging to ensure that that classpath is as I think it > is and that the jar file exists before running this check) classes that are > built in my jars are unable to be instantiated by the RJB Java object and I > get spurious errors. > > Any insights? Has this environment done something to unhinge the RJB > "classpath lifecycle"? Perhaps something now creating the JVM earlier? >
