March 2016 - cdi-dev - Jboss List Archives

Enabling programmatic/synthetic decorators added by extension

by arjan tijms

Hi, I'm trying to add decorators and/or interceptors to a Bean<T> that's added via an extension. There doesn't seem to be any way to add interceptors, but decorators seem almost possible. I've added a decorator in the following way: AnnotatedType<AutoApplySessionDecorator> annotatedType = beanManager.createAnnotatedType(AutoApplySessionDecorator.class); BeanAttributes<AutoApplySessionDecorator> beanAttributes = beanManager.createBeanAttributes(annotatedType); Bean<AutoApplySessionDecorator> bean = beanManager.createBean(beanAttributes, AutoApplySessionDecorator.class, beanManager.getInjectionTargetFactory(annotatedType)); afterBeanDiscovery.addBean(bean); Where the "AutoApplySessionDecorator" is an existing (non-scanned) decorator just used as an example. While this seems to work, the problem is with the enablement. @Priority is not processed in this way, since it's only read from an AnnotatedType that's been added to the deployment (see e.g. in Weld org.jboss.weld.bootstrap.BeanDeployer.processPriority(AnnotatedType<?>)). beans.xml is not really an option here due to the static nature of that and the fact that the decorator needs to be enabled dynamically here, plus that the implementation class of the decorator is a detail I would not like to expose to the application. Is there any other way to either enable a (synthetic) decorator programmatically, or to add Interceptors to a programmatically added Bean<T>? Kind regards, Arjan Tijms

8 years, 4 months

5
6
0 / 0

PR review and Hangout meeting

by Antoine Sabot-Durand

Hi all, During last meeting we discuss about making some meeting with hangout to be more efficient with the current PR. We could setup a meeting Tuesday evening to replace our IRC meeting (6:00 pm CEST) or any other day of the week (and later if necessary), but this meeting will be useless if you don't have time to review the open PR. So let me know if the slot is ok for you regarding availability and review capacity before. Antoine

8 years, 8 months

3
4
0 / 0

Closing PR 270 to open a fresher one

by Antoine Sabot-Durand

Hi, PR 270, related to metadata builder api (CDI-558) had became too complicated in its history. With a major new contribution from Martin on the feature, I decided to close the PR and reopen it tomorrow (after some rework in the spec and javadoc). Antoine

8 years, 8 months

1
0
0 / 0

No meeting today?

by John D. Ament

I was on IRC a few minutes late, but looked like there was no meeting. Was it canceled? John

8 years, 8 months

2
1
0 / 0

[JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau updated CDI-594: ----------------------------------- Description: We suppose we have an injection of type Instance<Greeting>. {code} // adapted from javaee7-samples repo Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {}); Greeting anotherBean = select.get(); assertThat(anotherBean, instanceOf(SimpleGreeting.class)); select.destroy(anotherBean); {code} This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: {code} Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get(); assertThat(anotherBean, instanceOf(SimpleGreeting.class)); instance.destroy(anotherBean); {code} The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. > Instance#destroy should be linked to Instance instance which has been used for the creation > ------------------------------------------------------------------------------------------- > > Key: CDI-594 > URL: https://issues.jboss.org/browse/CDI-594 > Project: CDI Specification Issues > Issue Type: Epic > Affects Versions: 1.2.Final > Reporter: Romain Manni-Bucau > > We suppose we have an injection of type Instance<Greeting>. > {code} > // adapted from javaee7-samples repo > Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {}); > Greeting anotherBean = select.get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > select.destroy(anotherBean); > {code} > This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work: > {code} > Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get(); > assertThat(anotherBean, instanceOf(SimpleGreeting.class)); > instance.destroy(anotherBean); > {code} > The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation

by Romain Manni-Bucau (JIRA)

Romain Manni-Bucau created CDI-594: -------------------------------------- Summary: Instance#destroy should be linked to Instance instance which has been used for the creation Key: CDI-594 URL: https://issues.jboss.org/browse/CDI-594 Project: CDI Specification Issues Issue Type: Epic Affects Versions: 1.2.Final Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by Mark Paluch (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] Mark Paluch commented on CDI-546: --------------------------------- Without a MR of JSR250 (for {{@Priority}}) the whole priority story is no fun at all. > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 (discussion) > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-546: ---------------------------------- I believe we should place the constant on the {{javax.enterprise.inject.spi.ObserverMethod}}. > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 (discussion) > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc

by Martin Kouba (JIRA)

Martin Kouba created CDI-593: -------------------------------- Summary: Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc Key: CDI-593 URL: https://issues.jboss.org/browse/CDI-593 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba * javadoc would definitely deserve some more info * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-593: ----------------------------- Fix Version/s: 2.0 (discussion) > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2016