[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314650 ] Jeremy Brown commented on JBAS-1283: No dice. I changed my jboss-web.xml to read: [quote] ?xml version='1.0' encoding='UTF-8' ? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web class-loading java2ClassLoadingCompliance=true loader-repositorydot.com:loader=app1 loader-repository-configjava2ParentDelegation=false/loader-repository-config /loader-repository /class-loading /jboss-web [/quote] But I am still seeing the Tomcat errors in the JBoss logs when I try to access a JSP for the first time. I even undeployed the app, stopped the server, started the server, and redeployed the app (after the server had come up all the way), same result. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at
[JBoss-dev] [JBoss JIRA] Created: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assigned to: Scott M Stark See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at
[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=history ] Jeremy Brown updated JBAS-1283: --- Attachment: test.war Test war file which exhibits behavior. Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Scott M Stark Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1283) Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp
[ http://jira.jboss.com/jira/browse/JBAS-1283?page=comments#action_12314641 ] Jeremy Brown commented on JBAS-1283: What's the net effect of setting java2ClassLoadingCompliance to true or false? Is there a wiki topic or doco about this? Tomcat Unable to Compile JSPs when Separate ClassLoader Namespace Used for Webapp - Key: JBAS-1283 URL: http://jira.jboss.com/jira/browse/JBAS-1283 Project: JBoss Application Server Type: Bug Components: Web (Tomcat) service Versions: JBossAS-3.2.6 Final Environment: Stock JBoss 3.2.6 running on Linux (kernel 2.4.26), Sun JDK and JRE version 1.4.2_04 Reporter: Jeremy Brown Assignee: Anil Saldhana Priority: Minor Attachments: test.war See my initial forum post at http://www.jboss.org/index.html?module=bbop=viewtopicp=3861452#3861452;. The dom4j libs provided by JBoss do not work correctly with my web application, so I attempted to configure my webapp's jboss-web.xml--as per the wiki page at http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration--so that my webapp would essentially be in a different classloader namspace and would be able to override the server dom4j implementation with its own. Now, Tomcat bails out during JSP compilation with a dom4j-related ClassCastException, leading me to believe there might some problem with the sort of setup I'm trying to attempt...for example, Tomcat's JSP compiler might be trying to link with the dom4j in my application's namespace while its classes have been loaded next to (and probably are already using) dom4j in the server namespace. I'll attach a .war file exhibiting this behavior to this bug report. Here's the specific exception for this .war file: java.lang.ClassCastException at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:93) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:91) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:70) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:188) at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:240) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:160) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:470) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:158) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at
