• Ensure that you have the RWT 1.5 Nightly Build later than October 6th, because there was a bug on registering RWT resources.
• There is a strange bug of IBM WebSphere Application Server 8 that provides the Servlet 3.0 API with the javax.servlet.* packages exported as version 2.6.0! Fortunately, the RAP team has minded this bug. Thanks guys!
• I did not already test the whole RAP platform, only RWT and JFace.
• I only got it work using the isolated way of running the RWT platform. WebSphere provides a Shared Bundle Framework to all applications. Each application is run in an isolated framework, but can access services running in the Shared Bundle Framework. It is possible to install the OSGi Http Service into the Shared Bundle Framework and register servlets of applications to this service. This way, you have a single context root that can be extended by multiple applications. Installing the org.eclipse.rap.rwt bundle into the Shared Bundle Framework did not work because of some strange errors (without any details). I have tested to remove some entries from the manifest file, but this is like finding the needle in a haystack. And I guess, this would not be the default scenario because isolation is one of the requirements to multiple applications running on a single server.

You can find my demo EBA here. The RWT and JFace bundles are not packaged into the EBA. You can add those that are named within the META-INF/APPLICATION.MF file to the EBA or provide the bundles using WAS’ bundle repository configuration. Take care of the versions, because I used RWT 1.5 with Eclipse 3.6.0 bundles, because WebSphere Application Server provides the org.eclipse.osgi bundle version 3.6.0.

After installing this EBA on WebSphere Application Server, you can open the demo with the URL http://<host&gt;:<port>/http/demo. You should then get this:

Servlet Annotations

@WebServlet(value = "/control", name="Controller Servlet", initParams = { 
  @WebInitParam(name = "param1", value = "value1"), 
  @WebInitParam(name = "param2", value = "value2") 
})
public class ControllerServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {
    // implement request processing
  }
}

Okay, it’s a nice feature that servlets can now be declared using annotations to replace the web deployment descriptor and to have all metadata within the Java code. This fits common concepts of modern frameworks. But the Servlet API is still invasive, i.e. you have to implement a Servlet interface and you are dependent from a request and a response object which makes testing difficult. I would expect to change this in the future, but it does not seem to matter in the next release. So you have to extract your controller logic from the Servlet API by yourself or use frameworks like Spring Web furthermore.

Pluggability

Since Servlet API 3.0, it is possible to split a web module into (a web module and) multiple web fragments. Web applications can be divided by special functionality, and web frameworks can configure the web application by itself instead of writing manuals how to install the framework into the web application. In addition, servlets, filters and listeners can be installed into the web application programmatically (in a very dynamic way).

final Dynamic servlet = getServletContext()
  .addServlet("Controller Servlet", new ControllerServlet());
servlet.addMapping("/control");
servlet.setInitParameter("param1", "value1");
servlet.setInitParameter("param2", "value2");

With regard to OSGi, the concepts of web fragments and OSGi bundle fragments are very similar, because both extend web modules and OSGi bundles respectively. But the devil is in the details, because

• OSGi bundle fragments have a dependency to a single host bundle, whereas web fragments are published into the WEB-INF/lib folder of the web app (any desired web app!) – so we have reverse dependencies
• Servlets, filters and listeners can only be registered during application startup within a ServletContextListener (and cannot be removed) – so in comparison to the lifecycle of OSGi bundles, it does not provide such a dynamic behaviour. If you want to register and remove servlets at runtime without restarting the web application, you should use the OSGi HttpService that only provides a Servlet 2.x API. (see my notes on “Using the OSGi Http Service on IBM WebSphere Application Server”)

Upload Support

@WebServlet("/upload.html")
@MultipartConfig(
  location = "/upload-files", 
  fileSizeThreshold = 1024 * 1024, 
  maxFileSize = 1024 * 1024 * 5, 
  maxRequestSize = 1024 * 1024 * 5 * 5
)
public class FileUploadServlet extends HttpServlet {

  @Override
  protected void doPost(HttpServletRequest req, HttpServletResponse resp)
      throws ServletException, IOException {
    resp.setContentType("text/plain");
    final PrintWriter out = resp.getWriter();
    try {
      final Collection<Part> parts = req.getParts();
      out.println("Total parts : " + parts.size());
      for (Part part : parts) {
        out.println();
        out.println("Name : " + part.getName());
        out.println("Content-Type : " + part.getContentType());
        //part.getInputStream();
      }
    } finally {
      out.close();
    }
  }
	
}

Nice feature. The location attribute of the @MultipartConfig is used as temporary directory to store uploaded files on the server. You can specify both an absolute and relative (to the app server’s temp) directory.

Be aware that WebSphere Application Server uses the web app’s installation directory as the temporary directory and does not prevent that the location attribute has the value “/WEB-INF“.

Asynchronous Request Processing

final AsyncContext ctx = request.startAsync();
executor.execute(new Runnable() {
			
  @Override
  public void run() {
    // Asynchronous processing
    // Write response
    // Complete request processing
    ctx.complete();
  }
});

