Long thread, my summary: 1. Adding OSGI manifests to tomcat jars: there is interest, it will provide benefits for people using tomcat in an OSGI environment. I don't think there is any major controversy - it'll not affect any existing functionality. If Henri or someone familiar with OSGi and interested can contribute the work - it would be great.
2. Using OSGi for webapp loading/deployment: there is no direct benefit and risks to alter the standard ( webapps are not allowed to share classes ) - but it would be an interesting experiment for sandbox or some separate module. It seems clear it won't provide 'gapless' deployment. If there are volunteers - I'm curious to see how it works. 3. Using OSGi to modularize tomcat - i.e. to deploy things like connectors, session managers, etc - Peter mentioned that it is possible to do it without requiring each module to be started and using the activator to register services. I believe there is interest in modularizing tomcat, and this seems like one clear option - if it can be done non-intrusively ( i.e. it should be in some separate package and should be possible to run tomcat as it is now, without requiring OSGI ). That's the part I'm most interested in, I'll probably play with this for tomcat-lite. 4. Using OSGi extensions to the servlet API ( HttpService ) - I'm not convinced, but since it can be provided in a separate bundle I don't think it's worth arguing about it. 5. OSGi defines a basic 'core' - i.e. bundles, manifests and advanced class loader - and a number of extra services and APIs. Peter explained that the core can be used without touching the 'extra', he obviously believes the extras are valuable - I believe they are dangerous, but given that tomcat already decided to use JMX and other equivalents - it would be a hard battle to change. In any case - for any new dependency or API to be used in tomcat I'm sure we can have a technical debate and decide what to do - since most OSGi APIs depend on OSGi and we want OSGi to be optional ( i.e. to have tomcat working with and without OSGI ) - it'll be an easy one :-) IMO it is clear stability of the existing code (and community) is the major concern, so 'walking on eggs' seems appropriate. Costin On Thu, May 1, 2008 at 1:24 AM, Peter Kriens <[EMAIL PROTECTED]> wrote: > 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. > > > Ok, but who is re-inventing here? :-) > > 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. > > > I think you underestimate what OSGi does and how closely the module layer, > lifecycle layer, > and service layer interact to make things work for the programmer. OSGi is > really more than > classloaders on steroids. > > However, referring to an earlier discussion, I think the trick is not to > become dependent on > any one technology. I.e. the core Servlet and JSP engines should be POJO, > and receive their > connections from the outside. Be that JMX, OSGi, or whatever. This would > make it trivial > to provide the core functionality as a bean as well as an OSGi service. As > long as the engines > can handle the dynamism. > > The OSGi framework is about one idea: decoupling. All OSGi services are > optional and none of the > services is based on other services. The majority of bundles does not have > to touch OSGi API. The > recommendation has always been to configure your bundle in the bundle > activator, but do not perform > any user functionality there so you can reuse your implementations in > other contexts. > > The OSGi functionality is limited to the management of the environment and > how these decoupled units > can leverage each other. Interestingly, the majority of open source > projects have (re)invented this > wheel over and over again, invariably not taking into account the > important issues like versioning > and strict modularity. > > 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. > > > Well, you seem to have the desired functionality? Why switch? I would > never update a project > to use a new technology until it really is a significant improvement. I do > not think the value > proposition of the OSGi class loaders warrants the switch on its own? > > 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. > > > Not on its own. However, the bundle model allows you to do a lot of > interesting things here. In the > Http Service model you know exactly the bundle that registered the servlet > (through the use of an > OSGi Service Factory). If the servlet is unregistered, I assume you can > keep the session object around. > the problem is, I am out of my league here, is that the session object > contains classes > to the old bundle. The trick is to convert these to the classes in the > updated bundle. I guess you > could use serialization (you know exactly the bundle where the new classes > should come from) or a fancy > reflection based mechanism, or use a mechanism that includes the bundle. > Then again, this is not my area of expertise. However, I do believe that > the bundle model and service model with their notification model do help > allow you to do this > without ending up in class cast exceptions and version mismatches. > > Of course there are nasty issues when classes in a session are reused by > independent bundles. We have > a similar (I think) problem with security. One bundle can use a different > version of a permission class > than another. We therefore convert the permission info to the correct > version of the permission > class when doing the check because we then know exactly what version that > caller is using. You could > do something similar with the session object. If an object is gotten from > it, you can check if the servlet's > bundle is compatible with the class in the session and automatically > convert it to the appropriate class. > > Then again, I am not an expert here so this might not be the problem at > all. I only know that the devil > is in the details. :-( > > 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. > > > I agree, this is aligned with the POJO ideas. Separate the functionality > in a set of completely disjoint > functionalities. Then allow the customer to wire them into an OSGi based > system, JMX based system, > standalone server, etc. You can then always provide one or more of those > instances. The trick is > decoupling functional units from each other, with requires that things > that are put together are > highly cohesive. Anyway, no dynamism is the simple instance of dynamism > ... > > I think the remainder of your mail is about this decomposition into > functional units. I wholeheartedly > agree that you want to minimize dependencies on OSGi API. In this phase I > would need a whiteboard > with people that have expertise in the different units to make the best > decomposition. I will be at JavaOne next > week so if people want to discuss the use of OSGi, feel free to contact me > there. > > ( well, we also have some social problems from time to time :-) > > > I must admit I feel I am walking on eggs ... and I am a bit surprised how > few others tune in. If I am > trespassing here, please let me know kindly :-) > > Kind regards, > > Peter Kriens > > > > > > > > > On 30 apr 2008, at 19:28, Costin Manolache wrote: > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
