search

ops4j / org.ops4j.pax.web

OSGi R7 Http Service, Whiteboard and Web Applications (OSGi CMPN Release chapters 102, 140 and 128) implementation using Jetty 9, Tomcat 9 or Undertow 2.
https://ops4j1.jira.com/wiki/display/paxweb/Pax+Web
Other
146 stars 184 forks source link

Upgrade JSP version to 2.2 [PAXWEB-304] #648

Closed ops4j-issues closed 11 years ago

ops4j-issues commented 13 years ago

Achim Nierbeck created PAXWEB-304

Affects: 3.0.0.M1, 3.0.0.M2, 3.0.0.M3 Fixed in: 4.0.0 Attachments:

Votes: 1, Watches: 2

Referenced issues

relates to:

ops4j-issues commented 12 years ago

Achim Nierbeck commented

currently not needed for servlet 3.0

ops4j-issues commented 11 years ago

Serge Huber commented

Any change this is still possible for 3.0.0 ? Would be great to have servlet 3.0 along with JSP 2.2 to be consistent with Java EE spec ? If it's not too hard to do , maybe I could help with this ?

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Would be great if you could help on this, that'll ensure it makes it into a 3.0 :wink:

ops4j-issues commented 11 years ago

Serge Huber commented

Any pointers how to do this ? I see that we're currently using a dependency org.mortbay.jetty:jsp-2.1-glassfish but I couldn't find any updated package except for a 2.2.2b05... Is the org.glassfish.web:jsp-impl 100% compatible too ?

ops4j-issues commented 11 years ago

Achim Nierbeck commented

hmm, good one. I guess that's the reason I stopped working on this issue :smile:
the latest jetty (8.1.10xx) does ship with:

ops4j-issues commented 11 years ago

Serge Huber commented

Ok thanks I found all the dependencies in Maven Central :

<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>com.sun.el</artifactId>
<version>2.2.0.v201108011116</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>javax.el</artifactId>
<version>2.2.0.v201108011116</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>javax.servlet.jsp.jstl</artifactId>
<version>1.2.0.v201105211821</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>javax.servlet.jsp</artifactId>
<version>2.2.0.v201112011158</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>org.apache.jasper.glassfish</artifactId>
<version>2.2.2.v201112011158</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>org.apache.taglibs.standard.glassfish</artifactId>
<version>1.2.0.v201112081803</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.orbit</groupId>
<artifactId>org.eclipse.jdt.core</artifactId>
<version>3.7.1</version>
</dependency>

Will do a quick test to see what happens when I use them :smile:

ops4j-issues commented 11 years ago

Serge Huber commented

I'm attaching a quick patch file where basically I put all the new dependencies (commented out the old ones), and quickly removed the com.sun.org.apache.commons.logging imports to replace them with org.apche.commons.logging imports but I'm now stuck with the following compilation error:

ERROR Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project pax-web-jsp: Compilation failure
ERROR /Users/loom/java/technologies/git/ops4j/org.ops4j.pax.web/pax-web-jsp/src/main/java/org/apache/jasper/JspCompilationContext.java:570,34 cannot find symbol
ERROR symbol : method getTldLocationsCache()
ERROR location: interface org.apache.jasper.Options
ERROR -> Help 1

Looking at the JSP engine source code I couldn't find any TldLocationsCache all I could find is a TldScanner so I'm wondering if they haven't changed that. If anyone knows more about that your help would be welcome because here I'm not too sure how to proceed :smile:

ops4j-issues commented 11 years ago

Serge Huber commented

From some googling I found the following commit in the Jasper source code, which seems to show the changes from TldLocationsCache to TldScanner :

http://java.net/projects/jsp/lists/commits/archive/2009-07/message/7

ops4j-issues commented 11 years ago

Serge Huber commented

From what I understand of the code changes, it seems we should probably provide our own implementation of a TldScanner that adds the scanBundlesFromClassSpace that we had previously patched into the TldLocationsCache

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Looks like I'm gonna test first with only the JspCompilationContext class patched

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Just some feedback to let you know what I'm going to try.
As Geronimo does provide libraries for 2.2 that should work in OSGi (as it is based on Karaf)
I'm gonna give those libs a go first. If that's not going to work I'm gonna try to tweak on the existing stuff, cause the glassfish stuff I'm not sure about the license, it contains a Apache 2 license and something different.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

