[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
11:27 a.m.
Mark Struberg created CDI-228:
---------------------------------
Summary: Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
This clarification is intended for all methods which gets invoked by the CDI container and
create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:45 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Arne Limburg commented on CDI-228:
----------------------------------
I think we should exclude @Inject here. @Inject denotes a dependency to another bean. So
imho this is like @Keep by definition.
I agree completly with the rest of this issue.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:18 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-228:
----------------------------------
Actually observers and disposers are already mentioned in the spec.
{quote}
6.4.2. Destruction of objects with scope @Dependent
...
Additionally, the container must ensure that:
* ...
* all @Dependent scoped contextual instances injected into method parameters of a disposer
method or observer method of any other event are destroyed when the invocation completes,
* any @Dependent scoped contextual instance created to receive a producer method, producer
field, disposer method or observer method invocation is destroyed when the invocation
completes, and
* ...
{quote}
I don't think we should declare this for bean constructors and initializer method
parameters - such contextual instances logically depend on the declaring bean.
The only problem I see are producer method parameters injection points. However I suppose
it should work the same way as Bean constructors do (contextual instances depend on
produced bean).
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:22 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-228:
-----------------------------------
Thanks for the Observer catch, Martin! I did knew that we have it somewhere, but
didn't find it quickly ;)
I don't think we should declare this for bean constructors and
initializer method parameters
- such contextual instances logically depend on the declaring bean.
The problem here is that the CDI-1.0 spec was overly strict with the Serialization checks.
We generally didn't allow non-serializable @Dependent beans getting injected into a
passiviting Scope beans. But thats bollocks as well.
There are 2 important use cases
A.) the @Inject method param gets stored inside the class
public class X {
Y y;
@Inject
public initY(Y myY) {
myY.doSomeInit();
this.y = myY;
}
}
B.) the @Inject method param gets NOT stored inside the class
public class X {
Z z;
@Inject
public initY(Y myY) {
z = myY.createZ();
}
}
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:13 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-228:
--------------------------
Fix Version/s: 1.1 (Proposed)
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:04 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-228:
-------------------------------
Looking at this initially.
This is specified as you describe, for produvers, disposers and observers, in 6.4
"Any instance of the bean injected into method parameters of a disposer method or
observer method exists to service the method invocation only (except for observer methods
of container lifecycle events)."
So if impls aren't doing this, its a bug in the impl.
However this isn't covered for initializer methods, as initializer methods are
designed to receive injections for the bean itself, just like constructor and field level
injections.
Initially I would say that we are in a reasonable position here.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:47 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-228:
-----------------------------------
Ok, we are now down to the point that we need to clarify the behaviour for @Inject method
and constructor parameters.
Again: we face 2 logically distinct use cases. Not sure if we could define that we
immediately destroy any @Dependent @Inject method and ct parameter because of the case A.)
I described above.
This usage seems to be particularly popular for unit testing. I personally don't get
it why people like injector methods and ct instead of field injection, but Adam and Oliver
are big fans of it. We might like to get them to comment on this issue.
From my point I'd simply use field injection if I need the
@Dependent stuff for the whole contextual instance lifetime. Setting those via setter just
messes up the interface of my classes imo.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:49 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Jozef Hartinger edited comment on CDI-228 at 8/16/12 4:48 AM:
--------------------------------------------------------------
Pete, which part of the sentence you quoted covers producer methods?
was (Author: jharting):
Which part of the sentence you quoted covers producer methods?
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:49 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Jozef Hartinger commented on CDI-228:
-------------------------------------
Which part of the sentence you quoted covers producer methods?
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:59 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-228:
-------------------------------
Sorry, I missed one of the two sentences. Full quote is:
{quote}
Any instance of the bean that receives a producer method, producer field, disposer method
or observer method invocation exists to service that invocation only.
Any instance of the bean injected into method parameters of a disposer method or observer
method exists to service the method invocation only (except for observer methods of
container lifecycle events).
{quote}
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:59 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-228:
-------------------------------
Good point, I mentally included the sentence above, which discusses instances created to
receive invocations on methods, which does discuss producers.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:59 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-228:
--------------------------
Comment: was deleted
(was: Sorry, I missed one of the two sentences. Full quote is:
{quote}
Any instance of the bean that receives a producer method, producer field, disposer method
or observer method invocation exists to service that invocation only.
Any instance of the bean injected into method parameters of a disposer method or observer
method exists to service the method invocation only (except for observer methods of
container lifecycle events).
{quote})
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:01 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-228:
-------------------------------
Mark, I agree re setter injection.
As Martin said, the big issue is around producer methods, as initializer methods are
clearly intended for injection purposes.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:23 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir reassigned CDI-228:
-----------------------------
Assignee: Mark Struberg
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-228:
-----------------------------------
A quick summary of what we discussed last week:
We have 4 different kind of method injections:
1. Observer methods
2. Producer methods
3. @Inject constructor
4. @Inject methods
The CDI-1.0 spec already defines that @Dependent scoped beans injected into an Observer
method (case 1.) must get destroyed after the method invocation.
For the other 3 cases there is no such a definition, which indicates that those @Dependent
scoped contextual instances need to remain stored in the CreationalContext of the
respective bean.
The CDI-1.0 spec further was overly strict and did forbid injecting a non-serializable
@Dependent bean into a method parameter of a passivation capable bean. We removed this
restriction already in CDI-1.1.
Action: We will introduce a new annotation @Transient (or similar) which denotes that the
parameter shall not get stored in the CreationalContext of it's owner but instead
shall get thrown away immediately after the method invocation.
The spec wording will get changed to amend the section 6.4.2
OLD:
"• all @Dependent scoped contextual instances injected into method parameters of a
disposer method or observer method of any other event are destroyed when the invocation
completes,"
NEW:
"• all @Dependent scoped contextual instances injected into method parameters which
are marked or assumed as @Transient are destroyed when the invocation completes,"
In addition to that we change the definition of observer methods 10.4.1:
OLD:
"In addition to the event parameter, observer methods may declare additional
parameters, which may declare qualifiers. These additional parameters are injection
points."
NEW:
"In addition to the event parameter, observer methods may declare additional
parameters, which may declare qualifiers. These additional parameters are injection points
where @Transient is assumed for.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:51 a.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir reassigned CDI-228:
-----------------------------
Assignee: Pete Muir (was: Mark Struberg)
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:11 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg updated CDI-228:
------------------------------
Priority: Critical (was: Major)
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Priority: Critical
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:11 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-228:
-----------------------------------
folks, this is still not clarified but an important point for CDI-1.1
Are method parameters for producer methods now assumed 'Transient' or
'Keep' ?
The CDI-1.1 draft completely ignores this new 'Transient' stuff by now, thus all
our serialisation rules are a bit broken atm as well...
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:20 p.m.
[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-228:
-------------------------------
[~struberg] this was originally assigned (as discussed in the EG meeting) to you until 7th
Nov, however I saw no activity on it by you, so I assigned it over to me as I assumed you
weren't going to do it. I'll try to get to it this week or next.
Clarify that _all_ @Dependent beans created for a containers method
invocation will get destroyed after the method exits
------------------------------------------------------------------------------------------------------------------------
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Mark Struberg
Assignee: Pete Muir
Priority: Critical
Fix For: 1.1 (Proposed)
This clarification is intended for all methods which gets invoked by the CDI container
and create a new @Dependent contextual instance especially for this invocation. This can
happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject
contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most
containers store it in the CreationalContext of the bean containing the invoked method.
This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after
such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation,
even if the @Dependent instance will stored away in a member field and still being used
later. This will not make any problems in most cases. We just need to make people aware
that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our
'temporary' created @Dependent method parameter, those Interceptors and Decorators
will _not_ be available after the method invocation. Storing away this bean and re-using
it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are
quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize
it.
*) We might add an additional annotation which denotes either @Transactional or au
contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4168
days inactive
4375
days old
18 comments
5 participants
participants (5)
-
Arne Limburg (JIRA) -
Jozef Hartinger (JIRA)
-
Mark Struberg (JIRA)
-
Martin Kouba (JIRA)
-
Pete Muir (JIRA)