[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
11 years, 6 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 resolved CDI-247.
---------------------------
Resolution: Done
Merged
> 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, 6 months
@Priority, application enablement spec changes
by Pete Muir
Hi guys,
I've attached a build of the spec with these changes done:
* switching to use @Priroity for application wide enablement of interceptors, decorators and alternatives (CDI-18)
* adding a bean defining annotation, which removes the need to use beans.xml (CDI-321)
* added a new lifecycle event, AfterTypeDiscovery (CDI-3)
The changes are at https://github.com/jboss/cdi/pull/166 for those who prefer a diff. Please take a look at the issues for the details of the changes.
Pete
11 years, 6 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
I've updated this quite substantially to account for @Priority:
* I've removed all the stuff I moved to the interceptors spec, and updated the CDI spec to just cover any extensions it makes
* I've totally removed the xml definition of priorities, and returned XML enablement to how it worked in 1.0. This means we keep the 1.0 mechanism intact for backwards compat
* I've added global enablement using @Priority for decorators, based on the definition in the interceptors spec, and reusing priority ranges from there.
* I've added global enablement using @Priority for alternatives, based on the simple principle that the highest priority wins, as we had it before
* I've allowed @Priority to be altered during PAT
* CDI-3 allows an absolute order of interceptors, decorators and alternatives to be set in the AfterTypeDiscovery event
I know many were hoping to be able to override @Priority using xml, however I decided not to do this in the end:
(a) it keeps the XML definition clean for the 1.0 backwards compat. I tried to merge the two last time, and it ended up being tough to spec, and tough to understand, as Mark mentioned ;-)
(b) it's in keeping with the spirit of CDI to keep the XML config to an absolute minimum, especially if you can achieve the same via the portable extension SPI. As we've added that, it would be easy for an extension to implement XML ordering for any of these things, either by setting priorities, or doing a total order, or any other scheme it liked.
(c) it's less controversial, and leaves the way open for future changes if we decide they are necessary.
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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, 6 months
[JBoss JIRA] (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-3:
-----------------------------
I've:
* added AfterTypeDiscovery
* added getInterceptors(), getDecorators() and getAlternatives from ProcessModule to this new event
* added addAnnotatedType() to this event
* removed ProcessModule
Pull request is https://github.com/jboss/cdi/pull/166
> Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
> ------------------------------------------------------------------------------------------------------------
>
> Key: CDI-3
> URL: https://issues.jboss.org/browse/CDI-3
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes.
> Some of the things that the bean interface will not let you mimic are:
> - Interceptors
> - Disposal methods
> - Producer fields for normal scoped beans
--
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, 6 months
[JBoss JIRA] (CDI-321) Application wide CDI enablement
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-321?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-321:
-------------------------------
I've spec'd this out almost exactly as discussed above. The only major change is that I've added that a container must provide a way to completely disable archives which have no beans.xml, in to provide exactly the CDI 1.0 behavior. This is language proposed by Bill Shannon, and can be implemented in anyway the vendor wants (e.g. -D, xml config, property file).
I think my changes make chapter 12 much easier to understand as well.
Pull is https://github.com/jboss/cdi/pull/166
> Application wide CDI enablement
> -------------------------------
>
> Key: CDI-321
> URL: https://issues.jboss.org/browse/CDI-321
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
> This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
> * A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
> * This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
> Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
> Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
> Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
> If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
> OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
> OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
> OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
> OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?
--
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, 6 months
[JBoss JIRA] (CDI-321) Application wide CDI enablement
by Joe Bergmark (JIRA)
[ https://issues.jboss.org/browse/CDI-321?page=com.atlassian.jira.plugin.sy... ]
Joe Bergmark commented on CDI-321:
----------------------------------
I like auto-discovery defaulting to false, and keeping backwards compatibility for empty "marker file" beans.xml files!
> Application wide CDI enablement
> -------------------------------
>
> Key: CDI-321
> URL: https://issues.jboss.org/browse/CDI-321
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
> This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
> * A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
> * This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
> Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
> Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
> Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
> If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
> OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
> OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
> OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
> OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?
--
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, 6 months
[JBoss JIRA] (CDI-321) Application wide CDI enablement
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-321?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-321:
-------------------------------
In email, the EG agreed that:
# Auto-discover is false by default in CDI 1.1 and the attribute is required. In detail:
## We would add a standard version="" attribute to the root element similar to other java EE descriptors
## When version is set to "1.1" (or later), the deployer or deployment tool would enforce the specification of "bean-discovery-mode (annotated, all, none)" (likely a better name would be chosen).
## The 1.1 xml schema would also require specification of bean-discovery-mode
## Absence of the version attribute in the descriptor, or a value set to 1.0 would assume bean-discovery-mode="all", and not require specification
# Yes
# Yes we should
# Yes.
# Package level scanning control won't make it in CDI 1.1, this proposal makes it less relevant.
> Application wide CDI enablement
> -------------------------------
>
> Key: CDI-321
> URL: https://issues.jboss.org/browse/CDI-321
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
> This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
> * A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
> * This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
> Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
> Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
> Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
> If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
> OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
> OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
> OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
> OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?
--
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, 6 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg edited comment on CDI-271 at 2/22/13 8:54 AM:
-----------------------------------------------------------
~meetoblivion No, getAnnotated() and getMember() have completely different semantics. Both represent the target of the injection. The BeanManager is the source...
was (Author: arnelim):
No, getAnnotated() and getMember() have completely different semantics. Both represent the target of the injection. The BeanManager is the source...
> 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
> Assignee: 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, 6 months
