MG>Good Afternoon Gary
MG>(hopefully brief) comment annotations displayed below
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Fri, 22 May 2009 15:01:37 -0400
> From: gary.wea...@duke.edu
> To: users@tomcat.apache.org
> Subject: Peering into the pit of jar hell - the mess of tomcat's and other
> jars in RPM distributions
>
> 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
MG>what is qname? who builds qname? a quick glance at wsdl4j build.xml
contains:
MG><jar jarfile="${build.lib}/qname.jar" basedir="${build.dest}">
MG> <include name="javax/xml/**/*.class"/>
MG>who in wsdl4j references wsdl4j?
MG>%WSDL4J_HOME%\src\javax>grep -S -l wsdl4j *.*
MG> .\wsdl\OperationType.java
MG>only 1 reference here and thats a comment
MG>that means qname is now the DRIVER (and wsdl4j is supporting library)
MG>/* The following equals method is not used within wsdl4j but
MG> * it is historically part of the jsr110 wsdl4j API, so it
MG> * will not likely be removed. Although it overloads the
MG> * Object.equals method (i.e. it has a different arg) it does
MG> * not override it, so Object.equals will still be used by
MG> * the readResolve method at deserialization.
MG> */
MG>
MG>what is wsdl4j? who builds wsdl4j? a quick glance at wsdl4j build.xml
contains:
MG><jar jarfile="${build.lib}/${name}.jar" basedir="${build.dest}">
MG> <exclude name="javax/xml/**"/>
MG>a quick hop to the ibm code tree and a grep on qname displays
MG>%WSDL4J_HOME%\src\com>grep -S -l qname *.*
MG>.\ibm\wsdl\AbstractWSDLElement.java
MG>.\ibm\wsdl\DefinitionImpl.java
MG>.\ibm\wsdl\extensions\schema\SchemaConstants.java
MG>.\ibm\wsdl\util\xml\QNameUtils.java
MG>.\ibm\wsdl\xml\WSDLReaderImpl.java
MG>as you can see wsdl4j functions are empty stubs that call to qname for real
work
MG>(the justification for symlink alias of wsdl4j.jar -> qname-1.5.2.jar is
validated)
> 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
>
_________________________________________________________________
Hotmail® goes with you.
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009
