CDI 2.0 Alpha 5 hit Maven cetral
by Antoine Sabot-Durand
Hi all,
A new alpha version of CDI 2.0 API was released on is now available on
Maven Central, to help Weld and TCK team to work on their project.
It's also a convenient way to experiment our new API.
Check:
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>2.0.Alpha5</version>
</dependency>
Antoine
7 years, 5 months
[JBoss JIRA] (CDI-649) Typo in specification document - 2.0-EDR2
by Nico Schlebusch (JIRA)
Nico Schlebusch created CDI-649:
-----------------------------------
Summary: 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-497) session scope doesn't follow session lifecycle
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-497:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.0 .Final)
> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
> Key: CDI-497
> URL: https://issues.jboss.org/browse/CDI-497
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
> Fix For: 2.1 (Discussion)
>
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-633) Introduce BeanManager.event()
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-633:
------------------------------------------
[~tzwoenn] I reopened CDI-516 and targeted to be discussed during CDI 2.1.
This ticket is only a mean to get a more standard and typesafe way to fire event from the BeanManager.
> Introduce BeanManager.event()
> -----------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-516:
-------------------------------------
Release Notes Text: (was: Should be resolved with CDI-633)
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antonin Stefanutti
> Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-516:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antonin Stefanutti
> Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reopened CDI-516:
--------------------------------------
Not a duplicate of CDI-633. It's a request to enhance event API by supporting parameterized type resolution at runtime.
> Firing events with dynamic parameterized types
> ----------------------------------------------
>
> Key: CDI-516
> URL: https://issues.jboss.org/browse/CDI-516
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antonin Stefanutti
> Fix For: 2.1 (Discussion)
>
>
> For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]:
> {quote}
> If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.
> If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]:
> {quote}
> If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown.
> {quote}
> While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.:
> {code}
> @Inject
> Event<Object> event;
> event.select(new TypeLiteral<String>() {});
> {code}
> It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}.
> Yet, there are use cases where that need is valid, for example:
> {code}
> <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception {
> // Represents the runtime type for T
> Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0];
> String uri = endpointUri(type, ip.getQualifiers());
> if (context.hasEndpoint(uri) == null) {
> // Work around to pass the dynamic type
> TypeLiteral<T> literal = new TypeLiteral<T>() {};
> for (Field field : TypeLiteral.class.getDeclaredFields()) {
> if (field.getType().equals(Type.class)) {
> field.setAccessible(true);
> field.set(literal, type);
> break;
> }
> }
> // Here we used the dynamic type
> Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()]));
> context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context));
> }
> return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class);
> }
> {code}
> In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument.
> Another alternative would be to enrich the {{BeanManager}} SPI with the following method:
> {code}
> public void fireEvent(Object event, Type type, Annotation... qualifiers);
> {code}
> That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (CDI-633) Introduce BeanManager.event()
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-633:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Introduce BeanManager.event()
> -----------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
