Osgifing Tomcat

[hgomez]

Hi to all,

Did there is plans, ideas or interest around about OSGI-fing Tomcat ?

Regards

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

[Costin Manolache-2]

I think OSGI has some good ideas - it is pretty good at handling class
loaders and loading/unloading modules. On the other side, they are
very 'framework'  - and like all other frameworks you have to do all
things their way and they re-invent a lot of wheels ( from logging
APIs to almost everything else ). If we could stick to the core - i.e.
module loading/unloading - it wouldn't be bad.

I did a quick search for OSGI implementations with apache license -
and it looks there is even an apache project, felix...

Costin


On 4/22/08, Henri Gomez <henri.gomez@...> wrote:

> Hi to all,
>
>  Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>
>  Regards
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

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

[hgomez]

2008/4/22, Costin Manolache <costin@...>:
> I think OSGI has some good ideas - it is pretty good at handling class
>  loaders and loading/unloading modules. On the other side, they are
>  very 'framework'  - and like all other frameworks you have to do all
>  things their way and they re-invent a lot of wheels ( from logging
>  APIs to almost everything else ). If we could stick to the core - i.e.
>  module loading/unloading - it wouldn't be bad.
>
>  I did a quick search for OSGI implementations with apache license -
>  and it looks there is even an apache project, felix...

Yep, I allready take look at felix and it's fine.

I think OSGIfing Tomcat is a good idea, as today a servlet engine is
only piece of code in IT architectures.

With more and more OSGI plugins in enterprises, we should have an OSGi
plugable tomcat or we'll see in a very near future others players do
servlet services in OSGI land.

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

[Filip Hanik - Dev Lists]

Henri Gomez wrote:
> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>  
I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt
my original plan was just to make sure all the MANIFEST.MF for each file
would have enough in it so that each JAR can be a OSGi bundle.

after that, one can add on as much or as little as one wishes

Filip
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>  


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

[Paul Benedict-2]

Is that enough so that web applications, either as a whole or in partial,
can be upgraded without stopping them? It's my understanding that if web
applications are loaded in an OSGi classloader, these kind of things are
possible.

Paul

On Tue, Apr 22, 2008 at 7:24 PM, Filip Hanik - Dev Lists <devlists@...>
wrote:

> Henri Gomez wrote:
>
> > Hi to all,
> >
> > Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
> >
> >
> I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt
> my original plan was just to make sure all the MANIFEST.MF for each file
> would have enough in it so that each JAR can be a OSGi bundle.
>
> after that, one can add on as much or as little as one wishes
>
> Filip
>
> > Regards
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[benoitf]

    Hello,

As part of OW2 JOnAS 5.0 OSGi based application server we're interested
to have Tomcat packaged as an OSGi bundle.
All our modules are bundles and if tomcat is already a bundle we won't
have to wrap it into a bundle on our side.

Regards,

Florent

Henri Gomez wrote:

> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>
> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>  

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

[hgomez]

>  I've put a note about this a while ago in tomcat/trunk/PROPOSALS.txt
>  my original plan was just to make sure all the MANIFEST.MF for each file
> would have enough in it so that each JAR can be a OSGi bundle.

Well it shouldn't hurt updating MANIFEST.MF. Could you update some so
we could take a look ?

>  after that, one can add on as much or as little as one wishes

Correct

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

[hgomez]

2008/4/23 Florent.BENOIT <Florent.BENOIT@...>:
>    Hello,
>
>  As part of OW2 JOnAS 5.0 OSGi based application server we're interested to
> have Tomcat packaged as an OSGi bundle.
>  All our modules are bundles and if tomcat is already a bundle we won't have
> to wrap it into a bundle on our side.
>
>  Regards,

Hum do you have some stuff to contribute or show us for review ?

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

[benoitf]

Our bundle of Tomcat is exposing JOnAS service API. I think that from a
tomcat bundle view it should expose its own interface like API for
registering/deploying a war component, etc.

If you want to see some source code, it's in the SVN.
http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/?rev=13842

Apache Felix iPOJO is used as well as the maven-bundle-plugin:
for the maven bundle plugin :
http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/src/main/resources/META-INF/jonas-web-container-tomcat-6.0.bnd?rev=13488&view=markup

metadata.xml for iPOJO :
http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas/jonas/trunk/jonas/modules/services/web-container/tomcat/6.0.x/src/main/resources/metadata.xml?rev=13058&view=auto

Regards

Florent


Henri Gomez wrote:

> 2008/4/23 Florent.BENOIT <Florent.BENOIT@...>:
>  
>>    Hello,
>>
>>  As part of OW2 JOnAS 5.0 OSGi based application server we're interested to
>> have Tomcat packaged as an OSGi bundle.
>>  All our modules are bundles and if tomcat is already a bundle we won't have
>> to wrap it into a bundle on our side.
>>
>>  Regards,
>>    
>
> Hum do you have some stuff to contribute or show us for review ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>  

