tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Osgifing Tomcat
Date Tue, 29 Apr 2008 17:48:00 GMT
On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens <>
>  Tomcat to really make a lot of sense. Providing OSGi headers seems to
> fulfill
>  the immediate need of several groups. However, it would be really nice if
> you
>  could provide a service interface like an Http Service (Http Service
> is Servlet 2.1,
>  so you likely need something better). However, if you put the headers in

Headers seems to be ok - I don't think anyone objected to this.

Regarding HttpService - I don't think it's a good idea for tomcat.
One of the major problems with OSGI ( and we need to make sure we don't fall
in this trap )
is the re-invention of common APIs - logging, servlet interfaces, etc. It
would be quite inappropriate
for tomcat to not use the standard deployment/configuration mechanism for
So using or implementing any of the OSGI-re-defined service interfaces in
tomcat would be a hard sale IMO.

>  I think the more ambitious case then is to leverage the OSGi class
> and
>  allow WARs to be installed dynamically. Several people (there is also an

There are 3 issues here:
- dynamic installation and uninstallation of WARs - that's already working
quite well, no need for OSGI.

- 'gapless' upgrade (old version running alongside with the new one)- OSGI
has no magic bullet for that, the problem
is more in the mapping layer.

- using OSGI class loading to allow more flexible interaction between WARs.
Unfortunately that is invalidated by
the servlet spec, which clearly defines this area.

>  Of course then there is the possibility to turn Tomcat itself into
> bundles and
>  leverage OSGi internally. This is an interesting exercise but looking at
> the sentiments
>  in this list I think this is a far way off :-)

Quite the opposite, I think this would be the best use of OSGI - if we can
avoid the bad things in OSGI ( like the
service APIs and over-use of bundle activator and service registration ).

What tomcat needs the most IMO is a way to separate 'core' functionality
from 'modules' - like
authenticators, session management, connectors. Using OSGI bundles for
modules and integrating
with the lifecycle would be ok if it can be done non-intrusive:

- some OSGI-independent interface ( with a OSGI implementation and a
'direct' one ) to load the module.
I personally like JBoss style of modules as well - so that could be a 3rd
implementation ( maybe outside of apache ).

- some code loaded from server.xml that would start the OSGI container and
load the modules

- use OSGI/Jboss-style class loader to allow the modules and core to share

Most of this can be done in an 'optional' package ( i.e. in the trunk, but
not included in the 'official' base release ).
Few simple interfaces and impl changes may need to be added to the core -
but it can be very light.

>  In OSGi, the bundles are first class citizens in the API. This allows an
>  extender bundle to read resources from the bundle when it gets started
>  take appropriate actions. I.e. a WAR manager bundle can detect reliably
>  installation of new bundles, read the appropriate XML files, and do the
>  registrations. So the "non standard" method would be internal Tomcat API
>  called by a Tomcat bundle. I think it is a very good requirement to keep
> the
>  WAR the WAR and not require any OSGi code in there. In the longer run
>  OSGi could update the rather stale Http Service specification to add this
>  kind of management API, allowing the WAR manager and the web server to be
>  independent bundles so that developers can mix and match.

I'm pretty sure most people want to use OSGi for services, and Servlet API
for web development.
HttpService is a non-starter - it would be great if the next servlet API
defines interfaces
for dynamic (code-based) loading of servlets -  and we can provide some
interfaces ( like jetty does )  - but OSGi is not the right place to look
for servlet ( or logging ) APIs.

My main question regarding OSGI bundles and services:

Is there a way for a bundle to declare that it implements some services
using manifest or some config file, but without
 requiring it to be started to register services via BundleContext ? What I
would like is to start tomcat, use server.xml
to find what services are needed, and load the bundles providing the modules
( and only those ).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message