Apache Felix HTTP Service

This is an implementation of the R8.1 Whiteboard Specification for Jakarta Servlet, HTTP Whiteboard Service as described in chapter 140 of the OSGi Compendium (R7) in combination with an implementation of the HTTP Service Specification as described in chapter 102 of the OSGi Compendium. The goal is to provide a standard and simplified way to register servlets, listeners, filters, and resources in a servlet container, to managed them in servlet contexts, and to associate them with URIs. Complete set of features:

  • Standard OSGi Http Service implementation
  • Standard OSGi Http Whiteboard implementation
  • Run either with Jetty (version 11 or 12) bundle or inside your own application server using the servlet bridge
  • Correctly versioned Servlet API.

Installing

The Apache Felix HTTP Service project includes several bundles.

Note that as of version 3.x, the Servlet APIs are no longer packaged with the implementation bundles! If you are migrating from lower versions, be sure to add the org.apache.felix.http.servlet-api (or any other compatible Serlvet API bundle) to your classpath and deployment!

Using classifiers: light, with-jetty-websockets and with-jakarta-websockets bundle

If you would like to use your own Jetty jars instead of the one packaged with the Felix Jetty bundles, you can use the variants with the following classifiers:

  • light - A light version of the bundle that does not include the Jetty classes. This is useful when you want to use your own Jetty jars. Available for both Jetty bundles.
  • with-jetty-websockets - A bundle that includes the classes required for Jetty WebSocket support for Jakarta EE10. Jetty12 bundle only.
  • with-jakarta-websockets - A bundle that includes the classes required for Jakarta WebSocket support for Jakarta EE10. Jetty12 bundle only.

When building the Felix Jetty bundle with Maven (mvn clean install), the additional bundles will be created in the target directory, postfixed with classifier. This jar can be deployed to your Felix OSGi environment, along with a compatible Jetty jars. See the unit tests for the required bundles and versions that need to be deployed.

Or just use maven to include the dependency with the proper classifier.

<dependency>
   <groupId>org.apache.felix</groupId>
   <artifactId>org.apache.felix.http.jetty12</artifactId>
   <version>1.0.2</version>
   <classifier>light</classifier>
   <scope>runtime</scope>
</dependency>

Installing additional bundles for the optional HTTP/2 support with jetty

Configure org.apache.felix.http2.enable=true to enable HTTP/2 in Jetty.

The Jetty implementation uses the OSGi ServiceLoader mediator technique to find certain pluggable components that are required for HTTP/2 support. Your OSGi runtime must first have the bundles needed for OSGi ServiceLoader support deployed. Background information about the OSGi ServiceLoader integration is discussed here

Deploying the following set of bundles would be one way to enable the ServiceLoader mediator support:

Jetty 12 bundle

For the Jetty 12 bundle, start the following set of bundles before the Jetty 12 bundle, but after the beforementioned ServiceLoader bundles (the order is important and can be configured in felix.auto.start.1). The Jetty version should correspond with the version used in the Jetty 12 bundle.

Jetty 11 bundle

For the predecessor Jetty 11 bundle, depending on your server environment, you must choose only one of the following sets of additional bundles to deploy as described in the jetty documentation

  1. For java 9 or later:

    • org.eclipse.jetty.alpn:alpn-api:1.1.3.v20160715
    • org.eclipse.jetty:jetty-alpn-java-server:${jetty.version}

  2. For java 8:

    • org.eclipse.jetty:jetty-alpn-openjdk8-server:${jetty.version}

    • For java 8 versions earlier than 1.8.0_252 download and add -Xbootclasspath/p:/path_to_file_here/alpn-boot-8.1.13.v20181017.jar as an argument to the java process and then deploy the following bundle:

      • org.eclipse.jetty.osgi:jetty-osgi-alpn:${jetty.version}

    • For java 8 version 1.8.0_252 or later skip the bootclasspath argument and deploy the following bundle instead:

      • org.eclipse.jetty.alpn:alpn-api:1.1.3.v20160715

Using the OSGi Http Whiteboard

