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 Tue, 29 Apr 2008 06:25:33 GMT
>>  Please, I think the audience is pretty much "mature" developpers  
>> here :-)
I know, that is why it is scary and sounds complex because experienced  
developers
know much better what can go wrong. Novices have much fewer qualms. :-)

Anyway, the dynamism is not Eclipse's strongest feature, but they are  
getting better
because the underlying OSGi engine allows them to be dynamic. Update  
manager
now asks you if you want to restart, it used to just do it. And it  
often works. I think that it
just takes time for all the thousands of developers to get used to  
dynamics. There
might be similar issues with WARs but the key difference is, is that a  
WAR is
much more self contained than a plugin in Eclipse. Plugins willy nilly  
refer to each other.

I guess maybe it is time to gather some requirements for this effort?  
There are so
many ways to skin a cat, but you first need to know which cat. Because
I am not sure how big you want to make this effort? I do not know  
enough about
Tomcat to really make a lot of sense. Providing OSGi headers seems to  
fulfill
the immediate need of several groups. However, it would be really nice  
if you
could provide a service interface like an Http Service (Http Service  
itself is Servlet 2.1,
so you likely need something better). However, if you put the headers  
in place,
I am sure someone else will provide this functionality as another  
bundle.

I think the more ambitious case then is to leverage the OSGi class  
loading and
allow WARs to be installed dynamically. Several people (there is also an
RFC inside the OSGi about this, and we added several features to OSGi  
R4 for this
use case), are working on this. The devil is in the details, but I am  
pretty sure
you can do this with a bit of effort.

Of course then there is the possibility to turn Tomcat itself into  
separate bundles and
leverage OSGi internally. This is an interesting exercise but looking  
at the sentiments
in this list I think this is a far way off :-)

> So basically, if you have a webapp with JSPs, with this "not hard too
> write mechanism", you have too query a specific Bundle from the
> webapp, and call a non-standard method. Am I reading that right?

In OSGi, the bundles are first class citizens in the API. This allows an
extender bundle to read resources from the bundle when it gets started  
and
take appropriate actions. I.e. a WAR manager bundle can detect  
reliably the
installation of new bundles, read the appropriate XML files, and do the
registrations. So the "non standard" method would be internal Tomcat API
called by a Tomcat bundle. I think it is a very good requirement to  
keep the
WAR the WAR and not require any OSGi code in there. In the longer run
OSGi could update the rather stale Http Service specification to add  
this
kind of management API, allowing the WAR manager and the web server to  
be
independent bundles so that developers can mix and match.

I am not intricately involved with these efforts but I am more than
willing to organize some effort to get the different groups together  
that are
working on this?

Kind regards,

	Peter Kriens




On 28 apr 2008, at 23:23, Damien B wrote:

> On Mon, Apr 28, 2008 at 12:52 PM, pkriens wrote:
>>> To me, a webapp adds "entries" (aka Servlet) to menus (aka url  
>>> patterns)
>>> from a static file inside the war (web.xml). If it was not  
>>> possible in 4
>>> years to solve this problem in Eclipse, how will it be possible for
>>> Tomcat?
>> More and more code is supporting the dynamic life cycle model  
>> because it is
>> not that hard and the Eclipse people like it. However, you should  
>> realize
>> that there is a very diverse community out there. Only recently is  
>> OSGi on their
>> radar.
>
> I was talking about a very specific case; Eclipse 3.3, only with core
> plugins, is still unable to be updated without a full restart. Or
> maybe it's able to do it, but it does not know whether or not it's
> safe to do it.
>
>> Providing a mechanism to get servlets registered from the web.xml are
>> available. The OPS 4J guys are providing tools and bundles:
>> http://wiki.ops4j.org/confluence/display/ops4j/Pax+Web+Extender. It  
>> is
>> actually not that hard.
>
> So, it's easily doable, why didn't the Eclipse folks used that  
> approach?
> I see on the page you reference that JSPs must be registered manually,
> and it works only with their specific HTTP Service Bundle:
> "Then you have to let Pax Web know that you have jsps by calling the
> registerJsps() method on WebContainer."
> So basically, if you have a webapp with JSPs, with this "not hard too
> write mechanism", you have too query a specific Bundle from the
> webapp, and call a non-standard method. Am I reading that right?
>
>> This may all sound scary and complex,
>
> Please, I think the audience is pretty much "mature" developpers  
> here :-)
>
>> but it is surprisingly simple when you try it
>> out because it feels very natural in an OSGi environment.
>
> The goal is to make a .war to feel very comfortable in a Servlet
> Container environment :-) If an action is required from the web
> application builder, then bye bye RI status :-)
> One thing I don't see in Pax Web Extender - War is the handling of
> resource-env-ref; but I'm not sure it raises a real question though.
>
>> Programming models like Spring DM, iPOJO, DS, etc. can further help  
>> to support this model while
>> not showing up in any Java code.
>
> The good things when something shows up in Java code are that: it can
> be easily be audited and it can be easily refactored. But maybe it's a
> question of taste after all.
>
> Cheers,
> Damien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


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


Mime
View raw message