tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: Osgifing Tomcat
Date Wed, 30 Apr 2008 08:00:31 GMT
> 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.
As a bit of background. The logging and Http Service API are from  
1999. At that time
there was no dominant common logging API (neither in Java SE nor in  
open source),
and the Http Service API is 100% based on the, at that time, standard  
Servlet API (it
uses javax.servlet.http), it only provides an API to dynamically  
register and unregister
servlets, which is still lacking in the current Servlet API. On top of
that, all these service APIs are optional. If you look in more detail,  
than many services are
similar: providing a possibility to -dynamically- use Java APIs. I.e.  
XML parsers, IO Connectors
(J2ME), Servlets, URL stream and content handlers, Preferences, etc.  
We are not looking for
work and try to leverage the existing Java environment to the utmost  
extent.

This said, I agree that you want the core of a product like Tomcat to  
be as decoupled
as possible of any frameworks, including OSGi. Decoupling is the  
guiding principle behind
OSGi and the raison d'etre for most of its functionality. Not using a  
service is better than
coupling to it. But sometimes not using a service is more expensive  
than using it, that
decision is what design is all about.

> It would be quite inappropriate for tomcat to not use the standard  
> deployment/configuration mechanism for
> servlets. So using or implementing any of the OSGI-re-defined  
> service interfaces in
> tomcat would be a hard sale IMO.

Well, I do not see that this is an dichotomy. By nature of being the  
RI, you must follow the
JSR. However, it would not be hard to provide the Http Service as an  
additional component. If
Tomcat provides an API to dynamically register servlets, it would be  
trivial for someone
to provide an OSGi compatibility bundle, just like people are doing it  
today.
But it would be a nice service to get this from the horse's mouth. I  
am sure people are willing
to provide this code.

A bit more background. 4 years ago IBM started to like the OSGi  
modularity (class loaders on
steroids) and the silly, unnecessary life cycle and service layer.  
Actually, we had no visible
layers back then. At that time, there were raging debates about  
modularity with lots of
competition. This was actually the trigger for R4 to put the 4 layers  
into place: security, execution
environment, modularity, life cycle, service. Key idea was that people  
could pick the modularity
layer without dragging in the life cycle and service layer. I think  
the dislike for these
layers was based on lack of familiarity because what happened was that  
people started to
use the modularity, then found out how convenient the life cycle layer  
is in development. You
can keep your app server running while debugging and updating code.

However, getting hooked to the life cycle layer (if only for  
development) means things are
coming and going. Coupling through the module layer (i.e. factories,  
Class.forName, etc) means
you create import wires to other modules that can not be dynamically  
withdrawn because Java lacks an API for
this. In OSGi, it is not a big deal because you can still stop a  
bundle, update it, and refresh all the
import wires. This is feasible because bundles can be started and  
stopped and the OSGi framework
is intricately aware of these import wires.

In reality, this is a rather crude approach because in well designed  
systems the coupling between bundles
is minimal. At this point in time, services usually start to look more  
attractive because they provide
an API to allow dynamic updates without crudely stopping all bundles  
in the module dependency
graph (which in non-service based systems, and especially require- 
bundle based systems tends
to become the whole system). And a service is just a POJO that is  
registered under one or more interfaces. By allowing
it to withdrawn at any moment in time, as well as registered by  
multiple independent parties, OSGi
provides a good abstraction of this dynamism. And there is no Java  
counterpart for this.

With JSR 291 we had the same situation. There was a requirement to get  
rid of the service layer
because it was deemed unnecessary. We puzzled with the interfaces in  
OSGi so that we
could be backward compatible and still have this separation. We got  
some solution but it
felt awkward. Worse, there are a number of optional APIs in the OSGi  
framework to manage
the modularity layer (PackageAdmin), the security (PermissionAdmin and  
ConditionalPermissionAdmin),
startlevels, and URL stream and content handling. By removing the  
service layer we had to
find an alternative way to provide these APIs to the bundles.  
Factories? Dependency Injection?
Class.forName? They all felt far inferior to the service model, all  
lacking the dynamics. We then
looked at the API, only 4 specific classes and 3 methods on the core  
framework interface class
BundleContext. The implementations were around 30-40k so in the end we  
decided to keep the
service layer around in JSR 291 because there was no decent  
alternative, the functionality
was needed, and 50k seems a low price to pay.

Last illustration and then I shut up. 2 years ago we were approached  
by Spring. Customers had told them that OSGi was
cool. Spring is in the business of providing convenience APIs to  
complex core APIs and they approached
this job in that vein. OSGi, just one of the zillion environments that  
had to be supported
by the Spring suite. However, something very interesting happened over  
the next few months. I think
they fell in love and the service layer was a major part of their  
infatuation. They
realized very quickly how they could leverage the services as beans in  
their model and the
advantages of dynamism without rebooting.

> 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 ).
This is the use case of Declarative Services. The Service Component  
Runtime (SCR)
will inspect the bundle when it gets installed and register any  
services that
are declared and which have their dependencies on other services  
satisfied.

The bundles themselves are not having a classloader, nor started. Only  
when the
service is really used by another bundle will the bundle be activated  
by the
SCR. If the dependencies go away, the component is deactivated. This  
is of course
all runtime based.

There is also OBR (Apache Felix's Richard Hall is the key author of  
this) which is the
OSGi Bundle Repository. This is a model where you can install bundle  
X, and then
OBR can install any dependent bundles. The dependency model is very  
flexible (an extension
to JSR 124) which also supports dependencies on services. However,  
realize that the dynamic
nature means that there never is a guarantee a service is registered  
by a bundle, even
if it is started because some dependency can be missing, or a bundle  
can be updated, etc.

The OSGi manifest does have a header Export-Service and Import-Service  
defined but because
you can't give an guarantees about them without running the bundle, we  
decided to deprecate them.

However, how much do you want to be in the business of deployment?  
Tomcat is very often used
as an application server but the web site tells me your core is a  
Servlet and
JSP implementation. If you are going for strict modularity, wouldn't  
it make sense to distinguish
between these core functions; Aren't the application management  
aspects secondary? I.e.
allow your core JSP and Servlet engines to be used by others that  
provide the deployment
aspects and allow your deployment code to be able to use other web  
service providers? How
can you leverage existing deployment servers and management agents?  
For me the key thing about
modularity is to do as little as possible and focus on core business.

Sorry for the rather verbose mail, I did not have enough time to write  
a short one. :-(

Kind regards,

	Peter Kriens







On 29 apr 2008, at 19:48, Costin Manolache wrote:

> On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens  
> <peter.kriens@aqute.biz>
> wrote:
>> 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
> itself
>> 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
> servlets.
> 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
> loading
>> 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
> separate
>> 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
> classes.
>
> 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
> and
>> take appropriate actions. I.e. a WAR manager bundle can detect  
>> reliably
> the
>> 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
> tomcat-specific 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 ).
>
>
> Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message