buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Smiley <esmi...@ebrary.com>
Subject Re: Anybody see this?
Date Mon, 29 Nov 2010 21:55:33 GMT
Couldn't get that to work....

On Wed, Nov 17, 2010 at 3:54 PM, Ed Smiley <esmiley@ebrary.com> wrote:

> Interesting.
>
> I saw a post by "Arton", the guy mentioned in the release notes, indicating
> that the proper way to add a jar to the classpath is using the new dynamic
> functionality
>
> Rjb::add_classpath, rather than setting it really early on though
> Java.classpath.  I am messing with that approach, currently.
>
> On Wed, Nov 17, 2010 at 9:50 AM, Alex Boisvert <alex.boisvert@gmail.com>wrote:
>
>> 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 <esmiley@ebrary.com> 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?
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message