[cdi-dev] CDI-519 notes
mkouba at redhat.com
Wed May 18 03:54:12 EDT 2016
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):
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().
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.
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.
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.
Red Hat, Czech Republic
More information about the cdi-dev