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
7 years, 8 months
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
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
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
[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
[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
[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
[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
