Interesting. Both Jörg and you prefer solution 1. That's perfectly fine with me. So if there are no other voices in the next couple of days I shall do the necessary changes next week. It's probably best to dedicate a separate page on the release docs to the topic so it's visible enough.
Thanks for the feedback. On 30.01.2008 22:59:53 Andreas Delmelle wrote: > 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 Jeremias Maerki
