RE: webapps' classpath

2001-10-18 Thread E B

I think I can get around this problem by moving
to tomcat 4. There seems to be a shared classloader
for all the webapps. But I am wondering if other
app servers also support tomcat-4's classloading
structure, otherwise my app will become tc4-only.

 --- Brendan Johnston [EMAIL PROTECTED] wrote: 
Theoretically when a class wants to load a class it
 asks its own classloader
 to do it.
 Its own classloader then asks its parent to do it
 and if its parent can't it
 tries.
 
 Some concept of how to work around this might be:
 
 1. Have a factory class that return the instances
 you want in A1 (therefore
 A1 classloader)
 
 2. Register the factory it in some collection that
 the soap classloader can
 see (potentially create some factory registry and
 load it with the
 application servers classloader)
 
 3. Call methods on the factory to get instances
 
 I have not tested this I may have missed something,
 and don't recommend this complex approach.
 
 I think the answer in your case is to
 have fewer (one) web applications.
 
 Brendan
 
 
 
 
 -Original Message-
 From: E B [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 15, 2001 11:34 PM
 To: [EMAIL PROTECTED]
 Subject: RE: webapps' classpath
 
 
 So that means there are two classloaders:
 soap's and the other webapps's (in my case A1).
 now when the contol goes from soap to
 A1's class, which class loader loads the 
 classes of A1. ?
 Can I make A1's classloader come into picture
 and take over things ?
 
 
  --- Brendan Johnston [EMAIL PROTECTED] wrote: 
 Each Web Application gets its own private class
  loader.
  A class loader can only see classes
 loaded/loadable
  by it and by its
  parents.
  The Two Web Applications are siblings, independant
  from each other.
  
  I think you should give each WebApplication a
  complete set of its own
  classes so that you can upgrade each
 independantly.
  
  Brendan
   
  
  -Original Message-
  From: E B
  To: [EMAIL PROTECTED]
  Sent: 10/15/01 9:04 PM
  Subject: webapps' classpath
  
  I am using apache soap 2.2 with tomcat 3.2.1.
  There seem to be 2 classpaths, one tomcat's
  and the other webappp's WEB-INF/classes.
  For a SOAP service class, which of these two
  is visible first ?
  which of the two is recommended and why ?
  
  I have two web-app's: A1 and A2. (A2 is soap).
  I want to refer A1's objects in A2's class.
  But A1's classes are not visible to A2. why ?
  I had to put A1's classes in tomcat's classpath
  to get it working.
  
  thanks.
  
  
  
 


  Do You Yahoo!?
  Get your free @yahoo.co.uk address at
  http://mail.yahoo.co.uk
  or your free @yahoo.ie address at
  http://mail.yahoo.ie
   
 


 Do You Yahoo!?
 Get your free @yahoo.co.uk address at
 http://mail.yahoo.co.uk
 or your free @yahoo.ie address at
 http://mail.yahoo.ie
  


Nokia Game is on again. 
Go to http://uk.yahoo.com/nokiagame/ and join the new
all media adventure before November 3rd.



RE: webapps' classpath

2001-10-18 Thread Craig R. McClanahan



On Thu, 18 Oct 2001, E B wrote:

 Date: Thu, 18 Oct 2001 09:52:50 +0100 (BST)
 From: E B [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED],
  [EMAIL PROTECTED]
 Cc: 'E B' [EMAIL PROTECTED]
 Subject: RE: webapps' classpath

 I think I can get around this problem by moving
 to tomcat 4. There seems to be a shared classloader
 for all the webapps. But I am wondering if other
 app servers also support tomcat-4's classloading
 structure, otherwise my app will become tc4-only.


All servlet containers that support the 2.2 or 2.3 specification are
required to provide a separate classloader per web application.  The
availability of a shared JAR mechanism is not required by the spec, but is
very commonly implemented.

In a servlet 2.3 environment, the following additional notes are relevant:

* There is a SHOULD statement in the specification with
  regards to checking in the webapp's class loader first
  before checking higher up the class loader hierarchy.
  Tomcat 4 implements this SHOULD (although you can turn
  it off if you want to), but I don't know how others are
  handling it.

* Web applications can count on the Thread context class loader
  being set to the webapp's class loader.  This means that, in
  library code that *is* loaded from a shared classloader,
  you can still load application classes from the webapp
  class loader if you take steps like this:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
Class clazz = cl.loadClass(... classname ...);

Craig McClanahan