struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: [Roller-development] Ant file oddity
Date Sat, 10 Aug 2002 04:53:52 GMT


On Fri, 9 Aug 2002, Matt Raible wrote:

> Date: Fri, 9 Aug 2002 22:25:30 -0600
> From: Matt Raible <matt@raibledesigns.com>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: roller-development@lists.sourceforge.net
> Cc: struts-dev@jakarta.apache.org
> Subject: RE: [Roller-development] Ant file oddity
>
> Struts Dev Team - please verify my hypothesis below.
>
> I believe the Struts JARs and the DBCP JARs from common should be the
> same.  After all, Struts does use the DBCP in it's distribution.  You
> might want to upgrade to the latest build of Struts (which includes DBCP
> and Logging, among others).  I know they're planning on releasing 1.1
> Beta 2 this weekend.
>

The story is somewhat convoluted (I *hate* class loaders :-), but it goes
like this:

If you are going to use a JNDI datasource, then both your webapp AND
Tomcat need to see the same copy of the JDBC driver and the dbcp classes
(for 4.1.x) -- and the way to make that happen is to put the driver into
common/lib.

Because commons-dbcp.jar is there, it's dependent jars (such as
commons-collections.jar, jdbc2_0-stdext.jar, and (recently added)
commons-lang.jar) need to be in common/lib as well.  Plus, of course,
jndi.jar if you're on a 1.2 system.

Having any of these JARs duplicated inside the webapp causes a problem in
4.x based systems, because they try to use the local copy first -- and a
copy if foo.bar.MyClass loaded from the webapp is *not* the same class as
a copy of foo.bar.MyClass loaded from common/lib.  This is a place where
Tomcat's modified class loader model causes grief (but only because you're
trying to use the same classes that Tomcat internally is trying to use --
if you were using something like GenericDataSource with your own copy of
the connection pool, it would not be a problem).

One workaround for this would be to try turning off the modified loader
delegation model, by putting something like this in your server.xml file
(or in a context configuration file on Tomcat 4.1.x.):

  <Context path="/myapp" ...>
    <Loader delegate="false"/>
  </Context>

This *should* let you have a copy of all the JAR files inside your webapp,
as well as in common/lib, but not cause any conflicts.

Please let me know, one way or the other, if this works -- it's clearly a
desireable goal that you can ship a WAR file with all the included commons
JARs but not have problems like this.  I want to review how Tomcat's
default configuration can make this easier.  And, from a Struts
application perspective (not just for Roller), this is a pretty serious
usability issue.

> HTH,
>
> Matt
>

Craig McClanahan

PS:  In Tomcat 4.1.x, the "deploy" command of the manager app lets you
include a context configuration file in the WAR, at location
"META-INF/context.xml".  So it might still be possible to configure a
single WAR that works correctly in Tomcat 4.1.x and still works in other
servers (that would obviously ignore such a file).



> > -----Original Message-----
> > From: roller-development-admin@lists.sourceforge.net
> > [mailto:roller-development-admin@lists.sourceforge.net] On
> > Behalf Of Dave Johnson
> > Sent: Friday, August 09, 2002 8:37 PM
> > To: roller-development@lists.sourceforge.net
> > Subject: Re: [Roller-development] Ant file oddity
> >
> >
> > Hi Simon,
> >
> > Simon Stewart wrote:
> >
> > >From a preliminary poke about and looking at the installation
> > >instructions, I'm a little nervous about the dependencies on the
> > >extra-jars. Is there any reason in particular that they need to be
> > >placed into tomcat's common/lib directory?
> > >
> > >
> > I would like to have all of the Roller jars inside the Roller
> > WEB-INF/lib directory, but after some experimentation my current
> > thinking is:
> >
> > 1) even though the JNDI datasource is configured inside the Roller
> > context in server.xml, Tomcat still seems to need the DBCP
> > and JDBC jars
> > in the common classpath.  Maybe this is a Tomcat bug?
> >
> > 2) the commons jars needed for DBCP and the commons jars needed for
> > Struts 1.1b are not compatible and are not interchangable.
> > So we need
> > to put the DBCP compatible commons jars in common/lib where they are
> > used for Datasource creation and the Struts compabible
> > commons jars in
> > WEB-INF/lib.
> >
> > I'm not totally sure about either of these conclusions.
> > Perhaps getting
> > the most recent commons DBCP, pool, and collections jars
> > would solve #2
> > and perhaps #1 is just operator error on my part.
> >
> > >Would an entry in the manifest classpath of the ear (or even in a
> > >roller.war) be a sensible alternative? When it comes to packing up
> > >the EAR, that might be neater.
> > >
> >
> > I don't think you can do that in an EAR or a WAR.  I don't remember
> > seeing that in the J2EE specs, but as always - I could be wrong.
> >
> > - Dave
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Roller-development mailing list
> > Roller-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/roller-development
> >
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message