[jboss-osgi-dev] [JBoss OSGi Development] - Goals of OSGi integration - Using a Standard spi for deploym

Beyond the obvious goal of implementing the OSGi spec the other part to having the OSGi framework implemented on top of the MC/Deployers is so you can control other types of deployments using the Bundle/Service api. This is a standardised api. Which means some people are much more confortable writing to it than for example the JBoss MainDeployer api. There's also the reverse requirement that the OSGi components should work properly from the MC/Deployers. Some typical use cases: 1 ) INSTALLATION I want to deploy a webapp. I do: Bundle myWar = someBundle.installBundle(myWarURL); Since this is not an OSGi bundle it will automatically move to the ACTIVE state (unlike normal bundles which which require a bundle.start() unless there is some other rule to do it, e.g. start level service or persistent state, etc). This worked until the latest changes. 1a) It should be possible to deploy OSGi bundles using the MainDeployer, e.g. via hot deployment. AFAIK this works? 2) CONTROLLING LIFECYCLE I can use the OSGi api to control the lifecycle of non-osgi deployments. e.g. Bundle tomcat = ...; tomcat.stop(); // do stuff tomcat.start(); This also worked until the latest changes. 2a) In reverse you should be able to control the OSGi bundles and services using the MC/Deployers api. This works for deployments, but it isn't going to understand things like the AUTO_START_PROPERTY which is unknown to the MC code. 3) ACCESSING SERVICES I should be able to use the OSGi api to access jboss services, e.g. ServiceReference[] dataSources = bundleContext.getServiceReferences(javax.sql.DataSource.class.getName(), null); Those services should look like they are associated with a Bundle (the BundleState associated with the DeploymentUnit that created the datasource) and do all the notifications, security checks etc. that OSGi requires. This doesn't work. See the "ServiceTracking" thread where Ales and I discussed how to implement this. 3a) In reverse, OSGi deployed services should be available to the MC for use in dependency injection. 4) INTEGRATED CLASSLOADING I should be able to import classes from JBoss deployments. e.g. ImportPackage: javax.ejb;version=3.0 This doesn't work for the reasons described on the "resolver is wrong" thread. 4a) In reverse OSGi bundle classes should be available to non-osgi deployments. This works, but the rules will likely be inconsistent to what the ResolverPlugin is doing, leading to classloading problems? 5) MANAGEMENT Other deployments and services that are not OSGI deployments should still appear in things like the package admin. 5a) In reverse, OSGi bundles and services should be available to JBoss management tools, e.g. the management console 6) OTHER OSGI FEATURES Other OSGi features, like lazy start should work for other non-osgi deployments. Or you should be able to add a war to an osgi start level. etc. 6a) You can use JBoss specific features to augment/change the standard behaviour of an osgi-bundle. e.g. adding a META-INF/jboss-classloading.xml to change the classloading requirements without touching the manifest. (This would be essentially what the management console will do if you modify the classloading rules there). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266334#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...