[jboss-as7-dev] OSGi subsystem dependencies

[David M. Lloyd]

On 11/29/2010 12:33 PM, Brian Stansberry wrote:
> 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.

Agreed.

-- 
- DML