None of our modules are directly dependent upon each other, so ordering isn't something we've needed to solve. They do all share the same persistence unit however, using the Spring JPA support. We were already using Spring for the SimpleJdbcOperations stuff (easiest way I've found by far to do JDBC), to mix/match JPA/JDBC and for Transaction management, so was a quick win really. I can try and post some code somewhere if you're interested.
One extra benefit I didn't anticipate of this, it allows us to define what the entity classes are in java, so no more forgetting to update the class name in persistence.xml when you rename a class, as eclipse will include it in the refactoring. On May 8, 2:05 pm, Eduardo Nunes <[email protected]> wrote: > Uhmm, It's a nice solution. I have just one problem. My modules can > define some filters/servlets (I'm using guice-servlet extension) and I > have to define some order to load these services. Do you have an idea > how to do it? Do your modules share the same persistence unit? Or they > have their own domain control? Currently I'm using the > modules.properties definition order to define the load order of my > services but it isn't the best solution. > > > > On Fri, May 8, 2009 at 6: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 > > -- > 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 -~----------~----~----~----~------~----~------~--~---
