Home » Eclipse Projects » Equinox » OSGI Service vs Plugin extension point
|
| Re: OSGI Service vs Plugin extension point [message #111675 is a reply to message #111377] |
Tue, 10 June 2008 13:23   |
 Kees Pieters
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
Hi Roland,
I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).
Maybe this may help you in your quest!
Kees
|
|
|
| Re: OSGI Service vs Plugin extension point [message #111704 is a reply to message #111675] |
Tue, 10 June 2008 15:07 |
Danail Nachev
Messages: 110
Registered: July 2009 |
Senior Member |
|
|
If you are using services, you need to make sure that the bundle which
is supposed to register the service is in ACTIVE state. You can use the
osgi.bundles property to specify which bundles are to be active after
startup.
You may want to check out the Declarative Services specification, part
of the OSGi spec. They provide similar mechanism to extension points -
they register/fetch references to services via declarative approach.
BR,
Danail
Kees Pieters wrote:
> Hi Roland,
>
> I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
> From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
> Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
> Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
> The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
> The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).
>
> Maybe this may help you in your quest!
>
> Kees
|
|
|
| Re: OSGI Service vs Plugin extension point [message #111798 is a reply to message #111704] |
Thu, 12 June 2008 09:55 |
Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Hi Danail and Kees,
Thanks for you answers.
Danail - does using declarative services somehow mean that my declared
services will be automagically activated (along with the bundles they're
declared/implemented in)?
Or do I still have to "activate" the bundles with osgi.bundles property
in order for them to be started?
If it is the latter, then the only benefit I can see from using declared
vs. coded services is that starting/stopping declared services is
handled by the framework and I do not have to write explicit bundle
activator code to manage all that.
Danail Nachev kirjutas mulle midagi seesugust:
> If you are using services, you need to make sure that the bundle which
> is supposed to register the service is in ACTIVE state. You can use the
> osgi.bundles property to specify which bundles are to be active after
> startup.
>
> You may want to check out the Declarative Services specification, part
> of the OSGi spec. They provide similar mechanism to extension points -
> they register/fetch references to services via declarative approach.
>
> BR,
> Danail
>
> Kees Pieters wrote:
>> Hi Roland,
>>
>> I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
>> From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
>> Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
>> Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
>> The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
>> The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).
>>
>> Maybe this may help you in your quest!
>>
>> Kees
--
Roland Tepp
|
|
|
| Re: OSGI Service vs Plugin extension point [message #111804 is a reply to message #111798] |
Thu, 12 June 2008 11:12 |
Danail Nachev
Messages: 110
Registered: July 2009 |
Senior Member |
|
|
Roland,
You'll need to make sure the bundles are activated, but:
1) you don't need explicit registration code
2) your components/services are lazy initialized - which is one of the
big advantages of extension registry over service registry and it is
mitigated by this
3) the complexity of dealing with service registry dynamics are either
hidden in the DS implementation itself (static references) or they are
greatly simplified (dynamic references).
BR,
Danail
Roland Tepp wrote:
> Hi Danail and Kees,
>
> Thanks for you answers.
>
> Danail - does using declarative services somehow mean that my declared
> services will be automagically activated (along with the bundles they're
> declared/implemented in)?
>
> Or do I still have to "activate" the bundles with osgi.bundles property
> in order for them to be started?
>
> If it is the latter, then the only benefit I can see from using declared
> vs. coded services is that starting/stopping declared services is
> handled by the framework and I do not have to write explicit bundle
> activator code to manage all that.
>
> Danail Nachev kirjutas mulle midagi seesugust:
>> If you are using services, you need to make sure that the bundle which
>> is supposed to register the service is in ACTIVE state. You can use the
>> osgi.bundles property to specify which bundles are to be active after
>> startup.
>>
>> You may want to check out the Declarative Services specification, part
>> of the OSGi spec. They provide similar mechanism to extension points -
>> they register/fetch references to services via declarative approach.
>>
>> BR,
>> Danail
>>
>> Kees Pieters wrote:
>>> Hi Roland,
>>>
>>> I have been facing the same problems, and my own estimation is that
>>> OSGI services are still quite young and need to mature a bit more.
>>> From my own experiences (which are probably not going to be best
>>> practices), I have come to rely on the default activations of
>>> plugins, so if something goes wrong there, then I treat it as a big
>>> failure.
>>> Secondly the activation sequence of plugins can help you to ensure
>>> that certain plugins are started before others. This is also quite
>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>> guess-, is that I have made some service helpers that run in a
>>> separate thread, that wait for services to be registered. This way I
>>> can include time-outs when services fail to register and I can
>>> gracefully terminate equinox, or conversely decide that it is ok to
>>> keep monitoring (which is seldom the case, by the way).
>>> The helpers implement Callable or Runnable interfaces, and basically
>>> do little more than wait until a service returns a non-null value.
>>> The way things will probably be going is that there will be
>>> extensions that represent OSGI services. This way you can check
>>> beforehand what services will be available (through the extension
>>> registry) and then make informed decisions on the actual starting of
>>> services. Currently you would have to implement this yourself (I
>>> believe).
>>>
>>> Maybe this may help you in your quest!
>>>
>>> Kees
>
|
|
|
| Re: OSGI Service vs Plugin extension point [message #112005 is a reply to message #111804] |
Fri, 13 June 2008 07:08 |
Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Okay,
But what about referencing these services from the runtime code?
I still need a handle on BundleContext to get my hands on the service
instance (or service tracker).
Which implies that I'll have to scatter explicit references to bundle
activators throughout my code - which I am not really a big fan of.
When moving classes or packages between bundles or splitting bundles,
there is scores of manual error prone work to do to re associate classes
with their new bundle activators (I've been through that and I must say,
I've developed somewhat of an allergy towards it)
Danail Nachev kirjutas mulle midagi seesugust:
> Roland,
>
> You'll need to make sure the bundles are activated, but:
>
> 1) you don't need explicit registration code
> 2) your components/services are lazy initialized - which is one of the
> big advantages of extension registry over service registry and it is
> mitigated by this
> 3) the complexity of dealing with service registry dynamics are either
> hidden in the DS implementation itself (static references) or they are
> greatly simplified (dynamic references).
>
> BR,
> Danail
>
> Roland Tepp wrote:
>> Hi Danail and Kees,
>>
>> Thanks for you answers.
>>
>> Danail - does using declarative services somehow mean that my declared
>> services will be automagically activated (along with the bundles they're
>> declared/implemented in)?
>>
>> Or do I still have to "activate" the bundles with osgi.bundles property
>> in order for them to be started?
>>
>> If it is the latter, then the only benefit I can see from using declared
>> vs. coded services is that starting/stopping declared services is
>> handled by the framework and I do not have to write explicit bundle
>> activator code to manage all that.
>>
>> Danail Nachev kirjutas mulle midagi seesugust:
>>> If you are using services, you need to make sure that the bundle which
>>> is supposed to register the service is in ACTIVE state. You can use the
>>> osgi.bundles property to specify which bundles are to be active after
>>> startup.
>>>
>>> You may want to check out the Declarative Services specification, part
>>> of the OSGi spec. They provide similar mechanism to extension points -
>>> they register/fetch references to services via declarative approach.
>>>
>>> BR,
>>> Danail
>>>
>>> Kees Pieters wrote:
>>>> Hi Roland,
>>>>
>>>> I have been facing the same problems, and my own estimation is that
>>>> OSGI services are still quite young and need to mature a bit more.
>>>> From my own experiences (which are probably not going to be best
>>>> practices), I have come to rely on the default activations of
>>>> plugins, so if something goes wrong there, then I treat it as a big
>>>> failure.
>>>> Secondly the activation sequence of plugins can help you to ensure
>>>> that certain plugins are started before others. This is also quite
>>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>>> guess-, is that I have made some service helpers that run in a
>>>> separate thread, that wait for services to be registered. This way I
>>>> can include time-outs when services fail to register and I can
>>>> gracefully terminate equinox, or conversely decide that it is ok to
>>>> keep monitoring (which is seldom the case, by the way).
>>>> The helpers implement Callable or Runnable interfaces, and basically
>>>> do little more than wait until a service returns a non-null value.
>>>> The way things will probably be going is that there will be
>>>> extensions that represent OSGI services. This way you can check
>>>> beforehand what services will be available (through the extension
>>>> registry) and then make informed decisions on the actual starting of
>>>> services. Currently you would have to implement this yourself (I
>>>> believe).
>>>>
>>>> Maybe this may help you in your quest!
>>>>
>>>> Kees
--
Roland Tepp
|
|
|
| Re: OSGI Service vs Plugin extension point [message #112098 is a reply to message #112005] |
Mon, 16 June 2008 07:43 |
Danail Nachev
Messages: 110
Registered: July 2009 |
Senior Member |
|
|
You are correct, you'll need to get hold of BundleContext and use it for
service instance retrieving. It is a question of good design to arrange
your code, so that there aren't references to BundleActivator all over
your code. Perhaps, the best thing is to use dependency injection
(dealing with services is done in BundleActivator and related classes).
The remaining classes don't care how they receive their dependencies.
Or
Use DS, which takes care of this for you.
BR,
Danail
Roland Tepp wrote:
> Okay,
>
> But what about referencing these services from the runtime code?
>
> I still need a handle on BundleContext to get my hands on the service
> instance (or service tracker).
>
> Which implies that I'll have to scatter explicit references to bundle
> activators throughout my code - which I am not really a big fan of.
>
> When moving classes or packages between bundles or splitting bundles,
> there is scores of manual error prone work to do to re associate classes
> with their new bundle activators (I've been through that and I must say,
> I've developed somewhat of an allergy towards it)
>
>
> Danail Nachev kirjutas mulle midagi seesugust:
>> Roland,
>>
>> You'll need to make sure the bundles are activated, but:
>>
>> 1) you don't need explicit registration code
>> 2) your components/services are lazy initialized - which is one of the
>> big advantages of extension registry over service registry and it is
>> mitigated by this
>> 3) the complexity of dealing with service registry dynamics are either
>> hidden in the DS implementation itself (static references) or they are
>> greatly simplified (dynamic references).
>>
>> BR,
>> Danail
>>
>> Roland Tepp wrote:
>>> Hi Danail and Kees,
>>>
>>> Thanks for you answers.
>>>
>>> Danail - does using declarative services somehow mean that my declared
>>> services will be automagically activated (along with the bundles they're
>>> declared/implemented in)?
>>>
>>> Or do I still have to "activate" the bundles with osgi.bundles property
>>> in order for them to be started?
>>>
>>> If it is the latter, then the only benefit I can see from using declared
>>> vs. coded services is that starting/stopping declared services is
>>> handled by the framework and I do not have to write explicit bundle
>>> activator code to manage all that.
>>>
>>> Danail Nachev kirjutas mulle midagi seesugust:
>>>> If you are using services, you need to make sure that the bundle which
>>>> is supposed to register the service is in ACTIVE state. You can use the
>>>> osgi.bundles property to specify which bundles are to be active after
>>>> startup.
>>>>
>>>> You may want to check out the Declarative Services specification, part
>>>> of the OSGi spec. They provide similar mechanism to extension points -
>>>> they register/fetch references to services via declarative approach.
>>>>
>>>> BR,
>>>> Danail
>>>>
>>>> Kees Pieters wrote:
>>>>> Hi Roland,
>>>>>
>>>>> I have been facing the same problems, and my own estimation is that
>>>>> OSGI services are still quite young and need to mature a bit more.
>>>>> From my own experiences (which are probably not going to be best
>>>>> practices), I have come to rely on the default activations of
>>>>> plugins, so if something goes wrong there, then I treat it as a big
>>>>> failure.
>>>>> Secondly the activation sequence of plugins can help you to ensure
>>>>> that certain plugins are started before others. This is also quite
>>>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>>>> guess-, is that I have made some service helpers that run in a
>>>>> separate thread, that wait for services to be registered. This way I
>>>>> can include time-outs when services fail to register and I can
>>>>> gracefully terminate equinox, or conversely decide that it is ok to
>>>>> keep monitoring (which is seldom the case, by the way).
>>>>> The helpers implement Callable or Runnable interfaces, and basically
>>>>> do little more than wait until a service returns a non-null value.
>>>>> The way things will probably be going is that there will be
>>>>> extensions that represent OSGI services. This way you can check
>>>>> beforehand what services will be available (through the extension
>>>>> registry) and then make informed decisions on the actual starting of
>>>>> services. Currently you would have to implement this yourself (I
>>>>> believe).
>>>>>
>>>>> Maybe this may help you in your quest!
>>>>>
>>>>> Kees
>
|
|
|
Goto Forum:
Current Time: Tue Apr 16 05:44:30 GMT 2024
Powered by FUDForum. Page generated in 0.60146 seconds |
] 
Search
Help
Register
Login
Home
