Board index » jbuilder » JAR conflict in OpenTool with JBuilder's version

JAR conflict in OpenTool with JBuilder's version


2004-09-22 11:18:40 PM
jbuilder18
Hi all,
I'm developing an OpenTool that uses a library that requires the JDom
library version 1.0b8. The problem is that JBuilderX comes with it's own
version of JDom that's a lot older, and is placed on the classpath
before my OpenTool, so in effect all org.jdom.* classes resolve to
JBuilder's version instead of the one I package with my OpenTool.
Is there a way to get around this ?
Thanks for any help,
Regards,
Serge Huber.
 
 

Re:JAR conflict in OpenTool with JBuilder's version

Serge Huber wrote:
Quote
Is there a way to get around this ?
If JBuilder doesn't actually use JDom internally or if your newer
version is backward compatible, you could probably get away with
replacing the one JBuilder uses by putting your newer one in the patch
directory. Of course, the usual caveats apply about how that might
break JBuilder and don't go calling Borland support when it does and so
forth, but that's certainly the easy solution.
The harder approach is to write your own class loader and make sure your
tool and the various libraries it uses (like JDom) are loaded using that
one. You can probably extend URLClassLoader. You'll need to override
some methods so the JDom classes are *not* loaded from the parent class
loader, since that will just get you the older version that you're
trying to get rid of.
Warning: This approach will work (I did it once, though I can't remember
when or why or where the source code is), but it's a bit hackish/klugy.
You'll need to learn more about class loaders than you really want to
know. :-) There are some old articles on the Sun web site that will
help, but at some point you'll probably just find yourself experimenting.
--
Gillmer J. Derge [TeamB]
 

Re:JAR conflict in OpenTool with JBuilder's version

Actually I was thinking about a "worst case implementation" that would
use class loaders, but I was mostly hoping there was an alternative way
of doing it, maybe using .config files for my OpenTool ?
Regards,
Serge Huber.
Gillmer J. Derge [TeamB] wrote:
Quote
Serge Huber wrote:

>Is there a way to get around this ?


If JBuilder doesn't actually use JDom internally or if your newer
version is backward compatible, you could probably get away with
replacing the one JBuilder uses by putting your newer one in the patch
directory. Of course, the usual caveats apply about how that might
break JBuilder and don't go calling Borland support when it does and so
forth, but that's certainly the easy solution.

The harder approach is to write your own class loader and make sure your
tool and the various libraries it uses (like JDom) are loaded using that
one. You can probably extend URLClassLoader. You'll need to override
some methods so the JDom classes are *not* loaded from the parent class
loader, since that will just get you the older version that you're
trying to get rid of.

Warning: This approach will work (I did it once, though I can't remember
when or why or where the source code is), but it's a bit hackish/klugy.
You'll need to learn more about class loaders than you really want to
know. :-) There are some old articles on the Sun web site that will
help, but at some point you'll probably just find yourself experimenting.

 

{smallsort}

Re:JAR conflict in OpenTool with JBuilder's version

Serge Huber wrote:
Quote

Actually I was thinking about a "worst case implementation" that would
use class loaders, but I was mostly hoping there was an alternative way
of doing it, maybe using .config files for my OpenTool ?

The .config file will allow you to alter
Open Tool loading, not class loading.
JDOM is not an Open Tool; it is possibly
used by an Open Tool or two in either the
primetime or jbuilder packages of Open Tools
and therefore classes from the JDOM library
may be loaded. Gill's suggestion of custom
class loading is the only route available to
you, as I see it.
--
Paul Furbacher (TeamB)
Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:JAR conflict in OpenTool with JBuilder's version

Ok thanks Paul,
I'll look into writing a class loader then, I hope I can make it work,
because I will need to access JBuilder's PrimeTime and JBuilder packages
, while prohibiting the other library to use the "root" classloader.
Tricky but I guess I can do it, but I'll have to redesign parts of the
OpenTool.
cheers,
Serge...
Paul Furbacher [TeamB] wrote:
Quote
Serge Huber wrote:

>
>Actually I was thinking about a "worst case implementation" that would
>use class loaders, but I was mostly hoping there was an alternative
>way of doing it, maybe using .config files for my OpenTool ?
>

The .config file will allow you to alter
Open Tool loading, not class loading.
JDOM is not an Open Tool; it is possibly
used by an Open Tool or two in either the
primetime or jbuilder packages of Open Tools
and therefore classes from the JDOM library
may be loaded. Gill's suggestion of custom
class loading is the only route available to
you, as I see it.


 

Re:JAR conflict in OpenTool with JBuilder's version

Ok I experimented yesterday with class loaders, but that didn't solve
the problem. The JAR that's giving me a problem is the JDom JAR that
comes with the Enterprise Edition of JBuilderX. It is an old version of
JDom, and the OpenTool I'm writing uses a library that requires a more
recent version of JDom.
The problem is that JBuilder's JDom JAR is in the root class loader
path. I've tried everything I could figure out with class loaders,
including creating a class loader without any parents that would reload
all the JBuilder JARs but then I ran into problems because I had two
different instances of the JBuilder classes.
The problem is really that class loaders in Java always first go to the
parent to find a class, and in this case the JDom is always loaded from
the root class loader.
If you have any ideas on how to solve this problem I'd be more than
thankful, because I'm out of ideas here.
Regards,
Serge Huber.
Serge Huber wrote:
Quote

