Google Guice IoC framework

[Matthias Lübken]

Hi
first of all: impressive project! It will really help getting started
with an OSGi project. Congratulations to Prosyst!

For me right now using pure dynamic OSGi services is a big hazzle. So
I would look into Spring DM, Declarative Services and Service-Binder.

I am wandering why did you chose Guice IoC?
Does Guice IoC help handling OSGi services like Spring DM?
And could I replace Guice with one of these service helper
technologies?

Matthias

[Roman Roelofsen]

On 18 Sep., 16:28, Matthias Lübken <matthias.lueb...@gmail.com> wrote:
> Hi
> first of all: impressive project! It will really help getting started
> with an OSGi project. Congratulations to Prosyst!

Thank you!

> For me right now using pure dynamic OSGi services is a big hazzle. So
> I would look into Spring DM, Declarative Services and Service-Binder.

Yes, dealing with the dynamics of OSGi make things more complex and
it's easy to do something wrong. So I always recommend to use a
framework that helps with using OSGi services correctly. However,
there are several such frameworks out there: SpringDM, DS,
ServiceBinder, iPOJO, Guice Peaberry, etc and, of course, they are all
different from each other. Some are more static, others are more
dynamic, some use XML, others a more "fluent API" in Java and it
depends on your needs and programming style.

> I am wandering why did you chose Guice IoC?

SpringDM is an obvious choice since the Spring Framework is one of the
most used frameworks in the enterprise Java world currently. However,
a lot of Spring's features are not that important in the OSGi world
and I see SpringDM more as an extension to Spring so that you can use
Spring in OSGi. But if you start with a more "pure" OSGi architecture,
you can evaluate the DI frameworks in detail and you are free to
choose the best one for you. For example, ModuleFusion promotes the
use of OSGi's ManagedServices instead of a proprietary features like
property placeholders offered by one specific framework. So the only
important missing piece is the dependency injection + service registry
interaction. By default, ModuleFusion ships with the Google Guice
framework, which is refreshingly different and the best medicine if
you have a litte XML sickness ;-)

> Does Guice IoC help handling OSGi services like Spring DM?

ModuleFusion contains the Peaberry project, which extends Guice with
features for the easy use of OSGi services.

If you think that Guice+Peaberry does not solve your problem, I
recommend to take a look at iPOJO (successor of service binder and
DS). It is far superior to any DI framework I have seen so far and
does a lot more when it comes to dealing with the dynamics of OSGi.
iPOJO is on the roadmap for inclusion in future releases.

> And could I replace Guice with one of these service helper
> technologies?

Of course! You are free to use any framework you would like. One of
the advantages of OSGi is that by using the bundle concept, this is
easily possible! Furthermore, ModuleFusion promotes the OSGi model and
one aspect of this is the use of the OSGi service registry. So as long
as your favorite framework registers your "public" services in the
registry, you can use this service from any bundle, regardless of the
frameworks the other bundles might use.

Cheers,

Roman

[Roman Roelofsen]

> > And could I replace Guice with one of these service helper
> > technologies?
>
> Of course! You are free to use any framework you would like. One of
> the advantages of OSGi is that by using the bundle concept, this is
> easily possible! Furthermore, ModuleFusion promotes the OSGi model and
> one aspect of this is the use of the OSGi service registry. So as long
> as your favorite framework registers your "public" services in the
> registry, you can use this service from any bundle, regardless of the
> frameworks the other bundles might use.

Simply copy your framework's bundle files to the load directory of
ModuleFusion and they will be available in the OSGi container.