The OSGi whiteboard implementation simplifies the task of registering servlets, filters, resources, listeners, and servlet contexts. For a complete introduction, please refer to the OSGi R7 Compendium or Enterprise specification.

For a short introduction: Such a whiteboard service can be registered by exporting it as a service, making it no longer necessary to track and use the HttpService directly (or the ExtHttpService in legacy implementations, for registering filters). The whiteboard implementation detects all jakarta.servlet.Servlet and jakarta.servlet.Filter services with the right service properties. Let us illustrate the usage by registering a servlet and a filter:

public class Activator implements BundleActivator {
    private ServiceRegistration<Servlet> servletRegistration;
    private ServiceRegistration<Filter> filterRegistration;

    public void start(BundleContext context) throws Exception {
        Hashtable propsServlet = new Hashtable();
        propsServlet.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN, "/hello");
        propsServlet.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_ASYNC_SUPPORTED, true);
        propsServlet.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX + "message", "Hello World servlet!");

        this.servletRegistration = context.registerService(Servlet.class.getName(), new HelloWorldServlet(), propsServlet);

        Hashtable propsFilter = new Hashtable();
        propsFilter.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_REGEX, ".*");
        propsFilter.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_ASYNC_SUPPORTED, true);
        propsFilter.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_FILTER_INIT_PARAM_PREFIX + "message", "Hello World filter!");

        this.filterRegistration = context.registerService(Filter.class.getName(), new HelloWorldFilter(), propsFilter);
    }

    public void stop(BundleContext context) throws Exception {
        this.servletRegistration.unregister();
        this.filterRegistration.unregister();
    }
}

An implementation note for when using the Felix HTTP Jetty 12 bundle: only registering a filter without a servlet, will not work. Make sure that there is a servlet registered (on the same path as the filter) when registering a filter, even when that servlet is not hit eventually.

To ensure the HTTP whiteboard service picks up your servlet and filter correctly, your service registration must provide several service properties.

Servlet service properties

See full reference in the OSGi specification. The most important properties are:

  • osgi.http.whiteboard.servlet.pattern - defines the servlet pattern to register the servlet under, should be a path as defined in the Servlet specification.
  • osgi.http.whiteboard.context.select - Filter expression to select the servlet context (optional).
  • osgi.http.whiteboard.servlet.asyncSupported - Declares whether the servlet supports the asynchronous operation mode. Allowed values are true and false independent of case. Defaults to false. (optional)
  • osgi.http.whiteboard.servlet.multipart.enable - Enables support for multipart configuration on the servlet. Allowed values are true and false independent of case. Defaults to false. (optional)
  • servlet.init.* - these properties (sans the servlet.init. prefix) are made available throught the ServletConfig object of your servlet. This allows you to supply your servlet initialization parameters as you would normally do in the web descriptor (web.xml).

Filter service properties

See full reference in the OSGi specification . The most important properties are:

  • osgi.http.whiteboard.filter.regex - The regular expression pattern to register filter with.
  • osgi.http.whiteboard.context.select - Filter expression to select the servlet context (optional).
  • osgi.http.whiteboard.filter.pattern - Apply this servlet filter to the specified URL path patterns. The format of the patterns is specified in the servlet specification.
  • osgi.http.whiteboard.filter.asyncSupported - Declares whether the servlet filter supports asynchronous operation mode. Allowed values are true and false independent of case. Defaults to false. (optional)
  • filter.init.* - these properties (sans the filter.init. prefix) are made available throught the FilterConfig object of your filter. This allows you to supply your filter initialization parameters as you would normally do in the web descriptor (web.xml).

The order of filters is no longer managed by the service.ranking property, but by implementing the compareTo method. Multiple servlet filters can process the same servlet request/response. If more than one Filter matches, they are processed in ranking order, as specified in ServiceReference.compareTo. The servlet filter with the highest ranking is processed first in the filter chain, while the servlet filter with the lowest ranking is processed last, before the Servlet.service method is called. After the servlet completes its service method the filter chain is unwound in reverse order.

ServletContextHelper service properties

