December 2015 - cdi-dev - Jboss List Archives

Getting injection point from Bean#create

by arjan tijms

Hi, In a producer method it's trivial to get access to an InjectionPoint instance representing the point where the value produced by the producer will be injected. When registering a Bean manually from an extension using AfterBeanDiscovery#addBean, this is not immediately obvious. After some fumbling with the CDI APIs I came up with the following code that seems to work on both Weld and OWB (didn't test CanDI yet). It uses a small "dummy" class, which is used to grab an InjectionPoint off: In a Bean: public Object create(CreationalContext<Object> creationalContext) { InjectionPoint injectionPoint = (InjectionPoint) beanManager.getInjectableReference( resolve(beanManager, InjectionPointGenerator.class).getInjectionPoints().iterator().next(), creationalContext ); With InjectionPointGenerator being the following class: public class InjectionPointGenerator { @Inject private InjectionPoint injectionPoint; } And resolve being the following method: public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) { Set<Bean<?>> beans = beanManager.getBeans(beanClass); for (Bean<?> bean : beans) { if (bean.getBeanClass() == beanClass) { return (Bean<T>) beanManager.resolve(Collections.<Bean<?>>singleton(bean)); } } return (Bean<T>) beanManager.resolve(beans); } As mentioned, while this seems to work, I wonder if it's the best approach. Kind regards, Arjan

8 years, 11 months

4
8
0 / 0

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-527: --------------------------------- Sorry, typo... You were right this initHashSeedAsNeeded was introduced to jdk7. I meant say their app will be broken once they move up to java7. > 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

1
0
0 / 0

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-527: ----------------------------------- But this final method is already in HashMap as of Java7. This is nothing which only got introduced with Java8... > 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

1
0
0 / 0

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-527: --------------------------------- >>Not sure about this. Most of this classes already have final protected methods as of Java7. Which class do you have in mind? HashMap#initHashSeedAsNeeded, as mentioned in your description. > 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

1
0
0 / 0

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-527: ----------------------------------- [~french_c] Imo a perfectly valid use case. In the case you described only the option with the excludes or with the special Annotation would be possible. [~emilyj]] Not sure about this. Most of this classes already have final protected methods as of Java7. Which class do you have in mind? > 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

1
0
0 / 0

Next meeting on Tuesday 5th January 2016

by Antoine Sabot-Durand

Hi All, I'll be on PTO for Holliday season for the 2 next weeks. For those who celebrate christmas: Merry Chtistmas ! For all see you next year! Antoine

9 years

2
1
0 / 0

[JBoss JIRA] (CDI-576) Provide an API to say a bean depends on another instance

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-576?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-576: ---------------------------------------- [~struberg] this is what I said (on the broken side) but it still needs a solution. "just touch that stuff" DOESNT solve anything since you have to know an API you can touch for proxies which is not obvious + as explained in the description you can not be able to do it if it is in several sublayers (it is more common that we think and why @DependsOn wouldnt even work in 50% of cases). See this very simplified case (jira pseudo-coding so please forget typo etc): {code} class InstanceManager { @Produces @ApplicationScoped MyInstance produce() { ... } void release(@Disposes MyInstance instance) {...} } {code} {code} class InstanceUsage1 { @Inject MyInstance instance; void start(@Observes @Initialized(AppScoped.class) Object start) { instance.doWork(); } } {code} {code} @Startup @Singleton // or any other start thing class InstanceUsage2 { @Inject MyWorker worker; @PostConstruct void init() { worker.startJobs(); } } {code} {code} class MyWorker { @Inject MyInstance instance; void doWork() { instance.doSomethingElse(); } } {code} This use case is : not orderable events (in previous samples the startup event) we need to be able to enforce dependencies to ensure the InstanceManager is started as expected at the very beginning. You can touch MyInstance in InstanceUsage1 but likely not in InstanceUsage2 where it is also needed. The case of startup is obvious and you can surely argue it is not 100% CDI - but it is real - but it is the same if you have a resource while would be hit later in the request/session/... and you need to validate it exists before starting the flow. Of course you can "touch" it but then if you mock it or specialize it your touching code can just be wrong and corrupt your application. Since we have the metadata in extensions I don't see any issue to ask for an eager instantiation there. Even adding constraints for such a feature (like scopes supporting it etc) is perfectly valid and fine but not having it makes some cases very hard to support IMHO. > Provide an API to say a bean depends on another instance > -------------------------------------------------------- > > Key: CDI-576 > URL: https://issues.jboss.org/browse/CDI-576 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers. > If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. > We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice. > we would get something like > {code} > event.dependencyOn(bean1, bean2); > {code} > and it would be fired before after validation event. > The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-576) Provide an API to say a bean depends on another instance

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-576?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-576: ----------------------------------- @DependsOn in EJB is SERIOUSLY broken in practice. Imo we don't like that in CDI. Just touch that stuff in @PostConstruct and be done. If you create a loop then it will blow up anyway. I cannot see what problem this should solve. > Provide an API to say a bean depends on another instance > -------------------------------------------------------- > > Key: CDI-576 > URL: https://issues.jboss.org/browse/CDI-576 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers. > If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. > We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice. > we would get something like > {code} > event.dependencyOn(bean1, bean2); > {code} > and it would be fired before after validation event. > The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-576) Provide an API to say a bean depends on another instance

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-576?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau updated CDI-576: ----------------------------------- Description: Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers. If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice. we would get something like {code} event.dependencyOn(bean1, bean2); {code} and it would be fired before after validation event. The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. was: Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with CDI but it can be more vicious and through several layers. If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belongs to extensions) allowing to require this kind of eager initialization can be nice. we would get something like {code} event.dependencyOn(bean1, bean2); {code} and it would be fired before after validation event. The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. > Provide an API to say a bean depends on another instance > -------------------------------------------------------- > > Key: CDI-576 > URL: https://issues.jboss.org/browse/CDI-576 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers. > If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. > We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice. > we would get something like > {code} > event.dependencyOn(bean1, bean2); > {code} > and it would be fired before after validation event. > The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-576) Provide an API to say a bean depends on another instance

by Romain Manni-Bucau (JIRA)

Romain Manni-Bucau created CDI-576: -------------------------------------- Summary: Provide an API to say a bean depends on another instance Key: CDI-576 URL: https://issues.jboss.org/browse/CDI-576 Project: CDI Specification Issues Issue Type: Epic Reporter: Romain Manni-Bucau Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with CDI but it can be more vicious and through several layers. If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A. We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belongs to extensions) allowing to require this kind of eager initialization can be nice. we would get something like {code} event.dependencyOn(bean1, bean2); {code} and it would be fired before after validation event. The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2015