Okay, I understood that I can use it for “COMET”, “Reverse Ajax” or however they call it. For me, it sounds like the possibility to shift the problems that occur within the request processing thread to another thread.
The risk is that the web container’s thread limitation is bypassed. This should only be used for managing custom queues or any other algorithm that does not slow down performance when it is invoked 100 times in parallel.

Contexts and Dependency Injection (CDI)

This is the greatest new feature of Java EE 6 for me. It allows to simplify application code by using annotations to manage beans and replace lookups. CDI also introduces Interceptors and Decorators for cross-cutting concerns (e.g. logging, dealing with transactions) and to extend the business logic by separate components.
Concerning OSGi, it would be helpful to get OSGi services injected into a servlet or EJB. Apache Aries declares such a possibility with the usage of the @Resource annotation.

@Resource(lookup = "osgi:service/de.ars.demo.helloworld.api.HelloWorldService")
private HelloWorldService hw;

This should also be possible using the @Inject annotation with a qualifier to avoid the usage of JNDI namespaces. GlassFish provides such a mechanism:

@Inject @OSGiService
private HelloWorldService hw;

Wouldn’t it be nice to have such dependency injection within (non-JavaEE) OSGi environments too? I guess this could be a good alternative to declarative services. I know that OSGi core does not use annotations to support (all) mobile devices (that do not run a Java 5 JVM), but it could be part of OSGi enterprise. Eclipse 4.x also uses these annotations for dependency injection. So CDI has the potential to provide an application model for multiple environments (because it is independent from the environment).

CDI interceptors can be used for cross-cutting concerns.

