tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [PATCH] TC 4.0 build patch - not a joke
Date Thu, 13 Sep 2001 15:36:47 GMT

On Thu, 13 Sep 2001, GOMEZ Henri wrote:

> Date: Thu, 13 Sep 2001 11:44:19 +0200
> From: GOMEZ Henri <>
> Reply-To:
> To:
> Subject: RE: [PATCH] TC 4.0 build patch - not a joke
> Hi Craig and others in USA,
> First, I make a point of presenting to you all
> my condolences for the tragedy which struck
> the USA, Tuesday last.


For those of you who don't know, Sun had an office on the 25th and 26th
floor of WTC #2, housing about 350 employees.  Thankfully, all of them
have been accounted for -- but a Sun manager was on one of the hijacked
planes from Boston.

> >Henri,
> >
> >I'm not necessarily opposed to this patch -- just want to
> >understand it a
> >little better.  Basically, it looks like you are trying to do the
> >following (my comments interspersed in indented paragraphs):
> >
> >* Declare "foo.lib" properties for all of the actual directories
> >  in which the JAR files would be found.
> >
> >    I presume this is the thing your RPM build
> >    script would be customizing, right?
> Exact. For your information, the consensus on Linux Boxes,
> Debian, Redhat, Mandrake, Suse, is to put ALL the jar jars
> in /usr/share/java/
> So all the TC 4.0 required stuff is installed in
> /usr/share/java/
> And when we package a RPM we indicate that to build TC 4.0
> for example, we need JSSE, JAVAMAIL... which all lives in
> /usr/share/java/

How does the RPM packaging deal with the fact that different JAR files
need to be loaded into different class loaders?  If they are all under
"/usr/share/java", I don't see how that can work.

How does the RPM packaging deal with the fact that you might want to use
different XML parsers inside Catalina (i.e. from serverl/lib) or in
webapps (from lib)?

> >* Declare the "foo.jar" properties based on "foo.lib" settings
> >
> >    A logical consequence of the previous goal, but ...
> >
> >* Remove declarations and uses of any "foo.home"
> >  properties that currently exist.
> >
> >    This one I have some heartburn with, because
> >    it breaks backwards compatibility with environments
> >    that depend on this approach (which is also used in
> >    several other projects at Jakarta and elsewhere).
> >
> >* Add support for JSSE jar files using the standard approach
> >
> >    I haven't caught up on the email thread and/or patches
> >    about this, but agree in principle that it should follow
> >    the same conventions as for other JAR dependencies.
> >
> >Can we think of a way to accomplish what you would like for RPMs that
> >does *not* create backwards incompatibilities?  How about a three-layer
> >model like this (for a package with JARs in the "home" directory):
> >
> >    <property name="activation.home"    value="/usr/local/jaf-1.0.1"/>
> >    <property name="activation.lib"     value="${activation.home}"/>
> >    <property name="activation.jar"
> >       value="${activation.lib}/activation.jar"/>
> Ok for me that way.

OK, I will go ahead and modify the build scripts to follow this pattern.

> >or like this for something with a nested "lib" directory:
> >
> >    <property name="jsse.home"          value="/usr/local/jsse-1.0.2"/>
> >    <property name="jsse.lib"           value="${jsse.home}/lib"/>
> >    <property name="jcert.jar"          value="${jsse.lib}/jcert.jar"/>
> >That way, you could override at *any* of the three levels, without
> >breaking old scripts that rely on the "foo.home" approach.
> >
> >What do you think?
> Ok for me also like this, since I could override jsse.lib in command
> line. We want to avoid having to patch all the build.xml.
> I fully agree, but we'll need also another modification since
> in catalina build you grab every .jar in for regexp and when
> regexp is in /usr/share/java/, you copy just ALL system jars !!!
> In my case not less that 80 jar (regexp, oro, jtopen, .....)

I did a separate patch to catalina.bat/ that specifically adds
the JSSE classes.

For Regexp, if Jon would remove the version number from the JAR file I
wouldn't have to do that :-).  Of all the dependencies in Tomcat, this is
the *only* project that does versioning in the JAR file name.

> A another addon, be naming the name :
>  <property name=""          value="jakarta-regexp-1.2.jar"/>

I'll make sure I cover that one too.


View raw message