incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jaquith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JSPWIKI-465) JSP classloading does not work because of package name collision org.apache.jsp <=> org.apache.jspwiki
Date Mon, 05 Jan 2009 05:13:46 GMT

    [ 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.


Mime
View raw message