Oh so Guice is instantiating the factory, even if it's not using assisted
injection. Then yes, this will work.
--
Cédric
On Thu, Apr 11, 2013 at 2:02 PM, Newbie McBozo wrote:
> Yep. Within the calling class (which itself was created by guice) I have
>
> @Inject
> MyClassFactory mcf;
>
> An
Yep. Within the calling class (which itself was created by guice) I have
@Inject
MyClassFactory mcf;
And then when I need one...
MyClass myObj = mcf.create("Something");
I'm unsure of whether I can do that inject within the calling method, but I
actually need the factory in a few methods,
On Thu, Apr 11, 2013 at 1:17 PM, Newbie McBozo wrote:
>
> I still create the object with MyClassFactory.create("Something");
>
If MyClassFactory is instantiated by you and not Guice (through assisted
injection), then the returned object will not have its fields injected, you
might want to double
I probably wasn't clear enough.
By assisted injection, I was talking about something that looks like this:
==
public interface MyClassFactory{
public MyClass create(String myString);
}
public class MyClass{
private String myString;
private MyObject superThing;
@Inject
publi
On Thu, Apr 11, 2013 at 11:43 AM, Newbie McBozo wrote:
>
> I had 6 parameters required on instantiation, and one necessary injected
> variable that did not need to be private. Rather than annotate 6 variables
> and have Guice add the 7th, I chose to simply inject the 7th as a member
> variable d
Thanks!
In my case it was necessary to have parameters in the constructor, but I
found the discussion that followed very interesting.
My first iteration that worked followed the assisted injection model, but I
found it to be a little more straightforward to use field injection.
I suppose the c
That's more or less where I'm at, Cedric.
That said, I'm also in favor of "new" for pure raw value types. There
are places where you don't need a seam for testing or for
modularity/decoupling, because you're dealing with something that you
are never going to sanely mock or stub or swap.
Pur
Sorry - the wording is perhaps overstated. javax.inject.Provider is
merely a standardization of Guice's Provider in order to provide more
compatibility between different DI systems. They occupy the same space
in the design.
And I suppose it's not "internal" to Guice in that it is a public AP
To me, Provider should only be used if, in order to create the instance,
you need some additional information that's not available at the very
beginning of the application, when Guice establishes all the bindings. From
this standpoint, @Inject and providers are not really interchangeable:
- @In
Note that Provider is not guaranteed to always return a new instance, it
depends on the scope of the binding behind it.
If X has been bound as a singleton in the injector then you'll always get the
same instance returned from Provider.get().
On 11 Apr 2013, at 09:32, Peter Reilly wrote:
> I to
Are you talking about com.google.inject.Provider or javax.inject.Provider
or both?
Calling javax.inject.Provider an internal type seems a bit harsh.
--tim
On Thu, Apr 11, 2013 at 3:06 AM, Christian Gruber wrote:
> It is easier, but please don't. While the two are practically similar, it
> is a
I totally disagree. Provider a, a.get(), is the correct replacement for
new X();
Peter
On Thu, Apr 11, 2013 at 8:06 AM, Christian Gruber wrote:
> It is easier, but please don't. While the two are practically similar, it
> is a design obfuscation to inject a Provider merely to serve as a
> fac
It is easier, but please don't. While the two are practically similar,
it is a design obfuscation to inject a Provider merely to serve as
a factory of Foo. Provider is an internal type to Guice/DI, whereas a
factory is class that manages value types and domain objects.
It is technically vali
If your factory method has no arguments it is easier to remove the
factory and have guice inject a Provider instead of the factory
see: http://code.google.com/p/google-guice/wiki/InjectingProviders
On 04/11/2013 04:33 AM, Newbie McBozo wrote:
Thanks for your help guys, I figured it out.
The
Thanks for your help guys, I figured it out.
The way I attacked this was this:
I created a factory interface. I then added a line to the configure
function of the module:
binder.install(new FactoryModuleBuilder().build(MyClassFactory.class));
rather than calling "new" for new instances of the
On Wed, Apr 10, 2013 at 5:09 PM, Newbie McBozo wrote:
> I get that, and forgive me for being dense, but I don't get how to make it
> so that my class is created by Guice so that my injections will work.
>
This is the first thing you need to fix. If you can't get Guice to
instantiate these object
On Wed, Apr 10, 2013 at 8:09 PM, Newbie McBozo wrote:
> I get that, and forgive me for being dense, but I don't get how to make it
> so that my class is created by Guice so that my injections will work.
>
> I see that the application provides a module that's called on startup.
> Within that modul
I get that, and forgive me for being dense, but I don't get how to make it
so that my class is created by Guice so that my injections will work.
I see that the application provides a module that's called on startup.
Within that module I see a series of functions that call binder.bind and in
al
Dependency Injection 101: only objects created by the DI container (Guice
in this case) are injected; this means only objects that have been
retrieved from the Injector (through its getInstance method generally) or
have themselves been injected into other classes. It's possible to inject
object
I'm working with an application that uses Guice.
I know nothing about guice, and parsing the documentation for my particular
situation hasn't been easy.
I have a java class. That class needs an object provided by the
application.
If I subclass an application provided class and override it's b
20 matches
Mail list logo
