[
https://issues.apache.org/jira/browse/JSPWIKI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660663#action_12660663
]
Andrew Jaquith commented on JSPWIKI-465:
----------------------------------------
Good news!
I was able to pre-compile the JSPs using the Jasper jars in tests/lib. They
*seem* to load fine, and I don't see any classloader errors thrown in the
Catalina log file. Wiki.jsp displays too, just like it did before moving the
WikiPage package change caused the classloader to barf.
Even better: this was done with the *old* version of Tomcat -- i.e., the
version that refused to compile the JSPs on demand.
Here's what I did: run the Jasper2 Ant task on the JSPs to generate Java
sources; compile & jar 'em into a JSPWiki-jsp.jar file; modify the web.xml file
to map the classes to the JSP paths; and add all this stuff to the WAR. To
guarantee servlet container portability, we can (and probably should) add the
~100k jasper-runtime-*.jar file to the WAR also.
The (slightly) bad news: When you pre-compile JSPs you are essentially
substituting servlet class mappings for JSPs themselves. Normally, this enables
you to omit the JSPs from the WAR because they aren't needed any more. However,
in this case we *must* continue to include the actual JSPs in the WAR file, or
else they won't get included properly by <wiki:include>. This is because
TemplateManager calls ServletContext.getResourceAsStream(), which works great
for finding actual file-based/JARred resources like Wiki.jsp, but not so well
mapped ones (like with generated JSP classes).
Overall, I think the tradeoff is probably worth it.
If everyone agrees that this is a viable workaround, I'd like to go ahead and
commit the fix to build.xml to make JSPs pre-compiled by default. We could add
a property to build.properties to allow admins who have upgraded to "fixed"
versions of Jasper to turn off pre-compilation.
We could also pre-pend some text to the beginning of the included JSP files in
the WAR that tells users that they are non-functional. Something like:
"This JSP does not execute. When this JSP's path is called, the code that
executes is actually located in JSPWiki-jsp.jar. We have included the JSP here
for educational purposes only."
(a little white lie, but not too bad...)
> JSP classloading does not work because of package name collision
> org.apache.jsp <=> org.apache.jspwiki
> ------------------------------------------------------------------------------------------------------
>
> Key: JSPWIKI-465
> URL: https://issues.apache.org/jira/browse/JSPWIKI-465
> Project: JSPWiki
> Issue Type: Bug
> Components: Servlet Container/Java compatibility
> Affects Versions: 3.0
> Environment: JSPWiki 3.0.0-svn-41
> Reporter: Harry Metske
> Assignee: Harry Metske
>
> JSPWiki is an incubating project in ASF, one of the required steps here is to
> move the java package naming from com.ecyrd.jspwiki to org.apache.jspwiki.
> After moving several classes to this new package we are seeing
> NoClassDeffoundErrors when classes are imported from JSP's
> "Normal" servlets/classes work fine.
> After digging for a couple of days we found that the problem is caused by a
> bug in the JasperLoader classloader:
> http://svn.eu.apache.org/viewvc/tomcat/jasper/tc6.0.x/src/share/org/apache/jasper/servlet/JasperLoader.java?view=markup
> The following code snippet shows the failure :
> {noformat}
> if( !name.startsWith(Constants.JSP_PACKAGE_NAME) ) {
> // Class is not in org.apache.jsp, therefore, have our
> // parent load it
> clazz = parent.loadClass(name);
> if( resolve )
> resolveClass(clazz);
> return clazz;
> }
> {noformat}
> The constant Constants.JSP_PACKAGE_NAME is loaded as follows:
> {noformat}
> /**
> * The default package name for compiled jsp pages.
> */
> public static final String JSP_PACKAGE_NAME =
> System.getProperty("org.apache.jasper.Constants.JSP_PACKAGE_NAME",
> "org.apache.jsp");
> {noformat}
> Note the missing trailing dot !
> So there is a workaround by specifying the Java System Property
> org.apache.jasper.Constants.TAG_FILE_PACKAGE_NAME=org.apache.somethingelse
> However, this workaround is only available since revision 441109 of Tomcat 6.
> (
> http://svn.eu.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/Constants.java?r1=423920&r2=441109&diff_format=h
> )
> A bug has been filed for the Tomcat team at :
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46462
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
