[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-527:
----------------------------------------
Assignee: Mark Struberg
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-527:
-------------------------------------
Fix Version/s: 2.0 (proposed)
(was: 2.0 (discussion))
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-563:
----------------------------------
bq. Perhaps we could find a way to have a clearer phrase pointing to this assertion.
+1
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-543) Handling exception during async event - contradiction?
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-543?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-543:
-------------------------------------
Fix Version/s: 2.0-EDR2
> Handling exception during async event - contradiction?
> ------------------------------------------------------
>
> Key: CDI-543
> URL: https://issues.jboss.org/browse/CDI-543
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Fix For: 2.0-EDR2
>
>
> In {{10.5. Observer notification}} there is (wrt sync observer method):
> {quote}
> Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called
> {quote}
> This looks like contradiction to {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}} where is:
> {quote}
> If an event is asynchronous, and an exception is thrown by any of its notified observers, the CompletionStage returned by fireAsync will complete exceptionally ..
> {quote}
> The question is following: Async Event is fired -> some sync observers are notified -> one of them throws exception -> async observers will be notified or not?
> I assume they should be notified and therefore {{10.5. Observer notification}} needs an update.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-563:
------------------------------------------
{quote}bq. What do you think we should add?
I don't like the wording "called in a new lifecycle contexts". What exactly does it mean? Maybe we should just rephrase this.{quote}
I'm not a big fan of this wording either. But it came from discussion with Jozef, and the fact that for the sake of non-denormalize the spec we shouldn't repeat what is said in [6.7|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#builtin_contexts]:
bq. The context associated with a built-in normal scope propagates across local, synchronous Java method calls. The context does not propagate across remote method invocations or to asynchronous processes.
Perhaps we could find a way to have a clearer phrase pointing to this assertion. It lets the possibility for a third party to create a normal scope supporting propagation.
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-563:
----------------------------------
bq. My favorite option as well . I'm just not sure where to add it in the chapter
I would add a new paragraph in 10.2.3. The Event interface... something like "The fireAsync() methods return a CompletionStage whose default asynchronous execution facility is specific to the container implementation."
bq. What do you think we should add?
I don't like the wording "called in a new lifecycle contexts". What exactly does it mean? Maybe we should just rephrase this.
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-563:
------------------------------------------
{quote}bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.{quote}
I'm not sure, but I think we should, since it's the only way to access the {{get()}} method to allow user to wait for the outcome...
{quote}
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.
{quote}
+1
{quote}I'm for:
* having {{CompletionStage}} in the CDI API{quote}
Yes we also agree here.
{quote}* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
{quote}
My favorite option as well ;). I'm just not sure where to add it in the chapter
{quote}* declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor)
{quote}
Regarding propagation, I thought that the mention in [10.5.3. Observer method invocation context|http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#observer_me...], was explicit enough:
bq. If the observer method is asynchronous, it is called in a new lifecycle contexts, a new transaction context but the same security context as the invocation of Event.fireAsync().
What do you think we should add?
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
Adding Lambdas as CDI beans
by David Blevins
In brainstorming mode about fun that could be made possible with Java 8 and Java EE.
Question in my mind is: is there some way we could make it possible for Lambdas or Method Refs to be CDI beans?
It goes against the grain obviously as CDI creation is very much a “Don’t call us, we’ll call you” kind of thing. The VM dynamically creates a wrapper object around the Lambda or method reference and it implements the given interface.
To make it work, there would need to be some non-producer method way of saying “put this thing in the context with these qualifiers”.
Imagine a method somewhere that would allow you to:
public <T> void addObserver(java.util.function.Consumer<T> observer, Annotation... qualifiers);
Then you could take advantage as follows:
final List<URI> uris = new ArrayList<>();
// @Observes URI
addObserver((Consumer<URI>) uris::add);
// @Observes Thread
addObserver(Runtime.getRuntime()::addShutdownHook);
// @Observes Runnable
addObserver((Consumer<Runnable>) Executors.newFixedThreadPool(3)::submit);
// @Observes URI
addObserver((Consumer<URI>) System.out::println, new AnnotationLiteral<Fine>() {
});
// @Observes Handler
final Logger logger = Logger.getLogger("somewhere");
addObserver(logger::addHandler); // add handlers via event
// @Observes @Fine String
addObserver((Consumer<String>) logger::fine, new AnnotationLiteral<Fine>() {});
}
-David
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-563 at 10/19/15 11:09 AM:
-------------------------------------------------------------
bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.
bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor...
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.
I'm for:
* having {{CompletionStage}} in the CDI API
* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
* declaring explicitly that *the context propagation is not guaranteed for ANY execution* (default execution, default async execution and custom async via a supplied Executor)
What do you think?
was (Author: mkouba):
bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.
bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor...
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.
I'm for:
* having {{CompletionStage}} in the CDI API
* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
* declaring explicitly that *the context propagation is not guaranteed for asynchronous execution* (both the default and custom executor)
What do you think?
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-563:
----------------------------------
bq. I'm not sure to follow him there, especially when CompletionStage has a dependency on CompletableFuture with the toCompletableFuture() method
It's kind of a strange dependency, intended probably as a compatibility/interoperation feature. However, implementations are not required to support this conversion.
bq. Martin Kouba, you're probably the best person to know if this default Executor is the best for us or if we should use our own Executor...
I don't think {{ForkJoinPool.commonPool()}} is a good fit for Java EE. But it's ok for Java SE.
I'm for:
* having {{CompletionStage}} in the CDI API
* declaring explicitly that *the stage's default asynchronous execution facility is not defined*, in other words it is implementor and environment specific
* declaring explicitly that *the context propagation is not guaranteed for asynchronous execution* (both the default and custom executor)
What do you think?
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months