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
> <mailto: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
> <mailto: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.
>
>
>