Re: Osgifing Tomcat

[David Jencks <da...@yahoo.com>]

On Apr 30, 2008, at 10:28 AM, Costin Manolache wrote:

> On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <pe...@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

umm, jsr-88??

david jencks

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