Very nicely said. In the real world shit happens and you need to deal with it.
The worst applications are the ones that pretend shit does not happen, they are
the most fragile. Since shit can always happen (like a power failure) any
application that relies on no-shit happening is bound to fail one day. So you
need to recover from NPE in any complex application, power outages, network
failures, etc. Get over it, and handle them.
As Chris said, it is part of modularity that you're calling an unknown party.
The authors could throw an NPE as well, a ServiceException is just one of this
unpreventable things.
That said. The OSGi dynamics are 'slow' dynamics. They are not intended to be
used in the mainline of the application and cycle hundreds of times per second.
I've been programming with this model a long time and never had the urge to do
something special to prevent this small window. You might see some wrong data
on the GUI for a fraction of a second but good code will handle the subsequent
shutdown event and grey out or remove the culprit.
Trust me, this is the LEAST of your worries in today's software :-)
Kind regards,
Peter Kriens
> On 19 mrt. 2015, at 15:05, chris.g...@kiffer.be wrote:
>
> Hi Andreas,
>
>> So I think with some unlucky timing there allways remains a small risk of
>> failure when calling a service due to service dynamic.
>
> Yes.
>
>> My question is, if it is possible to avoid this small risk?
>
> No. Or to put it another way: when you invoke a service you are always (in
> principle) invoking "unknown" code which may not behave the way you
> expect, so you should program defensively. Be prepared for the service to
> fail, and take the time to think what you should do if it does - propagate
> the failure? or try to carry on?
>
> To me this is a part of modularity, independent of dynamics - within your
> service you should not need to perform many checks, but you should check
> the parameters with which you are invoked and if you call another service
> you should treat it as fallible.
>
> Chris
>
>
>> -----Ursprüngliche Nachricht-----
>> Von:David Bosschaert <david.bosscha...@gmail.com>
>> Gesendet:Mi 18.03.2015 21:45
>> Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic
>> An:OSGi Developer Mail List <osgi-dev@mail.osgi.org>;
>> Hi Andreas,
>>
>> If I understand your email correctly the following is your concern:
>>
>>> So it may occur, that a call by the DomainsService on a property of an
>>> entity happens when the DAO-Service is not available anymore.
>>> ...
>>> What options do I have to safely load the entities?
>>
>> AFAICS you really have two options:
>> 1. If the service is gone, the call will fail. Maybe you can
>> gracefully deal with the failure.
>> 2. If the dependent service is gone then make sure the depending code
>> does not run. This is really the approach taken by DS. If you declare
>> a mandatory dependency on your DAO service for the DomainService code
>> then if the DAO service disappears the DomainService will also not
>> exist. In DS mandatory dependencies are the default model.
>>
>> Option 2. above is clearly the most elegant scenario. Does this cover
>> your concern or is there something that I missed?
>>
>> Best regards,
>>
>> David
>>
>>
>> On 14 March 2015 at 16:41, Andreas Klotz <andreas.kl...@n-design.de>
>> wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I have an use case where I want the dynamic of a service to be bound to
>>> another higher level service. Maybe I need Subsystems...?
>>>
>>>
>>>
>>> I think it is a good design of an OSGi-service if it just provides data
>>> in
>>> contrast to provide objects on which an operation can be performed that
>>> is
>>> using resources of the underlying bundle. Although the second variant
>>> would
>>> be possible, I think that handling service/bundle dynamic becomes very
>>> complex or even unmanageable.
>>>
>>>
>>>
>>> However there is a use case where I can't deliver just data by a
>>> service. I
>>> think of lazy loading when dealing with persistence.
>>>
>>> I usually define interfaces for the data access layer. So I get a
>>> Bundle-Setting like this:
>>>
>>>
>>>
>>> - Entity-Bundle (contains Entities)
>>>
>>> - DataAccessAPI-Bundle (contains DAO-Interfaces)
>>>
>>> - DataAccessImpl-Bundle (provides Services implementing DAO-Interfaces)
>>>
>>> - DomainService_A-Bundle (contains domain Logic for e.g. a GUI, uses
>>> DAO-Services; would be separated in API and impl of course)
>>>
>>> - DomainService_B-Bundle (contains more domain Logic, uses same
>>> DAO-Services
>>> as DomainsService_A)
>>>
>>>
>>>
>>> DomainServices A and B are clients of DAO-Services. A DAO-Service may
>>> provide an entity with some lazy loading properties. The transactions of
>>> the
>>> data accesses are defined by the DomainServices. So it may occur, that
>>> a
>>> call by the DomainsService on a property of an entity happens when the
>>> DAO-Service is not available anymore. That would lead to an
>>> unsuccessful
>>> attempt to load the property lazily (assuming that connections to the
>>> database are managed by the DAO-Bundle and not by a separate e.g.
>>> EntityManager-Service). So the DAO-Service delivered an object that
>>> tries to
>>> perform an operation on its delivering service.
>>>
>>>
>>>
>>> What options do I have to safely load the entities?
>>>
>>> - Do not use lazy Loading? I know cases where this would load the whole
>>> DB
>>> in to the RAM...
>>>
>>> - Make assumptions about certain properties a client might need and
>>> load
>>> them explicitly in the DAO-Layer? This will not work if I have
>>> different
>>> clients for one DAO-Service.
>>>
>>> - Is there a possibility to package DomainServices A and B as different
>>> Subsystems with the DAO-Service as a shared capability? Would this have
>>> the
>>> effect that the bundle providing the DAO-Service will only be stoppable,
>>> if
>>> both DomainServices are stopped?
>>>
>>>
>>>
>>> To be more general: In our OSGi-projects we use micro-services intensely
>>> to
>>> loosely couple not only domain logic (vertical) but also the
>>> architectural
>>> layers (horizontal). And I often feel that I only want dynamic for the
>>> vertical bundles/services.
>>>
>>>
>>>
>>> I am very interested in your opinion and how you deal with lazy loading
>>> or
>>> equivalent cases.
>>>
>>>
>>>
>>> Thanks and best regards,
>>>
>>> Â Â Â Â Â Â Â Â Andreas
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
