[jboss-as7-dev] MSC service names in AS7

[David M. Lloyd]

On 06/01/2011 04:05 PM, David Bosschaert wrote:
> ... replies inline ...
>
> ----- Original Message -----
>> From: "David M. Lloyd"<david.lloyd at redhat.com>
>> To: jboss-as7-dev at lists.jboss.org
>> Sent: Wednesday, 1 June, 2011 9:51:04 PM
>> Subject: Re: [jboss-as7-dev] MSC service names in AS7
>> On 06/01/2011 03:08 PM, David Bosschaert wrote:
>>>
>>> One further question. Let's say my service performs some async
>>> action in start() and when that action is finished I'm not really
>>> interested in the service any more. Should I remove it somehow from
>>> the system then?
>>
>> In other words, a one-time task which is triggered when all its
>> dependencies start? We don't have a generalized API for this. There
>> are subtle conceptual issues.
>
> Yes, correct.
>
>> First, using a service will cause its dependencies to automatically
>> start if they are, say, ON_DEMAND. However if your service then
>> immediately stops or is removed, the dependency services will stop
>> again, which is not a useful semantic.
>>
>> You can use listeners instead, however a listener can only presently
>> be
>> added to an installed service (i.e. you can't install a listener on a
>> name in anticipation of a future service).
>>
>> So the real question is, what problem are you trying to solve here?
>
> Ok, so let's look at an example. In the AutoInstallIntegration service in the OSGi subsystem it first installs the bundles asynchronously and then, on line 140 it creates an anonymous service that runs once the install of all bundles is finished to start them.
>
> Is this correct service usage?

It depends on the required semantics.  If all bundles in the entire 
system have to be installed first and then started, then you should have 
a "barrier" service which depends on the install phase service for all 
bundles system-wide, and upon which the start phase service for all 
bundles depends.  When new bundles are added you'd then have to remove 
and replace this barrier service, causing all bundles to be stopped and 
re-started again.

This is obviously a pretty clunky solution.

Another solution is to simply directly control the service via a mode 
setting.  This is also clunky, but in a different way - a user messing 
with service modes via a console for example can screw up the 
installation process of OSGi bundles (contrast with other deployment 
types which can use dependencies for everything).

Ideally there'd be a way to frame this lock-step semantic in terms of a 
fixed dependency specification.  In other words, don't think in terms of 
what is required for a bundle to be started (as a transitional action), 
but rather what is required for a bundle to be in the "started" state. 
In other, other words, think about the criteria which must be true in 
order for a bundle to not stop automatically.

>>> Additionally, let's say I have a service that can run more than
>>> once, should I give it a different name every time?
>>
>> Services can be stopped and started repeatedly, and in fact it is part
>> of the contract of a service that it must be able to do so.
>
> Hmmm, it looks like the services in [1] don't adhere to this contract, as the stop is a no-op...

This will cause a problem if the service is re-started for some reason 
(i.e. a [possibly distantly transitive] dependency is removed causing 
all dependents to stop and then the problem is resolved causing 
dependents to re-start).

-- 
- DML