buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <alex.boisv...@gmail.com>
Subject Re: Anybody see this?
Date Tue, 30 Nov 2010 02:45:27 GMT
Can you post a simple example of what you're trying to do?

On Monday, November 29, 2010, Ed Smiley <esmiley@ebrary.com> wrote:
> 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
View raw message