RE: [JBoss-dev] Xalan removal saga
It's a tradeoff between introducing a xsl parser dependency that the user may not want vs modifying the TransformerFactory to be more flexible at the cost of the user potentially have to configure the TransformerFactory default. I think modifying the TransformerFactory is the most flexible, but maybe just bundling the xsl parser is the simplest. Since the current options are to upgrade or remove/patch I've upgraded both 4.x and HEAD to xalan 2.7.0/xerces2.7.1 hoping to revisit the xalan removal in a later version. I've recorded the discussion here: http://www.jboss.com/index.html?module=bbop=viewtopicp=3925787#3925787 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader(). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Wednesday, February 22, 2006 4:02 AM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga It all boils down to here: ... return (TransformerFactory) FactoryFinder.find( /* The default property name according to the JAXP spec */ javax.xml.transform.TransformerFactory, /* The fallback implementation class name */ org.apache.xalan.processor.TransformerFactoryImpl); ... I don't see how we can patch the TF to return a proper fallback implementation name, because we just don't know what that is. On Sun jdk1.4 it would be org.apache.xalan.processor.TransformerFactoryImpl On Sun jdk5 it would be com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl But on other vendor jdks, whats the correct value? And if it is just a question of setting a sensible default value, we could do just the same setting the javax.xml.transform.TransformerFactory property. But isn't this exactly the role of the TransformerFactory offered by the jdk vendor? I think the best compromise is to just remove javax.xml.transform.TransformerFactory from xml-apis.jar (replace with xml-apis-notf.jar ?) to let the vendor supplied default apply. I've attached the TransformerFactory code that comes with xml-apis.jar --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
I don't follow why this is necessary. If we just remove javax.xml.transform.TransformerFactory from xml-apis.jar then the jdk bundled TransformerFactory will be used to choose the correct implementation. A user can always drop his own xalan.jar to lib/endorsed (for jdk1.4/5), or server/xxx/lib for jdk5, or use a scoped xalan.jar to override the jdk version, since xalan.jar contains: META-INF/services/javax.xml.transform.TransformerFactory file containing the class name of its implementation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 22 February, 2006 18:16 To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader(). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
Its not clear that removal of the javax.xml.transform.* is safe. There are references to org.w3c.dom.* from the javax.xml.transform.dom for example. We cannot simply remove just the javax.xml.transform.TransformerFactory. It would have to be all javax.xml.transform.* classes. The presence of the javax.xml.transform.TransformerFactory should not affect a user being able to override the transformer by dropping in an xsl jar with a META-INF/services/javax.xml.transform.TransformerFactory entry as this takes precedence over the TransformerFactory defaults. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Wednesday, February 22, 2006 9:24 AM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga I don't follow why this is necessary. If we just remove javax.xml.transform.TransformerFactory from xml-apis.jar then the jdk bundled TransformerFactory will be used to choose the correct implementation. A user can always drop his own xalan.jar to lib/endorsed (for jdk1.4/5), or server/xxx/lib for jdk5, or use a scoped xalan.jar to override the jdk version, since xalan.jar contains: META-INF/services/javax.xml.transform.TransformerFactory file containing the class name of its implementation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 22 February, 2006 18:16 To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader(). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
Removing javax.xml.transform.TransformerFactory or patching it to try invoke the underlying TransformerFactory (if this is possible) which is essentially the same thing, is undesirable because you'll end up with a transformer API and an underlying implementation that may not match (correct?) Removing javax.xml.transform.* is not clear that is safe (I guess because you might have incompatible parser api+impl - transformer api+impl interactions?) Ok, we are doomed :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 22 February, 2006 19:50 To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga Its not clear that removal of the javax.xml.transform.* is safe. There are references to org.w3c.dom.* from the javax.xml.transform.dom for example. We cannot simply remove just the javax.xml.transform.TransformerFactory. It would have to be all javax.xml.transform.* classes. The presence of the javax.xml.transform.TransformerFactory should not affect a user being able to override the transformer by dropping in an xsl jar with a META-INF/services/javax.xml.transform.TransformerFactory entry as this takes precedence over the TransformerFactory defaults. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Wednesday, February 22, 2006 9:24 AM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga I don't follow why this is necessary. If we just remove javax.xml.transform.TransformerFactory from xml-apis.jar then the jdk bundled TransformerFactory will be used to choose the correct implementation. A user can always drop his own xalan.jar to lib/endorsed (for jdk1.4/5), or server/xxx/lib for jdk5, or use a scoped xalan.jar to override the jdk version, since xalan.jar contains: META-INF/services/javax.xml.transform.TransformerFactory file containing the class name of its implementation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 22 February, 2006 18:16 To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader(). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Wednesday, February 22, 2006 1:09 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga Removing javax.xml.transform.TransformerFactory or patching it to try invoke the underlying TransformerFactory (if this is possible) which is essentially the same thing, is undesirable because you'll end up with a transformer API and an underlying implementation that may not match (correct?) This is always the case though. Any attempt to override the xsl factory will be subject to matching the javax.xml.transform.* in effect. Removing javax.xml.transform.* is not clear that is safe (I guess because you might have incompatible parser api+impl - transformer api+impl interactions?) Ok, we are doomed :) There are some xml parser class dependencies in the javax.xml.transform.dom and javax.xml.transform.sax packages. I just don't know if the javax.xml.transform.* in jaxp 1.3 can use the 1.2 xml parsers. It's a tradeoff between introducing a xsl parser dependency that the user may not want vs modifying the TransformerFactory to be more flexible at the cost of the user potentially have to configure the TransformerFactory default. I think modifying the TransformerFactory is the most flexible, but maybe just bundling the xsl parser is the simplest. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
This is probably a jaxp requirement to not subset the apis. The next question is whether the xml-apis.jar is needed. Is jdk1.4.x at jaxp 1.2? The xerces 2.7.x release supports jaxp 1.3. The potential problem with doing this is are there dependencies between the javax.xml.transform.* classes and the other javax.xml.* classes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Tuesday, February 21, 2006 3:07 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga I traced this down to a TranformerFactory included in the xml-apis.jar that comes with xerces tools (e.g. Xerces-J-tools.2.7.1.zip). This is tagged as 1.3.02 and in turn originates from http://xml.apache.org/commons/ The xml-commons hadn't had any releases for some time, so the tagged xml-apis.jar comes directly from their cvs. I think I will remove all javax.xml.transform.** from xml-apis.jar to create a new xml-apis-no-transform.jar and include this instead. From a quick test it seems to be working with both jdk1.4 and jdk5. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Xalan removal saga
The more I think about it the more I doubt this is legal for a java ee distribution. If we are bundling jaxp 1.3, we need it to be the complete 1.3 set of apis and we would just have to patch the TranformerFactory to do the right thing, whatever that is. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Tuesday, February 21, 2006 3:07 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Xalan removal saga I traced this down to a TranformerFactory included in the xml-apis.jar that comes with xerces tools (e.g. Xerces-J-tools.2.7.1.zip). This is tagged as 1.3.02 and in turn originates from http://xml.apache.org/commons/ The xml-commons hadn't had any releases for some time, so the tagged xml-apis.jar comes directly from their cvs. I think I will remove all javax.xml.transform.** from xml-apis.jar to create a new xml-apis-no-transform.jar and include this instead. From a quick test it seems to be working with both jdk1.4 and jdk5. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
