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

[Thomas Diesler]

All your comments make most sense when you see Tx and JNDI as core 
services and OSGi providing an additional view on those services. From 
the user experience this is in fact the case now. Tx and JNDI start at 
boot time and their respective OSGi services are not available. Only 
when the OSGi subsystem starts the Tx and JNDI services also become 
available in the OSGi registry.

I still maintain that the OSGi subsystem provides the core 
infrastructure and should not have an every changing set of dependencies 
on X, Y, Z. Instead X, Y, Z can create lazy services that depend on the 
the system BundleContext when it becomes available. The code should 
nevertheless live with X, Y, Z and perhaps if you really care it could 
live in X-OSGi, Y-OSGi, Z-OSGi, but not in the OSGi subsystem.

Sorry, I don't quite follow your config example. I'd say

<subsystem xmlns="foo"/>

enables plain service foo. If you also have

<subsystem xmlns="osgi"/>

then foo might show up in the OSGi registry if subsystem foo chooses to 
do so. The OSGi subsystem would not know about foo.

-thomas


On 11/30/2010 08:37 PM, David M. Lloyd wrote:
> 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 :)
>>>
>

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