Closed GoogleCodeExporter closed 9 years ago
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
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
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
[deleted comment]
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
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
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
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
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
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
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
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
Thanks. I'll see what I can come up with.
Original comment by Bitmei...@gmail.com
on 9 Jul 2009 at 3:10
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
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:
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
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
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
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
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
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
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
> 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
> 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
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
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
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
Committed in r112.
Original comment by aragos
on 15 Sep 2009 at 10:02
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
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
Forget it :D
Original comment by goudreau...@gmail.com
on 1 May 2011 at 8:50
Original issue reported on code.google.com by
Bitmei...@gmail.com
on 25 Jun 2009 at 3:56