[JBoss JIRA] (CDI-369) check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-369?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-369:
-----------------------------
Fix Version/s: 2.1 (Discussion)
> check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
> --------------------------------------------------------------------------
>
> Key: CDI-369
> URL: https://issues.jboss.org/browse/CDI-369
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.0
> Reporter: Gerhard Petracek
> Fix For: 2.1 (Discussion)
>
>
> as discussed with pete this ticket is based on https://issues.apache.org/jira/browse/OWB-798
> the check needed to pass org.jboss.jsr299.tck.tests.event.bindingTypes.EventBindingTypesTest#testFireEventWithNonRuntimeBindingTypeFails is slow and even more important too late.
> we can do the same check (once) during bootstrapping before adding an observer.
> reason why we don't need this check after bootstrapping:
> if an invalid event (with an invalid qualifier) is used in a dyn. #fire, we can ignore the invalid literal-instance, because there is no corresponding observer (qualifiers of the observers would be checked during bootstrapping -> the startup would fail, if there is such an invalid observer).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (CDI-699) AnnotationLiteral should use privileged actions for reflective operations
by Martin Kouba (JIRA)
Martin Kouba created CDI-699:
--------------------------------
Summary: AnnotationLiteral should use privileged actions for reflective operations
Key: CDI-699
URL: https://issues.jboss.org/browse/CDI-699
Project: CDI Specification Issues
Issue Type: Bug
Components: Javadoc and API
Reporter: Martin Kouba
Fix For: 2.1 (Discussion)
Currently, if an application declares its own literal which extends {{AnnotationLiteral}} and is run with {{SecurityManager}} enabled, some methods might lead to {{SecurityException}} (e.g. {{AnnotationLiteral.getMembers()}} called in constructor requires {{accessDeclaredMembers}} permission). The only possible fix seems to be to grant the permission to the deployment/application which is not very convenient. If privileged actions were used, the app server could grant the permissions to the provided CDI API module only.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
Question on BeanManager#createInstance()
by Laird Nelson
Hello; BeanManager#createInstance() says (in part):
"Instances of dependent scoped beans obtained with this Instance must be
explicitly destroyed by calling Instance.destroy(Object)."
>From the standpoint of the caller of, say, instance.select(MyBean.class),
how is that caller supposed to know whether MyBean is in dependent scope or
not? Is it anticipated that they will call BeanManager#getBeans() and
investigate the Bean objects? Should Instance have a getScope() method on
it, or the like?
Thanks,
Best,
Laird
7 years, 1 month
Bean discovery question
by Laird Nelson
I have a portable extension not annotated in any way. It has a nested
class inside it named Producers. That class is annotated with @Singleton
(and nothing else). It has producer methods in it. They are being
discovered while a bean discovery mode of "annotated" is in effect. Is
this correct?
(CDI 2.0-PRD.)
Best,
Laird
7 years, 1 month
[JBoss JIRA] (CDI-698) Ordering of Async Events
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-698:
----------------------------------
In Weld 3.0.0.CR2 when an event is fired asynchronously all observer methods are scheduled to be notified synchronously in a separate thread, ie. at most one thread is used for a specific notification. Also ordering should work there.
If we decide to standardize this we should use {{javax.enterprise.event.NotificationOptions}} which was designed exactly for this kind of configuration.
> Ordering of Async Events
> ------------------------
>
> Key: CDI-698
> URL: https://issues.jboss.org/browse/CDI-698
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 2.0 .Final
> Reporter: John Ament
>
> Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (CDI-698) Ordering of Async Events
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny edited comment on CDI-698 at 3/22/17 3:54 AM:
------------------------------------------------------------
Hmm, my two cents:
* If you _feel_ you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that.
* Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration.
* Last but not least I think this ruins the idea of async which is "fire and forget".
was (Author: manovotn):
Hmm, my two cents:
* If you *feel* you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that.
* Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration.
* Last but not least I think this ruins the idea of async which is "fire and forget".
> Ordering of Async Events
> ------------------------
>
> Key: CDI-698
> URL: https://issues.jboss.org/browse/CDI-698
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 2.0 .Final
> Reporter: John Ament
>
> Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (CDI-698) Ordering of Async Events
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-698?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-698:
-----------------------------------
Hmm, my two cents:
* If you *feel* you are blocked waiting for the result of async observer (e.g. want to make sure certain observer goes first), then it would, perhaps, be better to use a sync event/observer for that.
* Also, we allow to provide custom executors - I cannot really see how we make sure those exectutors take this into consideration.
* Last but not least I think this ruins the idea of async which is "fire and forget".
> Ordering of Async Events
> ------------------------
>
> Key: CDI-698
> URL: https://issues.jboss.org/browse/CDI-698
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 2.0 .Final
> Reporter: John Ament
>
> Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (CDI-698) Ordering of Async Events
by John Ament (JIRA)
John Ament created CDI-698:
------------------------------
Summary: Ordering of Async Events
Key: CDI-698
URL: https://issues.jboss.org/browse/CDI-698
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 2.0 .Final
Reporter: John Ament
Async Events don't presently support ordering. When the number of observers grows, and is larger than the number of available threads, I may wan to have events follow a certain order, to ensure my more important observers are seen first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
