[
https://issues.apache.org/jira/browse/JSPWIKI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661056#action_12661056
]
Andrew Jaquith commented on JSPWIKI-465:
----------------------------------------
When all options begin with the loaded word "abandon," we are not likely to
have a rational discussion. Let's re-cast our choices:
1) Go forward with the org.apache.jspwiki package name, and wait for the Tomcat
Jasper team to issue a fix.
Pros: least invasive option by far -- after the fix is issued.
Cons: everyone using Tomcat, Glassfish, Geronimo, Jetty, and JBoss can't use
JSPWiki 3.0 until their containers include the updated Jasper JARs -- AND they
have upgraded to the fixed version. This could take months or years. Who would
be affected: nearly every deployer.
2) Go forward with the org.apache.jspwiki package name, but add pre-compiled
JSPs to the WAR file as the default build setting (this could be switched off
for those who have the updated Jasper JARs in their production servers).
Pros: re-uses existing Jasper JARs already included in JSPWiki source distro
(which which would be upgraded). Allows use of org.apache.jspwiki package name.
Cons: Unpacked JSPs from WAR can't be "hacked" because they don't actually do
anything any more. Also, this makes the templates directories less "dynamic"
because new templates can't be dropped in. Who would be affected: deployers who
have created their own templates or modified existing ones; they would be
required to propagate custom JSP changes by running Ant scripts to recreate the
WAR, rather than simply modifying JSPs in the file system.
3) Keep JSPWiki in the org.apache namespace, but choose a package that isn't
named JSPWiki, such as org.apache.wiki.
Pros: Works without any other hacks or fixes. Zero *marginal* impact on
template developers (they will have to change their JSP imports anyway due to
the package change to org.apache).
Cons: Apache Incubator PMC might not let us do this. Also, JSPWiki brand might
be diluted. Who would be affected: nobody other than those whose tastes might
be affected, and possibly plugin or core (not JSP) developers.
4) Rename package to org.apache.JSPWiki
Pros: same as #3. Works without any other hacks or fixes. Zero marginal impact
on template developers.
Cons: unconventional naming scheme that is legal but looks strange. Might run
afoul of some heretofore-unknown Apache coding convention. Who would be
affected: nobody other than those whose whose tastes might be offended.
5) Stay with the com.ecyrd.jspwiki package name, or use another that isn't
under the Apache banner.
Pros: same as #3. Works without any other hacks or fixes. Zero marginal impact
on template developers.
Cons: JSPWiki likely to be kicked out of Apache Incubator.
Let's rule out the ones that are likely non-starters: #5 and #1. I can't see
how a bug like this should be the trigger that would cause JSPWiki to leave
Apache. Equally unlikely is the requirement to force developers to upgrade
their containers. Won't happen -- we'd have better luck mandating Java 6. :)
Personally I think #2 is the best option, because it gets us the package name
we want (and always thought we'd use), while buying time until the Jasper fix
is widely available. (Of course, this could take years...) It *does*
inconvenience template developers who aren't in the habit of building WARs from
source. I would argue they *should* build their own WARs if they modify
existing templates or make their own. But that's a bit of a change for us; one
we'd have to document pretty clearly.
Options 4 and 5 are roughly equivalent. Option 4 -- assuming can do it --
doesn't offend my tastes particularly, although I understand Janne's concern
about dilution of the JSPWiki name. Option 5 does kinda offend my
sensibilities, in the sense that it's weird and strikes me as hack-y. But, they
both are like that.
So: to summarize, I'd stack-rank them 2, 3, 4, 5, 1, in that order.
One thing I *will* say about this bug: as a side effect, I've finally figured
out how to fix the problems with using pre-compiled JSPs, which haven't *ever*
worked in the three? four? years I've been a committer. Whether we make
pre-compiled JSPs the default or not is an open question. But it does seem like
a very good idea to allow this to be an *option* if deployers want it --
finally.
> 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
>
> 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.
