Re: The Context Classpath: Getting Java to see our added classpath.

<BrainDump>

This ClassCastException is actually a desired behavior inside the JVM
because 2 classes with identical names, loaded by different classloaders
could technically have entirely different methods, fields, etc..

In a multiple classloader situation, the only way I know of to cast
between classes loaded in 2 different classloaders is to create an
interface that both classes with the same names implement, but that is
loaded by the root classloader that both implementing classes have in
common, and then cast the objects to that interface. The alternative is
lots of reflection code.

</BrainDump>

Is it possible that these data objects are each being loaded separately
by different classloaders? or is it possible that your new classloader
doesn't have the system classloader set as it's parent classloader?

Clint

On Thu, 2004-02-12 at 12:47, David Ward wrote:
> Pat,
> 
> I've seen the ClassCastException you're talking about.  I don't know *exactly*
> why it happens, but if it provides any insight, two Classes are only equal if
> they have the same name *and* came from the same ClassLoader.
> 
> Also, though I like the idea of the new command addContextClassPath(String), I'm
> wary about having it turn into the default.  As you stated, not all java code
> respects the thread context classloader.  I'm also not sure if containers like
> weblogic, tomcat, jboss, etc. will assume that since *they* originally set the
> context classloader (via interceptors of some kind), they they should be able to
> pull it out at any time later and cast it back to their own specific impl.  The
> code in your sample bsh would break that.  I know it would be a bad assumption
> on their part, but still...
> 
> David
> 
> 
> Mensaje citado por Pat <[email protected]>:
> 
> > You may have noticed that when adding classes using addClassPath() those
> > classes aren't available to external Java code that you invoke from your
> > BeanShell scripts.  They are effectively local to the script itself.
> > 
> > I've been experimenting with a version of the addClassPath() command that
> > adds classpath to the current thread's context classloader.  This is the
> > general mechanism in Java that allows system and framework classes to see
> > classes loaded by application specific classloaders.  For example, it allows
> > a
> > J2EE container to work with classes supplied in an EAR or WAR.
> > 
> > BeanShell has for a long time *read* from the context classloader in order
> > to
> > see classes provided by applications, but it has not previously *set* the
> > context classloader with its own classpath extensions.  This has meant that
> > added classes could be referred to in BeanShell scripts, but would not be
> > seen
> > by Java code called by those scripts.
> > 
> > The example below shows a simple EJB lookup requiring the Weblogic JNDI
> > factory
> > and some application classes in an EJB client jar.  This script adds the
> > weblogic.jar and client jar to the classpath and works without any external
> > classpath being provided:
> > 
> >   import javax.naming.*;
> > 
> >   addContextClassPath("/home/pat/weblogic.jar");
> >   addContextClassPath("/home/pat/ejb-client.jar");
> > 
> >   // Lookup JNDI context using the Weblogic factory
> >   String initialContextFactory = "weblogic.jndi.WLInitialContextFactory";
> >   String localContextURL = "t3://172.16.75.139:7001";
> >   Properties p = new Properties(); 
> >   p.put( Context.INITIAL_CONTEXT_FACTORY, initialContextFactory );
> >   p.put( Context.PROVIDER_URL, localContextURL );
> >   ctx = new InitialContext(p);
> > 
> >   // Look up an EJB requiring the ejb-client classes to be seen by Weblogic
> >   home = ctx.lookup ("MyEJB");
> >   bean = home.create(); 
> >   bean.test();
> > 
> > Using the current addClassPath() command BeanShell would be able to see the
> > added classes, but system classes - for example InitialContext - would not
> > and
> > so it would fail to load the weblogic JNDI factory.  Similarly, weblogic
> > would
> > not be able to see the necessary EJB home class without the context
> > classpath.
> > 
> > I expected this new command to make it easier to do testing using the
> > BeanShell
> > Servlet... being able to add client jars directly in the script rather than
> > having to deploy the bsh servlet with every app you want to test.  However
> > I'm
> > getting a ClassCastException that I can't explain when data objects are
> > passed
> > between the two classloaders.
> > 
> > Anyway, for your amusement I've attached a copy of the new command if
> > anyone
> > wants to experiment.
> > 
> > At minimum I will add this as a new command in an upcoming release.  If it
> > proves to be generally useful and harmless I may make this the default
> > functionality of addClassPath().
> > 
> > Note that this doesn't solve the problem entirely, as not all Java code
> > obeys
> > the context classloader.  For example, code that calls Class.forName()
> > directly
> > will not see our added classpath unless we load both BeanShell and the
> > application through our own classloader and this is something I plan to
> > provide
> > a means for later.  I'm not sure why Sun doesn't have Class.forName() defer
> > to
> > the context classloader if no class is found.  There must be a reason.
> > 
> > 
> > Thanks,
> > Pat
> > 
> > 
> 
> 
> ---------------------
> David Ward
> [email protected]
> http://www.dotech.com
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Beanshell-developers mailing list
> Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/beanshell-developers
> 



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click