geronimo didn't work out.
So I went on with the initial plan. Works now and I'm able to use it.
Did need to make a nasty hack for using the right compiler.
Right now only the ecj 3.5 works. And a system property is set by the runtime activator to make sure the jdt compiler is used instead of the std. jdk one.

oh, the tld tests fail ...

ops4j-issues commented 11 years ago

Achim Nierbeck commented

I'm going to attach a patch later, giving the current state

ops4j-issues commented 11 years ago

Serge Huber commented

Thanks for doing all this (btw do you ever sleep ? :smile:)

If you haven't integrated with the TldScanner it seems normal that the TLD fails. I'm surprised you had to hack for the compiler though ? Did we do this previously in the class forks ?

I look forward to your patch, I'll have a look at it when you attach it.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Don't ask my wife if I have enough sleep :wink:

I'm using the TldScanner and it fails for the supposedly known TLDs, like http://java.sun.com/jsp/jstl/core.
That's why I commented the block about exluding them, after sleeping over this issue :grinning:
But I think I still miss something, probably the std. jstl and jsp and servlet jars are not parsed as they should (just a wild guess right now)
Concerning the compiler, no this wasn't needed it's a new feature since JDK6 is available. The 2.1. was still jdk 5 that's why eclipse jdt 3.5.1 is still used :grinning:
and that part is in the runtime, I'm setting a system parameter in the activator not nice but works right now ...

ops4j-issues commented 11 years ago

Achim Nierbeck commented

new patch, does compile and jsps without tlds do work

ops4j-issues commented 11 years ago

Achim Nierbeck commented

best to be tested with the JspIntegrationTest

ops4j-issues commented 11 years ago

Serge Huber commented

Hello thanks for all the work ! I tested the patch this morning and I saw the failure in the JspIntegrationTest. It also seems that there are some version issues with the following tests:

org.ops4j.pax.web.itest.WarJSFIntegrationTest
org.ops4j.pax.web.itest.WarJSFPrimefacesIntegrationTest

If I can find some time I'll try to look at the TLD issue unless you are on it already ?

ops4j-issues commented 11 years ago

Achim Nierbeck commented

The version issues are probably because the used myfaces stuff depends on Jsp 2.1 therfore need to work around that also :/

just give it a try, I'm not sure I'll get through it today I'm now trying to trap the issue by adding lot's of debug messages :grinning:

ops4j-issues commented 11 years ago

Achim Nierbeck commented

think I found the reason ...
the scaning of the bundles in classloader doesn't seem to work anymore cause it doesn't get anything will look into it ...

ops4j-issues commented 11 years ago

Achim Nierbeck commented

found the reason for the taglibs ..
since pax-web-jsp does embedd the jsp libraries I failed to include the tld files due to skipping the signature files in the pom ...

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Created a new Branch to let you guys know how far we got

it's PAXWEB-304

all changes are merged into that one now, makes it also easier if someone takes over :wink:
cause I'm running out of time right now.
So Serge Huber would really be great if you could look into this :grinning:

Branch: refs/heads/PAXWEB-304
Home: https://github.com/ops4j/org.ops4j.pax.web
Commit: 9b744db273fb59668d65bbff42a854f4284d9202
https://github.com/ops4j/org.ops4j.pax.web/commit/9b744db273fb59668d65bbff42a854f4284d9202
Author: Achim Nierbeck <bcanhome@googlemail.com>
Date: 2013-03-18 (Mon, 18 Mar 2013)

ops4j-issues commented 11 years ago

Serge Huber commented

Thanks Achim, I'm a bit busy today but if I have a moment I'll have a go at it. A branch will certainly help work on this.

ops4j-issues commented 11 years ago

Serge Huber commented

Sorry Achim didn't have the time I had hoped to spend on this this last week. I hope to be able to get back to it soon.

Best regards,
Serge

ops4j-issues commented 11 years ago

Serge Huber commented

Hello Achim,

I wanted to start debugging, but I'm having an issue running the tests in my IDE (JetBrains IDEA). You wouldn't happen to know how to set that up ? Putting debugging logs everywhere is always a possible fallback but it seems a bit tedious.

