I can throw something together, basically my own version of @PostConstruct
I guess. It should probably be documented though that PostProduction
lifecycle event happens after PostConstruct.
> There are three possibilities: 1) Right after construction but before
anything is injected 2) After construction and injection but before
post-construct 3) both 1 and 2.
I don't think (1) is a valid use case. At least my initial thought would be
there's only two states the object can be in: Resolved (implying the object
has been constructed and all necessary dependencies injected) and
Constructed (implying @PostConstruct has been called and the object is
really initialized.) At least for the system I'm thinking of I'd really
like to be able to inject logic post-Resolved/pre-Constructed. This gives
the system components a clear guarantee that by the time
per-component-level logic kicks in (@PostConstructed called) that the
container is done with them and all their 'container-level' dependencies
and initialization has been done.
If this is not a common use case that's fine. I can whip something up but it
leads to some ugliness because objects in @PostConstruct aren't really
fully initialized by the container -- there's still further work to be done
by the container and any registered lifecycle listeners. And I'll have to
be sure that component writers don't use @PostConstruct but something...
maybe @PostConstructed ;)
On Thu, Aug 8, 2013 at 8:37 AM, John Wells <john.wells_at_oracle.com> wrote:
> Right now the event happens after production (and hence the postConstruct
> has already been called). We would have to add new events, but I'd be a
> little reticent to do so, simply because of the overhead. Plus, it is
> unclear when the other events should occur. There are three possibilities:
> 1) Right after construction but before anything is injected 2) After
> construction and injection but before post-construct 3) both 1 and 2.
>
> Further, these other two events would only be available for non-factory,
> non-thirdparty descriptors.
>
> Can you instead invent your own postPostProduction API that you call after
> you have completed your initialization?
>
>
> On 8/8/2013 7:42 AM, buko wrote:
>
> It looks like for a given object @PostConstruct methods will be invoked
> before the InstanceLifeCycleListener is given the chance to post-process
> the object by handling the POST_PRODUCTION event. So if I have an
> InstanceLifeCycleListener and its goal is to post-process an object, it
> gets a LifeCycleEvent with lifeCycleObject=null (the PRE_PRODUCTION) case,
> then @PostConstruct gets invoked but of course everything is still null
> because the listener was never given a chance to do its post-processing.
>
> Is there a way around this? Can I post-process an object to get in there
> to set some variables before its @PostConstruct methods get invoked?
>
>
> On Wed, Aug 7, 2013 at 10:18 AM, buko <buko_at_chiubarobot.com> wrote:
>
>> Thanks John. The qualifier thing makes sense, I'll give it a shot.
>> On Aug 7, 2013 9:07 AM, "John Wells" <john.wells_at_oracle.com> wrote:
>>
>>> Answers in-line.
>>>
>>> The fact that you are asking these questions implies that we do not have
>>> enough documentation for the feature. I will try to find somewhere to add
>>> an example or find some other way to upgrade the documentation.
>>>
>>> On 8/7/2013 8:43 AM, buko wrote:
>>>
>>>>
>>>> Are there any examples of custom InstanceLifeCycleListeners out there?
>>>>
>>> We have no example of the InstanceLifeCycleListener in our
>>> documentation. However, the config subsystem of HK2 uses it in order to
>>> have a backwards reference from the injectee to the injector. I think some
>>> kind of example should be added to the hk2 documentation.
>>>
>>>>
>>>> I'm looking to do some basic post-processing of managed objects. In the
>>>> normal injection phase a resource is passed to the ctor. In the next phase
>>>> I'd like to go back and use the injected resource to further customize the
>>>> object.
>>>>
>>>> I've taken a look at ConfigInstanceListener and don't quite get it.
>>>>
>>>> Does the lifecycle object (post-processing target?) need to implement a
>>>> specific interface in order for the Filter to match? Ideally I'd like to
>>>> just slap an annotation on them. But it's not clear how to construct a
>>>> Filter that matches an annotation.
>>>>
>>> If you just want to put an annotation on the classes you want to operate
>>> on the best thing to do would be to make your annotation a qualifier (i.e.,
>>> put @Qualifier on your annotation). That way your annotation would show up
>>> in the list of qualifiers in the Descriptor. And thus the Filter could
>>> easily match just those services that have that qualifier.
>>>
>>>>
>>>> If I need to actually initialize/wrap/set fields on the lifecycle
>>>> object does hk2 offer any facilities for that? Should normal java
>>>> reflection be used? I'm worried this won't work if the post-processing
>>>> object is proxied by hk2. Do InstanceLifeCycleListeners get called for the
>>>> creation of proxies if the underlying object hasn't been created yet?
>>>>
>>> You would need to do your own reflection. The object returned here is
>>> NOT the proxy, but the real underlying object, which means you can call any
>>> methods you want on the object and not worry about causing the proxy to
>>> create the underlying object (thus invalidating the point of the proxy!).
>>> This fact should be documented in the javadoc though!
>>>
>>>>
>>>> What does InstanceLifeCycleEvent#knownInjectees return? Are these the
>>>> same injectees that are passed to a custom InjectionResolver?
>>>>
>>> For this the javadoc is pretty clear. The descriptor has a set of
>>> injectees. This is a map from that set of injectees to the real objects
>>> that were created for this object. This is useful in the usecase described
>>> above, where the user wants to have a backwards pointer from the injectee
>>> to the injector.
>>>
>>>>
>>>> Thanks for any help.
>>>>
>>>
>>>
>
>