July 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-9) Interceptors are not applied to custom bean types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.syst... ] Antoine Sabot-Durand updated CDI-9: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Interceptors are not applied to custom bean types > ------------------------------------------------- > > Key: CDI-9 > URL: https://issues.jboss.org/browse/CDI-9 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added through the SPI do not have interceptors applied. > Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Antoine Sabot-Durand updated CDI-4: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Need a way to provide ordering for Event observers > -------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-8) Decorators are not applied to custom beans

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.syst... ] Antoine Sabot-Durand updated CDI-8: ----------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Decorators are not applied to custom beans > ------------------------------------------ > > Key: CDI-8 > URL: https://issues.jboss.org/browse/CDI-8 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ] Antoine Sabot-Durand updated CDI-21: ------------------------------------ Fix Version/s: 2.0 (discussion) (was: TBD) > Support PostConstruct callbacks in Extension class > -------------------------------------------------- > > Key: CDI-21 > URL: https://issues.jboss.org/browse/CDI-21 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Sivakumar Thyagarajan > Priority: Minor > Fix For: 2.0 (discussion) > > > It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification. > Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-414: ------------------------------------------ IMO, the best solution would be to support inner call AOP in CDI (instead of crappy self-injection). [~jharting] told me once that it was possible in the RI and that we chose to avoid this behavior to be consistent with EJB. Probably a topic to discuss for CDI 2.0. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection

by Rafael Sisto (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Rafael Sisto commented on CDI-414: ---------------------------------- I'm facing this limitation right now in JBoss EAP 6.1 The injection actually works, but the aspects (i.e.: Interceptors) are not applied. For example, I have this scenario: @Named @RequestScoped public class MyBean { @Inject private MyBean self; @Interceptors(InterceptorA.class) public void methodA() { self.methodB(); } @Interceptors(InterceptorB.class) public void methodB() { System.out.println("extra"); } } When I call methodA, InterceptorA is called, but when this method calls methodB, the InterceptorB is never called. > Support for "self" injection > ---------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-78: ------------------------------- Fix Version/s: (was: 1.1.PFD) > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-78: -------------------------------- Reopening as this issue seems to have never actually been resolved. > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

InjectionPoint when injecting into Decorators

by Mark Struberg

Hi! I struggle with a few TCK tests which assume that in Decorators and Interceptors you can have an @Inject ct which has a valid InjectionPoint. But I cannot find in the spec how this is supposed to work. 5.5.7 defines in which situations the CDI container must create an InjectionPoint: ---- An instance of InjectionPoint may represent: • an injected field or a parameter of a bean constructor, initializer method, producer method, disposer method or observer method, or • an instance obtained dynamically using Instance.get(). ---- But if you e.g. look at @Inject public OrderedEventDeliveryDecorator(@Delegate Event<T> delegate, InjectionPoint ip, BeanManager manager, OrderedEventDeliveryExtension extension) then this does not fit any requirement imo. Because the Decorator is a dependent bean on the decorated contextual instance. Thus it's 'internal' and does not have any InjectionPoint. This would be different if you would @Inject the Decorator into some other bean... The TCK test in question is ComplexEventDecoratorTest#testOrderedEvents Did I overlook something? LieGrue, strub

9 years, 9 months

2
1
0 / 0

About JSR 330.Next and CDI 2.0

by Antoine Sabot-Durand

Hi all, Since the first mention of CDI 2.0 preparation work, we've received a lot of comment about JSR 330 evolution. With the release of the proposal draft yesterday, this topic came up again. So let me give my point of view on this subject to have an open discussion here. When we started to discuss about modularity with Pete in last november, my first idea was to go see what we could add in JSR 330 to make it a true specification that could be the first module of CDI. My idea at that time was to discuss with JSR 330 owner to see if we could bring basic concept we have in CDI to AtInject spec. In my mind the main features would have been: - Enhance the javax.inject.Provider<T> interface to bring it at the same level than javax.enterprise.inject.Instance<T>. That would have included support for AnnotationLiteral and TypeLiteral as well - Add a Container interface (a very light BeanManger) in JSR 330 to be able to resolve beans instance from outside managed beans - Add a mechanism to get this Container from non managed beans (like we get access to BeanManager from JNDI or CDI class) At that time, I contacted Bob Lee without success (didn’t tried Pivotal since I don’t have contact there). I checked with JCP what could be done if we’d like to see an evolution of JSR 330 and the owner doesn’t care, there seems to have solutions but I let it aside since we were in the middle of CDI 1.2 MR at that time. Today I’m a bit torn about this point. Working on opening JSR 330 could be like opening pandora box, since I see 2 scenarios : 1) former JSR 330 owners wake up and are ok to get for a new spec version they lead: Knowing the history of JSR 330 vs JSR 299 I’m not sure everything we’d need would be heard and even if the people leading this would be cooperative, a lot of discussion and negotiation would be needed to be sure that this new AtInject wouldn’t contain features incompatible with CDI. So it’d be very time consuming with no guarantee to get what we’d need at the end. 2) former JSR 330 owner don’t mind others take ownership of their spec to enhance it and we (Red Hat) are the one to take this ownership to secure CDI: The best solution to minimize risk. But leading a new specification is a lot more work than just deciding that we have a specific basic inject « part » in CDI 2.0. Leading a spec is very time consuming, so it could be better on the paper but will impact CDI 2.0 new features. To sum up, as a Java EE user (like I have been for 10 years) I’d be happy to see this (scenario 2), but as CDI spec lead I fear that it could lead us in a trap (going to scenario 1 or consuming precious time on AtInject+1 instead of CDI 2.0) Your input, solutions or comment would be appreciated on this point. Antoine

9 years, 9 months

10
35
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2014