On Thu, 13 Sep 2001, GOMEZ Henri wrote:
> Date: Thu, 13 Sep 2001 11:44:19 +0200
> From: GOMEZ Henri <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> 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.
>
Thanks.
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/catalina.sh 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="regexp.name" value="jakarta-regexp-1.2.jar"/>
>
I'll make sure I cover that one too.
Craig
