Re: Feedback on Processing Feedback
Hi Andreas, Jeremias, Andreas Delmelle wrote: snip/ [Vincent:] Using a TransformerFactory just to serialize data into an XML file may sound a bit weird (this has nothing to do with XSLT). It appears that Xerces defines an XMLSerializer class dedicated to that. snip / It's not weird at all, if you look at what is needed to serialize your data into a different format --possibly non-XML. Using the XMLSerializer, you would either: a) need a different sort of Serializer (properietary?) b) if the target is still XML, you /could/ add an XSLT step before the serialization Now, looking at it this way, why not simply use an identity Transformer to begin with. If your output target changes, all you need to do is write a stylesheet (which is much simpler than implementing your own Serializer), and alter one or two lines of Java code (some more if you also want the stylesheet to be pluggable). Thanks for the links and explanations. I tended to find the XMLSerializer idea quite elegant, but indeed this is not a very big deal to use TrAX (I guess the creation of the TransformerHandler can be encapsulated anyway), and also probably more flexible. Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: What to do with the XML JARs?
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 Yes. 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 functionality. See also: http://svn.apache.org/viewvc?view=revrevision=201418 http://wiki.apache.org/xmlgraphics-batik/UsingDOM3 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
Re: What to do with the XML JARs?
I guess I don't completely understand why it's better to move away from the status quo (if it's not broken don't 'fix' it) and increase (IMHO) complexity. IMO it's not enough to say 'it'll make better, more knowledgeable FOP users' (to paraphrase ;-). I'd need measurable--or at least--obvious benefits. If Java experts can't easily override our versions, that may be enough impetus. But if they can, then my 'vote' would be a fat -0... Tnot a veto)... I would think it'd be better to wait for a separation of Batik dependencies, or some compelling reason. Web Maestro Clay On 1/31/08, Jeremias Maerki [EMAIL PROTECTED] wrote: 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 Yes. 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 functionality. See also: http://svn.apache.org/viewvc?view=revrevision=201418 http://wiki.apache.org/xmlgraphics-batik/UsingDOM3 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
Re: What to do with the XML JARs?
Thanks Jeremias. There are two different aspects I think: - we used to provide JAXP for the convenience of Java 1.3 users. Now that we have moved to Java 1.4 there is no reason anymore to provide it. As Andreas said, buggy implementations bundled with early versions of Java 1.4 or 1.5 is not really our problem. I may be wrong, but I assume that “standalone” users (those running FOP on their own machine for private-like project) will always have a reasonably recent version of Java, and will be happy to be told to upgrade anyway if they have any problem. While power users setting up FOP in a server-like environment are already aware of those early JAXP issues and know how to handle them. Which means we forget any endorsed mechanism. - for the rest I consider the following: FOP appears to have dependencies which are simply not in the Java 1.4 Standard Library. Just like any other dependency they will be put in the lib/ directory and added to the classpath. They won’t affect the JAXP implementation bundled with the JVM. It just appears that the classes in the org.w3c.dom.xpath package are available in later versions of JAXP, but we forget that and this will be transparent to the user: those using Java 1.4 and 1.5 will find those classes in the xml-apis.jar, those using later versions will get them through their JAXP implementations. Once we switch to Java 1.7 (or whichever includes them in the standard library) as a minimal requirement, we remove the xalan.jar and xml-apis.jar, and we switch the org.apache.xpath namespace to javax.xml.xpath. Which means for today that we remove the no longer necessary serializer.jar and xercesImpl.jar and we keep the other ones. Solution 1, amended. I hope I’m clear. WDYT? Vincent Jeremias Maerki wrote: 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 Yes. 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 functionality. See also: http://svn.apache.org/viewvc?view=revrevision=201418 http://wiki.apache.org/xmlgraphics-batik/UsingDOM3 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
Re: What to do with the XML JARs?
Thanks Jeremias. There are two different aspects I think: - we used to provide JAXP for the convenience of Java 1.3 users. Now that we have moved to Java 1.4 there is no reason anymore to provide it. As Andreas said, buggy implementations bundled with early versions of Java 1.4 or 1.5 is not really our problem. I may be wrong, but I assume that “standalone” users (those running FOP on their own machine for private-like project) will always have a reasonably recent version of Java, and will be happy to be told to upgrade anyway if they have any problem. While power users setting up FOP in a server-like environment are already aware of those early JAXP issues and know how to handle them. Which means we forget any endorsed mechanism. - for the rest I consider the following: FOP appears to have dependencies which are simply not in the Java 1.4 Standard Library. Just like any other dependency they will be put in the lib/ directory and added to the classpath. They won’t affect the JAXP implementation bundled with the JVM. It just appears that the classes in the org.w3c.dom.xpath package are available in later versions of JAXP, but we forget that and this will be transparent to the user: those using Java 1.4 and 1.5 will find those classes in the xml-apis.jar, those using later versions will get them through their JAXP implementations. Once we switch to Java 1.7 (or whichever includes them in the standard library) as a minimal requirement, we remove the xalan.jar and xml-apis.jar, and we switch the org.apache.xpath namespace to javax.xml.xpath. Which means for today that we remove the no longer necessary serializer.jar and xercesImpl.jar and we keep the other ones. Solution 1, amended. I hope I’m clear. WDYT? Vincent I like this idea best of the ideas to go by so far. Here's my perspective on Clay's issue (why bother if it works as is?): I string together chains of tools that my customers use for document production. I'd like to have as much control as possible over which tools I use. So, removing Xalan from FOP gives me one more place to have some control of the process. That's a good thing, at least to me. Also, as Vincent mentioned, it provides an opportunity to educate people (not just users but also the developers of other tools) about what exactly FOP does. That is, it makes FOP's boundaries clearer and cleaner. IMO, that's also a good thing. If this were the proposed re-arrangement of the jars, I'd vote for it. However, I gather that some other ideas may still come rolling in (perhaps in response to this latest iteration of the core idea). Also, I understand that it's not an issue needing a vote (yet). Jay Bryant Bryant Communication Services http://www.bryantcs.com/
Re: Feedback on Processing Feedback
On Jan 31, 2008, at 08:50, Jeremias Maerki wrote: I'm not sure, yet, if it's so easily possible to get the TransformerFactory from the FopFactory as it's not available everywhere. This could take some additional wiring. At first I was simply thinking about a classloader-wide setting (i.e. static variable) plus a system property. After all, it's not just FOP that instantiates Transformers, but XML Graphics Commons and Batik, too. I'll look into it. Indeed. Sorry, I write that far too often: ...should 'simply'..., while it is not at all simple... Hey, maybe I should become a manager. ;-) I totally overlooked Commons and Batik. In that case, it could be worth considering moving this logic to Commons. In that case, if both Batik and FOP use it, the problem is solved for both. As indicated in the other thread about the XML APIs, not as a mandatory dependency that would also affect people who happen to use Commons, but not FOP or Batik, but as part of a special xmlgraphics-commons.jar that is built especially for the two sub-projects. Cheers Andreas
Re: What to do with the XML JARs?
On Jan 31, 2008, at 16:25, Vincent Hennebert wrote: snip / Which means for today that we remove the no longer necessary serializer.jar and xercesImpl.jar and we keep the other ones. Solution 1, amended. I hope I’m clear. WDYT? This also sounds good enough for me. As long as we can't safely remove the dependency on Xalan without causing more troubles, I'm fine with keeping it for the time being. The goal in the end should be to avoid hard dependencies on components for which there is a standard API (just like we don't have dependencies on any of the com.sun.* classes behind some of the classes in the public/standard Java API). Following Vincent's suggestion is already one step in the right direction. Then again, since Xalan is actually needed because of the dependency on Batik, I'm wondering whether those libraries can be moved into Commons. Not as a mandatory dependency there, but an optional one, a resource in a special commons.jar which FOP and in time maybe also Batik can share... Cheers Andreas
Re: What to do with the XML JARs?
Can you two please explain to me what you mean by that? On 31.01.2008 21:37:42 J.Pietschmann wrote: Andreas Delmelle wrote: Then again, since Xalan is actually needed because of the dependency on Batik, I'm wondering whether those libraries can be moved into Commons. Not as a mandatory dependency there, but an optional one, a resource in a special commons.jar which FOP and in time maybe also Batik can share... I just got the same thought. J.Pietschmann Jeremias Maerki
Re: What to do with the XML JARs?
Jeremias Maerki wrote: 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. Whoa! Pull that tail end hanging out of the foliage and you get an elephant! J.Pietschmann
