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

[David Bosschaert]

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 :)
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx