how can i install the other modules after creating a injector

[king]

I created a injector like:

injector = Guice.createInjector(Stage.valueOf(stage), configModules);

then,i need to install some other modules after this option,how to do
it?

[Dhanji R. Prasanna]

As things stand, you can't add modules to an injector after it has been created. Some support for rebinding and chained injectors is coming in 2.0, IIRC. 

Dhanji.

[Kevin Bourrillion]

Still, at least 9 times out of 10 this isn't *really* what you want to do...

[king]

so,i must add all the modules at first?

and,if i want to binding some modules at another class,it's not
possible?

> > it?- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Dhanji R. Prasanna]

On Tue, Mar 18, 2008 at 7:21 PM, Kevin Bourrillion <kevi...@gmail.com> wrote:

Still, at least 9 times out of 10 this isn't *really* what you want to do...

I agree totally, Injectors ought to be immutable ( I dont particularly like the rebinding support that has been proposed ).

There are better design patterns (strategy, for one).

Dhanji.

[Danno]

Care to expand on this?

[Eric Anderson]

I will provide a counter-point for when it would be useful.  If you are using Guice to supply objects for test, then it is nice to get a regular module and then go back and inject a stub into that module for a service that you want to stub out.  So, I might want things wired up as normal except for swapping out a service so that I can inject errors.  This is a highly useful flow for testing.

I might suggest a syntax like this:

injector.injectStubFor(MyService.class).boundToInstance(myServiceStub);

Eric

[Sam Berlin]

I think there's another extension being worked on to support this.
Jesse Wilson (?) mentioned it the other day. See
http://publicobject.com/2008/02/guice-commands.html for some info.

Sam

[Ben]

I've been always wanting a easy way to override bindings, but not through an already instantiated injector. To me the best place is at the point of creating Injector:

Injector injector = Guice.createInjectorWithOverride(new TestOverrideModule(), new ProductionModule());

[Danno]

On Mar 18, 12:19 pm, "Eric Anderson" <d.eric.ander...@gmail.com>
wrote:
> I will provide a counter-point for when it *would* be useful. If you are

> using Guice to supply objects for test, then it is nice to get a regular
> module and then go back and inject a stub into that module for a service
> that you want to stub out. So, I might want things wired up as normal
> except for swapping out a service so that I can inject errors. This is a
> highly useful flow for testing.
>
> I might suggest a syntax like this:
>
> injector.injectStubFor(MyService.class).boundToInstance(myServiceStub);
>
> Eric

How about another counter point, a word processor that needs a
document bound per frame, therefore more than one module is
required. Where the application would have one module and it's
respective bindings, and the document or documents created would have
their own modules and bindings associated with it. Guice
unfortunately has anemic documentation and doesn't offer solutions for
real-life constructs like that.

Come to think of it there are probably more counterpoints out there
than the 1 out of 10 that you describe.

[Robbie Vanbrabant]

On Wed, Mar 19, 2008 at 8:38 PM, Danno <dh.evolu...@gmail.com> wrote:

How about another counter point, a word processor that needs a
document bound per frame, therefore more than one module is
required.   Where the application would have one module and it's
respective bindings, and the document or documents created would have
their own modules and bindings associated with it.  

I think you can get a long way with Providers and AssistedInject.
And let's see what Guice 2.0's hierarchical injectors feature brings. If that makes it in, but I'm guessing it will.
 

Guice
unfortunately has anemic documentation and doesn't offer solutions for
real-life constructs like that.

As for the documentation: April 2008 :-)

Thanks
Robbie

[Danno]

On Mar 19, 1:57 pm, "Robbie Vanbrabant" <robbie.vanbrab...@gmail.com>
wrote:

Hurry! ;)
I went to go look for your book and there is no Early Reader program
available is there?
Also I am confused as to who the publisher is...I went to Apress, and
then they landed me somewhere else, and as consumer that's scary.

Thanks, Danno

[Robbie Vanbrabant]

apress google guice
and you're feeling lucky :-)

Robbie

[Dhanji R. Prasanna]

While we are doing plugs =)

Here is a Dependency Injection book largely focused on Guice:

http://www.manning.com/prasanna

Dhanji.

[Josh McDonald]

Dhanji mate you're *always* doing plugs ;-)

--
"Therefore, send not to know For whom the bell tolls, It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: jo...@gfunk007.com

[Dhanji R. Prasanna]

On Thu, Mar 20, 2008 at 9:29 AM, Josh McDonald <dzn...@gmail.com> wrote:

Dhanji mate you're *always* doing plugs ;-)

Only of things that are worth it =)

Dhanji.

[Ales Justin]

What's the true benefit of using Guice Commands?
e.g. you already have a (huge) module, and you only want to change a
small fraction of its behavior, and then use that (rewritten) module to
create Injector?

>> binding commands will make other features like overriding bindings
trivial to implement

This is probably not yet available - unless you create new Injector?

Injector injector = Guice.createInjector(rewrittenModule);
assertEquals(new Pepsi(), injector.getInstance(Soda.class));

Will this help with unbinding as well?
e.g. I have a huge state machine where services come and go, meaning I
would still like to use Guice to handle my binding, but not for the cost
of class leakage - unless Class --> Provider mapping is weak, meaning
once I remove class's classloader that binding goes away as well?

Cheers,
Ales

btw: are Commands available in Maven2 repo?

[Dhanji R. Prasanna]

On Sun, Mar 23, 2008 at 11:23 PM, Ales Justin <ales....@gmail.com> wrote:

<snip> 

 I
would still like to use Guice to handle my binding, but not for the cost
of class leakage - unless Class --> Provider mapping is weak, meaning
once I remove class's classloader that binding goes away as well?

Well I'm not sure which JVM you are using, but the classloader cannot be "removed" -- it gets collected once there are no references to any of its classes. The Guice injector holds a strong reference to explicitly bound keys, however if the Guice injector is itself loaded in the same classloader (should be the case, normally) then this is a moot point and the entire class space will be cleaned.

As to leakage, this entirely depends on your architecture. Can you describe it some more?

Dhanji.

[Ales Justin]

> Well I'm not sure which JVM you are using, but the classloader cannot be
> "removed" -- it gets collected once there are no references to any of
> its classes.

Yup, explained a bit better. :-)

> As to leakage, this entirely depends on your architecture. Can you
> describe it some more?

I'm using this in the new JBoss5 kernel.
Imagine having a single Injector at the AS's bootstrap.
And then different apps come and go, and they can register new bindings
making its beans/services available to Guice.

I do control the service lifecycle together with its classloader, but if
I cannot remove the binding, probably leaves me with a leakage?

OK, I guess I could do things differently, creating Injector per
classloader, and use some sort of hierarchy of Injectors (already exists
afaik), the root being the one at bootstrap.

- Ales