See full reference in the OSGi specification. The most important properties are:

  • osgi.http.whiteboard.context.name - the identifier of the registered HTTP context to be referenced by a servlet or filter service
  • osgi.http.whiteboard.context.path - The path of the servlet context.
  • context.init.* - Properties starting with this prefix are provided as init parameters through the ServletContext.getInitParameter and ServletContext.getInitParameterNames methods. The context.init. prefix is removed from the parameter name.

Using the HttpService

In general the Http Service is regarded legacy and the OSGi Http Whiteboard should be used instead. If you still want to use the Http Service, this is a brief introduction. The main components provided by the Apache Felix HTTP Service bundle are:

  • HttpService - Service used to dynamically register resources and servlets;
  • HttpContext - Additional (optional) component to handle authentication, resource and mime type mappings.

Servlets created for the OSGi HTTP service don't need to have any reference to the OSGi specification (they only need to conform to the Servlet specification), like in the example:

public class HelloWorld extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        resp.getWriter().write("Hello World");		
    }
}

To register a servlet and map it to a URI, you need to retrieve the HttpService and call its registerServlet method. For this example, a ServiceTracker is used to ensure that the registration occurs when a HttpService actually is available, and a deregistration occurs when the HttpService becomes unavailable. Alternatively, you can use more high-level dependency management libraries, like Declarative Services, Felix Dependency Manager, or Felix HTTP whiteboard service (see below).

public class Activator implements BundleActivator {
    private ServiceTracker httpTracker;

    public void start(BundleContext context) throws Exception {
        httpTracker = new ServiceTracker(context, HttpService.class.getName(), null) {
          public void removedService(ServiceReference reference, Object service) {
            // HTTP service is no longer available, unregister our servlet...
            try {
               ((HttpService) service).unregister("/hello");
            } catch (IllegalArgumentException exception) {
               // Ignore; servlet registration probably failed earlier on...
            }
          }

          public Object addingService(ServiceReference reference) {
            // HTTP service is available, register our servlet...
            HttpService httpService = (HttpService) this.context.getService(reference);
            try {
              httpService.registerServlet("/hello", new HelloWorld(), null, null);
            } catch (Exception exception) {
              exception.printStackTrace();
            }
            return httpService;
          }
        };
        // start tracking all HTTP services...
        httpTracker.open();
    }

    public void stop(BundleContext context) throws Exception {
        // stop tracking all HTTP services...
        httpTracker.close();
    }
}

In the same way, you can unregister a servlet (for instance, in the removedMethod method in the former example) by calling the HttpService.unregister method.

As you notice in the example above, the registerServlet method accepts four parameters:

  • the servlet alias;
  • the Servlet instance;
  • an additional configuration Dictionary;
  • a HttpContext.

The servlet alias must begin with a slash and must not end with a slash. When a request is processed, the HTTP Service will try to exact match the requested URI with a registered servlet. If not existent, it will remove the last ‘/’ in the URI and everything that follows, and try to match the remaining part, and so on.

An additional configuration Map can be optionally specified; if present, all the parameters contained will be copied in the ServletContext object.

Finally, an HttpContext object can be optionally specified to handle authentication, mime type and resource mapping. The HttpContext interface is quite simple:

public interface HttpContext {
    /** Returns the mime type of the specified resource */
    String getMimeType(java.lang.String name);

    /** Returns the URL to retrieve the specified resource */
    URL getResource(java.lang.String name);

    /** Manages security for the specified request */
    boolean handleSecurity(HttpServletRequest request, HttpServletResponse response);
}

The use of a custom HttpContext is typical when you want to serve static contents with the HTTP Service. Let's first see an example of resource registration without HttpContext:

public class Activator implements BundleActivator {
    private ServiceTracker httpTracker;