Also I saw the following in the logs :

qtp372775507-25 DEBUG org.ops4j.pax.web.service.jetty.internal.HttpServiceContext - getting resource: /WEB-INF/tagPlugins.xml
qtp372775507-25 DEBUG org.ops4j.pax.web.service.jetty.internal.HttpServiceContext - not a URL or invalid URL: /WEB-INF/tagPlugins.xml, treating as a file path
qtp372775507-25 DEBUG org.ops4j.pax.web.service.internal.DefaultHttpContext - Searching bundle [org.ops4j.pax.web.samples.helloworld-jsp 51] for resource WEB-INF/tagPlugins.xml
qtp372775507-25 DEBUG org.ops4j.pax.web.service.jetty.internal.HttpServiceContext - found resource: null
2013-03-25 14:01:04.326:WARN:oejs.ServletHandler:Error for /helloworld/jsp/using-tld.jsp
java.lang.NoSuchMethodError: org.apache.jasper.runtime.TagHandlerPool.get(Ljava/lang/Class;)Ljavax/servlet/jsp/tagext/Tag;
at org.apache.jsp.helloworld.jsp.using_002dtld_jsp._jspx_meth_c_set_0(org.apache.jsp.helloworld.jsp.using_002dtld_jsp:81)
at org.apache.jsp.helloworld.jsp.using_002dtld_jsp._jspService(org.apache.jsp.helloworld.jsp.using_002dtld_jsp:58)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:383)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:145)
at org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:141)
at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
at org.ops4j.pax.web.jsp.JspServletWrapper.service(JspServletWrapper.java:140)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:457)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:184)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:488)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:932)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:994)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:680)

What is really strange is the lookup for WEB-INF/tagPlugins.xml because the only location I found for this file is in Jasper Glassfish package but it is the org.apache.jasper.tagplugins.jstl package. Maybe the location changed ? Or maybe it's not required by default.

As for the exception, this is why I'd like to setup debugging to analyze what is going on.

Best regards,
Serge

ops4j-issues commented 11 years ago

Serge Huber commented

Googling a little I found what looks like a similar problem here :

http://jira.ow2.org/browse/JONAS-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Unfortunately there is no solution provided.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Ok, so you did get to the same point as I did :smile:

regarding the other issue, well it does give a little hint.

It seems that the Servlet produced by the Jasper compiler contains some code depending on a method that is not present in the Jasper found at runtime.

currently we still have the eclipse jdc 3.5.1 which is like a 1.5 compiler. This might be an issue, cause jetty 8 uses 3.7.1 which should be either something like jdk 6 or 7. It might very well be the issue, but it's a wild guess :/

ops4j-issues commented 11 years ago

Serge Huber commented

Could you maybe explain why the Eclipse 3.7.1 compiler didn't work ?

ops4j-issues commented 11 years ago

Achim Nierbeck commented

can't remember right now, but somehow it didn't work, but oth that's been before I did that "hack" in runtime setting the jdc compiler.

ops4j-issues commented 11 years ago

Serge Huber commented

Ok I have some good news, I have found the JSP compilation issues. I didn't see earlier that the helloworld-jsp sample project was actually calling the Jetty JSPC precompiler in a Maven plugin. The version of the plugin was still referencing Jetty 7 hence the compilation error we were having.

I synchronized the version to the Jetty version used in PAX Web, added a web.xml file that seemed to be now required and it fixed the JSP Integration tests ! I now still have the following issues on the JSF tests :

Tests in error:
testSlash(org.ops4j.pax.web.itest.WarJSFIntegrationTest): Unresolved constraint in bundle org.apache.myfaces.core.api 54: Unable to resolve 54.0: missing requirement 54.0 osgi.wiring.package; (&(osgi.wiring.package=javax.servlet.jsp.jstl.core)(version>=1.1.2)(!(version>=2.0.0)))
testSlash(org.ops4j.pax.web.itest.WarJSFPrimefacesIntegrationTest): Unresolved constraint in bundle org.apache.myfaces.core.api 54: Unable to resolve 54.0: missing requirement 54.0 osgi.wiring.package; (&(osgi.wiring.package=javax.servlet.jsp.jstl.core)(version>=1.1.2)(!(version>=2.0.0)))
testPrimefacesTagRendering(org.ops4j.pax.web.itest.WarJSFPrimefacesIntegrationTest): Unresolved constraint in bundle org.apache.myfaces.core.api 54: Unable to resolve 54.0: missing requirement 54.0 osgi.wiring.package; (&(osgi.wiring.package=javax.servlet.jsp.jstl.core)(version>=1.1.2)(!(version>=2.0.0)))