Ok thanks Paul,

I'll look into writing a class loader then, I hope I can make it work,
because I will need to access JBuilder's PrimeTime and JBuilder packages
, while prohibiting the other library to use the "root" classloader.

Tricky but I guess I can do it, but I'll have to redesign parts of the
OpenTool.

cheers,
Serge...

Paul Furbacher [TeamB] wrote:

>Serge Huber wrote:
>
>>
>>Actually I was thinking about a "worst case implementation" that
>>would use class loaders, but I was mostly hoping there was an
>>alternative way of doing it, maybe using .config files for my OpenTool ?
>>
>
>The .config file will allow you to alter
>Open Tool loading, not class loading.
>JDOM is not an Open Tool; it is possibly
>used by an Open Tool or two in either the
>primetime or jbuilder packages of Open Tools
>and therefore classes from the JDOM library
>may be loaded. Gill's suggestion of custom
>class loading is the only route available to
>you, as I see it.
>
>
 

Re:JAR conflict in OpenTool with JBuilder's version

Serge Huber wrote:
Quote

Ok I experimented yesterday with class loaders, but that didn't solve
the problem. The JAR that's giving me a problem is the JDom JAR that
comes with the Enterprise Edition of JBuilderX. It is an old version of
JDom, and the OpenTool I'm writing uses a library that requires a more
recent version of JDom.

The problem is that JBuilder's JDom JAR is in the root class loader
path. [...]
Does the following JavaWorld article provide
something you didn't think of?
www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html
In it, the author replaces java.lang.Object.
My guess is that if he can do that, you should
be able to do the same with JDOM.
--
Paul Furbacher (TeamB)
Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:JAR conflict in OpenTool with JBuilder's version

Hmm... Thanks for the resource, I didn't have that one. Despite all this
I'm still stuck with the same problem. With the Java class loader
delegation model, the JDom JAR packaged with JBuilder X Enterprise
Edition always takes priority. And if I try to bypass delegation and
build a class loader "from scratch", I then can't integrate with
JBuilder because I then have two instances of the PrimeTime and JBuilder
classes.
The only solution that seems to work although I don't like it is to
replace the packaged JDom JAR with a more recent version.
This whole problem is very worrying to me because it looks a lot like a
design flaw of the OpenTools system. At some point OpenTools developers
will want to use specific version of JARs and they are bound to run into
the same problem as I have. It is relatively easy to built seperate
class loaders for each OpenTool (actually it's already been done here :
www.jpmcgrath.net/opentools/), but this still doesn't address the
problem of a conflict with a class coming from a PARENT class loader,
only solve the problem between siblings.
One rule of thumb would be to always use the JBuilder JARs as versions
for developing OpenTools, but unfortunately in this specific case, the
version packaged with JBuilder is an old one, that hasn't yet reached
version 1.0, and doesn't support XML entities. As for the OpenTool I'm
developing, the dependency I have on JDom is through a library common to
the MevenIDE project, that integrates Maven (maven.apache.org)
with multiple IDEs, and it seems a little unreasonable to remove support
for entities when the other IDEs don't have a problem working with a
more recent version of JDom.
If anybody has any ideas, suggestions, best practices to share on this
problem they would be more than welcome, because frankly I'm a bit lost
with this issue.
Regards,
Serge Huber.
Paul Furbacher [TeamB] wrote:
Quote
Serge Huber wrote:

>
>Ok I experimented yesterday with class loaders, but that didn't solve
>the problem. The JAR that's giving me a problem is the JDom JAR that
>comes with the Enterprise Edition of JBuilderX. It is an old version
>of JDom, and the OpenTool I'm writing uses a library that requires a
>more recent version of JDom.
>
>The problem is that JBuilder's JDom JAR is in the root class loader
>path. [...]


Does the following JavaWorld article provide
something you didn't think of?

www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html

In it, the author replaces java.lang.Object.
My guess is that if he can do that, you should
be able to do the same with JDOM.


 

Re:JAR conflict in OpenTool with JBuilder's version

I glad to help you. I encounter this problem this summer. It takes 2
days to overcome it.
You have to write some kind of exclusive classloader. You can enforce
using specific version of JARs for you opentool. I use chain of
classloaders.
1. System classloader
2. Filter classloader (inherited from URL classloader)
3. Target classloader (inherited from URL classloader)
Trick is to throw ClassNotFound exception in Filter classloader in case
you find out that class from your library is loading.
I collect all names of classes from libraries which I want to use my
own and don't let system classloader handle these loads by throwing
ClassNotFound exception in Filter classloader.
Target classloader in this case gets a chance to load class from urls
you provide to it.
Beware(!): Then you use threads you probably be forced to set Target
classloader as CurrentThread classloader, because thread uses system
classloader as current and you will fail in attempt to cast variables
of one class loaded by different classloaders.
more information about classloaders
www.javaworld.com/javaworld/jw-03-2000/jw-03-classload.html
www.javaworld.com/javaworld/javaqa/2003-03/01-qa-0314-forname.html