ClassLoader question

[Kathey Marsden <km...@sbcglobal.net>]

I have really just a general java  question and not sure where to send
it, so I thought I would try here. 

In these days of reusable components, it is hard to manage and protect
one component from another.  If I have foo.jar it might be used
multiple  times within the same JVM.  For example

PRODUCT A
    uses foo.jar v3.0
    uses component B

COMPONENT B
    uses foo.jar v2.1

I was wondering if anyone could point me to some good resources on 
programming practices and examples to make sure that both PRODUCT A and
COMPONENT B use their own version of foo.jar and don't accidentally just
load one or the other as would happen if the classpath was used.  I
assume such a thing would require ClassLoaders, but that is the extent
of my knowledge.

Thanks

Kathey

Re: ClassLoader question

[Kathey Marsden <km...@sbcglobal.net>]

Berin Loritsch wrote:

>The best resource I can think of would be Java Security by Scott Oaks 
>published by O'Reilly (ISBN: 0-596-00157-6).
>
>  
>
Thanks for the pointer and the heads up on what I am in for.   The right
book  to start with can make all the difference.


Kathey

Re: ClassLoader question

[Berin Loritsch <bl...@d-haven.org>]

On Friday 28 October 2005 5:08 pm, Kathey Marsden wrote:
> I have really just a general java  question and not sure where to send
> it, so I thought I would try here.
>
> In these days of reusable components, it is hard to manage and protect
> one component from another.  If I have foo.jar it might be used
> multiple  times within the same JVM.  For example
>
> PRODUCT A
>     uses foo.jar v3.0
>     uses component B
>
> COMPONENT B
>     uses foo.jar v2.1
>
> I was wondering if anyone could point me to some good resources on
> programming practices and examples to make sure that both PRODUCT A and
> COMPONENT B use their own version of foo.jar and don't accidentally just
> load one or the other as would happen if the classpath was used.  I
> assume such a thing would require ClassLoaders, but that is the extent
> of my knowledge.
>

The best resource I can think of would be Java Security by Scott Oaks 
published by O'Reilly (ISBN: 0-596-00157-6).

The short answer is that you would need a classloader hierarchy.  The base 
classloader has whatever classes are common to all the other classloaders 
(i.e. interfaces, core Java classes, etc.).  The child classloaders would 
have the implementation classes for your components, and any dependencies 
that they need to operate.  The interfaces need to be in the parent 
classloader so you can wire everything together--there are several gotchas 
when you are playing with classloaders.

Due to to complexity of the topic, I would recommend curling up with that book 
and try a few things yourself.  Classloaders and the Java Security Model 
(which is where the real enforcement happens) are not easy to understand.  It 
took me a few months to get a basic understanding of it--and I can't say that 
I have more than just a basic understanding.  I find that when I experiment 
is when I get those "aha!" moments.

Re: ClassLoader question

[Shane Curcuru <as...@shanecurcuru.org>]

Googling "Java ClassLoader Security example" shows a few good articles 
on the general subject as well.  One decent one (a little involved) is:
http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html

If you want a real-life example of an environment that implements this 
kind of thing, go to eclipse.org.  The plugin architecture of Eclipse is 
much like you describe, with each set of plugins having their own 
classpaths (and ClassLoaders).  There's plenty of examples there for you 
to see - unfortunately, the documentation may be a bit complex to wade 
through...

Note: Be sure to check which Java version you're using - Classloader 
semantics change significantly with different JVM versions.

- Shane