[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-271:
--------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1.PFD
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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, 3 months
[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-44:
-------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
> Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
> -------------------------------------------------------------------------------------------------------------
>
> Key: CDI-44
> URL: https://issues.jboss.org/browse/CDI-44
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not.
> When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification.
--
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, 3 months
[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-279:
--------------------------
Fix Version/s: TBD
(was: 1.1.PFD)
> Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-279
> URL: https://issues.jboss.org/browse/CDI-279
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Hong Zhang
> Assignee: Pete Muir
> Fix For: TBD
>
>
> Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform.
> Also attaching the relevant sections from Bill's @Stereotype proposal below:
> ================================================
> Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI.
> Many existing implementations would need to be changed to understand
> how to expand stereotypes. Requiring every technology to do this
> itself will almost certainly lead to inconsistencies. Since stereotypes
> are a CDI feature, CDI will provide a simple replacement for the
> java.lang.reflect methods such as getAnnotations that takes into
> account stereotypes.
> Some technologies will not want to have a hard dependency on CDI so
> we'll need to provide a simple way for them to conditionally invoke
> these new methods only if CDI is present, falling back to java.lang.reflect
> if not. This seems straightforward. In this case, the functionality of
> @Stereotype would not be available to applications that chose to run
> without CDI.
> ===============================
--
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, 3 months
[JBoss JIRA] (CDI-247) It's currently not possible to implement a primitive and wrapping type producer method for the same type
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-247?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-247:
-------------------------------
Please review https://github.com/jboss/cdi/pull/165 which makes the changes discussed here.
> It's currently not possible to implement a primitive and wrapping type producer method for the same type
> --------------------------------------------------------------------------------------------------------
>
> Key: CDI-247
> URL: https://issues.jboss.org/browse/CDI-247
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> I like to implement a producer which can satisfy the following injection points:
> {code}
> private @Inject @IsFeatureA Boolean featureA;
> private @Inject @IsFeatureA boolean featureA;
> {code}
> Boolean (wrapper type) and boolean (primitive type) used at the same time.
> This is currently not allowed by the CDI spec!
> 5.2.4. "Primitive types and null values" defines that
> "For the purposes of typesafe resolution and dependency injection, primitive types and their corresponding wrapper types in the package java.lang are considered identical and assignable."
> In the same paragraph it also states that
> "However, if an injection point of primitive type resolves to a bean that may have null values, such as a producer method with a non-primitive return type or a producer field with a non-primitive type, the container automatically detects the prob- lem and treats it as a deployment problem."
> This means that I can only have producer methods and fields which have primitive return values and never use their wrapper types if I like to inject into both boolean and Boolean fields.
> But if I use the primitive type, then I loose the ability to explicitly return null for those.
> Possible solution:
> As primitives and their wrapper only can be @Dependent, it would be perfectly possible to e.g. inspect the InjectionPoint and on a primitive type return a default value and for a wrapper type return null.
--
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, 3 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:
-------------------------------
[~arnelim] yeah, agreed, I was mislead by Mark's previous comment :-)
I'll reword and redo the annotation name to cover your case, which is very valid - it's more like "the container should release the reference after invocation, which if dependent, will cause it to be destroyed".
@Independent is a wild goose chase, it's confusing as it ties this too strongly to the dependent scope (which arne correctly points out is not right).
> 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, 3 months
[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:
-----------------------------------
+1 for @Independent. We also should look at how this might be used for Instance<T>. In that case @Independent also would make quite some 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
11 years, 3 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:
----------------------------------
Personally I think that @DestroyedAfterBlock is not readable and most time misleading.
Most time this feature is needed, is to circumvent the passivation capable check, that means to mark a parameter just being used to create the result of the method and not held by the result.
I.e. I had the case where I wanted to produce a passivation capable bean created from some request parameters. So I injected the FacesContext (which is not serializable). This wasn't possible due to the passivation-capable restriction. With CDI 1.1 I would annotate that parameter. But the annotation @DestroyedAfterBlock is misleading here, because I don't want the FacesContext to be destroyed after the call to the producer method (and in fact it will not, because I don't have a disposer method in my FacesContextProducer).
This code really looks wrong:
{code}
@Produces
public String getRequestParameterValue(@DestroyedAfterBlock FacesContext facesContext) {
return facesContext.getExternalContext().getRequestParameterMap().get("myName");
}
{code}
> 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, 3 months