Classes bound 'asEagerSingleton()' are injected as null.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a valid concrete instance class (MyClass)
2. bind( MyClass.class ).asEagerSingleton();
3. @Inject public MyConstuctor( MyClass myClass )

What is the expected output? What do you see instead?

I would expect that MyClass is initialised ASAP and that MyConstructor will
receive that one-and-only instance in its constructor.

Instead, while the class does seem to be initialised correctly, the inject
is always null. This is also the case if you then bind MyInterface to
MyClass and inject that. Eg:

bind( MyClass.class ).asEagerSingleton();
bind( MyInterface.class ).to( MyClass.class );

The same result if you then inject MyInterface instead. My guess is that
the lookup for MyClass is returning null for some reason...

What version of the product are you using? On what operating system?

Latest from trunk, on Mac OS X 10.5.7 running Java 6 (1.6.0_13).

Original issue reported on code.google.com by Bitmei...@gmail.com on 25 Jun 2009 at 3:56

[GoogleCodeExporter]

I'll look into this, might be that we don't properly handle eagerSingleton 
bindings.

Original comment by aragos on 2 Jul 2009 at 4:04

• Changed state: Accepted

[GoogleCodeExporter]

From my experience, when you start using eagerSingleton in the module, things go
weird. Sometimes project compiles, but instances are not instantiated in the 
right
order, (so you got null's injected) or are even instantiated several times. Not 
using
it brings project back to the sane state.

Original comment by A.A.Vasi...@gmail.com on 2 Jul 2009 at 4:36

[GoogleCodeExporter]

Actually, specifying '.in( Singleton.class )' also behaves weirdly. Not sure if
that's related.

Original comment by Bitmei...@gmail.com on 2 Jul 2009 at 5:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The latter is not the case for my little project. Of my 13 lines of configure 
method,
11 are in(Singlenton)'ed. And (I keep my fingers crossed) it provides stable 
injection
for changing dependency graph.

Original comment by A.A.Vasi...@gmail.com on 2 Jul 2009 at 6:01

[GoogleCodeExporter]

The problem I had with '.in(Singleton.class)' was that more than one instance 
was
being created, so different classes were getting different instances. I couldn't
track down exactly where or why. It's a different issue to the 
'isEagerSingleton()'
one, but might be related.

Original comment by Bitmei...@gmail.com on 2 Jul 2009 at 7:04

[GoogleCodeExporter]

Year, it was so when I had both .in(Singleton) and eagerSingleton in 
configure().
After I got rid of eagerSingleton, .in(Singleton) is back to it's singleness.

Original comment by A.A.Vasi...@gmail.com on 2 Jul 2009 at 7:47

[GoogleCodeExporter]

Aha - ok, that is quite possible. However, I currently can't get rid of my eager
singletons or the app won't do anything...

Original comment by Bitmei...@gmail.com on 3 Jul 2009 at 2:58

[GoogleCodeExporter]

I tried to replicate this issue and built a test for it but things seemed to 
work
fine. Please provide me with a test that reliably shows the issue (paste the 
code in
here, attach files or send a code review through codereview.appspot.com). Once 
I have
the failing code I'll investigate further.

Original comment by aragos on 6 Jul 2009 at 10:09

[GoogleCodeExporter]

I will see if I can build a test soon. Any chance I could get hold of your 
existing
test and work from there, rather than building my own from scratch? I'm a 
little rusty...

Original comment by Bitmei...@gmail.com on 8 Jul 2009 at 2:51

[GoogleCodeExporter]

Take a look at the test in test/com/google/gwt/inject/client/scopedimplicit. 
The new
tests that I wrote can be seen here: http://codereview.appspot.com/88134

Original comment by aragos on 9 Jul 2009 at 2:41

[GoogleCodeExporter]

Sorry, very busy currently. Would give a hand later if it would still needed.

Original comment by A.A.Vasi...@gmail.com on 9 Jul 2009 at 2:51

[GoogleCodeExporter]

Thanks. I'll see what I can come up with.

Original comment by Bitmei...@gmail.com on 9 Jul 2009 at 3:10

[GoogleCodeExporter]

I had a go at getting it to break also, and am so far unable to replicate the 
problem
in that environment. The problem definitely exists though, so I'll have another 
go
later this week and see if I can figure out what is different between the test
environment and my app where it is breaking... A.A - feel free to have a go too.

What environment do the GWTTestCases actually get executed in. Is it a true 
browser?
I'm on a Mac, so is it Safari/WebKit?

Original comment by Bitmei...@gmail.com on 10 Jul 2009 at 6:36

[GoogleCodeExporter]

I was unable to use .asEagerSingleton() and I would see the following error 
message.
 It appears that I am also having the issue where null is injected.  From what I can
tell it has something to do with injecting an eager singleton in to another 
eager
singleton.  In my case I had a class named EventBus which used constructor 
injection
to get a reference to another eager singleton named CachedTransactionService.

Original comment by bens%fas...@gtempaccount.com on 15 Jul 2009 at 2:09

Attachments:

• p1.jpg

[GoogleCodeExporter]

Ok, I've now figured out a test case that replicates both issues. I've added the
patch here:

http://codereview.appspot.com/96042

Specifically, there are two different issues which may or may not be related.

1. If a non-eager singleton is injected into an eager singleton _and_ a 
non-singleton
(or possibly even a non-eager singleton, didn't test that case), one instance 
of the
non-eager singleton will be created for the eager singleton, and another for the
non-singleton. This is tested by 'testEagerSingletonInjection'.

2. If an eager singleton (A) is injected into another eager singleton (B), the 
second
eager singleton is never instanciated. This is tested by
'testEagerSingletonDoubleInjection'.

I haven't been able to decipher exactly where the bug is yet, unfortunately, 
mostly
because I can't figure out how to get the GWTTestCases to run in Eclipse...

Original comment by Bitmei...@gmail.com on 15 Jul 2009 at 5:35

[GoogleCodeExporter]

Update - there was actually a bug in 'testEagerSingletonDoubleInjection'. That 
test
case now passes, so I'm still not sure what's causing the 'null' injection. 
Issue 1,
as tested by 'testEagerSingletonInjection' is still failing.

Original comment by Bitmei...@gmail.com on 15 Jul 2009 at 6:14

[GoogleCodeExporter]

I've updated the patch set in 96042 with the fixed test case.

Original comment by Bitmei...@gmail.com on 15 Jul 2009 at 6:15

[GoogleCodeExporter]

No word on getting a fix for this? Or at least a pointer towards the right 
section of
code in GIN for me to hack at myself? I took a quick look but was unable to spot
anything obvious...

Original comment by Bitmei...@gmail.com on 20 Jul 2009 at 10:44

[GoogleCodeExporter]

Sorry for the long delay! Unfortunately the failures of the provided test cases 
are
due to an unrelated configuration bug (overwriting a @Singleton annotation with 
an
empty binding in the module). Please take another look and try to replicate the
failure related to eagerSingleton.

Original comment by aragos on 24 Jul 2009 at 6:59

[GoogleCodeExporter]

So, if you annotate an object with @Singleton, it will be injected 
automatically even
if you don't bind it in a Module? My intent with those lines of code was to have
Guice/GIN bind the object using whatever scope was attached. That isn't 
necessary?

Original comment by Bitmei...@gmail.com on 25 Jul 2009 at 1:01

[GoogleCodeExporter]

Yes, that is correct. Guice will try to find an "implicit binding" if you don't
specify anything in your module and will take the annotations into account. As a
matter of fact, as you've seen in these tests, the annotations are taken into 
account
*only* if you use the implicit binding because that way you can always override 
any
default annotations in the module.

Original comment by aragos on 27 Jul 2009 at 5:35

[GoogleCodeExporter]

> Unfortunately the failures of the provided test cases are
> due to an unrelated configuration bug (overwriting a @Singleton 
> annotation with an empty binding in the module).

Does this configuration bug also mean that following scenario will fail to 
inject a
class as a singleton?

@Singleton class Foo implements Bar {
...
}

bind(Bar.class).to(Foo.class);

If so, that renders that @Singleton annotation useless for anything but implicit
bindings. Is there an open issue for this bug?

Original comment by sarne...@gmail.com on 9 Aug 2009 at 10:15

[GoogleCodeExporter]

> If so, that renders that @Singleton annotation useless for anything but 
implicit
> bindings. Is there an open issue for this bug?

The case you describe is slightly different from the issue mentioned above: Here
there is a binding target AND a singleton annotation on the target. In this 
case, we
will always return a singleton. This is a pure Guice issue, btw - Gin just does 
what
Guice tells it. :)

Original comment by aragos on 12 Aug 2009 at 9:31

[GoogleCodeExporter]

Since no one seems to be able to duplicate the problem, I'll close this issue. 
If you
happen to find an actual bug for this, let me know and I'll reopen this issue.

Original comment by aragos on 20 Aug 2009 at 12:07

• Changed state: Invalid

[GoogleCodeExporter]

This came up again and I was finally able to pinpoint a flaw within our
eagerSingleton initialization procedure, explained in this message:

http://groups.google.com/group/google-gin/msg/99f64d2935558a2f

I wrote a test and patch which can be reviewed here: 
http://codereview.appspot.com/110095

Original comment by aragos on 27 Aug 2009 at 5:04

• Changed state: Review

[GoogleCodeExporter]

Awesome! Sorry I wasn't able to figure it out earlier - essentially I had worked
around the problem by minimising the number of eager singletons my app had, so 
it
wasn't occurring any more...

Original comment by Bitmei...@gmail.com on 28 Aug 2009 at 12:26

[GoogleCodeExporter]

Committed in r112.

Original comment by aragos on 15 Sep 2009 at 10:02

• Changed state: Fixed

[GoogleCodeExporter]

Well this problem seem to be back in Gin 1.5, anyone else having this problem 
with eager singleton ?

Original comment by goudreau...@gmail.com on 1 May 2011 at 2:00

[GoogleCodeExporter]

Ok seem to be the same thing with Singleton and it does it even when I remove 
every eagersingleton.

Original comment by goudreau...@gmail.com on 1 May 2011 at 2:11

[GoogleCodeExporter]

Forget it :D

Original comment by goudreau...@gmail.com on 1 May 2011 at 8:50