Where to do Object initialization that would usually be in the constructor
christop...@googlemail.com
I like google-guice very much so far, especially for its simplicity,
expressiveness and that it can be used flexibly in many different
types of applications.
One thing that I either didn't figure out or that is missing is how to
do the initialization of an Object that uses guice's injection. Let me
try to clarify what I mean: In a POJO you would do all initialization
of an Object in its constructor. However, that pattern doesn't work
when using injection, since some initialization might depend on
properties that are being injected and thus are not available during
the constructor-call.
When all injections are done in the constructor this is not an issue.
But when property or method is used, the constructor cannot serve as a
place for initialization any more.
One dirty workaround that I figured out is to have a function like
"@Inject void init() { /* init stuff */ }" that is textually after all
other injection functions. However this is obviously a hack, since it
relies on the textual order of the functions.
What I imagine would be a nice solution is to have an annotation (I'll
call it "@Initialize") that can be used on a method. That method will
be called after all dependencies have been injected. Thus:
"@Initialize void init() { /* init stuff */ }"
Inheritance complicates the order of initialization a bit, but should
still be obvious.
what do you think?
so long,
Christoph
Bob Lee
The next version of Guice will handle this much better.
Bob
Dhanji R. Prasanna
Currently, you pretty much need to include all of your required dependencies in the constructor and put your initialization logic there. You can put some logic in an injected method, but you cannot depend on the ordering of injected methods (Java explicitly doesn't guarantee that the runtime order will match the order in your source file).
The next version of Guice will handle this much better.
I take it you're including lifecycle support in guice1.1? =(
How about something like multicast in picocontainer? that would be cool...
Out of curiosity, are you referring to the java reflection api (java.lang.reflect) as not guaranteeing the order of methods? I wonder if using an alternative reflection api (such as javassist) might solve that--then again I have not seen anything in the JLS guaranteeing the lexical order of methods in class files to reflect the sources.
Dhanji.
big bad joe
constructor injection. Thats the way we are doing our initialization:
One injected constructor and one injected void init() method for the
initialization.
Out of curiosity: How will the next version of Guice handle that? And
how long have we to wait for the next version? There are some
improvements announced for 1.1 which would be very helpful for our
project ...
On 23 Mai, 02:00, "Bob Lee" <crazy...@crazybob.org> wrote:
> Currently, you pretty much need to include all of your required dependencies
> in the constructor and put your initialization logic there. You can put some
> logic in an injected method, but you cannot depend on the ordering of
> injected methods (Java explicitly doesn't guarantee that the runtime order
> will match the order in your source file).
>
> The next version of Guice will handle this much better.
>
> Bob
>
> On 5/22/07, christoph.die...@googlemail.com <christoph.die...@googlemail.com>
Dhanji R. Prasanna
At least you know that a method injection is always called after a
constructor injection. Thats the way we are doing our initialization:
One injected constructor and one injected void init() method for the
initialization.
That sounds like a terrible hack. =(
Why not just call init() from the ctor?
I didnt think parameterless methods annotated with @Inject were honored...that sounds like a mistake. Wasnt there some discussion about this earlier in an issue? I recall bileblog had similar sentiments.
Dhanji.
big bad joe
> That sounds like a terrible hack. =(
> Why not just call init() from the ctor?
In many cases the initialization depends on the internal state of
other injected instances. But you can not call methods on injected
members, they are still just proxies. So calling init from the
constructor wont help.
I also dont like the way it is now, but it works. The alternative
could be to write Factories/Builders for all these classes that need
an initialization and thats a lot of overhead for a simple thing like
a "delayed" initialization. On the other hand, you are not able to
retrieve the instances of these (injected) Factories/Builders in your
injected constructor and there is the same problem again.
Dhanji R. Prasanna
On 23 Mai, 10:20, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> That sounds like a terrible hack. =(
> Why not just call init() from the ctor?
In many cases the initialization depends on the internal state of
other injected instances.
I guess you're talking about full-blown lifecycle here. Ive never been a big supporter of guice doing lifecycle as I feel it is too dependent on use cases and deployment environments.
Although I wouldnt mind a general multicast interface, separate from the injection model (as mentioned before) like pico. This lets people create their own lifecycle semantics. I suppose @Init is inevitable though... =(
Dhanji.