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 Thu, 01 May 2008 08:24:12 GMT
> 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.
Ok, but who is re-inventing here? :-)

> 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.
I think you underestimate what OSGi does and how closely the module  
layer, lifecycle layer,
and service layer interact to make things work for the programmer.  
OSGi is really more than
classloaders on steroids.

However, referring to an earlier  discussion, I think the trick is not  
to become dependent on
any one technology. I.e. the core Servlet and JSP engines should be  
POJO, and receive their
connections from the outside. Be that JMX, OSGi, or whatever. This  
would make it trivial
to provide the core functionality as a bean as well as an OSGi  
service. As long as the engines
can handle the dynamism.

The OSGi framework is about one idea: decoupling. All OSGi services  
are optional and none of the
services is based on other services. The majority of bundles does not  
have to touch OSGi API. The
recommendation has always been to configure your bundle in the bundle  
activator, but do not perform
any user functionality there so you can reuse your implementations in  
other contexts.

The OSGi functionality is limited to the management of the environment  
and how these decoupled units
can leverage each other. Interestingly, the majority of open source  
projects have (re)invented this
wheel over and over again, invariably not taking into account the  
important issues like versioning
and strict modularity.

> 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.
Well, you seem to have the desired functionality? Why switch? I would  
never update a project
to use a new technology until it really is a significant improvement.  
I do not think the value
proposition of the OSGi class loaders warrants the switch on its own?

> 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.
Not on its own. However, the bundle model allows you to do a lot of  
interesting things here. In the
Http Service model you know exactly the bundle that registered the  
servlet (through the use of an
OSGi Service Factory). If the servlet is unregistered, I assume you  
can keep the session object around.
the problem is, I am out of my league here, is that the session object  
contains classes
to the old bundle. The trick is to convert these to the classes in the  
updated bundle. I guess you
could use serialization (you know exactly the bundle where the new  
classes should come from) or a fancy
reflection based mechanism, or use a mechanism that includes the bundle.
Then again, this is not my area of expertise. However, I do believe that
the bundle model and service model with their notification model do  
help allow you to do this
without ending up in class cast exceptions and version mismatches.

Of course there are nasty issues when classes in a session are reused  
by independent bundles. We have
a similar (I think) problem with security. One bundle can use a  
different version of a permission class
than another. We therefore convert the permission info to the correct  
version of the permission
class when doing the check because we then know exactly what version  
that caller is using. You could
do something similar with the session object. If an object is gotten  
from it, you can check if the servlet's
bundle is compatible with the class in the session and automatically  
convert it to the appropriate class.

Then again, I am not an expert here so this might not be the problem  
at all. I only know that the devil
is in the details. :-(

> 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.
I agree, this is aligned with the POJO ideas. Separate the  
functionality in a set of completely disjoint
functionalities. Then allow the customer to wire them into an OSGi  
based system, JMX based system,
standalone server, etc. You can then always provide one or more of  
those instances. The trick is
decoupling functional units from each other, with requires that things  
that are put together are
highly cohesive. Anyway, no dynamism is the simple instance of  
dynamism ...

I think the remainder of your mail is about this decomposition into  
functional units. I wholeheartedly
agree that you want to minimize dependencies on OSGi API. In this  
phase I would need a whiteboard
with people that have expertise in the different units to make the  
best decomposition. I will be at JavaOne next
week so if people want to discuss the use of OSGi, feel free to  
contact me there.

> ( well, we also have some social problems from time to time :-)
I must admit I feel I am walking on eggs ... and I am a bit surprised  
how few others tune in. If I am
trespassing here, please let me know kindly :-)

Kind regards,

	Peter Kriens







On 30 apr 2008, at 19:28, Costin Manolache wrote:

> 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


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


Mime
View raw message