The poor man's approach could be to promote the org.osgi.core and and some org.osgi.service APIs to core modules similar to javax.* On 07/11/2012 05:14 PM, Thomas Diesler wrote: > Folks, > > related to [web,ejb,cdi,etc]/osgi integration an issue came up whereby > those ee subsystems don't want to have a dependency on osgi because osgi > is not a core component of the server. Likewise, osgi should not have a > dependency on these ee subsystems because it may be configured to run > independently. > > More general if foo and bar are both optional subsystems where do we put > the code that integrates foo and bar. foo-bar integration might require > to add a some DUPs. How are these registered? > > cheers > -thomas >

Just curious, Are you talking about deployed application EJBs, WARs, etc? or the actual subsystem modules themselves? For the former, why do the subsystems need to know about OSGi as it pertains to application deployments? Wouldn't OSGi class scoping metadata be handled at the JBoss MOdules level? For the latter, why would subsystems need to integrate with OSGi when we already have a kernel model and a class scoping project (jboss modules)? On 7/11/12 12:16 PM, Thomas Diesler wrote: > If there is no recommended alternative I would add optional dependencies > to integration modules to the osgi subsystem. > > On 07/11/2012 05:22 PM, Thomas Diesler wrote: >> The poor man's approach could be to promote the org.osgi.core and and >> some org.osgi.service APIs to core modules similar to javax.* >> >> >> On 07/11/2012 05:14 PM, Thomas Diesler wrote: >>> Folks, >>> >>> related to [web,ejb,cdi,etc]/osgi integration an issue came up whereby >>> those ee subsystems don't want to have a dependency on osgi because osgi >>> is not a core component of the server. Likewise, osgi should not have a >>> dependency on these ee subsystems because it may be configured to run >>> independently. >>> >>> More general if foo and bar are both optional subsystems where do we put >>> the code that integrates foo and bar. foo-bar integration might require >>> to add a some DUPs. How are these registered? >>> >>> cheers >>> -thomas >>>

If we are talking optional module dependencies thats fine. Service dependencies usually can't be optional across subsystems though, as it will cause a race. An example of the service problem is transactions and iiop. If JBoss Transactions is in JTS mode, it requires special interceptors to be enabled in the orb before it launches. From a service startup perspective both can't wait on the other. So right now we have an ugly solution where both subsystems have to be configured to match (transactions in jts mode, iiop with the transaction flag on). Awhile back we talked about addressing optional subsystem interdeps by introducing a generic capabilities api before the runtime stage executes. I think Kabir had a prototype somewhere. The idea was that after the model is built, there is a hook where subsystems can add some kind of indicator for what features they have made available, and other subsystems would then be able to define their service deps accordingly. On 7/11/12 11:16 AM, Thomas Diesler wrote: > If there is no recommended alternative I would add optional dependencies > to integration modules to the osgi subsystem. > > On 07/11/2012 05:22 PM, Thomas Diesler wrote: >> The poor man's approach could be to promote the org.osgi.core and and >> some org.osgi.service APIs to core modules similar to javax.* >> >> >> On 07/11/2012 05:14 PM, Thomas Diesler wrote: >>> Folks, >>> >>> related to [web,ejb,cdi,etc]/osgi integration an issue came up whereby >>> those ee subsystems don't want to have a dependency on osgi because osgi >>> is not a core component of the server. Likewise, osgi should not have a >>> dependency on these ee subsystems because it may be configured to run >>> independently. >>> >>> More general if foo and bar are both optional subsystems where do we put >>> the code that integrates foo and bar. foo-bar integration might require >>> to add a some DUPs. How are these registered? >>> >>> cheers >>> -thomas >>>