[
https://issues.apache.org/jira/browse/JSPWIKI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660658#action_12660658
]
Andrew Jaquith commented on JSPWIKI-465:
----------------------------------------
Yes, this is what I meant in my message to the mailing list about forcing 99%
of the "addressable market" to upgrade before using an Apache-released JSPWiki.
(A poor choice of words, perhaps.) Jasper is widely used by lots of web
containers. Incompatibility with Jasper means problems with anybody who uses
Tomcat, Glassfish, Geronimo, Jetty and JBoss.
So, I do think this is a serious issue. We should see if we can use an
alternative package name, but keep the JSPWiki project name.
One **other** alternative would be to pre-compile the JSPs and ensure that they
are included in the WAR. This would mean that only developers (not all of the
*deployers*) would need updated versions of Jasper -- or we could simply update
the tests/lib versions of the Jasper compiler we already ship.
However, I'm not sure pre-compiled JSPs work at the moment. (If memory serves:
I think this is because TemplateManager assumes it has access to the file
system.)
Pre-compiled JSPs have their own drawbacks, of course. But this might be a way
to get around the issue in the interim.
> 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.
