tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <cos...@gmail.com>
Subject Re: Osgifing Tomcat
Date Wed, 30 Apr 2008 17:28:39 GMT
On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <peter.kriens@aqute.biz>
wrote:

> 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.



Regarding 'dynamic register/unregister' - the servlet API defines one way to
do this, i.e. war and the
deployment. There is no standard API to install/uninstall/start/stop a .war
- but HttpService
is not that either. Runtime config changes ( adding/removing servlets
without web.xml changes
and re-deployment ) is not specified, but it's a whole different discussion
for the JSR people
 to solve, I'm pretty sure it'll be different from HttpService.



 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 lot of people would like for tomcat to provide more jetty-like APIs for
programmatic
configuration ( and in a way it is already possible - just not easy ).
As an API, HttpService is way off - in '99 and servlet 2.1 it may have been
valuable.

Let's keep HttpService for a different discussion :-)





> 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.
>

Actually - JMX provides a lot of this dynamism.  Tomcat is using a lot of
JMX ( and hopefully will use more ),
and provide very similar model with OSGI services.





> 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.


To clarify: updating webapps in tomcat without rebooting has been around for
many years :-).
Webapps are quite similar with the bundles - it would be interesting to see
if we could use
OSGI classloader instead of ours, but I don't think that's a real problem.
People are looking for 'gapless' restart, i.e. users who have an active
session continuing to
use the old version ( or some magic way to migrate the session - but that's
likely impossible
in most real cases, i.e. if code changes happen ). OSGi alone can't solve
this.

A whole different class of users would like to see _less_ dynamism - i.e.
embedding tomcat
as a jar and using simple APIs and no class loaders or config files. In both
high-end servers
and low-end embedding this is a very important use case.


The problem I would like to see solved in tomcat is breaking it up in
modules - i.e. separating
all the optional parts and having a way to ship a really minimal core and a
good way to release and
deploy add-on bundles. OSGi may be a good way to do this.

I think the requirements are:
- provide a way for different tomcat components and core to be packaged as
OSGi bundles, using manifests
and maybe optional activators if it can't be avoided ( as long as tomcat
doesn't depend on it ). I think this
is an easy sell, I can't think of any good technical reasons not to do it.

- break tomcat release ( for 7.0 or 6.5 or whatever trunk will be released
as ) into just core ( minimal servlet
impl ) and bundles

- find a easy way for people to download/install all modules they want.

- integrate this with the JMX layer and the manager servlet

- all this without a hard dependency on OSGI - for people who want 'one big
jar' for embedding
( we don't want to force them to use osgi - or be dynamic - if they don't
have a need for this)

I think 'more dynamism' is a good thing - but so is 'less dynamism',  both
are valid  goals and we  can and
should support both. ( right now we're somewhere in the middle -  don't
really support either one well enough )


 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.


Any pointer to the docs ?

If it only involves declarative stuff ( xml, manifest ) and is done at
install time - it may work
for us.

Having a bundle start just to declare they provide a service (that won't be
used) is a
non-starter.

The current model in tomcat is to use Class.forName to load components using
server.xml -
only the code that is used is started. I don't think it'll be acceptable to
replace
server.xml or use OSGi for configuration ( in particular when JMX is a
better solution for
many config problems ).



> 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.


Too bad :-)


>
> 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.


Tomcat is in the business of deployment and configuration of WAR files -
that's a core part of the spec.



> 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.


Sure - the core business of tomcat is to deploy/configure/run WAR files
conforming to the spec.


The biggest problems ( IMO ) facing tomcat are:
- it needs more modularity in terms of its own extensions ( connectors,
auth, session managers, etc ).
- it needs to be easier to embed - both dynamically and as 'one big jar' (
or jetty-style ).
For both OSGi could help.

( well, we also have some social problems from time to time :-)

Costin

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