On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]>
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
