[jboss-as7-dev] Fwd: Re: OSGi subsystem dependencies

[David M. Lloyd]

Comments inline.

On 11/30/2010 09:42 AM, Thomas Diesler wrote:
> IMHO it boils down to what you choose as the promoted service
> integration layer.

Actually this has nothing to do with it at all.  It's all about the user 
experience from the configuration standpoint.

If I have the OSGi subsystem enabled, and I have the Txn subsystem 
enabled, it's completely reasonable to expect that OSGi transactions 
would be available.  However this is an aspect of the OSGi subsystem, 
not the Txn subsystem.  There is certainly no rule which says "one 
subsystem equals one OSGi service" at all.  A subsystem is a 
configuration entity only.

> With respect to the (standard OSGi) Tx and JNDI services I said
>
>       "The OSGi subsystem provides the OSGi service registry. Subsystem
>       Foo may choose to publish a service in that registry which would
>       then readily be available for installed bundles to use. The OSGi
>       subsystem does not need to know about Foo."

There's nothing which says a subsystem cannot provide more than one 
capability to the user - this is a completely artificial constraint that 
you've put upon yourself.

> http://community.jboss.org/thread/158822
>
> So if the OSGi service registry is the standard view of the MSC service
> registry, It should readily be available whenever you want to publish a
> service in a standard way.
>
>    From my perspective #2 would be a bad choice for the same reason that
> you want to keep the MSC service registry generic (i.e. it does not know
> about any specific service)

#2 doesn't mean that the OSGi service registry has any special knowledge 
of the service - it just means that in addition to setting up the OSGi 
service registry, the subsystem (not the registry itself) also populates 
it with known services.

> The current implementation uses #1 because I believe the OSGi service
> registry should indeed be available to all subsystems that wish to
> publish services that can be used by user deployments. As an alternative
> I'd think #3 is reasonable. Every subsystem provides an OSGi bundle that
> makes the respective subsystem services available in the OSGi service
> registry.

#3 means that instead of saying:

     <subsystem xmlns="blah osgi">
         <!-- generic stuff here -->
     </subsystem>

and having txn and naming automatically turn on, you'd have to say:

     <subsystem xmlns="blah osgi">
         <!-- generic stuff here -->
     </subsystem>
     <subsystem xmlns="blah osgi txn"/>
     <subsystem xmlns="blah osgi naming"/>

In other words, no reasonable defaults, and the user has to add a whole 
mess of subsystems for basic things to work.  I think #2 is best in this 
regard - it's easier to set up, easier to read and understand, and 
easier to configure after the fact for the user, who would never think 
that they'd have to configure additional subsystems in order to enable 
services in OSGi that they've already turned on and have working in a 
non-OSGi sense.

> For simplicity reasons, I thought the abstraction in separate Service
> classes is "good enough" and we won't need an additional mvn module.

Yeah of course each thing could be its own service - there is absolutely 
no requirement that a subsystem be constrained to a single service.

> In reality, the folks that maintain MSC service Foo would also provide  the OSGi Foo service. Hence, one mvn module.

Maybe in some cases.  In other cases (core services for example) this is 
not the case - OSGi is an additional aspect which the core service 
maintainer may not want to have to worry about.

> cheers
> -thomas
>
>
>
>
> On 11/29/2010 07: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.
>>
>> Let the debate begin :)
>>
>


-- 
- DML