I hope this is just a version issue I will try to have a look at this this after noon.

I have committed my modifications in the branch:
https://github.com/ops4j/org.ops4j.pax.web/commit/57f2d71f75f0d3de6ca9d882797862d43e66926d

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Serge Huber commented

Ok more good news, I managed to fix the JSF dependency errors. They were due to an improper version on the javax.servlet.jsp.jstl.* packages. These packages need to be at 1.2 since JSTL 1.2 is linked with JSP 2.2 (as seen here : http://en.wikipedia.org/wiki/Java_EE_version_history)

I now have all the simple tests running without any errors, but there are still some remaining errors when executing the Karaf iTests (despite the fact that they are not reported as failures). Here are the errors :

2013-03-26 12:53:30,510 | WARN | qtp2078766524-69 | ServletHandler | pse.jetty.servlet.ServletHandler 517 | 60 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.9.v20130131 | /war/wc/error.jsp
java.lang.NullPointerException
at java.net.URLEncoder.encode(URLEncoder.java:188):1.6.0_43
at java.net.URLEncoder.encode(URLEncoder.java:154):1.6.0_43
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:474)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)55:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0
at org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:145)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at org.ops4j.pax.web.jsp.JspServletWrapper$2.call(JspServletWrapper.java:141)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at org.ops4j.pax.web.jsp.JspServletWrapper.service(JspServletWrapper.java:140)71:org.ops4j.pax.web.pax-web-jsp:3.0.0.SNAPSHOT
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:457)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:184)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.Server.handle(Server.java:368)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:488)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:932)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:994)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at java.lang.Thread.run(Thread.java:680):1.6.0_43

The above one should be simple to fix. The next ones might be more tricky, as they look more like class loading issues :

