July 2015 - cdi-dev - Jboss List Archives

Let's Sept 25th -26th for our F2F meeting

by Antoine Sabot-Durand

Hi all, So the vote closed on modally. We should have talk about the final date in the last meeting, but there was too much on our plate ;). We have a tie between 18th and 25th, but as John can make it for the 25th and he’s probably the farthest one from Paris to come I propose to keep this date. Regards, Antoine

9 years, 5 months

4
4
0 / 0

Inconsistency in the spec regarding remote EJBs

by Antoine Sabot-Durand

Hi guys, Bill Shanon, just pointed me to this test in TCK: https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss... <https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss...> It tests the following assertion: "If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.” The EJB containing the observers for the test is: https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss... <https://github.com/cdi-spec/cdi-tck/blob/1.2/impl/src/main/java/org/jboss...> The EJB contains one business method coming from a local interface, one from a remote and one static method. the 3 are observers methods The test expects that the remote business observer method should be called. Here we have an inconsistency IMO. By doing this we are violating rules the CDI spec regarding the fact that remote EJBs are not CDI beans. And we are calling this remote business method passing the event payload by reference and not by value which violates EJB specification regarding remote EJB. I suggest that we change the assertion to: If the bean is a session bean, the observer method must be either a local business method of the EJB or a static method of the bean class. and the TCK accordingly. Any thought ? Antoine

9 years, 5 months

6
10
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-548: ----------------------------------- Summary: FireAsyncException conflicting with CompletionStage definition Key: CDI-548 URL: https://issues.jboss.org/browse/CDI-548 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 2.0-EDR1 Reporter: Jozef Hartinger CompletionStage documentation says: {quote} if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. {quote} On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-547: ----------------------------------- Summary: Resolving sync/async observer methods Key: CDI-547 URL: https://issues.jboss.org/browse/CDI-547 Project: CDI Specification Issues Issue Type: Clarification Reporter: Jozef Hartinger There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] George Gastaldi commented on CDI-546: ------------------------------------- I think we do have a {{Prioritized}} interface for this, no? +1 to include it on that > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-546: ------------------------------------- This is a default value for observer methods. Interceptors do not have a default value. > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] George Gastaldi commented on CDI-546: ------------------------------------- Unless I misunderstood and you mean to create this constant in one of the CDI classes, then disregard my last comment > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] George Gastaldi commented on CDI-546: ------------------------------------- Although this is specified as a default for CDI 2.0, is it safe to assume that this value will be default for other specs that use the Interceptor annotation (eg. EJB)? Maybe we should involve the EJB spec team in this? > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-546: ----------------------------------- Summary: Constant for default observer priority Key: CDI-546 URL: https://issues.jboss.org/browse/CDI-546 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Jozef Hartinger Priority: Minor Currently we use: {code:JAVA} @Override public default int getPriority() { return javax.interceptor.Interceptor.Priority.APPLICATION + 500; }; {code} It would be nice to have the value stored as a constant e.g.: {code:JAVA} int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; {code} so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

Tomorrow's meeting agenda

by Antoine Sabot-Durand

Hi all, I propose the following agenda for tomorrow: 1) Launch AOP workshop: - AOP support on custom beans - AOP support on producers - Self Injection or AOP activated when method called from inside beans - Decorators without Interface 2) Finishing SE part - Context control in SE (CDI 530) - Bean Discovery in SE (CDI 529) 3) CDI-129 (bean visibility) if we have time Hope to see you online tomorrow Antoine

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2015