7

Guice is a great framework to separate API from implementation and to start modularizing your applications. OSGi is a great framework to load versioned services in their own secured environment and to offer these via an exported API.

Assuming an application has been developed with Guice and that its size now justifies moving to OSGi to convert early modules into new fully-fledge services, what are the driving steps to perform this move?

I am looking for guiding principles, step-by-step to do list, war experience, tips, caveats, etc...

user7116
  • 63,008
  • 17
  • 141
  • 172
Jérôme Verstrynge
  • 57,710
  • 92
  • 283
  • 453

2 Answers2

3

OSGi already offers dependency injection for services when using Declarative Services (DS) (like Felix SCR). This is standard in OSGi, and for portability across different OSGi frameworks DS is the way to go. I think Peaberry is doing exactly what standard DS is doing, but in a Guice way.

If I were to port a Guice application to OSGi, I would keep Guice dependency injection inside each bundle, and use DS for the injection of services between bundles in order to keep the compatibility with all the OSGi frameworks.

RaduK
  • 1,463
  • 10
  • 16
1

You could take a look at Peaberry, which is intended for bridging the worlds of OSGi and Guice.

Angelo van der Sijpt
  • 3,611
  • 18
  • 24
  • Thanks. Do you have experience with it? Any tips to share? – Jérôme Verstrynge Apr 22 '11 at 19:35
  • Unfortunately, I did not. There is a projected in which we integrated a Guice-using application by 'isolating' it in its own bundle, but that still gives problems when updating that bundle. If I were to do it again, I would definitely give Peaberry a go. There must be someone on stackoverflow who has worked with it; you could try retagging your question. – Angelo van der Sijpt Apr 22 '11 at 19:52
  • I guess we all hoped that someone who has experience in this could answer the question. That didn't came true. But I'll give the bounty anyway. – Gamlor Apr 28 '11 at 19:15