Difference between revisions of "Jetty/Feature/Jetty OSGi"

From Eclipsepedia

< Jetty‎ | Feature
Jump to: navigation, search
m
 
(13 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
{{Jetty Feature
 
{{Jetty Feature
| introduction = Jetty on OSGi consists of bootstrapping a standard jetty server from OSGi.
+
| introduction =  
 +
 
 +
{{Jetty Redirect|http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html}}
 +
 
 +
Jetty on OSGi consists of bootstrapping a standard jetty server from OSGi.
 
It supports the deployment of traditional J2EE web-applications as well as web-applications contained inside an OSGi bundle (RFC66).
 
It supports the deployment of traditional J2EE web-applications as well as web-applications contained inside an OSGi bundle (RFC66).
  
 
The goal of Jetty on OSGi is to offer a migration path for traditional J2EE applications to run inside an OSGi container.
 
The goal of Jetty on OSGi is to offer a migration path for traditional J2EE applications to run inside an OSGi container.
It favors J2EE applications currently deployed on jetty: developers and IT administrators familiar with a jetty deployment will found the same folder structure and configuration files.
+
It favours J2EE applications currently deployed on jetty: developers and IT administrators familiar with a jetty deployment will find the same folder structure and configuration files.
  
 
Jetty-on-OSGi also provides an SDK for Eclipse-PDE that supports the development and debugging of a mix of traditional web-applications and web-applications contained in an OSGi bundle: [[Jetty/Tutorial/Jetty-OSGi_SDK|Jetty on OSGi SDK for Eclipse PDE]].
 
Jetty-on-OSGi also provides an SDK for Eclipse-PDE that supports the development and debugging of a mix of traditional web-applications and web-applications contained in an OSGi bundle: [[Jetty/Tutorial/Jetty-OSGi_SDK|Jetty on OSGi SDK for Eclipse PDE]].
 +
 +
This document describes the internal architecture of Jetty-OSGi and describes the features supported.
 +
It assumes the reader is interested into taking advantage of OSGi.
  
 
| body =  
 
| body =  
Line 15: Line 22:
 
It starts a jetty server according to these configuration files:   
 
It starts a jetty server according to these configuration files:   
  
It locates a ${jetty.home} folder (or generate one by default) and starts a jetty server according to the [[Jetty/Reference/jetty.xml|jetty.xml]] file.
+
It locates a ${jetty.home} folder (or generates one by default) and starts a jetty server according to the [[Jetty/Reference/jetty.xml|jetty.xml]] file. If you add extra configuration files, then please ensure that the first element configures the server instance with the id of "Server":
 +
 
 +
<source lang="xml">
 +
<Configure id="Server" class="org.eclipse.jetty.server.Server">
 +
</source>
  
 
The classloader inside which the jetty server is executing is a mix of the OSGi classloader provided by the 'org.eclipse.jetty.osgi.boot' bundle and also the jars and folders found inside ${jetty.home}/lib/ext and ${jetty.home}/resources.
 
The classloader inside which the jetty server is executing is a mix of the OSGi classloader provided by the 'org.eclipse.jetty.osgi.boot' bundle and also the jars and folders found inside ${jetty.home}/lib/ext and ${jetty.home}/resources.
  
 
The jetty.xml provided by default in jetty will deploy all web-applications found inside the ${jetty.home}/webapps
 
The jetty.xml provided by default in jetty will deploy all web-applications found inside the ${jetty.home}/webapps
and will read the jetty context files found inside ${jetty.home/contexts}.
+
and will read the jetty context files found inside ${jetty.home}/contexts.
  
 
=== OSGi's HttpService via equinox servlet bridge ===
 
=== OSGi's HttpService via equinox servlet bridge ===
Line 40: Line 51:
  
 
The mandatory manifest header of RFC66 is supported:
 
The mandatory manifest header of RFC66 is supported:
<pre>
+
<pre>Web-ContextPath: /theContextPath<br></pre>
Web-ContextPath: /theContextPath
+
</pre>
+
 
The default behavior when it is missing is also supported: the default context path is the symbolic name of the bundle that contains WEB-INF/web.xml.
 
The default behavior when it is missing is also supported: the default context path is the symbolic name of the bundle that contains WEB-INF/web.xml.
  
Line 54: Line 63:
 
The "war" URL scheme specified by RFC66 support the installation of J2EE web archives - "war" files - into an OSGi environment.
 
The "war" URL scheme specified by RFC66 support the installation of J2EE web archives - "war" files - into an OSGi environment.
 
On the OSGi shell, it is possible to install a war file with a command like this one:
 
On the OSGi shell, it is possible to install a war file with a command like this one:
<pre>
+
<pre>>install war:file://path/to/pet.war<br></pre>
>install war:file://path/to/pet.war
+
</pre>
+
 
The corresponding war file is transformed into a suitable OSGi bundle and installed on to the OSGi container.
 
The corresponding war file is transformed into a suitable OSGi bundle and installed on to the OSGi container.
  
Line 63: Line 70:
  
 
Also RFC66 specifies a factory class that create URLs with the war scheme. This factory is not implemented currently.
 
Also RFC66 specifies a factory class that create URLs with the war scheme. This factory is not implemented currently.
The factory is not specific to jetty so hopefully it will be packaged with the OSGi APIs.
+
The factory is not specific to Jetty so hopefully it will be packaged with the OSGi APIs.
  
The support for the war scheme is almost fully decoupled from jetty APIs. It could be used in any RFC66 implementation.
+
The support for the war scheme is almost fully decoupled from Jetty APIs. It could be used in any RFC66 implementation.
It is in the bundle [[http://github.com/intalio/hightide-on-osgi/tree/master/org.eclipse.jetty.osgi.boot.warurl|org.eclipse.jetty.osgi.war]]
+
It is in the bundle [http://dev.eclipse.org/viewcvs/viewvc.cgi/jetty/tags/jetty-7.2.2.v20101205/jetty-osgi/jetty-osgi-boot-warurl/?root=RT_JETTY org.eclipse.jetty.osgi.warurl].
  
 
=== Internals and extensions to RFC66 ===
 
=== Internals and extensions to RFC66 ===
Line 72: Line 79:
 
==== Manifest headers specific to jetty ====
 
==== Manifest headers specific to jetty ====
 
<pre>Jetty-WarFolderPath: /path/to/a/webapp</pre>
 
<pre>Jetty-WarFolderPath: /path/to/a/webapp</pre>
This entry let's the user define a comma separated list of folder pathes relative to the base folder of the bundle.
+
This entry let's the user define a comma separated list of folder paths relative to the base folder of the bundle.
 
Each folder will be deployed as a web-application.
 
Each folder will be deployed as a web-application.
 
It is required that each folder contains WEB-INF/web.xml
 
It is required that each folder contains WEB-INF/web.xml
Line 78: Line 85:
 
Hence each webapp can eventually contain WEB-INF/lib and WEB-INF/classes for libraries specific to that web-app.
 
Hence each webapp can eventually contain WEB-INF/lib and WEB-INF/classes for libraries specific to that web-app.
  
<pre>Jetty-ContextFilePath: /path/to/a/context/file.xml</pre>
+
Optionally, you can also include a [http://wiki.eclipse.org/Jetty/Feature/ContextDeployer#Contexts context xml] file in the META-INF of your bundle called '''jetty-webapp-context.xml''' which will be applied to each webapp within the bundle to preconfigure it. Some settings within the webapp can be overridden by the manifest headers (eg Web-ContextPath). Of course you can also use jetty's [http://wiki.eclipse.org/Jetty/Reference/jetty-web.xml WEB-INF/jetty-web.xml file] to post-configure the webapp too.
Jetty also support the deployment of web-application via context files.
+
 
Those files use Jetty's IOC format to configure various jetty handlers and resources available to them (TODO is their a doc for the context files?).
+
<pre>Jetty-ContextFilePath: /path/to/a/context/file.xml,/path/to/another/context/file.xml</pre>
This header is a comma separated list of such files that will be executed by jetty.
+
This header is a comma separated list of [http://wiki.eclipse.org/Jetty/Feature/ContextDeployer#Contexts context xml] files that will be executed by jetty. These files can configure a webapp, or any type of ContextHandler supported by Jetty.
  
 
==== The OSGi service 'org.eclipse.jetty.server.handler.ContextHandler' ====
 
==== The OSGi service 'org.eclipse.jetty.server.handler.ContextHandler' ====
The internal mechanism through which jetty manages web-applications is through the OSGi service 'org.eclipse.jetty.server.handler.ContextHandler'.
+
The internal mechanism through which jetty manages web-applications is through the OSGi service [http://download.eclipse.org/jetty/stable-7/apidocs/index.html?org/eclipse/jetty/server/handler/ContextHandler.html org.eclipse.jetty.server.handler.ContextHandler].
 
Whenever an instance of that service is registered, jetty-osgi will read the attached service parameters and deploy the corresponding web-application.
 
Whenever an instance of that service is registered, jetty-osgi will read the attached service parameters and deploy the corresponding web-application.
  
Line 90: Line 97:
  
 
The following static method illustrate how to deploy a web-application in OSGi programmatically:
 
The following static method illustrate how to deploy a web-application in OSGi programmatically:
<pre>
+
<source lang="java">public static void registerWebapplication(Bundle contributor, String webappFolderPath, String contextPath) throws Exception {
    public static void registerWebapplication(Bundle contributor,
+
            String webappFolderPath, String contextPath) throws Exception
+
    {
+
 
         WebAppContext contextHandler = new WebAppContext();
 
         WebAppContext contextHandler = new WebAppContext();
 +
 
         Properties dic = new Properties();
 
         Properties dic = new Properties();
         dic.put(OSGiWebappConstants.SERVICE_PROP_WAR,webappFolderPath);
+
         dic.put(OSGiWebappConstants.SERVICE_PROP_WAR, webappFolderPath);
         dic.put(OSGiWebappConstants.SERVICE_PROP_CONTEXT_PATH,contextPath);
+
         dic.put(OSGiWebappConstants.SERVICE_PROP_CONTEXT_PATH, contextPath);
         contributor.getBundleContext().registerService(ContextHandler.class.getName(),contextHandler,dic);
+
 
    }
+
         contributor.getBundleContext().registerService(ContextHandler.class.getName(), contextHandler, dic);
</pre>
+
}
 +
</source>
  
 
When deploying a web-application, it is necessary to create a WebAppContext rather than a basic ContextHandler.
 
When deploying a web-application, it is necessary to create a WebAppContext rather than a basic ContextHandler.
  
All possible parameters are defined as constants in the class org.eclipse.jetty.osgi.boot.OSGiWebappConstants
+
All possible parameters are defined as constants in the class [http://download.eclipse.org/jetty/stable-7/apidocs/index.html?org/eclipse/jetty/osgi/boot/OSGiWebappConstants.html org.eclipse.jetty.osgi.boot.OSGiWebappConstants]:
* SERVICE_PROP_CONTEXT_PATH -> The context path of the installed web-application.
+
 
* SERVICE_PROP_WAR -> Path to the web-application folder. Those pathes are relative to the bundle location or to the  SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDE when it is specified.
+
<table class="wikitable">
* SERVICE_PROP_CONTEXT_FILE_PATH -> Path to the jetty context files.
+
<tr><th>Parameter</th><th>Description</th></tr>
* SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDE -> Base folder inside which all pathes are resolved. By default the location where the bundle is installed.
+
<tr><td>SERVICE_PROP_CONTEXT_PATH</td><td>The context path of the installed web-application.</td></tr>
* SERVICE_PROP_EXTRA_CLASSPATH -> extra jar and folders added to the classloader of the web-application.
+
<tr><td>SERVICE_PROP_WAR</td><td>Path to the web-application folder. Those pathes are relative to the bundle location or to the  SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDE when it is specified.</td></tr>
* SERVICE_PROP_WEB_XML_PATH -> path to the web.xml file when we don't default on WEB-INF/web.xml
+
<tr><td>SERVICE_PROP_CONTEXT_FILE_PATH</td><td>Path to the jetty context files.</td></tr>
* SERVICE_PROP_DEFAULT_WEB_XML_PATH -> path to the defaultweb.xml file when we don't default on the one provided by jetty.
+
<tr><td>SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDE</td><td>Base folder inside which all pathes are resolved. By default the location where the bundle is installed.</td></tr>
 +
<tr><td>SERVICE_PROP_EXTRA_CLASSPATH</td><td>Extra jars and folders added to the classloader of the web-application.</td></tr>
 +
<tr><td>SERVICE_PROP_WEB_XML_PATH</td><td>Path to the web.xml file when we don't default on WEB-INF/web.xml.</td></tr>
 +
<tr><td>SERVICE_PROP_DEFAULT_WEB_XML_PATH</td><td>Path to the defaultweb.xml file when we don't default on the one provided by Jetty.</td></tr>
 +
</table>
  
 
==== Notes: OSGi services versus bundles to manage web-applications. ====
 
==== Notes: OSGi services versus bundles to manage web-applications. ====
Line 125: Line 135:
 
== Architecture ==
 
== Architecture ==
 
=== Classloader tree ===
 
=== Classloader tree ===
<pre>
+
<pre>'org.eclipse.jetty.osgi.boot' (org.eclipse.jetty.*, javax.*, most optional) + dependencies_injected_by_fragments
'org.eclipse.jetty.osgi.boot' (org.eclipse.jetty.*, javax.*, most optional) + dependencies_injected_by_fragments
+
      jetty-server (${jetty.home}/resources, ${jetty.home}/lib/ext)
  jetty-server (${jetty.home}/resources, ${jetty.home}/lib/ext)
+
 
       web-application (OSGi-bundle-that-contains-it, WEB-INF/classes, WEB-INF/lib, extraClasspath)
 
       web-application (OSGi-bundle-that-contains-it, WEB-INF/classes, WEB-INF/lib, extraClasspath)
 
</pre>
 
</pre>
Line 147: Line 156:
  
 
=== Centralized logging support with slf4j and logback-classic ===
 
=== Centralized logging support with slf4j and logback-classic ===
When the bundle-fragment 'org.eclipse.jetty.osgi.logback' is present, jetty-osgi does some extra work to centralize the configuration of the logging.
+
In order to use logback/slf4j, make sure that your target platform contains those libraries.
Web-applications can use anyone of their favorite logging APIs: slf4j, commons.logging or log4j.
+
Then set the system property "logback.configurationFile" to point to your logback configuration file (more on Logback's [http://logback.qos.ch/manual/configuration.html documentation]).
 
+
The optional bundle 'org.eclipse.jetty.osgi.logback' bundles injects the slf4j and logback dependencies into the 'org.eclipse.jetty.osgi.boot' bundle: making them available to all of jetty and all of the web-application deployed there.
+
This bundle also calls-back the internal deployment class to configure it so that a web-application's own local implementations of slf4j, log4j, commons.logging are ignored.
+
This assures that all logging calls end up using the same classes in the same classloader and use the same configuration.
+
 
+
When logback is not configured by the time that the jetty server is started, 'org.eclipse.jetty.osgi.logback' looks into ${jetty.home}/resources for the logback configuration file: logback-test.xml or logback.xml
+
 
+
An alternative to 'org.eclipse.jetty.osgi.logback' is 'org.eclipse.jetty.osgi.log4j' which does the exact same work but relies on log4j for the actual logging. logback is licensed under the EPL and in the process of being distributed by eclipse. logback is more advanced than log4j. The latest releases of logback and slf4j or OSGi ready.
+
  
 
=== JSP support: Jasper integration ===
 
=== JSP support: Jasper integration ===

Latest revision as of 16:08, 23 April 2013



Contents

[edit] Introduction


Jetty on OSGi consists of bootstrapping a standard jetty server from OSGi. It supports the deployment of traditional J2EE web-applications as well as web-applications contained inside an OSGi bundle (RFC66).

The goal of Jetty on OSGi is to offer a migration path for traditional J2EE applications to run inside an OSGi container. It favours J2EE applications currently deployed on jetty: developers and IT administrators familiar with a jetty deployment will find the same folder structure and configuration files.

Jetty-on-OSGi also provides an SDK for Eclipse-PDE that supports the development and debugging of a mix of traditional web-applications and web-applications contained in an OSGi bundle: Jetty on OSGi SDK for Eclipse PDE.

This document describes the internal architecture of Jetty-OSGi and describes the features supported. It assumes the reader is interested into taking advantage of OSGi.

[edit] Feature

Jetty bootstrapping in OSGi

A single bundle 'org.eclipse.jetty.osgi.boot' acts as an alternative to Jetty's Start.jar. It wires up all the jetty jars that can be located. It locates the ${jetty.home} folder where the configuration files are located. It starts a jetty server according to these configuration files:

It locates a ${jetty.home} folder (or generates one by default) and starts a jetty server according to the jetty.xml file. If you add extra configuration files, then please ensure that the first element configures the server instance with the id of "Server":

 <Configure id="Server" class="org.eclipse.jetty.server.Server">

The classloader inside which the jetty server is executing is a mix of the OSGi classloader provided by the 'org.eclipse.jetty.osgi.boot' bundle and also the jars and folders found inside ${jetty.home}/lib/ext and ${jetty.home}/resources.

The jetty.xml provided by default in jetty will deploy all web-applications found inside the ${jetty.home}/webapps and will read the jetty context files found inside ${jetty.home}/contexts.

OSGi's HttpService via equinox servlet bridge

Equinox packages a servlet that supports HttpService. Jetty-OSGi is distributed with a bundle that deploys this servlet and hence provides an implementation of HttpService. The URL mapping to this servlet is "/*": it will catch any request not caught by other handlers.

Deployment of web-applications via OSGi

Support for RFC66

RFC66 standardize the format of a bundle that contains a web-application and its lifecycle. The basic use-case is this one: When a bundle is started and contains "WEB-INF/web.xml", an RFC66 implementation will deploy the web-application contained in that bundle. The RFc66 implementation reads the manifest headers of the bundle for non-default deployment parameters of that web-application.

Jetty-OSGi takes advantage of jetty's native web-app deployer and context deployers and exposes those as extensions to RFC66.

Manifest headers and access to OSGI in the servlet context

The mandatory manifest header of RFC66 is supported:

Web-ContextPath: /theContextPath<br>

The default behavior when it is missing is also supported: the default context path is the symbolic name of the bundle that contains WEB-INF/web.xml.

The optional header "Jsp-ExtractLocation" is not supported currently.

A web-application deployed by OSGi contains a pointer to the org.osgi.BundleContext object as the attribute 'osgi-bundlecontext' of the servlet context.

Jetty-OSGi does not currently enforce that the WEB-INF/classes folder and the WEB-INF/lib/*.jar must be part of the Manifest entry "Bundle-Classpath". If they are not present, jetty-osgi will still load them in the classloader of the web-application.

"war" URL scheme

The "war" URL scheme specified by RFC66 support the installation of J2EE web archives - "war" files - into an OSGi environment. On the OSGi shell, it is possible to install a war file with a command like this one:

>install war:file://path/to/pet.war<br>

The corresponding war file is transformed into a suitable OSGi bundle and installed on to the OSGi container.

The support for this protocol is mostly complete. The query string parameters that enable overriding the manifest headers and other settings have not been extensively tested.

Also RFC66 specifies a factory class that create URLs with the war scheme. This factory is not implemented currently. The factory is not specific to Jetty so hopefully it will be packaged with the OSGi APIs.

The support for the war scheme is almost fully decoupled from Jetty APIs. It could be used in any RFC66 implementation. It is in the bundle org.eclipse.jetty.osgi.warurl.

Internals and extensions to RFC66

Manifest headers specific to jetty

Jetty-WarFolderPath: /path/to/a/webapp

This entry let's the user define a comma separated list of folder paths relative to the base folder of the bundle. Each folder will be deployed as a web-application. It is required that each folder contains WEB-INF/web.xml Each of those web-application will use its own classloader which is a child of the bundle's classloader that contains them. Hence each webapp can eventually contain WEB-INF/lib and WEB-INF/classes for libraries specific to that web-app.

Optionally, you can also include a context xml file in the META-INF of your bundle called jetty-webapp-context.xml which will be applied to each webapp within the bundle to preconfigure it. Some settings within the webapp can be overridden by the manifest headers (eg Web-ContextPath). Of course you can also use jetty's WEB-INF/jetty-web.xml file to post-configure the webapp too.

Jetty-ContextFilePath: /path/to/a/context/file.xml,/path/to/another/context/file.xml

This header is a comma separated list of context xml files that will be executed by jetty. These files can configure a webapp, or any type of ContextHandler supported by Jetty.

The OSGi service 'org.eclipse.jetty.server.handler.ContextHandler'

The internal mechanism through which jetty manages web-applications is through the OSGi service org.eclipse.jetty.server.handler.ContextHandler. Whenever an instance of that service is registered, jetty-osgi will read the attached service parameters and deploy the corresponding web-application.

When such a service is unregistered, the corresponding web-application is undeployed.

The following static method illustrate how to deploy a web-application in OSGi programmatically:

public static void registerWebapplication(Bundle contributor, String webappFolderPath, String contextPath) throws Exception  {
        WebAppContext contextHandler = new WebAppContext();
 
        Properties dic = new Properties();
        dic.put(OSGiWebappConstants.SERVICE_PROP_WAR, webappFolderPath);
        dic.put(OSGiWebappConstants.SERVICE_PROP_CONTEXT_PATH, contextPath);
 
        contributor.getBundleContext().registerService(ContextHandler.class.getName(), contextHandler, dic);
}

When deploying a web-application, it is necessary to create a WebAppContext rather than a basic ContextHandler.

All possible parameters are defined as constants in the class org.eclipse.jetty.osgi.boot.OSGiWebappConstants:

ParameterDescription
SERVICE_PROP_CONTEXT_PATHThe context path of the installed web-application.
SERVICE_PROP_WARPath to the web-application folder. Those pathes are relative to the bundle location or to the SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDE when it is specified.
SERVICE_PROP_CONTEXT_FILE_PATHPath to the jetty context files.
SERVICE_PROP_BUNDLE_INSTALL_LOCATION_OVERRIDEBase folder inside which all pathes are resolved. By default the location where the bundle is installed.
SERVICE_PROP_EXTRA_CLASSPATHExtra jars and folders added to the classloader of the web-application.
SERVICE_PROP_WEB_XML_PATHPath to the web.xml file when we don't default on WEB-INF/web.xml.
SERVICE_PROP_DEFAULT_WEB_XML_PATHPath to the defaultweb.xml file when we don't default on the one provided by Jetty.

Notes: OSGi services versus bundles to manage web-applications.

It is (in my biased opinion) more interesting to manage web-applications via an OSGi service rather than via a bundle:

  • The lifecycle of an OSGi service is a lot finer than the life-cycle of a bundle. Developers can equally create or listen to them. Consoles are developped to administer them: change a parameter for a registered service via an admin console will trigger the reloading of the corresponding web-app with a new deployment parameter.
  • There are many ways to create OSGi services and all of them inter-operable:
    • java code that depends on OSGi API.
    • IOC frameworks including OSGi declarative services, springsource.
  • OSGi services are a promising abstractions for distributed servers etc. Bundles are a lot more coupled to the life-cycle of classloaders and underlying jar files.

The support for RFC66'manifest headers basically consists of listening to the bundles lifecycle and issuing the corresponding registration of the 'org.eclipse.jetty.server.handler.ContextHandler'

Architecture

Classloader tree

'org.eclipse.jetty.osgi.boot' (org.eclipse.jetty.*, javax.*, most optional) + dependencies_injected_by_fragments
      jetty-server (${jetty.home}/resources, ${jetty.home}/lib/ext)
      web-application (OSGi-bundle-that-contains-it, WEB-INF/classes, WEB-INF/lib, extraClasspath)

To be more precise we could mention the extra classloader for jsp that supports jasper and the taglibraries.

Injecting new server-wide features into jetty-osgi

A common situation for framework developers is to make a set of library installed in the server's classloader and to have a hook in the life-cycle of the server.

This is supported in 2 ways:

  • The traditional J2EE way: locate the ${jetty.home} folder and add the libs to lib/ext then configure jetty.xml
  • The OSGi way consists of installing a bundle-fragment hosted by 'org.eclipse.jetty.osgi.boot'

This will make the dependencies of the fragment available in the classloader of the server. In order to hook into the lifecycle of server it is possible to define an implementation of BundleActivator that will be invoked by the bundle 'org.eclipse.jetty.osgi.boot'. In order for this BundleActivator to be invoked it must be named following this convention: ${bundle.id.of.this.fragment}+".FragmentActivator"

Jetty-osgi is distributed with a number of optional bundles that illustrate this technique: Support for jsp with the bundle "org.eclipse.jetty.osgi.boot.jsp" Support for centralized logging on logback; "org.eclipse.jetty.osgi.boot.logback"

Centralized logging support with slf4j and logback-classic

In order to use logback/slf4j, make sure that your target platform contains those libraries. Then set the system property "logback.configurationFile" to point to your logback configuration file (more on Logback's documentation).

JSP support: Jasper integration

The optional bundle 'org.eclipse.jetty.osgi.jasper' adds support for jsp-2.1 and the standard tag libraries. TODO: support custom taglibs; make sure java server faces and other common libraries work well.

Runtime packaging

felix or equinox. The bare framework with jetty*, javax*, slf4j*, logback* installed as well as a folder where new bundles can be hot-deploy simply by droping them in. A jetty.home folder with the expected folder hierarchy.

Next steps

Better SDK with more UI for the config of jetty. Manage multiple instance of jetty. Better support for other frameworks that want to configure jetty themselves (geronimo, spring, eclipse-platform, nuxeo etc)

Additional Resources

Jetty on OSGi SDK for Eclipse PDE.