[JBoss JIRA] (CDI-653) Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-653?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-653 started by Antoine Sabot-Durand.
------------------------------------------------
> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
> Key: CDI-653
> URL: https://issues.jboss.org/browse/CDI-653
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (CDI-653) Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-653?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-653:
-------------------------------------
Fix Version/s: 2.0 .Final
(was: 2.1 (Discussion))
> Introduce BeanManager#getInstances() to ease instance resolution in custom SPI
> ------------------------------------------------------------------------------
>
> Key: CDI-653
> URL: https://issues.jboss.org/browse/CDI-653
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Right now if you need a bean instance in one of your extension or custom SPI (i.e. instance of Bean A is needed to create Bean B) you have to write something like
> {code:java}
> Set<Bean<?>> beanSet = beanManager.getBeans(MyClass.class);
> Bean<?> bean = beanManager.resolve(beanSet);
> MyClass instance = (MyClass) beanManager.getReference(bean, MyClass.class, beanManager.createCreationalContext(bean));
> {code}
> While it can be useful to get thru all this step of type safe resolution, a typical use case is: I need this contextual instance (or these contextual instances) to do conditional action according to its state.
> So providing a Bean Manager method returning an {{Instance<Object>}} could be a short cut that could help a lot of advanced developers:
> {code:java}
> beanManager.getInstances().select(MyClass.class).get();
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
Priority on PR
by Antoine Sabot-Durand
Hi all,
As you know, tomorrow is our feature freeze, beginning Thursday there
shouldn't be new PR open for CDI 2.0 unless they don't have impact on
implementation and TCK.
Yet we still have a bunch of PR to review and close. Martin has prioritised
them with label. So please try to focus your review and feedback on the
most urgent one to help the RI and TCK team.
Thanks,
Antoine
8 years, 1 month
CDI events in .ear packaged application
by sverker
Hi
I'm trying to solve an issue with CDI usage in Apache Camel where I was
suggested to use CDI Events to configure the context behavior. This works
fine in the testcases packaged as .jar or .war, but when I try to use it in
my application that is packaged as an .ear then it doesn't work. The event
is never received.
When I search on this issue it appears to be due to classloader boundary and
that CDI events won't be carried over them. I had a similar problem before
in the application which I solved by using a JMS topic instead but can't do
that now.
Anybody knows a way to make CDI events work in an .ear packaged application
deployed on Wildfly 10.1 application server?
Link to the ticket for Apache Camel:
https://issues.apache.org/jira/browse/CAMEL-10391
--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/CDI-events-in-e...
Sent from the CDI Development mailing list mailing list archive at Nabble.com.
8 years, 1 month
[JBoss JIRA] (CDI-655) Allow CDIProvider to specify the priority
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-655?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-655:
-----------------------------
Fix Version/s: 2.0 .Final
> Allow CDIProvider to specify the priority
> ------------------------------------------
>
> Key: CDI-655
> URL: https://issues.jboss.org/browse/CDI-655
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
Defining the order of event thru priority
by Antoine Sabot-Durand
Hi all,
In a recent discussion with Martin, I realized that the use of @Priotiy is
not consistent in CDI 1.2:
- For Interceptor and decorator the lowest value in @Priority is first (def
in interceptor spec and 8.2.1)
- For Alternatives the Highest value in @Priroty is first (def in 5.2.2)
Since we have these different interpretation of @Priority value in the spec
, we may find more consistent to change the definition of event ordering
with the @Priority annotation.
Right now we have:
"Observers with smaller priority values are called first"
We may find more intuitive to change it to:
"Observers with higher priority values are called first"
It will remove the oxymoron effect of the sentence and align this ordering
on @Alternative way of using @Priorty.
Wdyt?
Antoine
8 years, 1 month
[JBoss JIRA] (CDI-535) cdi instance injection ordering
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-535:
----------------------------------
Note that we should also provide a means of declaring priority for custom beans (e.g. with {{javax.enterprise.inject.spi.Prioritized}}).
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Reporter: Ochieng Marembo
> Priority: Optional
> Fix For: 2.1 (Discussion)
>
>
> We should allow ordering of bean instance injection using the {{Instance<MyBeanInterface>}} when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code:java}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code:java}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {{javax.annotation.Priority}} or any cdi specific annotation which we can add to {{MyBeanInterfaceImpl}} so that on injection of an {{Instance<MyBeanInterface>}}, all possible injection values are sorted based on the {{Priority.value()}} and if no annotation is defined, defaults to {{Priority.value = Integer.MAX_VALUE}}
> {code:java}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-541:
----------------------------------
Well, the whole idea of observers ordering is against the principle of loose coupling. However, the EG already decided to standardize it. In my opinion, it doesn't really matter whether we sort sync or async observers. Note that the only requirement of {{fireAsync()}} is: return immediately and notify observers asynchronously (we don't define when, where and how).
We could also state that async observer with priority results in "non-portable behavior" and let the implementations provide experimental support (e.g. by means of [NotificationOptions|https://github.com/cdi-spec/cdi/pull/337]).
> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
> Key: CDI-541
> URL: https://issues.jboss.org/browse/CDI-541
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Fix For: 2.0 .Final
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority?
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>
> void observeMessage(@Observes @Priority(2000) Message message){}
> }
> {code}
> {code}
> public class Second {
>
> void observeMessage(@ObservesAsync @Priority(2100) Message message){}
> }
> {code}
> {code}
> public class Third {
>
> void observeMessage(@Observes @Priority(2200) Message message){}
> }
> {code}
> {code}
> public class Fourth {
>
> void observeMessage(@ObservesAsync @Priority(2300) Message message){}
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