2013-03-26 12:54:07,118 | WARN | qtp916347070-70 | / | r.handler.ContextHandler$Context 2031 | 60 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.9.v20130131 | org.ops4j.pax.web.service.spi.model.ServletModel-7: Failed to instantiate plugin org.apache.felix.webconsole.internal.deppack.DepPackServlet
java.lang.NoClassDefFoundError: org/osgi/service/deploymentadmin/DeploymentException
at java.lang.Class.getDeclaredConstructors0(Native Method):1.6.0_43
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2398):1.6.0_43
at java.lang.Class.getConstructor0(Class.java:2708):1.6.0_43
at java.lang.Class.newInstance0(Class.java:328):1.6.0_43
at java.lang.Class.newInstance(Class.java:310):1.6.0_43
at org.apache.felix.webconsole.internal.servlet.PluginHolder$InternalPlugin.doGetConsolePlugin(PluginHolder.java:761)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder$Plugin.getConsolePlugin(PluginHolder.java:532)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder.getLocalizedLabelMap(PluginHolder.java:242)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:420)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)96:org.apache.felix.webconsole:3.1.8
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:457)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:184)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.Server.handle(Server.java:368)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:488)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:932)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:994)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at java.lang.Thread.run(Thread.java:680):1.6.0_43
Caused by: java.lang.ClassNotFoundException: org.osgi.service.deploymentadmin.DeploymentException not found by org.apache.felix.webconsole 96
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247):1.6.0_43
... 36 more
2013-03-26 12:54:07,132 | WARN | qtp916347070-70 | / | r.handler.ContextHandler$Context 2031 | 60 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.9.v20130131 | org.ops4j.pax.web.service.spi.model.ServletModel-7: Failed to instantiate plugin org.apache.felix.webconsole.internal.compendium.ComponentsServlet
java.lang.NoClassDefFoundError: org.apache.felix.scr.ScrService not found by org.apache.felix.webconsole 96
at org.apache.felix.webconsole.internal.compendium.ComponentsServlet.class$(ComponentsServlet.java:74)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.compendium.ComponentsServlet.<clinit>(ComponentsServlet.java:74)96:org.apache.felix.webconsole:3.1.8
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method):1.6.0_43
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39):1.6.0_43
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27):1.6.0_43
at java.lang.reflect.Constructor.newInstance(Constructor.java:513):1.6.0_43
at java.lang.Class.newInstance0(Class.java:357):1.6.0_43
at java.lang.Class.newInstance(Class.java:310):1.6.0_43
at org.apache.felix.webconsole.internal.servlet.PluginHolder$InternalPlugin.doGetConsolePlugin(PluginHolder.java:761)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder$Plugin.getConsolePlugin(PluginHolder.java:532)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder.getLocalizedLabelMap(PluginHolder.java:242)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:420)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)96:org.apache.felix.webconsole:3.1.8
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:457)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:184)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.Server.handle(Server.java:368)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:488)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:932)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:994)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at java.lang.Thread.run(Thread.java:680):1.6.0_43
2013-03-26 12:54:07,143 | WARN | qtp916347070-70 | / | r.handler.ContextHandler$Context 2031 | 60 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.9.v20130131 | org.ops4j.pax.web.service.spi.model.ServletModel-7: Failed to instantiate plugin org.apache.felix.webconsole.internal.compendium.ConfigManager
java.lang.NoClassDefFoundError: org/osgi/service/metatype/ObjectClassDefinition
at java.lang.Class.getDeclaredConstructors0(Native Method):1.6.0_43
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2398):1.6.0_43
at java.lang.Class.getConstructor0(Class.java:2708):1.6.0_43
at java.lang.Class.newInstance0(Class.java:328):1.6.0_43
at java.lang.Class.newInstance(Class.java:310):1.6.0_43
at org.apache.felix.webconsole.internal.servlet.PluginHolder$InternalPlugin.doGetConsolePlugin(PluginHolder.java:761)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder$Plugin.getConsolePlugin(PluginHolder.java:532)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.PluginHolder.getLocalizedLabelMap(PluginHolder.java:242)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:420)96:org.apache.felix.webconsole:3.1.8
at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)96:org.apache.felix.webconsole:3.1.8
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:457)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:184)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)70:org.ops4j.pax.web.pax-web-jetty:3.0.0.SNAPSHOT
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.Server.handle(Server.java:368)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:488)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:932)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:994)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)60:org.eclipse.jetty.aggregate.jetty-all-server:8.1.9.v20130131
at java.lang.Thread.run(Thread.java:680):1.6.0_43
Caused by: java.lang.ClassNotFoundException: org.osgi.service.metatype.ObjectClassDefinition not found by org.apache.felix.webconsole 96
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247):1.6.0_43
... 36 more

I'll try to work on these now, hopefully they will not be too difficult to fix.

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Serge Huber commented

I forgot to add a link to my last commit :

https://github.com/ops4j/org.ops4j.pax.web/commit/b99872a47d27c6cde06426d8802ecb0481f39a7a

ops4j-issues commented 11 years ago

Achim Nierbeck commented

I'd say a couple of those webconsole errors can be ignored since it would require to install scr and other kinds of "tools" from the felix project for those std. plugins to work.

2013-03-26 12:54:07,132 | WARN | qtp916347070-70 | / | r.handler.ContextHandler$Context 2031 | 60 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.9.v20130131 | org.ops4j.pax.web.service.spi.model.ServletModel-7: Failed to instantiate plugin org.apache.felix.webconsole.internal.compendium.ComponentsServlet
java.lang.NoClassDefFoundError: org.apache.felix.scr.ScrService not found by org.apache.felix.webconsole 96

Looks for ScrService definetly not available but safe to ignore.
The webconsole tests are included to make sure the webconsole does work, used to have an issue with that :smile:

thanks for looking at it :smile:

ops4j-issues commented 11 years ago

Serge Huber commented

Ok I checked the master branch and it seems the web console errors are also present there, so I will ignore them for the moment.

For the NPE it seems it was a change in the JspServlet implementation where they have added a call to URLEncode.encode and this is causing the problem. So I'm not too sure how to fix this problem. If you have any ideas I'm very interested :smile:

I'm hoping we don't have to fork the JspServlet for this but maybe that would be the only option ?

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Ok, I'm gonna take a look at it later, and possibly also merge the latest changes of master into this branch, makes it easier for merging this branch back into master later.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

The JspServlet probably does have the NPE due to the
https://github.com/ops4j/org.ops4j.pax.web/blob/PAXWEB-304/pax-web-jetty/src/main/java/org/ops4j/pax/web/service/jetty/internal/HttpServiceContext.java#L300
cause at that method we do return null in case no resource is found.
Might be good to dig there :smile:

ops4j-issues commented 11 years ago

Serge Huber commented

Thanks Achim, I had come to the same conclusion.

Actually it looks like the HttpServiceContext is doing nothing wrong. It seems to me that actually this looks more like a JDK bug because it should just return null if we try to encode a null String. Also, I tried to track down the original JspServlet SVN location but I couldn't find it neither at Eclipse nor at Glassfish. At Eclipse it's part of Eclipse Orbit that repackages source and binary JARs coming from somewhere at Glassfish, but I couldn't find the project at Glassfish that has this class (with this implementation at least).

Look at Jasper's source code over at Apache I see that their implementation is completely different (they now have a handleMissingResource method), and they never encode the string.

I just found a commit that completely removes this encoding code :
http://java.net/projects/jsp/lists/commits/archive/2011-05/message/0

Also it's not clear which is now the real location where Jasper development is happening since there seems to be more commit activity at java.net's project : https://svn.java.net/svn/jsp~svn/trunk than on Tomcat's trunk : http://svn.apache.org/repos/asf/tomcat/trunk/

So it looks like more recent versions of the Glassfish JSP implementation should solve this problem, but we still need to figure out what we do in the meantime.

Also, if we do decide to use a more recent version of the class from the Glassfish JSP how do we handle license issues ? The class has an Oracle license header although the code is also under an Apache Licence but the Oracle part clearly says "DO NOT REMOVE" ? The JspServlet class looks a lot more different so I would recommend using that one.

ops4j-issues commented 11 years ago

Serge Huber commented

Here is the latest stable one from Tomcat :

http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_39/java/org/apache/jasper/servlet/JspServlet.java

And in the Java.net impl :

https://svn.java.net/svn/jsp~svn/trunk/impl/src/main/java/org/apache/jasper/servlet/JspServlet.java

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Serge Huber commented

Hello,

I started testing the modifications in this ticket with my own application. It uses the Felix Http Bridge as my application actually is a web application that embeds an OSGi framework and uses the Http Bridge to bridge the requests internally.

Unfortunately the Felix Http Bridge only supports Servlet API 2.5, and the new Jetty 8 JSP engine (Jasper 2.2) implementation requires a Servlet API 3.0 implementation to run. Forking the Felix Http Bridge would require some major work and I don't think this is good timing right now.

Also the last issue with the JspServlet could be tricky to resolve if licensing is a problem ?

Despite all the hard work I put this I now think that it would probably be better to push this issue to a post 3.0.0 release so that it is still possible to run PAX Web JSP inside Servlet API 2.5 projects. Does this sound reasonable ? We could then integrate this in post-3.0 version of PAX Web ? Of course I'm assuming that PAX Web 3.0 is nearing release, if it's not schedule for the next months then this could be integrate for 3.0.

What are your thoughts on this ?

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Serge Huber, a big thank you for looking into this. I was offline all day that's why I wasn't able to interact earlier.

I know you put a lot of effort into this, and I think we are almost there.
I think the Licensing is an issue, that's why I think a redo based on the pure Apache Tomcat Jasper part needs to be done.
Regarding the Servlet Bridge, it might be interesting in actually thinking about forking it so it will work with Pax-Web smoothly.

Since all this development has been achieved on a seperate branch I think it's also safe to postpone it to a 3.1 or later.

ops4j-issues commented 11 years ago

Serge Huber commented

Hello Achim,

Thanks for your reply. I've updated the affect/fix version fields to reflect that we will move this to 3.1. Btw do you have an idea when you expect to release 3.0.0 ?

I was also thinking that it might be good to integrate the work done on this branch with the upgrade to Jetty 9. I see you have already created a ticket for that and that it is planned for 3.1. What do you think about that ? I could then link the two tickets together to indicate that this should happen at the same time.

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