[Filip Hanik - Dev Lists]

Henri Gomez wrote:

> 2008/4/23 Florent.BENOIT <Florent.BENOIT@...>:
>  
>>    Hello,
>>
>>  As part of OW2 JOnAS 5.0 OSGi based application server we're interested to
>> have Tomcat packaged as an OSGi bundle.
>>  All our modules are bundles and if tomcat is already a bundle we won't have
>> to wrap it into a bundle on our side.
>>
>>  Regards,
>>    
>
> Hum do you have some stuff to contribute or show us for review ?
>  

sure, for the whole bundle, it would look like this, but what I would
like to do for trunk, is to do one per JAR file

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.apache.tomcat
Bundle-Vendor: Apache Software Foundation
Bundle-Version: 6.0.16
Import-Package: org.eclipse.core.resources;resolution:=optional,
 org.eclipse.core.runtime;resolution:=optional,
 org.eclipse.jdt.core;resolution:=optional,
 org.eclipse.jdt.core.compiler;resolution:=optional,
 org.eclipse.jdt.core.dom;resolution:=optional,
 org.eclipse.jdt.internal.compiler;resolution:=optional,
 org.eclipse.jdt.internal.compiler.apt.dispatch;resolution:=optional,
 org.eclipse.jdt.internal.compiler.ast;resolution:=optional,
 org.eclipse.jdt.internal.compiler.batch;resolution:=optional,
 org.eclipse.jdt.internal.compiler.classfmt;resolution:=optional,
 org.eclipse.jdt.internal.compiler.codegen;resolution:=optional,
 org.eclipse.jdt.internal.compiler.env;resolution:=optional,
 org.eclipse.jdt.internal.compiler.flow;resolution:=optional,
 org.eclipse.jdt.internal.compiler.impl;resolution:=optional,
 org.eclipse.jdt.internal.compiler.lookup;resolution:=optional,
 org.eclipse.jdt.internal.compiler.parser;resolution:=optional,
 org.eclipse.jdt.internal.compiler.parser.diagnose,
 org.eclipse.jdt.internal.compiler.problem;resolution:=optional,
 org.eclipse.jdt.internal.compiler.util;resolution:=optional,
 org.eclipse.jdt.internal.core;resolution:=optional,
 org.eclipse.jdt.internal.core.builder;resolution:=optional,
 org.eclipse.jdt.internal.core.util;resolution:=optional,
 com.springsource.engine.servlet.tomcat.loader;resolution:=optional,
 javax.mail;resolution:=optional,
 javax.mail.internet;resolution:=optional,
 javax.management;resolution:=optional,
 javax.management.loading;resolution:=optional,
 javax.management.modelmbean;resolution:=optional,
 javax.naming;resolution:=optional,
 javax.naming.directory;resolution:=optional,
 javax.naming.spi;resolution:=optional,
 javax.persistence;resolution:=optional,
 javax.security.auth;resolution:=optional,
 javax.security.auth.callback;resolution:=optional,
 javax.security.auth.login;resolution:=optional,
 javax.security.auth.spi;resolution:=optional,
 javax.sql;resolution:=optional,
 javax.xml.parsers;resolution:=optional,
 javax.xml.transform;resolution:=optional,
 javax.xml.transform.stream;resolution:=optional,
 javax.xml.ws;resolution:=optional
