First, if you run into problems because certain mandatory services are not
running you've clearly not handled your dependencies explicitly ... Except for
situations where you need more than 1 of a specific service type, you can
always correctly create a dependency graph for each component. It sounds like
you have optional dependencies.
That said, I did have a similar problem last year with framework startup. I
decided I wanted a READY service that would be registered by the framework when
the framework was ready with the starting of all the bundles. This got
efficiently shut down in the CPEG though but during the discussion we came to
an interesting idea for DS.
The idea was to add a new filter to a DS component that controlled the enabled
status of the component. As long as that filter was not satisfied, the
component was disabled. Obviously, you could set this filter in the XML (or bnd
annotations [plug!]) or in Configuration Admin. I think this would address many
of your needs.
This idea is on my too long list of things to do for CPEG :-(
In the mean time, it is not very hard to create a component that provides the
READY service based on a configuration admin record (just add the filters in
the configuration record). The component waits until all the filters are
satisfied and then registers the READY. The filters could look for service
properties but you could also provide specific properties about the
environment: time of day, startlevel, bundles, etc.
Kind regards,
Peter Kriens
On 17 feb 2011, at 09:50, Eugen Reiswich wrote:
> Hi folks,
>
> The start up of an application is exactly where I get in trouble with OSGi.
> Although using DS, my application sometimes starts with say only 8 of 10
> available services due to misconfiguration. In this case I would rather throw
> a RuntimeException, NPE ore something comparable to point at the place where
> the misconfiguration happened. To be more precisely, what I need is a
> possibility to recognize that all 10 of 10 services are started. In this case
> I would like to print something out like "application started successfully,
> all 10 of 10 services are available". If less than 10 services are available
> throw an exception and give developers a hint that the application started
> inconsistently. But in OSGi there is no point in time where I can ensure that
> my application is in a consistent state and ensure that all services are
> started, right?
>
> Eugen
>
>
> Am 16.02.2011 um 18:53 schrieb Neil Bartlett:
>
>> Hi Eugen,
>>
>> This is a very interesting question, thanks for asking it!
>>
>> I appreciate that dynamics are not a big feature of enterprise
>> applications, but there is one time when ALL applications are dynamic,
>> and that is during startup (also, less importantly, during shutdown).
>> This is what I find most useful about OSGi Services: bundles can be
>> started in any order and they can find each other and wire themselves
>> up without requiring a fragile start ordering or a central "God"
>> component to do the wiring.
>>
>> If you are using Declarative Services (DS) you do not necessarily have
>> to handle dynamics and concurrency. The default policy for a service
>> reference is "static": this means that your component instance will be
>> destroyed and recreated if the target of the reference ever changes.
>> This hugely simplifies the programming model because you don't need to
>> worry about concurrency at all. It can be inefficient if things are
>> changing frequently but in an environment where dynamic
>> installation/uninstallation is rare then it can be the best policy.
>>
>> Spring DM/Blueprint has some similar features for "damping" dynamics;
>> I will let somebody else describe them because I am not an expert.
>>
>> With regard to ensuring all mandatory dependencies are satisfied, it's
>> very simple... just start ALL of your bundles! DS has a very helpful
>> feature called "delayed services" in which the implementation of the
>> service is not created until the service is actually needed by a
>> client. This means that it is essentially free to start a DS-based
>> bundle. You just have to be sure NOT to include a BundleActivator...
>> you don't need activators anyway if you are using DS.
>>
>> Regards,
>> Neil
>>
>> On Wed, Feb 16, 2011 at 5:34 PM, Eugen Reiswich
>> <[email protected]> wrote:
>>> Hi folks,
>>>
>>> we had today a conversation regarding OSGi with DS for business
>>> applications. The main point of the discussion was: how can I get rid of
>>> OSGi dynamics in applications where I do not need dynamics. For example: in
>>> an application for a savings bank I will NOT start to use hot plugging to
>>> add new bundles or remove existing bundles, start and stop services while
>>> customers are transferring money from one account to another. The point is
>>> that in OSGi applications I have to deal with dynamic behavior of services
>>> and bundles although I explicitly do not want to have this behavior.
>>> Declarative services in fact simplify the service orchestration and
>>> concurrency but they still have a dynamic character.
>>>
>>> Moving from a world currently dominated by Spring to an OSGi world the
>>> question arise: how can I ensure in an OSGi application that all
>>> required/mandatory services are satisfied at start up? In applications with
>>> more than a few services the OSGi console is not an appropriate way for
>>> this task.
>>>
>>> To give you an example: we are developing a server-side OSGi application
>>> which provides several domain related services: CustomerService,
>>> AccountService etc. When we start our server we do not know whether all
>>> service relations are satisfied and thus all mandatory services are
>>> started. Any ideas/best practices would be appreciated.
>>>
>>> Regards,
>>> Eugen
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> [email protected]
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