@AroundInvoke
private Object log(InvocationContext ctx) throws Exception {
  final long d1 = System.currentTimeMillis();
  try {
    return ctx.proceed();
  } finally {
    final long d2 = System.currentTimeMillis();
    log("Method " + ctx.getMethod().getName() + " invoked (" + (d2 - d1) + "ms)");
  }

This is a simple example for an interceptor within a single class. Interceptors can also be written as separate classes and bound to other classes or single methods using a custom annotation.
OSGi 4.3 introduced a Weaving Hook mechanism for bytecode instruction. The developer has to use frameworks like Javassist or ASM to add concerns. But CDI interceptors are much easier to use…

Bean Validation API

The Bean Validation API also uses annotations to declare constraints. Within the Java EE environment, managed beans are validated automatically at some layers, but validation can also be done programmatically.

This could be the code of a servlet class (maybe a little bit dirty to change instance variables during request processing):

@Inject
private Validator validator;
@Inject
private Person person;

protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException {
  person.setFirstName(request.getParameter("firstName"));
  person.setLastName(request.getParameter("lastName"));
  person.setEmail(request.getParameter("email"));
  final Set<ConstraintViolation<Person>> result = validator.validate(person);
  // continue...
}

Bean validation is automatically invoked when using JSF. But it’s a cool thing that can also be used out-of-the-box.

Conclusion

Java EE 6 introduces some nice features. Especially CDI for resolving OSGi service instances would be very cool. I have a dream… that the whole CDI framework is part of the Eclipse 4 application programming model.
There are still some stumbling blocks like the “web fragment vs. OSGi bundle fragment” comparison.

OSGi Feature of WebSphere Application Server

First, let me say some words about the OSGi feature in general. You can find a very detailed introduction at developerWorks. Developers that are familiar with OSGi core concepts should notice the following specifics:

• WAS7 provides the org.eclipse.osgi bundle version 3.5.2 to OSGi applications, WAS8 provides version 3.6.1.
• Although Equinox is the OSGi runtime, it is not intended to support features like the Extension Point Registry or the Declarative Services Specification.
• WAS implements the OSGi Web Application Specification. Enterprise Applications are now deployed as Enterprise Bundle Archives (EBAs instead of EARs), Web modules are packaged as Web Application Bundles (WABs instead of WARs). Non-OSGi WARs can be part of an EBA and are automatically wrapped into a WAB.
• WAS integrates Apache Aries technologies. OSGi Services can be declared by using the OSGi BluePrint Container specification. OSGi services are published to the JNDI and vice versa to connect both “worlds”.
• Because one very important requirement to an application server is the isolation of enterprise applications, OSGi applications are launched within their own framework. Nevertheless, it is possible to resolve bundles from a bundle repository, which are then shared between multiple applications. See the following picture from the WAS7 Infocenter that explains these facts:
  

  Isolated Frameworks

• It is possible to place bundles within a composite bundle, which is then started within its own framework too. An EBA can contain single and composite bundles.
• Bundle dependencies should be declared using the Import-Package header. On WAS, the Require-Bundle header is only allowed between bundles within the EBA. It is not possible to declare this header within a bundle of the EBA to a bundle resolved from the shared repository. (The EBA manifest names a list of bundles and their versions that can be resolved from the shared repository.)
• I use IBM Rational Application Developer V8 with PDE to create OSGi applications for WebSphere. It is also possible to use Eclipse PDE and install the IBM Rational Development Tools for OSGi Applications into the IDE.

OSGi Http Service Implementation of Equinox

The Equinox Server-Side Project provides an implementation of the OSGi Http Service Specification. The HttpServiceServlet registers the service at the platform and delegates requests from the webcontainer to the Http Service. In contrast to previous versions of WAS, we do not need the BridgeServlet anymore, that launches an external OSGi framework and does not allow sharing resources between multiple applications.

So we need the org.eclipse.osgi.services bundle (that defines the HttpService interface) and the org.eclipse.equinox.http.servlet bundle (containing the HttpServiceServlet). They are configured to be part of the PDE target platform. To make them available on WAS for testing your applications, you can install them into the internal bundle repository or refer to an external bundle repository that can be created using the OSGi BIndex Tool.

Creating the WAB

We need to create a WAB that delegates incoming requests from the web container to the OSGi platform. After creating the OSGi Bundle Project, do the following steps:

• Extend the Import-Package header of the manifest to list the “org.eclipse.equinox.http.servlet” package.
• Add a servlet to the web.xml with the servlet class “org.eclipse.equinox.http.servlet.HttpServiceServlet” and the URL mapping “/*”. Configure the servlet to be initialized immediately, if you want the HttpService implementation to be published to the OSGi platform during application startup, which can be a long operation because this can invoke the registration of servlets to the HttpService by other bundles.

That’s all! You can download the example WAB.

Using the OSGi Http Service

You can bind the Http Service programmatically using OSGi Servicetracker, or you can use Blueprint. See the BluePrint file example below:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
	<bean id="ServletRegistry"
		class="de.ars.ws.http.example.internal.ServletRegistry" />
	<reference interface="org.osgi.service.http.HttpService"
		activation="eager" availability="optional">
		<reference-listener bind-method="bind" unbind-method="unbind" ref="ServletRegistry"/>
	</reference>
</blueprint>

And the bean that registers the servlet to the Http Service:

package de.ars.ws.http.example.internal;

import java.util.logging.Level;
import java.util.logging.Logger;

import javax.servlet.ServletException;

import org.osgi.service.http.HttpService;
import org.osgi.service.http.NamespaceException;

public class ServletRegistry {

	private static final Logger logger = Logger.getLogger(ServletRegistry.class
			.getName());

	public void bind(HttpService service) {
		if (null != service) {
			try {
				logger.log(Level.INFO, "HTTP Service bound: " + service);
				service.registerServlet("/example/servlet", new ExampleServlet(service),
						null, null);
				service.registerResources("/example/resources", "/resources", null);
			} catch (ServletException e) {
				logger.log(Level.WARNING,
						"Unable to register example servlet!", e);
			} catch (NamespaceException e) {
				logger.log(Level.WARNING,
						"Unable to register example servlet!", e);
			}
		}
	}

	public void unbind(HttpService service) {
		if (null != service) {
			logger.log(Level.INFO, "HTTP Service unbound: " + service);
			service.unregister("/example/servlet");
			service.unregister("/example/resources");
		}
	}

}

You can download the example bundle.

Putting it all together – the EBA

Last but not least, let’s create an EBA with a single META-INF/APPLICATION.MF file with the following content:

Application-Name: Embedded OSGi Http Service
Application-SymbolicName: org.eclipse.equinox.http.embedded
Application-ManifestVersion: 1.0
Application-Version: 1.0.0.qualifier
Application-Content: org.eclipse.equinox.http.embedded.web;version="1.0.0",
  org.eclipse.equinox.http.servlet;version=1.0.200,
  org.eclipse.osgi.services;version=3.2.0,
  de.ars.ws.http.example;version=1.0.0
Manifest-Version: 1.0

This is the isolated version of the Http Service that is created for each application framework. You have to include the Equinox bundles and the WAB for each EBA (take care about the context root of the WAB to be unique) together with your application bundles.

Another possibility would be to share the Http Service between all applications. The EBA manifest would then look like this:

Application-Name: Embedded OSGi Http Service
Application-SymbolicName: org.eclipse.equinox.http.embedded
Application-ManifestVersion: 1.0
Application-Version: 1.0.0.qualifier
Application-Content: org.eclipse.equinox.http.embedded.web;version="1.0.0"
Manifest-Version: 1.0
Use-Bundle: org.eclipse.equinox.http.servlet;version=1.0.200,
  org.eclipse.osgi.services;version=3.2.0

You can download the EBA.

The difference is that the HttpServiceServlet is resolved from the bundle repository, which causes the HttpService to be published to the Shared Bundle Space. Your application bundles can then be packaged into a separate EBA.

Conclusion

As you can see, it is possible to use the OSGi Http Service both within isolated applications and within a shared space where the Http Service acts as a singleton like the web container does (with the exception that the Http Service does not support context roots). The next step is to test how to deploy the Rich Ajax Platform on WebSphere Application Server.