Ok, I'm convinced on using the Multibinder (and therefore not hotplugging the extensions). I don't want an eager singleton, and really prefer a Plugin interface that I can control.
About the ServiceProvider. Is it the annotation that "will" exist in Java 7, with the base existing as java.util.ServiceLoader in Java 6? This system is basicly what I want to have (and was about to implement), but I didn't know about it until I researched after your reply. (So, many thanks!) On 8 mai, 11:47, Dan Godfrey <[email protected]> wrote: > You'd still need to use the Multibinder to register more than one > implementation of the same interface though or jump throw some hoops > using eager singletons (see below). > > We're doing something similar, but using the Service Provider > interface rather than a properties file. This allows us to just drop a > jar onto the classpath and any "plugins" defined in that jar are > automatically added to the system at start-up. It means that the > "core" system doesn't need any dependencies upon the plugins either. > > * As we're not using Guice 2 yet, we actually bind the plugins as > eager singletons using a different annotation for each, and have an > @inject method on the plugin that it uses to register itself with a > plugin registry. > > On May 7, 6:57 pm, Eduardo Nunes <[email protected]> wrote: > > > I'm using a different approach. I created a main module that reads a > > modules.properties file with full path to each module that should be > > installed. Each module implements an interface that provides a method > > to create the guice module, something like this: > > > interface Module { > > > google.Module createGuiceModule(); > > > /* some other domain relevant methods */ > > > } > > > In the configure method of the MainModule, I call install method for > > each module that should be installed. > > > It looks a little bit complex because my Module interface has more > > things. I'm using warp-persist, so my Module interface has two other > > methods related to it: > > - Class<Serializable> getEntities(); > > - Class<Object> getAccessors(); > > > My framework will be opensource soon, the source code is not stable yet. > > > Well, I hope that I helped you a little bit, > > > 2009/5/7 Olivier Grégoire <[email protected]>: > > > > Yes, you seem to be right. I'll have to think (and test) a bit more > > > MultiBinding, especially in the case I would like the extension to be > > > hotplugged and unplugged. > > > > Thank you anyway! > > > > Olivier > > > > Daniel a écrit : > > >> Use the MultiBinding functionality. > > > >>http://publicobject.com/2008/05/guice-multibindings-extension-checked... > > > >> On May 6, 4:21 pm, Olivier Grégoire <[email protected]> wrote: > > >>> Dears, > > > >>> Behind my title, I have to admit that I obviously know about the > > >>> Injector.createChildInjector(Module...) method. However I was wondering > > >>> essentially about modules that interact between them: > > > >>> I hope my explanation will be clear enough: > > > >>> Main module: > > >>> + interface Plugin (no implementation) > > >>> + Plugin manager > > >>> + injector mainInjector created through Guice.createInjector() > > > >>> Extension 1 module: > > >>> + defines an implementation of Plugin > > >>> + injector ext1Injector created through > > >>> mainInjector.createChildInjector() > > > >>> Extension 2 module (does not require any components of Extension 1): > > >>> + defines an implementation of Plugin > > >>> + injector ext2Injector created through > > >>> mainInjector.createChildInjector() > > > >>> Extension 3 module (requires components of Extension 1) > > >>> + defines an implementation of Plugin (aouch : it already exists) > > >>> + injector ext3Injector created through > > >>> ext1Injector.createChildInjector() > > > >>> The problem of extension 3 is that, since I create an injector with the > > >>> extension 1 injector, I cannot provide a new implementation for my > > >>> Plugin > > >>> interface. > > > >>> The file in attachment shows a basic implementation of the error I > > >>> receive. > > > >>> The problem can easily be worked around by creating another entry point > > >>> in > > >>> Extension 1 accessible to extension 3, but I don't find it efficient at > > >>> all > > >>> since the plugin-manager is handled at the main module level, and the > > >>> main > > >>> module shouldn't know the various entry points of extension 1. > > > >>> I've immediately thought about Modules.override() but it only overrides > > >>> Modules with Modules, not Injectors with Modules. > > > >>> I can clearly see a problem here. However I don't know how to solve it > > >>> with > > >>> the current implementation of Guice. I also don't know how to handle a > > >>> single module that needs two modules as prerequisites. > > > >>> So, does anyone know how I can manage extensions that need components > > >>> found > > >>> in other extensions with Guice? > > > >>> This is my first modular application, so if all this is based upon > > >>> misunderstood basics about modular applications, please let me know why. > > > >>> Thank you and best regards, > > > >>> Olivier > > > >>> ModularityTest.java > > >>> 2KViewDownload > > > -- > > Eduardo S. Nuneshttp://e-nunes.com.br --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
