Here is a simple way to do what you want:
public class Lazy {
@Inject Provider provider;
private T instance;
public T get( ) {
if (instance == null) {
instance = provider.get();
}
return instance;
}
}
public class Main {
@Inject Lazy thingA;
@Inject Lazy thingB;
Ma
Maybe this will clarify what I was looking for:
http://codereview.appspot.com/4128063/
I implemented the SingleProvider, here is the test(FooBar isn't a
singleton):
public void testProviderInGinjector() {
Provider fooProvider = injector.getFooBarProvider();
assertNotSame(fooProvider.g
Thanks
On Thu, Feb 3, 2011 at 7:02 PM, zixzigma wrote:
> I am not sure if this helps,
> but there is a feature called Binding Annotations,
> you can use BindingAnnotation to differentiate the Provider used in Class
> A,
> from the one used in Class B.
>
> http://code.google.com/p/google-guice/wi
I am not sure if this helps,
but there is a feature called Binding Annotations,
you can use BindingAnnotation to differentiate the Provider used in Class A,
from the one used in Class B.
http://code.google.com/p/google-guice/wiki/BindingAnnotations
--
You received this message because you are su
Sorry, the example should be with "SimpleInstanceProvider", not with
"Provider"
On Thu, Feb 3, 2011 at 6:05 PM, Gal Dolber wrote:
> If I inject a provider on 2 different classes I expect them to return a
> different instance, but each provider must return the same one.
>
> class A {
> @Injec
If I inject a provider on 2 different classes I expect them to return a
different instance, but each provider must return the same one.
class A {
@Inject
public Provider p; // p.get() returns always the same instance
}
class B {
@Inject
public Provider p; // p.get() returns always
I am using the same technique as Ryan suggested.
Your comment : "non-singleton class that return always the same instance"
isn't a "non-singleton class that always return the same instance" in fact
the very definition of Singleton ? : )
I have read that there is a difference between Singleton De
No idea why you answer 3 times the same, but please read again my question.
I am using providers. As I already imagined gin doesn't have what I need.
I was looking for other solutions people were using.
What I need is: A provider of a non-singleton class that return always the
same instance.
I am
if you do not want your objects to be in Singleton scope,
just use Provider in following fashion.
no configuration is necessary.
public class MyClass {
private final Provider fooProvider;
@Inject
public MyClass(Provider fooProvider){
this.fooProvider = fooProvider;
}
public void myMethod(){
Fo
if you do not want your objects to be in Singleton scope,
just use Provider in following fashion.
no configuration is necessary.
public class MyClass {
private final Provider fooProvider;
@Inject
public MyClass(Provider fooProvider){
this.fooProvider = fooProvider;
}
public void myMethod(){
Fo
if you do not want your objects to be in Singleton scope,
just use Provider in following fashion.
no configuration is necessary.
public class MyClass {
private final Provider fooProvider;
@Inject
public MyClass(Provider fooProvider){
this.fooProvider = fooProvider;
}
public void myMethod(){
Fo
if you do not want your objects to be in Singleton scope,
just use Provider in following fashion.
no configuration is necessary.
MyClass {
private final Provider fooProvider;
@Inject
public MyClass(Provider fooProvider){
this.fooProvider = fooProvider;
}
public void myMethod(){
Foo foo = fooPr
using a Provider always result in delayed on-demand instantiation,
the object is not create unless you get() it.
however, if you don't bind it in Singleton scope,
this deferred on-demand instantiation will create a new instance every time
you call get() on the Provider.
in cases where you only ne
Yes, I know about singletons. This is not the case.
What I am talking about is delayed instantiation.
In most of my current use cases the binded object aren't singletons.
On Thu, Feb 3, 2011 at 5:03 AM, Ryan Mehregan wrote:
> yes, it is totally unnecessary.
>
> 1- you can annotate your Foo clas
yes, it is totally unnecessary.
1- you can annotate your Foo clas with @Singleton annotation.
2- alternatively you can use bind(Foo.class).in(Singleton.class)
in your GIN Module configure() method.
now you can use your Provider as you normally would,
and it gives you the same Foo instance all th
15 matches
Mail list logo