Export-Package: javax.annotation,
 javax.annotation.security,
 javax.ejb,
 javax.el,
 javax.mail,
 javax.mail.internet,
 javax.persistence,
 javax.servlet,
 javax.servlet.http,
 javax.servlet.jsp,
 javax.servlet.jsp.el,
 javax.servlet.jsp.resources,
 javax.servlet.jsp.tagext,
 javax.servlet.resources,
 javax.xml.ws,
 org.apache,
 org.apache.catalina,
 org.apache.catalina.ant,
 org.apache.catalina.ant.jmx,
 org.apache.catalina.authenticator,
 org.apache.catalina.connector,
 org.apache.catalina.core,
 org.apache.catalina.deploy,
 org.apache.catalina.ha,
 org.apache.catalina.ha.authenticator,
 org.apache.catalina.ha.context,
 org.apache.catalina.ha.deploy,
 org.apache.catalina.ha.session,
 org.apache.catalina.ha.tcp,
 org.apache.catalina.ha.util,
 org.apache.catalina.loader,
 org.apache.catalina.manager,
 org.apache.catalina.manager.host,
 org.apache.catalina.manager.util,
 org.apache.catalina.mbeans,
 org.apache.catalina.realm,
 org.apache.catalina.security,
 org.apache.catalina.servlets,
 org.apache.catalina.session,
 org.apache.catalina.ssi,
 org.apache.catalina.startup,
 org.apache.catalina.tribes,
 org.apache.catalina.tribes.group,
 org.apache.catalina.tribes.group.interceptors,
 org.apache.catalina.tribes.io,
 org.apache.catalina.tribes.membership,
 org.apache.catalina.tribes.tipis,
 org.apache.catalina.tribes.transport,
 org.apache.catalina.tribes.transport.bio,
 org.apache.catalina.tribes.transport.bio.util,
 org.apache.catalina.tribes.transport.nio,
 org.apache.catalina.tribes.util,
 org.apache.catalina.users,
 org.apache.catalina.util,
 org.apache.catalina.valves,
 org.apache.coyote,
 org.apache.coyote.ajp,
 org.apache.coyote.http11,
 org.apache.coyote.http11.filters,
 org.apache.coyote.memory,
 org.apache.el,
 org.apache.el.lang,
 org.apache.el.parser,
 org.apache.el.util,
 org.apache.jasper,
 org.apache.jasper.compiler,
 org.apache.jasper.compiler.tagplugin,
 org.apache.jasper.el,
 org.apache.jasper.resources,
 org.apache.jasper.runtime,
 org.apache.jasper.security,
 org.apache.jasper.servlet,
 org.apache.jasper.tagplugins.jstl,
 org.apache.jasper.tagplugins.jstl.core,
 org.apache.jasper.util,
 org.apache.jasper.xmlparser,
 org.apache.jk,
 org.apache.jk.apr,
 org.apache.jk.common,
 org.apache.jk.config,
 org.apache.jk.core,
 org.apache.jk.server,
 org.apache.juli,
 org.apache.juli.logging,
 org.apache.naming,
 org.apache.naming.factory,
 org.apache.naming.java,
 org.apache.naming.resources,
 org.apache.naming.resources.jndi,
 org.apache.tomcat,
 org.apache.tomcat.buildutil,
 org.apache.tomcat.jni,
 org.apache.tomcat.util,
 org.apache.tomcat.util.buf,
 org.apache.tomcat.util.buf.res,
 org.apache.tomcat.util.collections,
 org.apache.tomcat.util.digester,
 org.apache.tomcat.util.http,
 org.apache.tomcat.util.http.fileupload,
 org.apache.tomcat.util.http.mapper,
 org.apache.tomcat.util.http.res,
 org.apache.tomcat.util.log,
 org.apache.tomcat.util.modeler,
 org.apache.tomcat.util.modeler.modules,
 org.apache.tomcat.util.net,
 org.apache.tomcat.util.net.jsse,
 org.apache.tomcat.util.net.jsse.res,
 org.apache.tomcat.util.net.res,
 org.apache.tomcat.util.res,
 org.apache.tomcat.util.threads,
 org.apache.tomcat.util.threads.res



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

[benoitf]

    Yes, the modular aspect is for sure a better choice. So we can have
a smaller Tomcat (by only using few bundles) or bundles loaded on demand.

Regards,

Florent


Filip Hanik - Dev Lists wrote:

> Henri Gomez wrote:
>> 2008/4/23 Florent.BENOIT <Florent.BENOIT@...>:
>>  
>>>    Hello,
>>>
>>>  As part of OW2 JOnAS 5.0 OSGi based application server we're
>>> interested to
>>> have Tomcat packaged as an OSGi bundle.
>>>  All our modules are bundles and if tomcat is already a bundle we
>>> won't have
>>> to wrap it into a bundle on our side.
>>>
>>>  Regards,
>>>    
>>
>> Hum do you have some stuff to contribute or show us for review ?
>>  
>
> sure, for the whole bundle, it would look like this, but what I would
> like to do for trunk, is to do one per JAR file
>

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

[Remy Maucherat]

On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?

The only thing which ever attracts you is pointless hype, it's quite
funny ;)

Rémy



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

[hgomez]

>  The only thing which ever attracts you is pointless hype, it's quite
>  funny ;)

Remy, I, and many others, will be happy, at least one time, see you
discuss technicals and usage aspects of a Tomcat evolution.

* What's the pros and cons ?

* Interest, usage, openess


OSGI is not buzz, it's real world, and if you want TC keep its RI
status of servlet engine, please keep this in mind.

Do you check latest netcraft review ?

http://survey.netcraft.com/Reports/200804/

Do you want more Tomcat users switch to a more open minded engine like Jetty ?

Regards

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

[hgomez]

>    Yes, the modular aspect is for sure a better choice. So we can have a
> smaller Tomcat (by only using few bundles) or bundles loaded on demand.

+1

And select which part of the engine to be used.

What make HTTPD server so successfull was its modular approach and openess.

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

[Remy Maucherat]

On Wed, 2008-04-23 at 14:23 +0200, Henri Gomez wrote:

