[jboss-as7-dev] OSGi subsystem dependencies

Brian Stansberry brian.stansberry at redhat.com
Mon Nov 29 13:33:46 EST 2010


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.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat



More information about the jboss-as7-dev mailing list