Re: Tomcat 5.0.28 release

[Jess Holle]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]