J2EE and setting the Context Classloader...

So, I'm doing some J2EE work for which I decided to create a BeanShell EJB
analogous to the BshServlet...  In fact I'm going to set them up to work
together so that you can set a flag on the servlet to have it pass the script
over to the EJB for execution in the EJB context if you wish...

Anyway, of course the main headache in deployment of WARs and EARs for testing
is that you need the client side classes for the EJBs and whatever...  which
kind of ruins the fun of just dropping the BeanShell WAR or EAR into the server
for quick testing. 

So I did a little experiment and determined that it's easy to modify the
addClassPath() command to simply create a new URLClassLoader with both the new
path and the existing context classloader as its parent.  Then I set that new
classloader as the context classloader...  Nothing revolutionary there, but it
does work, allowing my scripts to add client jars with addClassPath() within
the J2EE container.

I'm just wondering if there's any reason I should do this all the time in 
BeanShell - i.e. should the BeanShell classloader always set the context
classloader?  Or only inside a J2EE container?

Thread setContextClassLoader() is a public method but has a security check.  I
don't know if common security policies guard this one more than other things we
use.

Any thoughts?

BTW, Weblogic 8.1. no longer suffers from the "old version of BeanShell in the
weblogic.jar" name conflict problem.  You can just drop bsh.jar in your web
apps, etc. and it works.


thanks,
Pat



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn