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

[Jason T. Greene]

I have added his jboss.com alias.

On 11/30/10 9:54 AM, David Bosschaert wrote:
> Forwarding an response from Thomas that doesn't seem to have made it to
> the mailing list...
>
> David
>
> -------- Original Message --------
> Subject: 	Re: [jboss-as7-dev] OSGi subsystem dependencies
> Date: 	Tue, 30 Nov 2010 09:42:56 +0100
> From: 	Thomas Diesler<thomas.diesler at jboss.com>
> To: 	Jason T. Greene<jason.greene at redhat.com>
> CC: 	jboss-as7-dev at lists.jboss.org<jboss-as7-dev at lists.jboss.org>
>
>
>
>    >  In addition we already have a module dependency from
>    >  domain to osgi.
>
> This is a bug.
> Fixed in
> https://github.com/jbosgi/jboss-as/commit/c68e62ec2662ecb6253c03eabc98ef753467701c
>
> ----
>
> IMHO it boils down to what you choose as the promoted service
> integration layer. As it is with most AS7 subsystems today they
> integrate via jboss-msc services. For system integration this is a
> direct and efficient approach. For user deployments however, the uptake
> of this is questionable. More likely we want to promote the integration
> via standard OSGi services. I take the benefit of using an open standard
> is generally accepted so I won't go into that much more.
>
> 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."
>
> 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)
>
> 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.
>
> For simplicity reasons, I thought the abstraction in separate Service
> classes is "good enough" and we won't need an additional mvn module. In
> reality, the folks that maintain MSC service Foo would also provide the
> OSGi Foo service. Hence, one mvn module.
>
> 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 :)
>>
>


-- 
Jason T. Greene
JBoss, a division of Red Hat