Clashing Jars

[princesewani]

Hi All,

Greetings for the day!

Well I'm in the middle of an integration and a jar which I'm to integrate clashes with one that's already present in the framework.
Both have a few common and rest different set of classes. To avoid clash I think of the class load concept,if a same class is loaded with
two different instances of a class-loader then both the instances of the class loaded twice are uniquely identified by the Jvm and the runtime clash
doesn't happen,there's a class that is common between both the jars with the same package hierarchy but the resources for both are different.
I've observed GenericDispatcher it internally uses custom class load concept,but then its just for getting the dispatcher.
Is there some way round this could be dealt?


Regards

Prince

[BJ Freeman]

FYI
there was a script in the ant build some time ago that inflated the jar
in to classes then re-assembled the jar. I think it was in the one of
the framework builds.
this would allow for others to know what was changed in the jar and a
upgrade path in the future.
Also as long as the Jars are not in the SVN, if they are not licensed
properly and you have the code to them, you can always recompile on of
them so the is no conflict.

I would not recommend hard coding jar loading to the level you are
considering.

my 3 cents

Prince Sewani sent the following on 7/12/2011 12:21 AM:

> Hi All,
>
> Greetings for the day!
>
> Well I'm in the middle of an integration and a jar which I'm to integrate clashes with one that's already present in the framework.
> Both have a few common and rest different set of classes. To avoid clash I think of the class load concept,if a same class is loaded with
> two different instances of a class-loader then both the instances of the class loaded twice are uniquely identified by the Jvm and the runtime clash
> doesn't happen,there's a class that is common between both the jars with the same package hierarchy but the resources for both are different.
> I've observed GenericDispatcher it internally uses custom class load concept,but then its just for getting the dispatcher.
> Is there some way round this could be dealt?
>
>
> Regards
>
> Prince
>

[princesewani]

Hi Bj,

Thanks for the prompt response.
Hard-coding jar loading isn't really the option I'm thinking of
and moreover the ant script you mentioned about also doesn't apply to the scenario I have.
Both Jars have a class that is common and it loads classes on runtime using a property

file that again has the same name. So what happens to occur at runtime is in the webapp that I'm working at,
at runtime it swaps the names of the classes to be loaded as obviously framework jars have a priority.

The jar that I'm using is a separate project and inflating,building and combining doesn't sound a good option
as I'm not the one to develop it and it may cause maintenance problems too.

What I'm looking for is that is there some way we can customize that for this webapp the jar lying in the
lib folder shall be loaded first,or shall be the the only one to be referenced.Could something be done for this

or is there an existing work-around,I've been googling around and browsing through jiras but unable to find it.
A little guidance will be of great help.


Regards
Prince



________________________________
From: BJ Freeman <[hidden email]>
To: [hidden email]
Sent: Tuesday, July 12, 2011 1:02 PM
Subject: Re: Clashing Jars

FYI
there was a script in the ant build some time ago that inflated the jar
in to classes then re-assembled the jar. I think it was in the one of
the framework builds.
this would allow for others to know what was changed in the jar and a
upgrade path in the future.
Also as long as the Jars are not in the SVN, if they are not licensed
properly and you have the code to them, you can always recompile on of
them so the is no conflict.

I would not recommend hard coding jar loading to the level you are
considering.

my 3 cents

Prince Sewani sent the following on 7/12/2011 12:21 AM:

> Hi All,
>
> Greetings for the day!
>
> Well I'm in the middle of an integration and a jar which I'm to integrate clashes with one that's already present in the framework.
> Both have a few common and rest different set of classes. To avoid clash I think of the class load concept,if a same class is loaded with
> two different instances of a class-loader then both the instances of the class loaded twice are uniquely identified by the Jvm and the runtime clash
> doesn't happen,there's a class that is common between both the jars with the same package hierarchy but the resources for both are different.
> I've observed GenericDispatcher it internally uses custom class load concept,but then its just for getting the dispatcher.
> Is there some way round this could be dealt?
>
>
> Regards
>
> Prince
>