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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
