JETTY-129 is not resolved.

Leena,

So I can attempt to reproduce this, what's your setup? Are you using jetty embedded or standalone? Do you have any special configuration of your context, or are you just deploying a straight webapp? Are you using any of the servlet 3.0 features such as annotations?

thanks
Jan

Thanks Jan, that is really a quick response.

So here is my detailed problem statement:

Technology stack for ACL (our application): Maven, Jetty and Jersey JAX-RS (for RESTful webservices),Spring 3.0

The ACL exposes a REST API and it is implemented using Jersey JAX-RS. To make code testable we wanted introduce IoC so we decided to use spring, and there is spring integration also available for Jersey.

On mvn clean install jetty:run, we are able to post the request to the exposed RESTful API.And it is working all fine.

But issue starts here: We have functional tests written in Cucumber for ACL service.
So we wanted to start the Jetty programmatically (by embedding Jetty). For this purpose we have created the executable jar for ACL(which has all dependencies). The main class, loads the webcontext and starts jetty as below.

ServletHolder sh = new ServletHolder(new ServletContainer(new PackagesResourceConfig("com.delta.api.resources")));
server = new Server(8080);
ServletContextHandler sch = new ServletContextHandler(server, "/");
sch.addServlet(sh, "/*");
server.start();
server.join();

It was working smooth until we introduced spring. For spring to work we modified above code as:
sch.getInitParams().put("contextConfigLocation", "classpath:applicationContext.xml");
sch.addEventListener(new ContextLoaderListener());

After incorporating this, it started loading the spring's application context. But it was loading it after the servlet instantiation ( ServletContextListeners called after servlets are initialized). Hence any method call on autowired objects in servlets started causing NPE.
After googling on it I found out that it is bug in jetty-servlet module and it is fixed in 6.0.2 (JETTY-129 ServletContextListeners called after servlets are initialized - jira.codehaus.org ); but we are using the latest version of jetty-servlet and it much ahead than this one. But still it does not work.

==========================================================================================
The maven dependancies are:

<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>8.1.1.v20120215</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>8.1.1.v20120215</version>
</dependency>

<dependency>
<groupId>jetty</groupId>
<artifactId>jetty</artifactId>
<version>5.1.10</version>
</dependency>

==========================================================================================
web.xml looks like:

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>

<servlet>
<servlet-name>jersey-serlvet</servlet-name>
<servlet-class>
com.sun.jersey.spi.spring.container.servlet.SpringServlet
</servlet-class>
<init-param>
<param-name>
com.sun.jersey.config.property.packages
</param-name>
<param-value>com.delta.api.resources</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>jersey-serlvet</servlet-name>
<url-pattern>/service/*</url-pattern>
</servlet-mapping>

==========================================================================================

This is the complete ACL project

I have attached the ACL project as zip.
com.delta.api.control.ApiServerRunner class is trying to start Jetty in embedded manner.

I have also encountered this problem. See the discussion on the Spring Forums and also here.

I was attempting to launch a simple webapp which uses a WebApplicationInitializer to register a Root Spring Application context and a DispatcherServlet. The issue is that the DispatcherServlet is initialized before the root context but needs to reference beans in the root context.

I have posted a work around on the forum.

Minimum test code.

Leena,

I've slightly modified the smallest example of using a Servlet and ServletContextHandler from the jetty embedded examples - the attached files are HelloServlet.java and OneServletContext.java. Put all the jetty files on the classpath and compile and execute those. I haven't been able to reproduce the ordering issue you describe, so you modify this simple code until it most closely resembles your embedded usage and reproduces the problem?

thanks
Jan

Leena,

Looking at your pom, I notice you are using version 6.1.10 of the jetty-maven-plugin, which means that at runtime, you are actually using jetty-6.1.10. You need to be using version 8.1.1.v20120215 (same as your dependencies), or better still, upgrade both the dependencies and plugin to the latest release 8.1.2.v20120308.

You also have some very old jetty classes on the dependency list (jetty-5!) I would definitely remove those.

Jan

I have created a tiny project which reproduces this issue using the jetty-maven-plugin 8.1.2.v20120308.

jetty:run fails because the spring app cannot autowire dependencies in a controller because the service is declared in the root context (this is registered as a listener so should already have been loaded).

Hi Alex, I just went through the solution you provided at http://forum.springsource.org/showthread.php?122876-Root-Application-Context-loading-after-Dispatcher-Context&p=405003#post405003.
But I do not think I will able to use that as I am not using spring-mvc (Dispatcher Servlet) instead I am using Jersey (another Front Controller)

@Jan: Can you please fix this issue in Jetty ASAP.

Leena,

Please don't forget this is an open-source project. If you need something fixed "ASAP", can I remind you that you can contact "sales@webtide.com" for a commercial support agreement.

Jan

Alex,

Thanks for that test case, it has helped localize the problem.

Jan

This issue was incorrectly closed as incomplete.

@Jan

Great news. I look forward to testing this fix when it's released. Do you know when 8.1.3 will be available through Maven?