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@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.