Probably the most common question asked on this list is:
"Are you using one of those @#$%$#$ Tomcats from a third party
distribution?"
The follow-up is always:
"You'll have to get help from the people creating that
distribution."
BTW: On my own CentOS box, I simply ignore the distribution, and use
the download from Apache.
Cheers,
Ken Bowen
On May 22, 2009, at 3:01 PM, Gary Weaver wrote:
Sorry to open up with venting, but I truly cannot believe how big of
a mess that I found of Tomcat's and others' jars under /usr/share/
java in a CentOS 5.2 distribution I examined this morning.
For years I've been using tar.gz'd Tomcat that I downloaded and
applications I used that had standalone installs would provide
similar looking directory layouts of Tomcat. All of those were just
great.
In the RPM'd Tomcat though, the directories are spread out all over
the place (which is acceptable), but from what I've been told, the
backporting of patches and possibly attempts to lower the number of
the same files (jar files in this case) leave you with a ton of
sometimes insane looking symlinks and files.
Here is what I'm talking about in /usr/share/java if you're
unfamiliar:
libgcj-4.1.1.jar
libgcj-4.1.2.jar -> libgcj-4.1.1.jar
libgcj-tools-4.1.1.jar
libgcj-tools-4.1.2.jar -> libgcj-tools-4.1.1.jar
Regardless of how trivial a small change in a version of a jar might
be in one case for one version of an application, since this is a
shared area for jars, you don't know what some other application
would expect out of that jar. And if the person trying to track down
an issue thinks they are using one version of a jar, but it is
really pointed at a different version.
xerces-j2.jar -> xerces-j2-2.7.1.jar
This seems wrong because you can't assume that, just because you are
dependent on a certain jar in one application, the same one would
apply to multiple applications. One app might be built with 2.7.1
and another with 2.7.3 that didn't deprecate some method that it
removed or changed the signature of, and you might not notice that
unless every facet of the jar were tested, and if RedHat or the
Fedora community has enough time to do that, they certainly aren't
spending their time very wisely.
wsdl4j.jar -> qname-1.5.2.jar
This just looks completely wrong, even if they completely merged the
same version of the previous jar into the new one:
and
servletapi5.jar -> tomcat5-servlet-2.4-api-5.5.23.jar
This seems wrong on a new counts here as it is a specific
implementation and specific version paired with a generic jar name
symlink. this one is more excusable than the others though.
I don't fundamentally disagree with things often, but I really don't
agree that this is a good idea, and it is unfortunately one of the
worst messes of jars/dependencies I've seen in my last 10 years as a
Java developer (and I've seen some pretty messed up things).
How and why could someone RPM Tomcat at all if this is the mess that
it falls into?
TIA for any comments, facts, or opinions you can provide,
Gary
Please note that I also just wrote a quick entry about this here
(feel free to comment there if you'd rather, although they shut it
down for comments after a while to avoid blog link spamming):
http://weblogs.java.net/blog/garysweaver/archive/2009/05/peering_into_th.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org