Hi Jeremias,

Jeremias Maerki wrote:
> Vincent's feedback reminded me about something else we probably should
> look at. Vincent proposed to add a dependency on the Xerces/Xalan XML
> serializer. As noted, I'd prefer to stick to plain JAXP. But yes, with
> Java 1.4 JAXP is built in so the 4 XML JARs are actually not necessary
> anymore (would one think). There are several things we can do:

I guess you’re talking of the following ones:
- serializer-2.7.0.jar
- xalan-2.7.0.jar 
- xercesImpl-2.7.1.jar
- xml-apis-1.3.02.jar

Then what does the xml-apis-ext.jar actually stand for? Obviously it’s 
needed but I’m not clear what it corresponds to. I guess it has nothing 
to do with JAXP?

> 1. Just remove them.
> Good:
> - Makes the distribution a lot smaller.
> Problems:
> - Early Java 1.4 and 1.5 JVMs contain (very) old and buggy JAXP
> implementations. It's a good idea to always replace them (this gets me
> to solution 2).
> - Our test code has a (useful) dependency on Xalan's XPath API. Java 1.4
> provides an old JAXP version without XPath support (javax.xml.xpath,
> available with Java 1.5). So we've got a problem here for the time being.

Note that by removing the 4 aforementioned jars and using a 1.5 jdk 
I have unresolved import errors in the 
org.apache.fop.layoutengine.EvalCheck class. And an “Organize imports” 
in Eclipse gives me com.sun classes. Is that to be expected? The missing 
classes are in the xalan jar. If I add this jar to the build path I then 
have the following error in 
“The type org.w3c.dom.xpath.XPathEvaluator cannot be resolved. It is 
indirectly referenced from required .class files”
I have to add the xml-apis.jar to the build path to solve that error. 
With a 1.6 jdk I don’t have this problem.
Have I missed anything?

> 2. Move the 4 JARs to a lib/endorsed directory and adjust our scripts to
> insert them into the bootclasspath which has the effect of overriding
> the JAXP implementation of the JVM.

I thought the only way to override the JAXP implementation bundled with 
the JVM was to put the jars in the lib/endorsed/ directory of the JVM 

> Good:
> - This also makes it much clearer that these JARs are not a dependency
> like every other.
> Problems:
> - User might wonder why the JARs are suddenly in a different place.
> Open Question:
> - Should we start programming against JAXP 1.3 (because of the XPath API)?
> But that requires that all users install JAXP 1.3 implementations in
> their environments which can be problematic for older application
> servers (like an old WebSphere which is used in many bigger companies).
> I'd say we should stick to JAXP 1.2 until we can move to Java 1.5.
> 3. Remove the implementations but not the xml-apis.jar with the JAXP 1.3
> API.
> Good:
> - Allows us to use the XPath and Validation facilities.
> Problems:
> - Pre-programmed user problems because old JAXP implementations are
> present and people don't know how to replace them or are not allowed to
> replace them or it's a stability danger to the whole application server
> when replacing it once you figure out how to do it.

I would also go with 1., if there is a suitable answer to my question 
above. When releasing the 1.4 versions of FOP we can always add the 
xml-apis.jar ourselves in the lib/ directory to be able to run the 


Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to