I'm doing the same. For each subsystem that lives in the same Injector framework, I define a trivial interface and then declare that each module in that subsystem implements that interface. The startup which creates the injector needs to know only about the subsystems it wants loaded, and uses the serviceprovider to find all the implementations of that (trivial) interface.
Ordering isn't something I've solved, nor is plugging in new services (or removing them). I have a vague sense that OSGI may be lurking in the future, but I'm using stuff I already understand to solve problems I have now, while keeping an open mind for the future. Leigh. On May 8, 2:47 am, 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 -~----------~----~----~----~------~----~------~--~---
