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]