[cdi-dev] CDI-519 notes

[Emily Jiang]

Thank you Martin for the useful summary!

+1: only support the Instance.destroy() to destroy the depended scoped 
objects created by the same Instance object. 

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     cdi-dev <cdi-dev at lists.jboss.org>, 
Date:   18/05/2016 08:55
Subject:        [cdi-dev] CDI-519 notes
Sent by:        cdi-dev-bounces at lists.jboss.org



Hi all,

John is questioning the clarification introduced in CDI-519. I think 
it's correct although not quite intuitive.

Below are some notes we should consider (I know it's long but the topic 
is quite complicated):

CreationalContext
=================

Besides other things, holds the references to all depenent bean 
instances together with their CCs (for normal scopes this is the 
responsibility of the context). So that these could be correctly 
destroyed when CC.release() is called.

Note that the context must pass the same instance of CC to 
Contextual.destroy() that it passed to Contextual.create() when it 
created the instance.

Possible "leak" description
===========================
The problem is if an Instance is injected into a normal scoped bean Foo 
and is used to get other @Dependent bean instances via Instance.get(). 
Each of this call returns a new depenent bean instance bound to the 
lifecycle of the Instance, which is also depenent and so it's 
effectively bound to the lifecycle of Foo. And that was the original 
motivation to introduce Instance.destroy().

Instance.select()
=================
The spec states the select() method returns a child Instance. What is 
that "child" is not defined though. In Weld, a child Instance shares the 
CreationalContext of the parent Instance. And I think this makes sense.

CDI-519 summary
===============
Instance.destroy() cannot be used for dependent bean instances not 
created by the same Instance object.

The reason: a dependent bean instance does not know the object it 
depends on. So if we pass a dependent bean instance it must be "managed" 
by the CC of the Instance. Otherwise, we would not be able to destroy 
the bean instance and all its dependent dependencies correctly.

 From the spec point of view it's clear:
"An instance of a bean with scope @Dependent obtained by direct 
invocation of an Instance is a dependent object of the instance of 
Instance." A dependent bean instance is bound to the lifecycle of 
Instance (or one of its child) so the Instance should be responsible for 
destroying it. Done.

 From the user point of view: I don't think it's a big problem. BTW it 
does not work in any CDI 1.1+ version of Weld. I'm not sure about OWB.

Impl notes
==========
If we allow this then we would probably have to create some central 
registry of CCs and during Instance.destroy() iterate over all these CCs 
and try to destroy given depenent bean instance. This will be 
complicated, error-prone and inefficient.

Thanks,

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160518/bb0fcea4/attachment.html