On Fri, 9 Aug 2002, Matt Raible wrote:
> Date: Fri, 9 Aug 2002 22:25:30 -0600
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On
> > Behalf Of Dave Johnson
> > Sent: Friday, August 09, 2002 8:37 PM
> > To: [EMAIL PROTECTED]
> > 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
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/roller-development
> >
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
