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
13 matches
Mail list logo
