Sounds good.. but doesn't that pattern run the risk of duplicating
Module installations? For instance.. I depend on serviceA and
serviceB, who both depend on utilC... They'd both attempt to install
utilC's Module... From glancing at the code, it seems that would lead
to this:
if (this.builder != null) {
throw new IllegalStateException("Re-entry is not allowed.");
}
The pattern makes sense if duplicated Module installations are
ignored... just looks like they may not be.
Phill
On Oct 2, 9:05 am, "Sam Berlin" <[EMAIL PROTECTED]> wrote:
> We use a pattern of a single Main module that installs the modules in
> each top-level subpackage, each of those modules installing their
> further subpackages. So something like:
>
> org.mycompany.MainModule {
> install(new FooModule());
> install(new BarModule());
>
> }
>
> org.mycompany.foo.FooModule {
> install(new org.mycompany.foo.internal.FooInternalsModule());
> bind(Foo.class).to(FooImpl.class);
>
> }
>
> org.mycompany.bar.BarModule {
> install(new org.mycompany.bar.internal.BarInternalsModule());
> bind(Bar.class).to(BarImpl.class);
>
> }
>
> Sam
>
> On Thu, Oct 2, 2008 at 11:23 AM, famousactress <[EMAIL PROTECTED]> wrote:
>
> > That's a really good point....
>
> > So... it sounds like 1 Injector per entry-point into the system is a
> > pattern folks are using.. and that Injector needs to know about all of
> > the modules of it's dependant packages... So... Is there a recipe
> > folks are using for making that less cumbersome than it sounds? I was
> > thinking along the lines of some sort of discovery pattern, or perhaps
> > a maven plugin? Maybe even a new .jar standard that contains
> > references to a jar's Guice Module in META-INF?
>
> > You have to admit.. .gar is pretty rad sounding.
>
> > Anyways.. Let me know if anyone's got a clever way of dealing with
> > this... the way I see it.. I have a servlet module (take lower case
> > module to mean a collection of related classes, or a single java
> > package)... anyways, I have a module that might depend on three or
> > four other modules. It can bootstrap an Injector, and it's not all
> > that cumbersome I guess for it to pull in it's dependencies Modules...
> > but what about _their_ dependencies.
>
> > I suppose if you're doing SOA, this problem goes away pretty quickly
> > since you're more likely to have a fairly close Injector-to-Module
> > ratio... but I'm curious what other folks are doing.
>
> > Phill
>
> > On Oct 1, 10:48 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> >> On Oct 1, 3:35 pm, famousactress <[EMAIL PROTECTED]> wrote:
>
> >> > but I'm not sure what the best practice is for organizing modules
>
> >> The simplest strategy is to have one Module
> >> per Java package. This allows you to make
> >> your implementation classes package-private,
> >> decreasing their visibility.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
