On 19 April 2011 15:42, Brian Pontarelli <[email protected]> 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 -bp > > On Apr 18, 2011, at 8:46 PM, Jolse Maginnis wrote: > > > 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 > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
