You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Chatree Srichart (Created) (JIRA)" <ji...@apache.org> on 2011/11/24 11:18:40 UTC
[jira] [Created] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
TLD is not loaded from CLASSPATH using Tomcat 7
-----------------------------------------------
Key: OFBIZ-4591
URL: https://issues.apache.org/jira/browse/OFBIZ-4591
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Environment: Ubntu
Reporter: Chatree Srichart
Priority: Critical
Hi community.
I have a problem when I render a JSP page which is defined a taglib, for example:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
To solve this problem we need to delete this line from CatalinaContainer.java file:
standardJarScanner.setScanClassPath(false);
because the standard jar scanner is set the default value as "true"
After we have done above, we will get these problems.
=========================================================
1. JAR files are conflicted by different webapp contexts
=========================================================
The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
Context(1)
Context(2)
Context(3)
A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
===========================================================
2. WebslingerAccessLogValve class does not support Tomcat 7
===========================================================
If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
=======================================================
3. groovy.jmx.builder.package-info class cannot be loaded
=======================================================
groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
<taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
============================
4. Starting time will slower
============================
A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
Regards,
Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
Posted by "Chatree Srichart (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chatree Srichart updated OFBIZ-4591:
------------------------------------
Attachment: EnableJarScanner.patch
Yes, it does. I attach a patch file to enable JAR Scanner for a webapp context. Unfortunately, when I applied this patch I still get an error. For example:
SEVERE: Error processing TLD files for context with name [/myportal]
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632)
at java.util.zip.ZipFile.access$200(ZipFile.java:56)
at java.util.zip.ZipFile$1.nextElement(ZipFile.java:491)
at java.util.zip.ZipFile$1.nextElement(ZipFile.java:481)
at java.util.jar.JarFile$1.nextElement(JarFile.java:242)
at java.util.jar.JarFile$1.nextElement(JarFile.java:237)
at org.apache.tomcat.util.scan.FileUrlJar.nextEntry(FileUrlJar.java:76)
> TLD is not loaded from CLASSPATH using Tomcat 7
> -----------------------------------------------
>
> Key: OFBIZ-4591
> URL: https://issues.apache.org/jira/browse/OFBIZ-4591
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Environment: Ubntu
> Reporter: Chatree Srichart
> Priority: Critical
> Labels: 7, tld, tomcat
> Attachments: EnableJarScanner.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Hi community.
> I have a problem when I render a JSP page which is defined a taglib, for example:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
> The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
> To solve this problem we need to delete this line from CatalinaContainer.java file:
> standardJarScanner.setScanClassPath(false);
> because the standard jar scanner is set the default value as "true"
> After we have done above, we will get these problems.
> =========================================================
> 1. JAR files are conflicted by different webapp contexts
> =========================================================
> The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
> Context(1)
> Context(2)
> Context(3)
> A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
> ===========================================================
> 2. WebslingerAccessLogValve class does not support Tomcat 7
> ===========================================================
> If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
> =======================================================
> 3. groovy.jmx.builder.package-info class cannot be loaded
> =======================================================
> groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
> ============================
> 4. Starting time will slower
> ============================
> A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
> However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
> Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
> Regards,
> Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
Posted by "Adrian Crum (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243670#comment-13243670 ]
Adrian Crum commented on OFBIZ-4591:
------------------------------------
According to the reporter, this is still an issue - so it should stay open.
> TLD is not loaded from CLASSPATH using Tomcat 7
> -----------------------------------------------
>
> Key: OFBIZ-4591
> URL: https://issues.apache.org/jira/browse/OFBIZ-4591
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Environment: Ubntu
> Reporter: Chatree Srichart
> Priority: Critical
> Labels: 7, tld, tomcat
> Attachments: EnableJarScanner.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Hi community.
> I have a problem when I render a JSP page which is defined a taglib, for example:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
> The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
> To solve this problem we need to delete this line from CatalinaContainer.java file:
> standardJarScanner.setScanClassPath(false);
> because the standard jar scanner is set the default value as "true"
> After we have done above, we will get these problems.
> =========================================================
> 1. JAR files are conflicted by different webapp contexts
> =========================================================
> The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
> Context(1)
> Context(2)
> Context(3)
> A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
> ===========================================================
> 2. WebslingerAccessLogValve class does not support Tomcat 7
> ===========================================================
> If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
> =======================================================
> 3. groovy.jmx.builder.package-info class cannot be loaded
> =======================================================
> groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
> ============================
> 4. Starting time will slower
> ============================
> A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
> However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
> Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
> Regards,
> Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
Posted by "Jacques Le Roux (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237854#comment-13237854 ]
Jacques Le Roux commented on OFBIZ-4591:
----------------------------------------
Doest this pb still exist?
> TLD is not loaded from CLASSPATH using Tomcat 7
> -----------------------------------------------
>
> Key: OFBIZ-4591
> URL: https://issues.apache.org/jira/browse/OFBIZ-4591
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Environment: Ubntu
> Reporter: Chatree Srichart
> Priority: Critical
> Labels: 7, tld, tomcat
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Hi community.
> I have a problem when I render a JSP page which is defined a taglib, for example:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
> The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
> To solve this problem we need to delete this line from CatalinaContainer.java file:
> standardJarScanner.setScanClassPath(false);
> because the standard jar scanner is set the default value as "true"
> After we have done above, we will get these problems.
> =========================================================
> 1. JAR files are conflicted by different webapp contexts
> =========================================================
> The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
> Context(1)
> Context(2)
> Context(3)
> A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
> ===========================================================
> 2. WebslingerAccessLogValve class does not support Tomcat 7
> ===========================================================
> If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
> =======================================================
> 3. groovy.jmx.builder.package-info class cannot be loaded
> =======================================================
> groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
> ============================
> 4. Starting time will slower
> ============================
> A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
> However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
> Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
> Regards,
> Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
Posted by "Jacques Le Roux (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243313#comment-13243313 ]
Jacques Le Roux commented on OFBIZ-4591:
----------------------------------------
Hi Adrian, then should we not close?
> TLD is not loaded from CLASSPATH using Tomcat 7
> -----------------------------------------------
>
> Key: OFBIZ-4591
> URL: https://issues.apache.org/jira/browse/OFBIZ-4591
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Environment: Ubntu
> Reporter: Chatree Srichart
> Priority: Critical
> Labels: 7, tld, tomcat
> Attachments: EnableJarScanner.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Hi community.
> I have a problem when I render a JSP page which is defined a taglib, for example:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
> The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
> To solve this problem we need to delete this line from CatalinaContainer.java file:
> standardJarScanner.setScanClassPath(false);
> because the standard jar scanner is set the default value as "true"
> After we have done above, we will get these problems.
> =========================================================
> 1. JAR files are conflicted by different webapp contexts
> =========================================================
> The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
> Context(1)
> Context(2)
> Context(3)
> A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
> ===========================================================
> 2. WebslingerAccessLogValve class does not support Tomcat 7
> ===========================================================
> If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
> =======================================================
> 3. groovy.jmx.builder.package-info class cannot be loaded
> =======================================================
> groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
> ============================
> 4. Starting time will slower
> ============================
> A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
> However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
> Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
> Regards,
> Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4591) TLD is not loaded from CLASSPATH
using Tomcat 7
Posted by "Adrian Crum (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240509#comment-13240509 ]
Adrian Crum commented on OFBIZ-4591:
------------------------------------
The webslinger component has been removed from the trunk, so that issue has been resolved.
The multi-threaded component loader was the result of a conversation I had with Adam Heath about SEDA and a multi-threaded consumer-provider design pattern. I had proposed speeding up the loading process by making it multi-threaded: One thread parses the XML files, while another thread does something with the parsed results. It appears the implementation mentioned in this issue doesn't follow that pattern (I can't be sure because I haven't looked at the code, but the behavior seems to indicate this). I would recommend keeping the multi-threading aspect, but change the roles/tasks of the threads - so the webapps will get loaded consecutively.
> TLD is not loaded from CLASSPATH using Tomcat 7
> -----------------------------------------------
>
> Key: OFBIZ-4591
> URL: https://issues.apache.org/jira/browse/OFBIZ-4591
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Environment: Ubntu
> Reporter: Chatree Srichart
> Priority: Critical
> Labels: 7, tld, tomcat
> Attachments: EnableJarScanner.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Hi community.
> I have a problem when I render a JSP page which is defined a taglib, for example:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
> The problem is TLD definition files are not loaded from CLASSPATH using Tomcat 7.
> To solve this problem we need to delete this line from CatalinaContainer.java file:
> standardJarScanner.setScanClassPath(false);
> because the standard jar scanner is set the default value as "true"
> After we have done above, we will get these problems.
> =========================================================
> 1. JAR files are conflicted by different webapp contexts
> =========================================================
> The ScheduledExecutorService that submit all webapp contexts does not run them respectively. For example:
> Context(1)
> Context(2)
> Context(3)
> A particular context will read all JAR files from CLASSPATH. The problem is, for example, the Context(2) will start to read all JAR files even though the Context(1) does not finish its task yet. So the Context (2) will not be able to read some JAR file that the Context(1) is reading and causes an error.
> ===========================================================
> 2. WebslingerAccessLogValve class does not support Tomcat 7
> ===========================================================
> If the jar scanner scan jar files from CLASSPATH, it will find WebslingerAccessLogValve class which does not support Tomcat 7
> =======================================================
> 3. groovy.jmx.builder.package-info class cannot be loaded
> =======================================================
> groovy.jmx.builder.package-info class cannot be loaded because its name is incorrect. If I remove this class from framework/base/lib/scripting/groovy-all-1.7.7.jar file, this line in macros.xml will cause an error:
> <taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="groovy.class.path"/>
> ============================
> 4. Starting time will slower
> ============================
> A particular webapp context will spend more time to parse JAR file from CLASSPATH to find TLD definition files.
> However I can avoid the TLD problem by copying JAR files that contain TLD definition files into /WEB-INF/lib directory of a particular webapp
> Lastly, I am not sure if we need this feature in the trunk but I think it is useful. If so, please help me to solve the problems.
> Regards,
> Chatree Srichart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira