On 31.01.2008 12:49:57 Vincent Hennebert wrote:
> 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?

DOM interfaces for SVG, SMIL etc.. They're not part of JAXP like other
DOM interfaces.

BTW, xml-apis-1.3.02.jar contains the the DOM Level 3 APIs (including
XPath support) which represents a superset of JAXP 1.4.

> > 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 
> org.apache.fop.image.loader.batik.PreloaderSVG:
> “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?

No, I have. Batik 1.7 works with a Level 3 DOM which is not even in Java
6 (only javax.xml.xpath is in JAXP 1.4 and therefore in Java 6). Batik's
AbstractDocument implements the Level 3 XPathEvaluator and provides the
functionality through Xalan-J. I think this is used for SVG 1.2

See also:

That means that as long as we have Batik as a mandatory dependency [1]
on our core we also have a dependency on DOM Level 3 and Xalan-J which
means we cannot remove any of the 4 JARs, except xerces.jar probably
which doesn't really have a big effect in itself. Hehe. We're back to my
solution 2 (or the status quo). And it would mean we can simply use
javax.xml.xpath as we like.

Note that it's probably not necessary to always put those JARs in the
bootclasspath (or lib/endorsed) just to make FOP/Batik work. Otherwise,
we'd already have many more questions about failing XML processing.

[1] Making Batik an optional dependency on FOP has been the wish of some
users in the past (but not recently). It's something I'd like to see if
only to enforce a cleaner design in FOP. But since I know many here
prefer a single source tree for all sources rather than splitting FOP
into more modules, I haven't pushed this. I'm not sure what this would
mean for user with limited knowledge of Java if they have to deal with
different classpath requirements depending on whether they use SVG or
not. And for building the plug-ins all the JARs will need to be there
anyway (or downloaded via Apache Ivy).

> > 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 
> installation?

Nono, -Xbootclasspath/p:<myjars> is another.

> > 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 
> tests.

1 does not seem to be possible at the moment due what you uncovered.

Jeremias Maerki

Reply via email to