Community
Participate
Working Groups
I'm trying to deploy a webapp (war file) into jetty, within an OSGI bundle. I want to do it in the traditional way (not though httpservice but by starting a new jetty server instance). The code for that looks like this (and works perfectly when OSGI is not in the picture): Server s2 = new Server(port); ContextHandlerCollection contexts = new ContextHandlerCollection(); s2.addHandler(contexts); WebAppContext webapp = new WebAppContext(); webapp.setWar("x.war"); webapp.setExtractWAR(true); webapp.setContextPath("/x"); contexts.addHandler(webapp); However, when the bundle is started within equinox, a mysterious exceptions occurs. Generated servlet error: The method getPageContext(Servlet, ServletRequest, ServletResponse, String, boolean, int, boolean) in the type JspFactory is not applicable for the arguments (index_jsp, HttpServletRequest, HttpServletResponse, null, boolean, int, boolean) at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:84) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:328) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:414) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:297) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) ... After some googling it seems to me that the issue may originate from the Eclipse JDT compiler (Jasper makes use of the Eclipse JDT compiler and there's some messup with the classpath(?)). I found a few patches and classpath/manifest tricks for similar problems but none of them seems to work. Versions & workarounds I tried: (1) 3.5.1 OSGI + javax.servet, javax.xml, org.apache.jasper, jetty-util, jetty-servlet, org.apache.commons.logging, org.apache.commons.el (2) (1) + buddy policy (3) 3.5.1 OSGI + jetty, jetty-util, jsp-2.1-glassfish, jsp-api-2.1-glassfish, jsp-2.1-jetty, servlet-api, core-3.1.1 (4) (3) + optional imports in manifests, DynamicPackage-Import: * (5) (4) but with ecj-3.5.1 instead of core-3.1.1 In all cases I managed to get all the bundles loaded and started (status is ACTIVE for each of them). When I start the OSGI framework there's no sign that anything would be wrong. But the exception occurs when I load the test page in the browser. The webapp (war file) itself cannot be the cause (there's just one jsp in it saying hello world). I also tried to track when does the jsp complation go wrong. I could locate the generated index_jsp code (from index.jsp) in the folder used by jetty, and the file seems to be syntactically OK. Any help is welcome. Cheers, Borbala
I assume you are using a bundlized version of jetty. Moving to Jetty for now.
I think this bug belongs to Equinox. Jetty alone is fine. Equinox + bundled Jetty does not work together.
(In reply to comment #2) > I think this bug belongs to Equinox. > Jetty alone is fine. > Equinox + bundled Jetty does not work together. Not necessarily. Just because some 3rd party library does not work on OSGi does not mean it is a bug in the OSGi implementation. For now I think this bug belongs here where the jetty experts can help in running jetty on OSGi. And I know it can and has been done. Can you answer the question from comment 1.
Yes it's the bundled version of jetty. (http://download.eclipse.org/equinox/drops/R-3.5.1-200909170800/index.php) Thanks.
Could someone advise please?
This version of jetty is jetty6 as bundled with Equinox. I authored the patch to jasper that supports either ecj-3.1.1 or a later version of ecj: https://jsp.dev.java.net/issues/show_bug.cgi?id=13 When I encounteredt the problem the stack trace was: java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/IProblem; at org.apache.jasper.compiler.JDTJavaCompiler$2.acceptResult(JDTJavaCompiler.java:442) I suspect that your stack trace reflect a classloading issue. The sample code will not work without a lot of extra glue code to make it work. The jasper classloader does not fit out of the box into the OSGi classloaders which certainly explain the weird stack traces you are looking at. I am not familiar with the equinox integration of jsp but I don't think it supports web-applications. Here is the doc: http://www.eclipse.org/equinox/server/jsp_support.php An alternative is to use the jetty-osgi integration we put in place for helios. It does support webapplication that contains jsp pages.
Thanks, it's sad to hear that JSP won't work with pure jetty under Equinox... > The jasper classloader does not fit out of the box into the OSGi classloaders > which certainly explain the weird stack traces you are looking at. Agree. > I am not familiar with the equinox integration of jsp but I don't think it > supports web-applications. > Here is the doc: http://www.eclipse.org/equinox/server/jsp_support.php I already tried this but didn't help. > An alternative is to use the jetty-osgi integration we put in place for helios. > It does support webapplication that contains jsp pages. That's not an option for me. I have to integrate two existing systems: one of them is an OSGI bundle and the other one is a webapp. The point is that the two systems have to use the same singleton instance of a common class (which plugs in extra hardware). The problem is that Equinox creates separate classloaders for each bundle, so each bundle has its own copy of the common class (with its own singleton), instead of sharing the same instance. So, it's not an option for me to have system1 and the webapp in two separate OSGI bundles (e.g. to put the webapp into the OSGI HttpService bundle). All I can do is to start a Jetty for the webapp from system1. But obviously that won't work due to classloading issues... Can you maybe spot any alternative direction to solve this?
(In reply to comment #7) > > An alternative is to use the jetty-osgi integration we put in place for helios. > > It does support webapplication that contains jsp pages. > > That's not an option for me. > I have to integrate two existing systems: one of them is an OSGI bundle and the > other one is a webapp. The point is that the two systems have to use the same > singleton instance of a common class (which plugs in extra hardware). > The problem is that Equinox creates separate classloaders for each bundle, so > each bundle has its own copy of the common class (with its own singleton), > instead of sharing the same instance. > So, it's not an option for me to have system1 and the webapp in two separate > OSGI bundles (e.g. to put the webapp into the OSGI HttpService bundle). All I > can do is to start a Jetty for the webapp from system1. But obviously that > won't work due to classloading issues... > > Can you maybe spot any alternative direction to solve this? With jetty-osgi you have multiple options 1- traditional J2EE: put your shared classes into the folder where the shared libraries are placed. jetty-osgi places them in lib/ext 2- OSGi route: package your common classes into an OSGi bundle and add the directive ":singleton=true" In the MANIFEST.MF of your 2 webapps add this bundle as a dependency. It will do what you want.
I suggest we mark this bug as invalid. There is not much else we can do. Borbala, let me know if you want to use jetty-osgi or the EclipseRT Web Starter Kit to support your scenario.
I guess the original problem - that JSP classloaders fall outside of the OSGI classloding tree and there's no way to get them together - is still there. I'm not familiar with your issue marking policy, please do as you think it's right (WONTFIX?). I managed to resolve the problem in my specific case by throwing out the original JSP based webapp, rewriting it to a non-JSP technology (GWT). Then, I used the Equinox HttpService to map the resources & servlets. Lessons learnt: (1) JSP is only supported for standalone webapps (there's no way to access any other bundle from JSP). (2) The integration of classic web applications (war files) into Equinox is just not supported. There may be workarounds, but there's no comprehensive overview/documentation about this area. However, forums/bug reports are relaly helpful. (3) If your webapp consists of servlets + static resources only, the integration is quite easy. All you have to do is to rewrite the content of the web.xml into an OSGI-understandable format, and add an Activator class (http://www.eclipse.org/equinox/server/http_writing_application.php). This way also the classloading hierarchy will be OK, so the webapp is able to interact with other bundles. @Hugues: thanks for your support & suggestions. Borbala
(In reply to comment #10) > > Lessons learnt: > (1) JSP is only supported for standalone webapps (there's no way to access any > other bundle from JSP). > (2) The integration of classic web applications (war files) into Equinox is > just not supported. There may be workarounds, but there's no comprehensive > overview/documentation about this area. However, forums/bug reports are relaly > helpful. Thanks for the feedback. Indeed war files are not supported by Equinox itself. For the record, the OSGi Entreprise Expert Group has released Enterprise Version 4.2 in March 2010. This describes the support for web-bundle. That covers the support of JSP. The spring-DM team is working on the reference implementation of this part of the spec. The jetty project also supports JSPs inside web-bundles. The integration is tricky with Jasper as it is for all the reasons you describe but it can be done.
