Guice and OSGi without peaberry

[Jolse Maginnis]

Hi all,

I work on a web application which is built up of a series of Java
Plugin Framework ( http://jpf.sourceforge.net/ ) plugins which are
analogous to OSGi bundles. To look after all our DI and cross cutting
concerns we integrated Spring with JPF, which allowed each plugin to
create it's own Spring Context and made a special BeanFactory which
could find beans in all dependent plugins. I guess you could say it's
like Spring-DM but for JPF.

The beauty of this system is that we can publish a service that can be
autowired into any dependent plugin simply by adding an annotation on
the class (combined with classpath scanning). So the client plugin
simply has to add the @Autowired annotation and voila, the service is
wired in, no configuration xml/java necessary at all.

But.. Starting Spring contexts is slowww, which was ok when we only
had about 30 plugins, but now we have over 220 and startup times are
beginning to annoy. Spring is overkill for what we use it for, guice
looks as though it would be a great fit for what we do and looks much
leaner/faster.

So the question is, what would the best way to get a system like this
up and running using guice? Having each plugin create it's own
injector seems the logical way, but what is the best way to share
services with dependent plugins (as in the actual instances of the
service, not just the configuration). Would we need to create a custom
scope which stored instances per JVM rather than per Injector?

Bearing in mind that the services aren't really dynamic, as once
they've been loaded, they stay loaded, so peaberry seems like it would
add a lot of unnecessary overhead with dynamic lookup proxies etc.

Any guidance would be helpful.

Regards,
Jolse

[Brian Pontarelli]

Could you use cross-injector providers? The Provider would have an instance to its plugin's Injector and then be bound into dependent plugin's injectors. This could require some lazy loading of injectors and maybe some proxies depending on how your dependencies map and if you have circular or other oddities in your graph.

-bp

> --
> You received this message because you are subscribed to the Google Groups "google-guice" group.
> To post to this group, send email to google...@googlegroups.com.
> To unsubscribe from this group, send email to google-guice...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
>

[Stuart McCulloch]

On 19 April 2011 15:42, Brian Pontarelli <br...@pontarelli.com> wrote:

Could you use cross-injector providers? The Provider would have an instance to its plugin's Injector and then  be bound into dependent plugin's injectors. This could require some lazy loading of injectors and maybe some proxies depending on how your dependencies map and if you have circular or other oddities in your graph.

+1, that's basically the approach I use in Sisu [https://github.com/sonatype/sisu]

Each plugin has its own Injector populated with bindings by doing local classpath scanning. Scanned bindings are analyzed using the Guice SPI, and any missing (ie. non-local) dependencies are satisfied by binding the appropriate key to a Provider that delegates to a dynamic Locator. This Locator knows about the available plugins and their bindings, again using the SPI, and can dynamically match requests to components.

You have to be careful about introducing too much magic, but that's where the SPI can help by making it easier to analyze :)

-- 
Cheers, Stuart

[Jolse Maginnis]

On Wed, Apr 20, 2011 at 9:18 AM, Stuart McCulloch <mcc...@gmail.com> wrote:

On 19 April 2011 15:42, Brian Pontarelli <br...@pontarelli.com> wrote:

Could you use cross-injector providers? The Provider would have an instance to its plugin's Injector and then  be bound into dependent plugin's injectors. This could require some lazy loading of injectors and maybe some proxies depending on how your dependencies map and if you have circular or other oddities in your graph.

+1, that's basically the approach I use in Sisu [https://github.com/sonatype/sisu]

Each plugin has its own Injector populated with bindings by doing local classpath scanning. Scanned bindings are analyzed using the Guice SPI, and any missing (ie. non-local) dependencies are satisfied by binding the appropriate key to a Provider that delegates to a dynamic Locator. This Locator knows about the available plugins and their bindings, again using the SPI, and can dynamically match requests to components.

You have to be careful about introducing too much magic, but that's where the SPI can help by making it easier to analyze :)

Thanks Brian & Stuart for the suggestions, using a cross-plugin-injector provider does sound like the way to go and the same style of provider for accessing existing spring based plugins would also allow us to incrementally move from spring to guice.

Regards,
Jolse