[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes reopened CDI-420:
-----------------------------
This has been marked as resolved, but I can't see anything about {{trim}} in beans_2_0.xsd.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-650:
----------------------------------
A user could either use convenient static methods - default immutable implementation (see also NotificationOptionsTest in the PR) or a custom implementation (e.g. container-specific).
> Introduce asynchronous event notification options
> -------------------------------------------------
>
> Key: CDI-650
> URL: https://issues.jboss.org/browse/CDI-650
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
> Executor getExecutor();
> // Implementation-specific options
> Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g.
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
> event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-495 started by Antoine Sabot-Durand.
------------------------------------------------
> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
> Key: CDI-495
> URL: https://issues.jboss.org/browse/CDI-495
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-650?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-650:
------------------------------------------
+1 for the idea.
How user would access to an implementation of this {{NotificationOption}} class?
> Introduce asynchronous event notification options
> -------------------------------------------------
>
> Key: CDI-650
> URL: https://issues.jboss.org/browse/CDI-650
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 2.0 .Final
>
>
> Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
> Therefore, I suggest to introduce {{NotificationOptions}} interface:
> {code:java}
> public interface NotificationOptions {
> Executor getExecutor();
> // Implementation-specific options
> Object get(String optionName);
> }
> {code}
> and change the method signature to:
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event, NotificationOptions options);
> {code}
> In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g.
> {code:java}
> Duration getTimeout();
> {code}
> instead of adding more and more params to {{Event.fireAsync()}}.
> We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
> {code:java}
> void fireEvents(Event event, Executor executor) {
> event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-649) Typo in specification document - 2.0-EDR2
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-649?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-649.
--------------------------------------
Resolution: Out of Date
Already corrected in previous typo review.
> Typo in specification document - 2.0-EDR2
> -----------------------------------------
>
> Key: CDI-649
> URL: https://issues.jboss.org/browse/CDI-649
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 2.0-EDR2
> Environment: Documentation - https://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html
> Reporter: Nico Schlebusch
>
> The is a typo in the "*Preface*" of the CDI 2 EDR2 spec.
> In the "*Mayor Problems*" section, first bullet point:
> {noformat}
> The spec was split in 3 parts as desibed in Organisation of this document to add the support for Java SE.
> {noformat}
> The typo is in the word *desibed* which should be *described*:
> {noformat}
> The spec was split in 3 parts as described in Organisation of this document to add the support for Java SE.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-650) Introduce asynchronous event notification options
by Martin Kouba (JIRA)
Martin Kouba created CDI-650:
--------------------------------
Summary: Introduce asynchronous event notification options
Key: CDI-650
URL: https://issues.jboss.org/browse/CDI-650
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Martin Kouba
Assignee: Martin Kouba
Fix For: 2.0 .Final
Currently, it's only possible to provide a custom executor when firing an event asynchronously - see also {{javax.enterprise.event.Event.fireAsync(U, Executor)}}. It might be useful to provide other implementation-specific options, e.g. notification timeout.
Therefore, I suggest to introduce {{NotificationOptions}} interface:
{code:java}
public interface NotificationOptions {
Executor getExecutor();
// Implementation-specific options
Object get(String optionName);
}
{code}
and change the method signature to:
{code:java}
<U extends T> CompletionStage<U> fireAsync(U event, NotificationOptions options);
{code}
In the future, if any implementation-specific configuration proves to be useful and worth standardizing, we may simply add a new method to {{NotificationOptions}}, e.g.
{code:java}
Duration getTimeout();
{code}
instead of adding more and more params to {{Event.fireAsync()}}.
We could also introduce some convenient static methods on {{NotificationOptions}}, e.g.:
{code:java}
void fireEvents(Event event, Executor executor) {
event.fireAsync(new Foo(), NotificationOptions.ofExecutor(executor));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-495:
----------------------------------------
Assignee: Antoine Sabot-Durand
> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
> Key: CDI-495
> URL: https://issues.jboss.org/browse/CDI-495
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-639) Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-639?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-639:
------------------------------------------
+1 to remove it.
I can find a use case since IPC is used to change configuration of existing IP. Changing the bean of an existing IP doesn't make sense.
> Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
> -----------------------------------------------------------------------
>
> Key: CDI-639
> URL: https://issues.jboss.org/browse/CDI-639
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Dear EG,
> I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method.
> I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl.
> Maybe I would remove this method from the {{InjectionPointConfigurator}} interface.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
CDI-471 and repeatable annotations
by Martin Kouba
Dear EG,
during the review of CDI API 2.0.Alpha5 with modified Annotated SPI [1]
I came across few questionable parts:
1. We should be more clear that the original methods like
Annotated.getAnnotations() or Annotated.isAnnotationPresent() DO NOT
support repeatable annotations - this is what Reflection API does to
remain backward compatible - see also AnnotatedElement javadoc [2]
2. Thus AnnotatedElement.getAnnotation(Class<T>) should not be
deprecated - for the same reasons as
AnnotatedElement.getAnnotation(Class<T>) is not
3. We should provide a default implementation of
Annotated.getAnnotations(Class<T>), otherwise a lot of extensions
providing their own Annotated implementations would be broken
4. We should consider renaming the method to "getAnnotationsByType()" to
keep it simple for users used to Reflection API
Thanks,
Martin
[1]
https://github.com/cdi-spec/cdi/pull/330
[2]
https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/AnnotatedElem...
7 years, 5 months
Need native speaker for CDI-420 (trim) reword
by Antoine Sabot-Durand
Hi all,
With Martin, we reword the <trim/> section like:
"If an explicit bean archive contains the `<trim/>` element in its
`beans.xml` file, types that don't have either a bean defining annotation
(as defined in <<bean_defining_annotations>>) or any scope annotation, are
removed from the set of discovered types."
Grammar feedback from native speaker is most welcome.
Antoine
7 years, 5 months
