On Tue, 11 Jun 2002, Gary Struthers wrote:

> Date: Tue, 11 Jun 2002 18:01:58 -0700
> From: Gary Struthers <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: deploying in jboss 3
>
> James Ward wrote:
>
> >I am actually using 1.1B1, but It shouldn't make a difference.  When you
> >are running the example wars that come with struts make sure you do NOT
> >have the struts.jar anywhere in JBoss's classloader (ie. deploy or any
> >lib dirs).  This will mess things up.
> >
> >-James
> >
> >
> Why will it mess things up? JBoss 3 has a unified class loader which is
> meant to solve problems  caused by classes being differentiated by their
> class loader.
>

This *definitely* matters ... Tomcat 4 has the same multi-class-loader
architecture, and you'll experience the same sorts of issues.  If you're
using Struts 1.0.x, you can pretty much guarantee that you will have class
not found issues if struts.jar is in a shared class loader.  Struts 1.1b1
has changes that should address this, so it should work.

The basic problem is that classes loaded from a parent (shared) class
loader cannot directly see any classes loaded from your webapp class
loader (i.e. /WEB-INF/classes and /WEB-INF/lib).  So, for example, if the
Struts ActionServlet was loaded from the parent, and your form bean class
is defined in /WEB-INF/classes, Struts will have problems when it tries to
execute:

  Class formBeanClass =
    this.getClass().getClassLoader().loadClass(formBeanClassName);

In Struts 1.1, the workaround is based upon a promise by the container to
supply a reference to the webapp class loader that can be accessed by
shared classes.  This promise is a requirement in Servlet 2.3, but is
widely implemented on Servlet 2.2 containers -- and makes the following
code work, even in the scenario we are talking about here:

  WebappClassLoader cl =
   Thread.currentThread().getContextClassLoader();
  Class formBeanClass = cl.loadClass(formBeanClassName);


> Gary

Craig



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to