Object is injected only once, but it's constructor is called twice :(

[Witold Szczerba]

Hi there,
today I have noticed strange thing in my application. I have a class
MainFrame like this:

@Singleton
public class MainFrame extends JFrame implements Runnable {
private final TaskBrowserCtr taskBrowserCtr;
...
@Inject
public MainFrame(TaskBrowserCtr taskBrowserCtr,...) {
this.taskBrowserCtr = taskBrowserCtr;
...
}
...
}

TaskBrowserCtr looks like this:

public class TaskBrowserCtr extends AbstractBrowserCtr {
private final Timer timer = new Timer("TaskBrowserCtrTimer", true);
...
@Inject
public TaskBrowserCtr(...) {
...
}
...
}

So, when TaskBrowserCtr gets injected into MainFrame, it creates new
TaskBrowserCtrTimer daemon thread.
Today I was debugging my application and I found there are two such
threads! So, I placed breakpoint inside TaskBrowserCtr constructor and
it was caught TWICE during Guice's Injector initialization
(Stage.PRODUCTION).

I have checked it very carefully: no other class in entire application
asks for TaskBrowserCtr. MainFrame is singleton and the only one who
asks for TaskBrowserCt... and there is only one injector, so how is
this possible that Guice calls constructor twice?

Thanks,
Witold Szczerba

[Witold Szczerba]

2009/12/18 Witold Szczerba <pljos...@gmail.com>:

> threads! So, I placed breakpoint inside TaskBrowserCtr constructor and
> it was caught TWICE during Guice's Injector initialization
> (Stage.PRODUCTION).

Now I can see it happens only when Stage.PRODUCTION is used.
Going back to the above problem, the MainFrame singleton's constructor
itself was called twice, not just the TaskBrowserCtrTimer...
In the constructor of MainFrame I have entered Thread.dumpStackTrace()
and two dumps were printed (see attachments). Third attachment was
taken during initialization of Stage.DEVELOPMENT injector.

[limpb...@gmail.com]

Might you have a circular dependency? Ie. one of your classes injects
something that injects itself. When that happens, Guice 2.0 would
sometimes call a constructor 2x, only to discard the second instance.
You can grab a copy of Guice that has the fix from SVN, or tweak your
code to avoid the circular dependency. Or add @Singleton to
TaskBrowserCtr, which seems like the most durable fix.
svn checkout http://google-guice.googlecode.com/svn/trunk/ google-
guice
http://code.google.com/p/google-guice/source/detail?r=1114

In general I dislike heavyweight side effects that come as a
consequence of object construction. Instead, trigger heavyweight
actions (starting threads, binding to ports, etc.) in a separate
startup() method after your injector has been created.

[Yashiro Nanakase]

hi Witold,

I'm having this problem too, did you get it solved? Can you please share the solution? thanks.

Regards,

Yashiro

[Luke Sandberg]

Can you share a test case that demonstrates this?

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/b76baba6-578a-453e-b7a5-30c10c06555d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephan Classen]

I had such a behavior once. In the end I had one point in the code where I injected the interface and another where I injected the concrete instance. Guice created a just in time binding for the concrete inatance. This was the reason the constructor was called twice.