    public void start(BundleContext context) throws Exception {
        httpTracker = new ServiceTracker(context, HttpService.class.getName(), null) {
          public void removedService(ServiceReference reference, Object service) {
            // HTTP service is no longer available, unregister our resources...
            try {
               ((HttpService) service).unregister("/static");
            } catch (IllegalArgumentException exception) {
               // Ignore; servlet registration probably failed earlier on...
            }
          }

          public Object addingService(ServiceReference reference) {
            // HTTP service is available, register our resources...
            HttpService httpService = (HttpService) this.context.getService(reference);
            try {
              httpService.registerResources("/static", "/etc/www", null);
            } catch (Exception exception) {
              exception.printStackTrace();
            }
            return httpService;
          }
      };
      // start tracking all HTTP services...
      httpTracker.open();
    }

    public void stop(BundleContext context) throws Exception {
      // stop tracking all HTTP services...
      httpTracker.close();
    }
}

As a result of the httpService.registerResources("/static", "/etc/www", null) code, all the files available under /etc/www will be exposed under /static (e.g. http://localhost:8080/static/001.jpg will render the /etc/www/001.jpg). However, the example above can be simplistic in practice; the HttpContext object is the solution to customize the resource handling.

For instance, you can set the define more complex URI to file mappings overriding the HttpContext.getResource method, or the correct MIME type implementing the method HttpContext.getMimeType like in the example:

//....
public String getMimeType(String file) {
    if (file.endsWith(".jpg") {
        return "image/jpeg";  
    } else if (file.endsWith(".png")) {
        return "image/png";  
    } else {  
        return "text/html";  
    }
}
//....

If you implement a customised HttpContext object, don't forget to specify it as third parameter of the registerResources method invocation:

// ....
public Object addingService(ServiceReference reference) {
    // HTTP service is available, register our resources...
    HttpService httpService = (HttpService) this.context.getService(reference);
    try {
        // explicitly use our own context as 3rd parameter...
        httpService.registerResources("/static", "/etc/www", new MyHttpContext());
    } catch (Exception exception) {
        exception.printStackTrace();
    }
    return httpService;
}
// ....

Using the Servlet Bridge

The servlet bridge is used if you want to use the HTTP service inside a WAR deployed on a 3rd part applicaiton server. A little setup is needed for this to work:

  1. deploy org.apache.felix.http.proxy jar file inside the web application (WEB-INF/lib);
  2. in a startup listener (like ServletContextListener) set the BundleContext as a servlet context attribute (see example;
  3. define org.apache.felix.http.proxy.ProxyServlet inside your web.xml and register it to serve on all requests /* (see example;
  4. define org.apache.felix.http.proxy.ProxyListener as a <listener> in your web.xml to allow HTTP session related events to be forwarded (see the section of Servlet API Event forwarding below and example;
  5. be sure to add javax.servlet;javax.servlet.http;version=2.6 to OSGi system packages (org.osgi.framework.system.packages);
  6. deploy org.apache.felix.http.bridge (or org.apache.felix.http.bundle) inside the OSGi framework.

A detailed example can be found here.

Using the SSL filter

This filter provides you means to transparently handle SSL termination proxies, allowing your servlets and filters to work like they were accessed directly through HTTPS. This filter is useful when deploying applications in large datacenters where frontend load-balancers distribute the load among several servers in the same datacenter by stripping the SSL encryption.

The SSL filter can be configured to let it detect whether the request was originating from an SSL connection. There are several non-standard request headers in use:

Header nameUsed valueDescription
X-Forwarded-Protohttpsused by Amazon ELBs and Nginx and more or less the de-facto standard to indicate a SSL-terminated connection.
X-Forwarded-Protocolhttpsalternative to X-Forwarded-Proto.
X-Forwarded-SSLonnon-standard way used by some applications.
Front-End-Httpsonused by Microsoft to indicate a SSL-terminated connection.

In case a client connected using a certificate, this certificate can be forwarded as well by the SSL filter. Several non-standard request headers are used for this:

HeaderDescription
X-Forwarded-SSL-CertificateThe de-facto(?) standard used to forward the client certificate by a proxy.
X-Forwarded-SSL-Client-CertAlternative header used by some proxies.

Note: instead of deploying the SSL filter bundle, you can also set the org.apache.felix.proxy.load.balancer.connection.enable property to true in order to achieve the same effect.

Configuration Properties

The service can both be configured using OSGi environment properties and using Configuration Admin. The service PID for this service is "org.apache.felix.http". If you use both methods, Configuration Admin takes precedence. The following properties can be used (some legacy property names still exist but are not documented here on purpose). As properties might change over time, the actual list of properties can be found here for the Jetty 12 bundle and here for the Jetty 11 bundle.

PropertyDescription
org.apache.felix.http.hostHost name or IP Address of the interface to listen on. The default is null causing Jetty to listen on all interfaces.
org.osgi.service.http.portThe port used for servlets and resources available via HTTP. The default is 8080. See port settings below for additional information. A negative port number has the same effect as setting org.apache.felix.http.enable to false.
org.osgi.service.http.port.secureThe port used for servlets and resources available via HTTPS. The default is 8443. See port settings below for additional information. A negative port number has the same effect as setting org.apache.felix.https.enable to false.
org.apache.felix.http.context_pathThe servlet Context Path to use for the Http Service. If this property is not configured it defaults to “/”. This must be a valid path starting with a slash and not ending with a slash (unless it is the root context).
org.apache.felix.http.timeoutConnection timeout in milliseconds. The default is 60000 (60 seconds).
org.apache.felix.http.session.timeoutAllows for the specification of the Session life time as a number of minutes. This property serves the same purpose as the session-timeout element in a Web Application descriptor. The default is “0” (zero) for no timeout at all.
org.apache.felix.http.enableFlag to enable the use of HTTP. The default is true.
org.apache.felix.https.enableFlag to enable the user of HTTPS. The default is false.
org.apache.felix.https.keystoreThe name of the file containing the keystore.
org.apache.felix.https.keystore.passwordThe password for the keystore.
org.apache.felix.https.keystore.key.passwordThe password for the key in the keystore.
org.apache.felix.https.truststoreThe name of the file containing the truststore.
org.apache.felix.https.truststore.typeThe type of truststore to use. The default is JKS.
org.apache.felix.https.truststore.passwordThe password for the truststore.
org.apache.felix.https.jetty.ciphersuites.excludedConfigures comma-separated list of SSL cipher suites to exclude. Default is null, meaning that no cipher suite is excluded.
org.apache.felix.https.jetty.ciphersuites.includedConfigures comma-separated list of SSL cipher suites to include. Default is null, meaning that the default cipher suites are used.
org.apache.felix.https.jetty.protocols.excludedConfigures comma-separated list of SSL protocols (e.g. SSLv3, TLSv1.0, TLSv1.1, TLSv1.2) to exclude. Default is null, meaning that no protocol is excluded.
org.apache.felix.https.jetty.protocols.includedConfigures comma-separated list of SSL protocols to include. Default is null, meaning that the default protocols are used.
org.apache.felix.https.clientcertificateFlag to determine if the HTTPS protocol requires, wants or does not use client certificates. Legal values are needs, wants and none. The default is none.
org.apache.felix.http.jetty.headerBufferSizeSize of the buffer for request and response headers, in bytes. Default is 16 KB.
org.apache.felix.http.jetty.requestBufferSizeSize of the buffer for requests not fitting the header buffer, in bytes. Default is 8 KB.
org.apache.felix.http.jetty.responseBufferSizeSize of the buffer for responses, in bytes. Default is 24 KB.
org.apache.felix.http.jetty.maxFormSizeThe maximum size accepted for a form post, in bytes. Defaults to 200 KB.
org.apache.felix.http.mbeansIf true, enables the MBean server functionality. The default is false.
org.apache.felix.http.jetty.sendServerHeaderIf false, the Server HTTP header is no longer included in responses. The default is false.
org.eclipse.jetty.servlet.SessionCookieName of the cookie used to transport the Session ID. The default is JSESSIONID.
org.eclipse.jetty.servlet.SessionURLName of the request parameter to transport the Session ID. The default is jsessionid.
org.eclipse.jetty.servlet.SessionDomainDomain to set on the session cookie. The default is null.
org.eclipse.jetty.servlet.SessionPathThe path to set on the session cookie. The default is the configured session context path (“/”).
org.eclipse.jetty.servlet.MaxAgeThe maximum age value to set on the cookie. The default is “-1”.
org.eclipse.jetty.UriComplianceModeThe URI compliance mode to set. The default is DEFAULT. See documentation and possible modes.
org.apache.felix.proxy.load.balancer.connection.enableSet this to true when running Felix HTTP behind a (offloading) proxy or load balancer which rewrites the requests. The default is false.
org.apache.felix.http.runtime.init.Properties starting with this prefix are added as service registration properties to the HttpServiceRuntime service. The prefix is removed for the property name.
org.apache.felix.jetty.gziphandler.enableWhether the server should use a server-wide gzip handler. Default is false.
org.apache.felix.jetty.gzip.minGzipSizeThe minimum response size to trigger dynamic compression. Default is GzipHandler.DEFAULT_MIN_GZIP_SIZE.
org.apache.felix.jetty.gzip.inflateBufferSizeThe size in bytes of the buffer to inflate compressed request, or <= 0 for no inflation. Default is -1.
org.apache.felix.jetty.gzip.syncFlushTrue if Deflater#SYNC_FLUSH should be used, else Deflater#NO_FLUSH will be used. Default is false.
org.apache.felix.jetty.gzip.includedMethodsThe additional http methods to include in compression. Default is none.
org.apache.felix.jetty.gzip.excludedMethodsThe additional http methods to exclude in compression. Default is none.
org.apache.felix.jetty.gzip.includedPathsThe additional path specs to include. Inclusion takes precedence over exclusion. Default is none.
org.apache.felix.jetty.gzip.excludedPathsThe additional path specs to exclude. Inclusion takes precedence over exclusion. Default is none.
org.apache.felix.jetty.gzip.includedMimeTypesThe included mime types. Inclusion takes precedence over exclusion. Default is none.
org.apache.felix.jetty.gzip.excludedMimeTypesThe excluded mime types. Inclusion takes precedence over exclusion. Default is none.
org.apache.felix.http2.enableWhether to enable HTTP/2. Default is false.
org.apache.felix.jetty.http2.maxConcurrentStreamsThe max number of concurrent streams per connection. Default is 128.
org.apache.felix.jetty.http2.initialStreamRecvWindowThe initial stream receive window (client to server). Default is 524288.
org.apache.felix.jetty.http2.initialSessionRecvWindowThe initial session receive window (client to server). Default is 1048576.
org.apache.felix.jetty.alpn.protocolsThe ALPN protocols to consider. Default is h2, http/1.1.
org.apache.felix.jetty.alpn.defaultProtocolThe default protocol when negotiation fails. Default is http/1.1.
org.apache.felix.jakarta.websocket.enableEnables Jakarta websocket support. Default is false.
org.apache.felix.jetty.websocket.enableEnables Jetty websocket support. Default is false.

Multiple Servers

It is possible to configure several Http Services, each running on a different port. The first service can be configured as outlined above using the service PID for "org.apache.felix.http". Additional servers can be configured through OSGi factory configurations using "org.apache.felix.http" as the factory PID. The properties for the configuration are outlined as above.

The default server using the PID "org.apache.felix.http" can be disabled by specifying a negative port and then all servers can be used through factory configurations.

SSL filter configuration properties

The SSL-filter bundle supports the following configuration options, using the PID org.apache.felix.http.sslfilter.SslFilter (no fallback to environment properties!):

PropertyDescription
ssl-forward.headerDefines what HTTP header to look for in a request to determine whether a request is a forwarded SSL request. The default is X-Forwarded-SSL.
ssl-forward.valueDefines what HTTP header value to look for in a request to determine whether a request is a forwarded SSL request in a request. The default is on.
ssl-forward-cert.headerDefines what HTTP header to look for in a request to obtain the forwarded client certificate. The default is X-Forwarded-SSL-Certificate.

HTTP port settings

As of HTTP Jetty version 2.2.2, it is possible to assign a free port for HTTP or HTTPS automatically, based on certain rules, for example, a range between 8000 and 9000. The syntax is based on the version ranges, as described in the OSGi specification. The following forms are supported:

  • * or 0: binds to the first available port;
  • 8000: binds to port 8000, failing if this port is already taken;
  • [8000,9000]: binds to a free port in the range 8000 (inclusive) and 9000 (inclusive);
  • [8000,9000): binds to a free port in the range 8000 (inclusive) and 9000 (exclusive);
  • (8000,9000]: binds to a free port in the range 8000 (exclusive) and 9000 (inclusive);
  • (8000,9000): binds to a free port in the range 8000 (exclusive) and 9000 (exclusive);
  • [,9000): binds to a free port in the range 1 (inclusive) and 9000 (exclusive);
  • [8000,): binds to a free port in the range 8000 (inclusive) and 65535 (exclusive).

Note that picking a port is not performed atomically and multiple instances can try to bind to the same port at the same time.

Servlet API Events

The Servlet API defines a number of EventListener interfaces to catch servlet or filter related events. As of HTTP Service 2.1.0 most events generated by the servlet container are forwarded to interested service. To be registered to receive events services must be registered with the respective EventListener interface:

InterfaceDescription
javax.servlet.ServletContextAttributeListenerEvents on servlet context attribute addition, change and removal.
javax.servlet.ServletRequestAttributeListenerEvents on request attribute addition, change and removal.
javax.servlet.ServletRequestListenerEvents on request start and end.
javax.servlet.http.HttpSessionAttributeListenerEvents on session attribute addition, change and removal. To receive such events in a bridged environment, the ProxyLister must be registered with the servlet container. See the Using the Servlet Bridge section above.
javax.servlet.http.HttpSessionListenerEvents on session creation and destroyal. To receive such events in a bridged environment, the ProxyLister must be registered with the servlet container. See the Using the Servlet Bridge section above.

Of the defined EventListener interfaces in the Servlet API, the javax.servlet.ServletContextListener events are currently not support (but will be in the near future). For one thing they do not make much sense in an OSGi environment. On the other hand they are hard to capture and propagate. For example in a bridged environment the contextInitialized event may be sent before the framework and any of the contained bundles are actually ready to act. Likewise the contextDestroyed event may come to late.

Servlet Context Notes

ServletContext instances are managed internally by the Http Service implementation. For each HttpContext instance used to register one or more servlets and/or resources a corresponding ServletContext instance is created. These ServletContext instances is partly based on the single ServletContext instance received from the Servlet Container --- either embedded Jetty or some external Servlet Container when using the Http Service Bridge --- and partly based on the provided HttpContext instance:

Method(s)Based on ...
getContextPath, getContext, getMajorVersion, getMinorVersion, getServerInfoServlet Containers ServletContext
getResourcePathsBundle.getEntryPaths of the bundle using the Http Service
getResource, getResourceAsStreamHttpContext.getResource
getMimeTypeHttpContext.getMimeType
getRequestDispatcher, getNamedDispatcher, getInitParameter, getServlet, getRealPathAlways return null
getInitParameterNames, getServlets, getServletNamesAlways returns empty Enumeration
getAttribute, getAttributeNames, setAttribute, removeAttributeBy default maintained for each ServletContext managed by the Http Service. If the org.apache.felix.http.shared*servlet*context_attributes framework property is set to true these methods are actually based on the ServletContext provided by the servlet container and thus attributes are shared amongst all ServlectContext instances, incl. the ServletContext provided by the servlet container

Examples

A set of simple examples illustrating the various features are available.

Maven Artifacts

This is a list of the most recent artifacts at the time of writing this document. There might already be newer versions available:

<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.servlet-api</artifactId>
    <version>3.0.0</version>
</dependency>
<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.jetty12</artifactId>
    <version>1.0.2</version>
</dependency>
<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.bridge</artifactId>
    <version>5.1.6</version>
</dependency>
<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.proxy</artifactId>
    <version>4.0.0</version>
</dependency>
<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.wrappers</artifactId>
    <version>1.1.2</version>
</dependency>
<dependency>
    <groupId>org.apache.felix</groupId>
    <artifactId>org.apache.felix.http.sslfilter</artifactId>
    <version>2.0.2</version>
</dependency>