On Mon, Apr 28, 2008 at 11:25 PM, Peter Kriens <[EMAIL PROTECTED]> wrote: > 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
Headers seems to be ok - I don't think anyone objected to this. 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. 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. > 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 There are 3 issues here: - dynamic installation and uninstallation of WARs - that's already working quite well, no need for OSGI. - 'gapless' upgrade (old version running alongside with the new one)- OSGI has no magic bullet for that, the problem is more in the mapping layer. - using OSGI class loading to allow more flexible interaction between WARs. Unfortunately that is invalidated by the servlet spec, which clearly defines this area. > > 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 :-) Quite the opposite, I think this would be the best use of OSGI - if we can avoid the bad things in OSGI ( like the service APIs and over-use of bundle activator and service registration ). What tomcat needs the most IMO is a way to separate 'core' functionality from 'modules' - like authenticators, session management, connectors. Using OSGI bundles for modules and integrating with the lifecycle would be ok if it can be done non-intrusive: - some OSGI-independent interface ( with a OSGI implementation and a 'direct' one ) to load the module. I personally like JBoss style of modules as well - so that could be a 3rd implementation ( maybe outside of apache ). - some code loaded from server.xml that would start the OSGI container and load the modules - use OSGI/Jboss-style class loader to allow the modules and core to share classes. Most of this can be done in an 'optional' package ( i.e. in the trunk, but not included in the 'official' base release ). Few simple interfaces and impl changes may need to be added to the core - but it can be very light. > > 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'm pretty sure most people want to use OSGi for services, and Servlet API for web development. HttpService is a non-starter - it would be great if the next servlet API defines interfaces for dynamic (code-based) loading of servlets - and we can provide some tomcat-specific interfaces ( like jetty does ) - but OSGi is not the right place to look for servlet ( or logging ) APIs. My main question regarding OSGI bundles and services: 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 ). Costin
