[JBoss JIRA] (CDI-84) Non EE modules should be able to inject/lookup in JNDI a BeanManager
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-84:
-------------------------
Fix Version/s: TBD
(was: 1.1.PFD)
Deferring
> Non EE modules should be able to inject/lookup in JNDI a BeanManager
> --------------------------------------------------------------------
>
> Key: CDI-84
> URL: https://issues.jboss.org/browse/CDI-84
> Project: CDI Specification Issues
> Issue Type: Tracker
> Components: Java EE integration, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Labels: visibility
> Fix For: TBD
>
>
> EE.5.19
> A bean manager is only available in modules in which CDI has been enabled.
> Where EE modules are defined to be; ejb-jar, rar, client jar and war.
> This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation.
> Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop.
--
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
12 years
PFD submission
by Pete Muir
All,
We need to submit the PFD on Wednesday next week.
Please review the attached copy of the spec, it contains the current spec, with the proposed changes I sent out earlier, along with excludes in XML.
There isn't much more to add now, just a few bits of tidying up, which I'lll aim to do on Monday.
Please get any issues to me asap.
Pete
12 years
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-228:
-----------------------------------
Good point, I think it would make a lot of sense.
> 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
12 years
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-228:
-------------------------------------
Would it make sense to expose the fact that @DestroyedAfterBlock is present (or whatever the annotation name is) through the InjectionPoint interface?
> 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
12 years
[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger edited comment on CDI-304 at 2/23/13 2:29 AM:
--------------------------------------------------------------
5.2.4. "Assignability of raw and parameterized types" now says
{quote}A raw bean type is considered assignable to a parameterized required type if the raw types are identical.{quote}
8.3.1. "Assignability of raw and parameterized types for delegate injection points" says:
{quote}A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical *and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.*{quote}
Wouldn't it make sense to make these two assertions coherent?
Note that the fact that the spec mentions this specifically in 8.3.1 indicates that the current wording of 5.2.4 (changed as a result of this issue) had not been originally intended in CDI 1.0!
was (Author: jharting):
5.2.4. "Assignability of raw and parameterized types" now says
{quote}A raw bean type is considered assignable to a parameterized required type if the raw types are identical.{quote}
8.3.1. "Assignability of raw and parameterized types for delegate injection points" says:
{quote}A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical *and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.*{quote}
Wouldn't it make sense to make these two assertions coherent?
Note that the fact that the spec mentions this specifically in 8.3.1 indicates that the change added recently to 5.2.4 had not been originally intended!
> 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
12 years
[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-304:
---------------------------------
5.2.4. "Assignability of raw and parameterized types" now says
{quote}A raw bean type is considered assignable to a parameterized required type if the raw types are identical.{quote}
8.3.1. "Assignability of raw and parameterized types for delegate injection points" says:
{quote}A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical *and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.*{quote}
Wouldn't it make sense to make these two assertions coherent?
Note that the fact that the spec mentions this specifically in 8.3.1 indicates that the change added recently to 5.2.4 had not been originally intended!
> 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
12 years
[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 resolved CDI-206.
---------------------------
Resolution: Done
Merged
> 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
12 years
