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

[Carlo de Wolf]

On 12/01/2010 11:10 AM, Thomas Diesler wrote:
> 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.
Not in the OSGi main subsystem, but I could argue a similar point for 
having OSGi-X, OSGi-Y and OSGi-Z.
The distinction is however close to moot. Maybe it's a matter of who has 
the main responsibility for providing OSGi enabled services. Which I 
would consider to be OSGi and not the individual subsystems.

But again this is a nitpicking detail.

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