On Wed, Apr 30, 2008 at 1:00 AM, Peter Kriens <[EMAIL PROTECTED]> wrote:
> 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. > > > As a bit of background. The logging and Http Service API are from 1999. At > that time > there was no dominant common logging API (neither in Java SE nor in open > source), > and the Http Service API is 100% based on the, at that time, standard > Servlet API (it > uses javax.servlet.http), it only provides an API to dynamically register > and unregister > servlets, which is still lacking in the current Servlet API. Regarding 'dynamic register/unregister' - the servlet API defines one way to do this, i.e. war and the deployment. There is no standard API to install/uninstall/start/stop a .war - but HttpService is not that either. Runtime config changes ( adding/removing servlets without web.xml changes and re-deployment ) is not specified, but it's a whole different discussion for the JSR people to solve, I'm pretty sure it'll be different from HttpService. 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. > > > > Well, I do not see that this is an dichotomy. By nature of being the RI, > you must follow the > JSR. However, it would not be hard to provide the Http Service as an > additional component. If > Tomcat provides an API to dynamically register servlets, it would be > trivial for someone > to provide an OSGi compatibility bundle, just like people are doing it > today. > But it would be a nice service to get this from the horse's mouth. I am > sure people are willing > to provide this code. > A lot of people would like for tomcat to provide more jetty-like APIs for programmatic configuration ( and in a way it is already possible - just not easy ). As an API, HttpService is way off - in '99 and servlet 2.1 it may have been valuable. Let's keep HttpService for a different discussion :-) > In reality, this is a rather crude approach because in well designed > systems the coupling between bundles > is minimal. At this point in time, services usually start to look more > attractive because they provide > an API to allow dynamic updates without crudely stopping all bundles in > the module dependency > graph (which in non-service based systems, and especially require-bundle > based systems tends > to become the whole system). And a service is just a POJO that is > registered under one or more interfaces. By allowing > it to withdrawn at any moment in time, as well as registered by multiple > independent parties, OSGi > provides a good abstraction of this dynamism. And there is no Java > counterpart for this. > Actually - JMX provides a lot of this dynamism. Tomcat is using a lot of JMX ( and hopefully will use more ), and provide very similar model with OSGI services. > they fell in love and the service layer was a major part of their > infatuation. They > realized very quickly how they could leverage the services as beans in > their model and the > advantages of dynamism without rebooting. To clarify: updating webapps in tomcat without rebooting has been around for many years :-). Webapps are quite similar with the bundles - it would be interesting to see if we could use OSGI classloader instead of ours, but I don't think that's a real problem. People are looking for 'gapless' restart, i.e. users who have an active session continuing to use the old version ( or some magic way to migrate the session - but that's likely impossible in most real cases, i.e. if code changes happen ). OSGi alone can't solve this. A whole different class of users would like to see _less_ dynamism - i.e. embedding tomcat as a jar and using simple APIs and no class loaders or config files. In both high-end servers and low-end embedding this is a very important use case. The problem I would like to see solved in tomcat is breaking it up in modules - i.e. separating all the optional parts and having a way to ship a really minimal core and a good way to release and deploy add-on bundles. OSGi may be a good way to do this. I think the requirements are: - provide a way for different tomcat components and core to be packaged as OSGi bundles, using manifests and maybe optional activators if it can't be avoided ( as long as tomcat doesn't depend on it ). I think this is an easy sell, I can't think of any good technical reasons not to do it. - break tomcat release ( for 7.0 or 6.5 or whatever trunk will be released as ) into just core ( minimal servlet impl ) and bundles - find a easy way for people to download/install all modules they want. - integrate this with the JMX layer and the manager servlet - all this without a hard dependency on OSGI - for people who want 'one big jar' for embedding ( we don't want to force them to use osgi - or be dynamic - if they don't have a need for this) I think 'more dynamism' is a good thing - but so is 'less dynamism', both are valid goals and we can and should support both. ( right now we're somewhere in the middle - don't really support either one well enough ) 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 ). > This is the use case of Declarative Services. The Service Component Runtime > (SCR) > will inspect the bundle when it gets installed and register any services > that > are declared and which have their dependencies on other services > satisfied. Any pointer to the docs ? If it only involves declarative stuff ( xml, manifest ) and is done at install time - it may work for us. Having a bundle start just to declare they provide a service (that won't be used) is a non-starter. The current model in tomcat is to use Class.forName to load components using server.xml - only the code that is used is started. I don't think it'll be acceptable to replace server.xml or use OSGi for configuration ( in particular when JMX is a better solution for many config problems ). > The OSGi manifest does have a header Export-Service and Import-Service > defined but because > you can't give an guarantees about them without running the bundle, we > decided to deprecate them. Too bad :-) > > However, how much do you want to be in the business of deployment? Tomcat > is very often used > as an application server but the web site tells me your core is a Servlet > and > JSP implementation. Tomcat is in the business of deployment and configuration of WAR files - that's a core part of the spec. > If you are going for strict modularity, wouldn't it make sense to > distinguish > between these core functions; Aren't the application management aspects > secondary? I.e. > allow your core JSP and Servlet engines to be used by others that provide > the deployment > aspects and allow your deployment code to be able to use other web service > providers? How > can you leverage existing deployment servers and management agents? For me > the key thing about > modularity is to do as little as possible and focus on core business. Sure - the core business of tomcat is to deploy/configure/run WAR files conforming to the spec. The biggest problems ( IMO ) facing tomcat are: - it needs more modularity in terms of its own extensions ( connectors, auth, session managers, etc ). - it needs to be easier to embed - both dynamically and as 'one big jar' ( or jetty-style ). For both OSGi could help. ( well, we also have some social problems from time to time :-) Costin
