You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Ed Smiley <es...@ebrary.com> on 2010/11/17 17:59:31 UTC
Anybody see this?
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?
Re: Anybody see this?
Posted by Alex Boisvert <al...@gmail.com>.
Can you post a simple example of what you're trying to do?
On Monday, November 29, 2010, Ed Smiley <es...@ebrary.com> wrote:
> Couldn't get that to work....
>
> On Wed, Nov 17, 2010 at 3:54 PM, Ed Smiley <es...@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 <al...@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 <es...@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?
>>> >
>>>
>>
>>
>
Re: Anybody see this?
Posted by Ed Smiley <es...@ebrary.com>.
Couldn't get that to work....
On Wed, Nov 17, 2010 at 3:54 PM, Ed Smiley <es...@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 <al...@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 <es...@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?
>> >
>>
>
>
Re: Anybody see this?
Posted by Ed Smiley <es...@ebrary.com>.
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 <al...@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 <es...@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?
> >
>
Re: Anybody see this?
Posted by Alex Boisvert <al...@gmail.com>.
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 <es...@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?
>