On Wed, 12 Jun 2002, Joseph Barefoot wrote:

> Date: Wed, 12 Jun 2002 12:40:22 -0700
> From: Joseph Barefoot <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
>      [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: deploying in jboss 3
>
> > 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);
>
> Thanks for the insight Craig, makes sense, however:  Why not just put the
> struts.jar into /WEB-INF/lib to avoid this issue?  That way, the
> ActionServlet will be loaded by the webapp class loader and not by the
> parent(shared) class loader, so no problems, correct?
>

In 1.0, this is the only practical choice and is the recommended approach.
In 1.1, you can share struts.jar across multiple Struts webapps if you
want.

> Done this way, I suppose you could even use two different versions of Struts
> in 2 different web apps.  I can also see why you might want struts.jar
> shared though -- if you have two web apps. both using the same version of
> Struts, you don't want to load all the classes twice.  This seems to be the
> only scenario where putting struts.jar into a shared class loader makes
> sense.  Am I missing something here?
>

No, that is *exactly* the motivation for trying to share a single copy of
struts.jar.  The unfortunate thing is that it won't work in 1.0, but will
in 1.1.

Craig


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

Reply via email to