[
https://issues.apache.org/jira/browse/JSPWIKI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661096#action_12661096
]
Janne Jalkanen commented on JSPWIKI-465:
----------------------------------------
Feedback from the Incubator mailing lists suggests 1, 3 and 4 being the
realistic choices, with Siegfried suggesting that the situation with #1 is not
as bad as it looks like.
To me it sounds like #3 or #4 are the ways forward (and we *can* use
org.apache.wiki, apparently). I personally don't like #2, because while it is
marginally useful for some people, it's kinda stupid to mandate precompiling
for everyone. It's good if we can include that option, yes, but I don't believe
that the pain is worth the gain. I've never needed precompiling anywhere; our
JSPs are relatively light still, so it's not a performance bottleneck by any
means with current CPUs.
> 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
> Priority: Blocker
> Fix For: 3.0
>
>
> 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.
