tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Tomcat 5.0.28 release
Date Thu, 19 Aug 2004 22:49:49 GMT
Overall, JAXP is a very painful thing to those deploying any intensive 
XML or XSLT that might care what implementation is used and not having 
the luxury of dictating this implementation to everything else in the 
JVM.  For instance, JAXP requires a separate classloader to change the 
XML or XSLT implementation used (i.e. to override the meta-inf/services 
entries as needed) -- yet one can't just create one's own classloader 
with a rigid security manager in place (e.g. in an applet).  Even for 
per-JVM manipulation, JAXP requires fairly intrusive screwing with one's 
jars (to remove unwanted meta-inf entries) or command lines or creation 
of endorsed directories.

In the end, I've resorted to using my own static factories to look up 
and instantiate JAXP implementation.  From there on out, the JAXP APIs 
are fairly nice and easy to use, so the result is having only a single 
non-standard line of code per XML or XSLT factory.

--
Jess Holle

Shapira, Yoav wrote:

>Hola,
>
>  
>
>>I must say I don't fully understand the above. So what exactly will
>>happen if the common/endorsed directory is removed? What will stop
>>working and on which platform(s)? Are there any specific pointers to
>>    
>>
>bug
>  
>
>>ids or discussions, that would explain why the endorsed directory was
>>added in the first place? I know configuring the XML parser and JAXP
>>    
>>
>was
>  
>
>>always pain, but I don't know what specifically was the problem. Any
>>insights you can bring into this will be appreciated.
>>    
>>
>
>JDK 1.4 was the first one to include JAXP and an XML parser
>implementation (Crimson) in the JDK itself.  This presented difficulties
>to all container writers, including Tomcat, because they had to jump
>through special hoops to allow user web applications to override the
>parser and JAXP interfaces that shipped with the JDK.
>
>The typical use-case is a user wishing to use Xerces version X, which
>provides new features not available in Crimson and not accessible via
>the JAXP APIs, but relying on new DOM or SAX classes.  The user needs
>both the xml-apis.jar and the xercesImpl.jar from his WAR file to be
>loaded, overriding those in the JDK itself (old JAXP and old Crimson
>parser).
>
>The endorsed classloading mechanism is the approach suggested by Sun and
>adopted by Tomcat.  "Endorsed" means that classes from that repository
>can override those classes with the same name that ship with the JDK.
>The XML parsers are the classic example, but there are others.
>
>Our classloader how-to
>(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
>) and Sun's documentation on the mechanism in general
>(http://java.sun.com/j2se/1.4.2/docs/guide/standards/) contain
>additional explanations.
>
>Yoav Shapira
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message