[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-228:
----------------------------------
Can someone please change the title of this ticket.
> 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.PFD
>
>
> 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
11 years, 10 months
[JBoss JIRA] (CDI-206) Conversation related exceptions cannot be handled
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-206:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
Assignee: Pete Muir
Please review https://github.com/jboss/cdi/pull/163
> Conversation related exceptions cannot be handled
> -------------------------------------------------
>
> Key: CDI-206
> URL: https://issues.jboss.org/browse/CDI-206
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Contexts
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> This issue emerged after adding support for conversations as part of CDI-80
> The spec says:
> {quote}The conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException.
> The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking
> or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException.
> {quote}
> The conversation association is supposed to be done before any servlet, filter or listener is invoked. If the association fails (due to NonexistentConversationException or BusyConversationException), the application has no way of handling this failure gracefully. The Servlet error-page mechanism cannot be used portably because it is only handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used exception handling mechanism - an outer filter that catches every uncaught exception, cannot be used since the association failure does not occur within the filter invocation.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-228:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
Please review https://github.com/jboss/cdi/pull/162
> 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.PFD
>
>
> 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
11 years, 10 months
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-228:
----------------------------------
What about @Independent to make a dependent bean independent ;)
> 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
11 years, 10 months
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-228:
-------------------------------
Proposal for annotation name is @DestroyedAfterBlock, which IMO is good enough to go ahead with.
> 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
11 years, 10 months
[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-304:
--------------------------
Assignee: Pete Muir
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
Please review https://github.com/jboss/cdi/pull/161.
I haven't made [~mkouba]'s proposed change, as I'm not sure about the side effects. Martin, maybe raise a new issue for this?
> Clarify Producers for injection into generic types
> --------------------------------------------------
>
> Key: CDI-304
> URL: https://issues.jboss.org/browse/CDI-304
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.1.PRD
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> There is a discussion over in DeltaSpike whether an injection point
> {code}
> @Inject
> private JsfMessage<SomeMessageClass>;
> {code}
> with a producer method
> {code}
> @Produces @Dependent
> JsfMessage createMessage(InjectionPoint ip)
> {code}
> 5.2 imo only defines the other way around. Having a raw type at the injection point and a parameterized producer method.
> We should define how this is intended to work.
> Please note that the producer above works in all existing containers so far but not in Weld2-beta1.
> Here is the link to the DS issue: https://issues.apache.org/jira/browse/DELTASPIKE-295
--
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
11 years, 10 months
[JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-291:
--------------------------
Description:
Currently the spec only says:
{quote}
A decorator is bound to a bean if:
* The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu-
tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points").
* The decorator is enabled in the bean archive containing the bean.
{quote}
AND
{quote}
An interceptor is bound to a method if:
* The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if
it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which
is not annotated @javax.enterprise.util.Nonbinding.
* The interceptor intercepts the given kind of lifecycle callback or business method.
* The interceptor is enabled in the bean archive containing the bean.
{quote}
What remains unspecified is:
* In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application.
* Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery.
was:
Currently the spec only says:
{quote}
A decorator is bound to a bean if:
* The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu-
tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points").
* The decorator is enabled in the bean archive containing the bean.
{quote}
AND
{quote}
An interceptor is bound to a method if:
* The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if
it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which
is not annotated @javax.enterprise.util.Nonbinding.
* The interceptor intercepts the given kind of lifecycle callback or business method.
* The interceptor is enabled in the bean archive containing the bean.
{quote}
What remains unspecified is:
* In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from X. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application.
* Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery.
> Clarify interceptor/decorator resolution rules
> ----------------------------------------------
>
> Key: CDI-291
> URL: https://issues.jboss.org/browse/CDI-291
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> Currently the spec only says:
> {quote}
> A decorator is bound to a bean if:
> * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu-
> tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points").
> * The decorator is enabled in the bean archive containing the bean.
> {quote}
> AND
> {quote}
> An interceptor is bound to a method if:
> * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if
> it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which
> is not annotated @javax.enterprise.util.Nonbinding.
> * The interceptor intercepts the given kind of lifecycle callback or business method.
> * The interceptor is enabled in the bean archive containing the bean.
> {quote}
> What remains unspecified is:
> * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application.
> * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery.
--
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
11 years, 10 months
[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-304:
-------------------------------
Yes, I think we could allow that, but like you, I suspec there is a reason. Trying to remember ;-)
> Clarify Producers for injection into generic types
> --------------------------------------------------
>
> Key: CDI-304
> URL: https://issues.jboss.org/browse/CDI-304
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.1.PRD
> Reporter: Mark Struberg
> Fix For: 1.1 (Proposed)
>
>
> There is a discussion over in DeltaSpike whether an injection point
> {code}
> @Inject
> private JsfMessage<SomeMessageClass>;
> {code}
> with a producer method
> {code}
> @Produces @Dependent
> JsfMessage createMessage(InjectionPoint ip)
> {code}
> 5.2 imo only defines the other way around. Having a raw type at the injection point and a parameterized producer method.
> We should define how this is intended to work.
> Please note that the producer above works in all existing containers so far but not in Weld2-beta1.
> Here is the link to the DS issue: https://issues.apache.org/jira/browse/DELTASPIKE-295
--
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
11 years, 10 months
Fwd: [jsr345-experts] Interceptors spec 1.2 DRAFT2 is available for review
by Pete Muir
FYI, update to interceptors.
Begin forwarded message:
> From: Marina Vatkina <marina.vatkina(a)oracle.com>
> Subject: [jsr345-experts] Interceptors spec 1.2 DRAFT2 is available for review
> Date: 11 February 2013 20:19:44 GMT
> To: jsr345-experts(a)ejb-spec.java.net, users(a)interceptors-spec.java.net
>
> Experts,
>
> You can now review the 2nd draft of the Interceptors spec. This version incorporates most of the review comments and the AroundConstruct interceptor. The full list of changes is below (the change log at the end of the document is an accumulative list).
>
> The draft: http://java.net/projects/interceptors-spec/downloads/download/interceptor...
> The diff from draft1: http://java.net/projects/interceptors-spec/downloads/download/interceptor...
>
> Please review it (AroundConstruct) in particular ASAP.
>
> Pete, please forward it to the CDI EG.
>
> The list of changes as found in the revision history:
>
> - Fixed page numbers in the book
> - Minor editorial changes
> - Moved Section 5.6 to the end of Chapter 5
> - Moved rule on invocation order of interceptors with superclasses to Section 5.3
> - Replaced rules on the Nonbinding annotation with references to the CDI spec
> - Clarified that an around-invoke interceptor method, around-timeout interceptor method, and lifecycle callback interceptor methods for different lifecycle events may be defined on the same interceptor class
> - Added the AroundConstruct lifecycle callback interceptor
> - Extended InvocationContext with getConstructor method; adjusted rules on the InvocationContext.getTarget return value, and InvocationContext.proceed result
> - Added notes to the around-invoke and around-timeout about the throw Exception clause in their signatures
> - Added a not that transaction context of interceptors may be changed by transactional interceptors in the invocation chain
> - Explained how interceptors are enabled
>
> Happy reading,
> -marina
>
11 years, 10 months
[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-304:
----------------------------------
Mark, I don't follow your comment. What do you mean with "ambiguous situations"? If you have multiple producer methods "which map to different generic types of the same base type" each PM has a different bean type (e.g. Foo<String> and Foo<Integer>), or not?
I also found this sentence in 3.3 Producer methods:
"If a producer method return type contains a wildcard type parameter the container automatically detects the problem and treats it as a definition error."
This seems a little bit inconsistent to me. We would allow raw return type and disallow type with wildcard... but there is probably some reason I don't see.
> Clarify Producers for injection into generic types
> --------------------------------------------------
>
> Key: CDI-304
> URL: https://issues.jboss.org/browse/CDI-304
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.1.PRD
> Reporter: Mark Struberg
> Fix For: 1.1 (Proposed)
>
>
> There is a discussion over in DeltaSpike whether an injection point
> {code}
> @Inject
> private JsfMessage<SomeMessageClass>;
> {code}
> with a producer method
> {code}
> @Produces @Dependent
> JsfMessage createMessage(InjectionPoint ip)
> {code}
> 5.2 imo only defines the other way around. Having a raw type at the injection point and a parameterized producer method.
> We should define how this is intended to work.
> Please note that the producer above works in all existing containers so far but not in Weld2-beta1.
> Here is the link to the DS issue: https://issues.apache.org/jira/browse/DELTASPIKE-295
--
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
11 years, 10 months