> >  The only thing which ever attracts you is pointless hype, it's quite
> >  funny ;)
>
> Remy, I, and many others, will be happy, at least one time, see you
> discuss technicals and usage aspects of a Tomcat evolution.
>
> * What's the pros and cons ?
>
> * Interest, usage, openess
>
>
> OSGI is not buzz, it's real world, and if you want TC keep its RI
> status of servlet engine, please keep this in mind.

It's as real world as any other microcontainer spec that has shown up,
and will show up afterwards. Thinking back about it, it was a really bad
decision to not use Avalon way back then when we had a chance.

> Do you check latest netcraft review ?
>
> http://survey.netcraft.com/Reports/200804/

I think it's a great domain names parking study. Don't hesitate to
provide evidence that Netcraft means anything for the servlet container
market (or even for httpd - see, it's falling really fast, any
conclusion based on that ? - on the webserver market as whole, as it
seems to measure what virtual hosters are using, which is nice to know,
but that's about it).

> Do you want more Tomcat users switch to a more open minded engine like Jetty ?

I don't know if you noticed, but I have not really been participating in
Tomcat's trunk development for months, and am only dealing with Tomcat
6.0. In trunk or any other future developments, at the moment my plan is
only to comment (pretty much like Costin does).

So fear not, your biggest problem is now gone, and you can now start
contributing :)

Rémy



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

[Costin Manolache-2]

On Wed, Apr 23, 2008 at 4:35 AM, Remy Maucherat <remm@...> wrote:
> On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
>  > Hi to all,
>  >
>  > Did there is plans, ideas or interest around about OSGI-fing Tomcat ?
>
>  The only thing which ever attracts you is pointless hype, it's quite
>  funny ;)

I share your concern about OSGI and hype :-)

I spent few years working on a project using OSGI heavily, with people
buying the hype. It was a big disaster, most time was spent
reinventing the wheels and turning perfectly simple code to services,
registering the services in a bundle and importing it in another, then
figuring out why it's slow to start up or start order problems or
manifests.

On the other side - OSGI has a good class loader implementation,
probably the best ( JBoss has a good one too - using a similar
delegation mechanism ).

As long as you stick to using the class loader - i.e. have manifests
with imports/exports and the boilerplate - OSGI can be a benefit.
Since IMO the main problem in tomcat is lack of modularity - it
wouldn't be bad to give it a try.

Costin

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

[Costin Manolache-2]

>  I don't know if you noticed, but I have not really been participating in
>  Tomcat's trunk development for months, and am only dealing with Tomcat
>  6.0. In trunk or any other future developments, at the moment my plan is
>  only to comment (pretty much like Costin does).

I'm actually working in sandbox, and I plan to propose stuff for the
trunk - and thus
become active ( I'm very slow  those days - I don't have a lot of free time ).



Costin

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

[benoitf]

    Yes, that looks great.

Also, for OSGi, as all is done by package (import/export) the first step
is to be sure that API and Implementation are never in the same package
name. So we can export APIs and keep private the implementation.

Florent



Henri Gomez wrote:

>>    Yes, the modular aspect is for sure a better choice. So we can have a
>> smaller Tomcat (by only using few bundles) or bundles loaded on demand.
>>    
>
> +1
>
> And select which part of the engine to be used.
>
> What make HTTPD server so successfull was its modular approach and openess.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>  

[jimmanico]

Remy - please consider the Apache guidelines about being respectful on the public lists.

Key word: please.

- Jim

-----Original Message-----
From: Remy Maucherat <remm@...>
Sent: Wednesday, April 23, 2008 7:35 AM
To: Tomcat Developers List <dev@...>
Subject: Re: Osgifing Tomcat

On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote:
> Hi to all,
>
> Did there is plans, ideas or interest around about OSGI-fing Tomcat ?

The only thing which ever attracts you is pointless hype, it's quite
funny ;)

Rémy



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



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

[hgomez]

>  I share your concern about OSGI and hype :-)

As a regular Eclipse user, I like OSGI, but from the plugin altitude.

>  I spent few years working on a project using OSGI heavily, with people
>  buying the hype. It was a big disaster, most time was spent
>  reinventing the wheels and turning perfectly simple code to services,
>  registering the services in a bundle and importing it in another, then
>  figuring out why it's slow to start up or start order problems or
>  manifests.

Could we say that today OSGI is more mature and stable, ie Equinox or Felix ?

>  On the other side - OSGI has a good class loader implementation,
>  probably the best ( JBoss has a good one too - using a similar
>  delegation mechanism ).

And OSGI help modularity

>  As long as you stick to using the class loader - i.e. have manifests
>  with imports/exports and the boilerplate - OSGI can be a benefit.
>  Since IMO the main problem in tomcat is lack of modularity - it
>  wouldn't be bad to give it a try.

A big +1.

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