This was talked about briefly on the pull request list, but no resolution was made. The issue is that JBAS-8585 and JBAS-8599 both add module dependencies from some of the core subsystems on to the osgi subsystem (naming and transactions). In addition we already have a module dependency from domain to osgi. So for all intents and purposes, we are moving towards AS7 having osgi as a required base level component. Before progressing much further in this direction we should evaluate whether this is the right thing to do, and how this solution compares to alternative approaches. I can think of three approaches right off the bat. 1. Continue as is, osgi is a core required component Pros: OSGi subsystem module is simpler, no additional subsystems or modules needed Cons: AS7 must always have OSGi binaries no matter the configuration 2. Change the osgi subsystem to use optional dependencies on all of the subsystems it maps. Pros: No additional subsystems are needed AS7 no longer requires OSGi binaries Cons: osgi subsystem code will need to do a lot of conditional checking for handling different subsystems being available 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming, osgi-transactions, etc) Pros: OSGi subsystem code is simpler AS7 no longer requires OSGi binaries Cons: More subsystems are introduced, almost one per functional subsystem.

On 11/29/10 12:15 PM, David M. Lloyd wrote: > On 11/29/2010 12:07 PM, Jason T. Greene wrote: >> This was talked about briefly on the pull request list, but no >> resolution was made. >> >> The issue is that JBAS-8585 and JBAS-8599 both add module dependencies >> from some of the core subsystems on to the osgi subsystem (naming and >> transactions). In addition we already have a module dependency from >> domain to osgi. So for all intents and purposes, we are moving towards >> AS7 having osgi as a required base level component. Before progressing >> much further in this direction we should evaluate whether this is the >> right thing to do, and how this solution compares to alternative >> approaches. I can think of three approaches right off the bat. >> >> 1. Continue as is, osgi is a core required component >> Pros: OSGi subsystem module is simpler, no additional subsystems or >> modules needed >> Cons: AS7 must always have OSGi binaries no matter the configuration >> >> 2. Change the osgi subsystem to use optional dependencies on all of the >> subsystems it maps. >> Pros: No additional subsystems are needed >> AS7 no longer requires OSGi binaries >> Cons: osgi subsystem code will need to do a lot of conditional >> checking for handling different subsystems being available >> >> 3. Create an osgi subsystem per subsystem it wraps (e.g. osgi-naming, >> osgi-transactions, etc) >> Pros: OSGi subsystem code is simpler >> AS7 no longer requires OSGi binaries >> Cons: More subsystems are introduced, almost one per functional >> subsystem. > > Either #2 or #3. #1 is a non-option in my opinion. Once we open this > door we're going to lose any rational boundaries between our subsystems > and end up with a mess. > Agreed. > We've used #2 to decent effect already in the Txn subsystem. An > additional advantage to this approach is that you don't need the > configuration overhead - you just enable OSGi, and if you have Txn > enabled, you get OSGi+Txn as well. This is in line with user > expectations in my opinion. > I don't think #3 works unless the end user configuration can be made trivial. A bunch of boilerplate like this won't work: <subsystem xmlns="urn:jboss:domain:osgi-naming:1.0"> <subsystem xmlns="urn:jboss:domain:osgi-transactions:1.0"> A 4th option is a hybrid of #2/#3; i.e. a single osgi-ee subsystem. That has the cons of #2, but lessens the cons of #3 to single new subsystem. That only makes sense though if there is some reason putting the #2 logic in the existing osgi subsystem is a big problem.