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
