Home/ Questions/Q 6125561
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T16:15:44+00:00

I am starting a project with OSGi and I am facing a very important

  • 0

I am starting a project with OSGi and I am facing a very important choice while defining the way I will handle service registration etc…

If I am not mistaken, I have three choices :

  • Use manual solution by implementing service listeners and handling my own registers (maybe not the worst choice actually)
  • Use the Declarative Service paradigm : Seems good but I have the feeling that it’s now a bit deprecated. Am I right ?
  • Use the Spring DM paradigm : It seems to be the latest paradigm but I am not sure it is well-standardized yet. Do I need a special OSGi implementation to run it (like Virgo/SpringDM Server ?) or can I use my classic OSGi platform as soon as it contains the plugins org.springframework.* ?

Do you have any comments or information about my interrogations ? Have you a preferred choice (and why ?) or do you use an other solution not included in my list ?

Thanks very much in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Declarative Services (DS) are not deprecated, they are in fact the cleanest way of handling service binding/unbinding in OSGi. You could do it manually, and this may be better depending on your use-cases, but generally DS are good. SpringDM uses Equinox underneath, but they have wrapped it for you to make certain things more Springy. I’ve never tried SpringDM so can’t comment much.

    If you are planning on using/integrating Spring in the future, start with SpringDM. Otherwise, start with DS. If you ever need to do something DS cannot handle, you can do it manually with service trackers. It is acceptable to mix DS and manual service handling.

    I think you have a fourth option called “Blueprint” which was proposed as an alternative to DS sometime in the last 2 years. I don’t know where they got to, but I think SpringDM might be using this internally.

    • 0