I've been playing with migrating to the tomcat jasper implementation last night looks promising though could take a bit longer. 3.1 is probably the best, this way I'm able to cut tthe RC1 shortly. Just one more issue reported from the karaf community.

ops4j-issues commented 11 years ago

Serge Huber commented

Ok thanks a lot.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

I switched to using the Apache Tomcat Jasper, this way we're safe on the ASF License.
Only one test is failing I didn't really find the reason for this.

Commit: ae1f29254f1fe85f44c63c6b64cb146cf003af68
https://github.com/ops4j/org.ops4j.pax.web/commit/ae1f29254f1fe85f44c63c6b64cb146cf003af68

ops4j-issues commented 11 years ago

Achim Nierbeck commented

We still have an Issue with already pre-compiled JSPs.
If you select Pre-Compiled inside Container it should work, but right now the pre-compiled JSPs are not found, cause it tries to compile them actually (and not finding them).
Still a real bummer, besides that everything is fine.

ops4j-issues commented 11 years ago

Serge Huber commented

Sorry I've been incredibly busy these last days.

Last time I had this problem it was due to the fact that in the projects we were using for building the precompiled JSPs we were either using a different version of the JSP API or JSP impl. Could you check if this is still the case ? I had added in my changes a variable to make sure that they stay in sync but maybe that modification was removed when switching to the Apache implementation ?

Best regards,
Serge Huber.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

No Problem about being busy, I just tried to get rid of this, cause it's just one tiny little issue we face.
Well actually the compiled JSPs are there it's more of the problem that the new Tomcat based Jasper doesn't know of "pre-compiled" JSPs and plainly tries to compile a jsp that is actually not there cause it should be compiled already.
It's all about just this line of code:
https://github.com/ops4j/org.ops4j.pax.web/blob/PAXWEB-304/pax-web-jsp/src/main/java/org/apache/jasper/servlet/JspServletWrapper.java#L349

regards, Achim

ops4j-issues commented 11 years ago

Achim Nierbeck commented

I went through the documentation of how the Tomcat Jasper project does handle the JSP precompiled servlets and found that the corresponding precompiling maven plugin does actually change the web.xml in a way that the precompiled jsps are actually registered as servlets.
For example I found the following webfrag.xml in the target folder of our helloworld-jsp sample project.

<!--
Automatically created by JspC.
Place this fragment in the web.xml before all icon, display-name,
description, distributable, and context-param elements.
-->

    <servlet>
        <servlet-name>org.apache.jsp.helloworld.jsp.simple_jsp</servlet-name>
        <servlet-class&gt;org.apache.jsp.helloworld.jsp.simple_jsp</servlet-class&gt;
    </servlet>

    <servlet>
        <servlet-name>org.apache.jsp.helloworld.jsp.using_002dtld_jsp</servlet-name>
        <servlet-class&gt;org.apache.jsp.helloworld.jsp.using_002dtld_jsp</servlet-class&gt;
    </servlet>

    <servlet-mapping>
        <servlet-name>org.apache.jsp.helloworld.jsp.simple_jsp</servlet-name>
        <url-pattern>/helloworld/jsp/simple.jsp</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>org.apache.jsp.helloworld.jsp.using_002dtld_jsp</servlet-name>
        <url-pattern>/helloworld/jsp/using-tld.jsp</url-pattern>
    </servlet-mapping>

<!--
All session-config, mime-mapping, welcome-file-list, error-page, taglib,
resource-ref, security-constraint, login-config, security-role,
env-entry, and ejb-ref elements should follow this fragment.
-->

So actually this just requires us to change the way pre-compiled jsps are handled!
And actually just change the documentation for it.

I'm gonna change the activator of the helloworld-jsp sample project to test if this is actually already it!

ops4j-issues commented 11 years ago

Serge Huber commented

Ok I thought you already knew that :smile:

So in effect it's not a question about knowing that they were already compiled, it's just that if they were precompiled the request should be served by the compiled class (through the servlet mapping), not through the JspServlet.

Best Regards,
Serge Huber.

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Yes, that's the change to how it previously worked.
By the previously used version of the jasper it was implicitly done by the compiler.

regards, Achim