On Jan 30, 2008, at 14:46, 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:

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.

If this were a vote, I'd vote a big +1 for this, but it would have to be properly announced and reflected in the documentation. The reason is educational, in that interested newbies will more clearly see what part of the processing is handled by FOP, and where the XML parser and XSLT processor --of *their* choice-- kick in.

At first, we're bound to get a lot of questions in this area --mostly from people who don't read the docs before asking ;-)
OTOH, later on, we might get less XSLT-related questions... (?)

The dependency of the test code on JAXP 1.3 is not problematic, because it is limited to FOP-devs, whom I assume to be able to have no problem with setting up their own environment. Buggy JAXP implementations are IMO not really an issue either, since this does not only affect FOP, but all JAXP applications. These should be overridden at the highest possible level: either upgrade the entire JVM to a more recent build, if possible, or use the endorsed standards mechanism to override them system-wide.

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.

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.

This is, IIC, more or less what Apache Tomcat does. Although a very interesting suggestion, I'm still leaning towards the first option. Tomcat is a different beast, since it is designed to run multiple Java applications concurrently, and so allows to override this in one place for all servlets. Still makes sense here. Allowing endorsed overrides on the level of the servlet container still permits one to run multiple instances of Tomcat on the same machine, each with different sets of global libraries. For FOP, this could maybe be used as a transitional measure, to draw the users' attention to the fact that these are indeed 'special' libraries, but then we might as well skip that step, and remove them altogether. While this makes it easier for the command-line/script users, in application server environments, however... Suppose /every/ XML application that runs on the server, comes bundled with its own JAXP libraries, that all contain basically identical implementations. This looks like a redundancy.

Ideally, 10 different servlets using FOP should all be sharing the same fop.jar. In practice, it could very well turn out that 10 developers each added their own fop.jar to their servlet's lib-directory, which would result in 10 times the very same versions of our libraries, and the best part is that they're not used (or may even cause problems) if the container runs in a JVM that has them bootstrapped... :)

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.

Agreed. See also above: no problem in the test code, since this does not affect plain users.

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.

Indeed not an option, and unnecessary as long as we're targeting 1.4

I guess it's clear that only solution 2 makes sense if we want to change something. And that would be revisited once we move to Java 1.5. Have I
missed something?

I don't think so, but I would be inclined to not wait-and-revisit, but remove-and-document.


Cheers

Andreas

Reply via email to