[JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
Dimitris, remind me why removing xalan is a problem. I'm not getting it from the discussion thread associated with this JBAS-2073 issue. From the TransformerFactory javadoc: public static TransformerFactory newInstance() throws TransformerFactoryConfigurationError Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load: * Use the javax.xml.transform.TransformerFactory system property. * Use the properties file lib/jaxp.properties in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. * Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. * Platform default TransformerFactory instance. Neither the javax.xml.transform.TransformerFactory system property nor jre lib/jaxp.properties exists by default: [EMAIL PROTECTED] bin]$ find /usr/java/jdk1.5.0_05 -name jaxp.properties [EMAIL PROTECTED] bin]$ find /usr/java/j2sdk1.4.2_09 -name jaxp.properties -print [EMAIL PROTECTED] bin]$ so the Services API (class loader scoped resources) should dictate how the jaxp factories are found. Having the xalan.jar in lib/endorsed overrides the javax.xml.transform namespace with classes loaded from the bootstrap class loader. I don't see why we need to do this? -Original Message- From: Dimitris Andreadis (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:00 AM To: Jira Notifications Subject: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed [ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] Dimitris Andreadis updated JBAS-2073: - Fix Version: (was: JBossAS-4.0.4.GA) I don't see how the lib/endorsed mechanism can be avoided, when running under jdk1.4, in which case, we can't fix this for Branch 4.x --- 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] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
What I'm saying is under jdk1.4 the only way to override the jdk embedded xalan with a different version is to drop it in lib/endorsed or use a scoped deployment. Putting it in server/xxx/lib or server/xxx/deploy won't work, even if specifying the javax.xml.transform.TransformerFactory property since setting it to org.apache.xalan.processor.TransformFactoryImpl makes no difference, it will just load the jdk provided xalan version because the class names collide. Now, I had the feeling that we *needed* a xalan.jar version newer than the one provided with jdk1.4, in which case, what other way we would have to override the jdk version? The rules you mention would work, if the overriding xalan version used different class names! I just removed lib/endorsed/xalan.jar and the server seems to boot happily. If we *do not need* a newer version, I guess we can just remove it, and let the user drop its own lib/endorsed/xalan.jar version, if necessary. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: 20 February, 2006 21:33 To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed Dimitris, remind me why removing xalan is a problem. I'm not getting it from the discussion thread associated with this JBAS-2073 issue. From the TransformerFactory javadoc: public static TransformerFactory newInstance() throws TransformerFactoryConfigurationError Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load: * Use the javax.xml.transform.TransformerFactory system property. * Use the properties file lib/jaxp.properties in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. * Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime. * Platform default TransformerFactory instance. Neither the javax.xml.transform.TransformerFactory system property nor jre lib/jaxp.properties exists by default: [EMAIL PROTECTED] bin]$ find /usr/java/jdk1.5.0_05 -name jaxp.properties [EMAIL PROTECTED] bin]$ find /usr/java/j2sdk1.4.2_09 -name jaxp.properties -print [EMAIL PROTECTED] bin]$ so the Services API (class loader scoped resources) should dictate how the jaxp factories are found. Having the xalan.jar in lib/endorsed overrides the javax.xml.transform namespace with classes loaded from the bootstrap class loader. I don't see why we need to do this? -Original Message- From: Dimitris Andreadis (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:00 AM To: Jira Notifications Subject: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed [ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] Dimitris Andreadis updated JBAS-2073: - Fix Version: (was: JBossAS-4.0.4.GA) I don't see how the lib/endorsed mechanism can be avoided, when running under jdk1.4, in which case, we can't fix this for Branch 4.x --- 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] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
So the problem is lack of encapsulation of the essentially global org.apache.xalan.processor.TransformFactoryImpl name due to the proliferation of the xalan distribution. One should be able to work around this by introducing a org.apache.xalan.processor.TransformFactoryImpl2 that loaded the org.apache.xalan.processor.TransformFactoryImpl visible via the thread context class loader. We don't need xsl during bootstrap, and as far as I know we don't have any requirements for a specific xsl version. The jira issue is a user request to update the xalan version since we do bundle it. So maybe just dropping it and defaulting to the jdk version is the best approach. We really should avoid introducing library dependencies unless they are needed. The xalan.jar dates from jboss-3.2 and the fact that jdk1.3 had no bundled xsl implementation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitris Andreadis Sent: Monday, February 20, 2006 12:39 PM To: jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed What I'm saying is under jdk1.4 the only way to override the jdk embedded xalan with a different version is to drop it in lib/endorsed or use a scoped deployment. Putting it in server/xxx/lib or server/xxx/deploy won't work, even if specifying the javax.xml.transform.TransformerFactory property since setting it to org.apache.xalan.processor.TransformFactoryImpl makes no difference, it will just load the jdk provided xalan version because the class names collide. Now, I had the feeling that we *needed* a xalan.jar version newer than the one provided with jdk1.4, in which case, what other way we would have to override the jdk version? The rules you mention would work, if the overriding xalan version used different class names! I just removed lib/endorsed/xalan.jar and the server seems to boot happily. If we *do not need* a newer version, I guess we can just remove it, and let the user drop its own lib/endorsed/xalan.jar version, if necessary. --- 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] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
So the problem is lack of encapsulation of the essentially global org.apache.xalan.processor.TransformFactoryImpl name due to the proliferation of the xalan distribution. One should be able to work around this by introducing a org.apache.xalan.processor.TransformFactoryImpl2 that loaded the org.apache.xalan.processor.TransformFactoryImpl visible via the thread context class loader. The org.apache.xalan.processor.TransformFactoryImpl visible through the TCL, for a non-scoped deployment, wouldn't be again the JDK bundled xalan, since this is loaded with the Bootstrap CL? (testing my CL knowledge here :) We don't need xsl during bootstrap, and as far as I know we don't have any requirements for a specific xsl version. The jira issue is a user request to update the xalan version since we do bundle it. So maybe just dropping it and defaulting to the jdk version is the best approach. We really should avoid introducing library dependencies unless they are needed. The xalan.jar dates from jboss-3.2 and the fact that jdk1.3 had no bundled xsl implementation. Fine, I'll remove it and see if anyone complaints :) Maybe we should go for an 4.0.4.RC2, too. --- 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] FW: [JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed
The org.apache.xalan.processor.TransformFactoryImpl visible through the TCL, for a non-scoped deployment, wouldn't be again the JDK bundled xalan, since this is loaded with the Bootstrap CL? (testing my CL knowledge here :) Not necessarily because the org.apache.* is not a jdk core classes. Neither are the javax.* nor bundled org.* classes. All of those can be created in a scoped context by a class loader that does not delegate to its parent. Only classes in the java.* namespace cannot be passed to the ClassLoader.defineClass method. When this does not work is when you have mixing of classes with static references to jdk bootstrap classes in a class that is being used across different class loaders. There is no notion of redefine class on inconsistent type system usage although there should be in server environments. Fine, I'll remove it and see if anyone complaints :) Maybe we should go for an 4.0.4.RC2, too. That is probably a good idea. Two weeks for CR2(RC2 is now bad, I'll update the jboss version usage today), and the GA in 3-4 weeks after that. --- 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
