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
New builders API
by John D. Ament
Hey guys
Based on the last f2f I was in, I took an action item to look at how
applications can leverage the new builder methods/classes from this PR:
https://github.com/cdi-spec/cdi/pull/287
To do this, I took some existing OSS CDI extensions and converted parts to
use the new APIs instead of the old ones.
The results were iffy to be honest. Here's some of the key issues I
noticed:
- AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean<?> bean)
In the latter, it's clearer to a developer which attributes are required vs
optional. Builders typically use sensible defaults. Maybe that was the
intention here, but I couldn't really get that sense when converting over.
It also wasn't clear what to do when done. I suspect I just leave it, but
without some kind of closing "build()" or "done()" method, it becomes
ambiguous.
- Annotated*Configurator
TBH, I have no idea what I was configuring in this one at the first pass.
I started with a method. I wanted to replace the method's annotations. It
seemed like I could set that up using the configurator, but I ended up
having to do setAnnotated at the end anyways, so I'm not sure what the
configurator bought me.
The one nice thing I saw was the simpler to use lambda functions. Being
able to stream through things like annotated method made the code much
cleaner.
For the open source code, I'll try to get some gists together that show the
changes. Maybe there's something I'm missing, so wouldn't mind a second
set of eyes on the changes to see.
John
7 years, 11 months
CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers
by arjan tijms
Hi,
I noticed a difference between using CDI.current()
and initialContext.lookup("java:comp/BeanManager") when called from within
a container jar (e.g. Mojarra) in a modular application server (e.g.
JBoss/WildFly).
With CDI.current() the bean manager I get when called from within Mojarra
is:
"Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean
count=44]"
With initialContext.lookup("java:comp/BeanManager") it's:
Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes [bean
count=97]
Where "example_app" is an EAR application that I used for testing.
I wonder, is this difference intended and did I overlook something, or is
it an unfortunate consequence of something? An additional problem is that
not all (modular) application servers act the same here. E.g. in
GlassFish/Payara I get the application bean manager in both cases.
Kind regards,
Arjan Tijms
7 years, 11 months
[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti commented on CDI-573:
----------------------------------------
As I moved from {{2.0-EDR1}} to {{2.0-EDR2}} and the {{getCDIProvider}} method visibility changed to become private, is the following code the expected way for a client to get a reference to the container:
{code}
CDI container = StreamSupport.stream(
ServiceLoader.load(CDIProvider.class, CDI.class.getClassLoader()).spliterator(), false)
.findFirst()
.map(CDIProvider::initialize)
.orElseThrow(() -> new IllegalStateException("No CDIProvider found in the classpath!"));
{code}
Instead of {{CDI.getCDIProvider().initialize()}}?
> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
> Key: CDI-573
> URL: https://issues.jboss.org/browse/CDI-573
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts
> Affects Versions: 2.0-EDR1
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
JSR 250 MR
by Antoine Sabot-Durand
Hi all,
I have some news from Linda about JSR 250 MR. It should be launched in the
coming weeks. I don't have confirmation of the estimated release date yet,
but it should be ok for our own release date.
Antoine
7 years, 11 months
[JBoss JIRA] (CDI-588) Adding missing annotation Literals
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-588?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-588:
----------------------------------
This issue could be probably resolved.
> Adding missing annotation Literals
> ----------------------------------
>
> Key: CDI-588
> URL: https://issues.jboss.org/browse/CDI-588
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Assignee: Martin Kouba
>
> We forgot literals for {{Inject}} and more questionably literals for:
> * {{Observes}} and {{ObservesAsync}}
> * {{Produces}} and {{Disposes}}
> * {{Specializes}}
> * {{TransientReference}}
> * {{Vetoed}}
> Most of these can be used to help defining a new AnnotatedType to be added to set of discovered types.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors
by Mark Paluch (JIRA)
[ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.sy... ]
Mark Paluch updated CDI-599:
----------------------------
Description:
With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start.
For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application.
An example API could look like:
{code}
/**
* The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a
* startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems.
*/
public interface ProcessDeploymentValidation {
}
/**
* The container fires an event of this type in case of multiple beans match a certain combination of required type and required
* qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}.
*/
public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation {
/**
*
* @return the affected InjectionPoint.
*/
InjectionPoint getInjectionPoint();
/**
*
* @return the set of matching beans for the InjectionPoint.
*/
Set<Bean<?>> getMatchingBeans();
/**
* Clarify bean resolution by specifying the bean to inject.
*
* @param bean
*/
void resolve(Bean<?> bean);
}
/**
* The container fires an event of this type in case no bean matches a certain combination of required type and required
* qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}.
*/
public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation {
/**
*
* @return the affected InjectionPoint.
*/
InjectionPoint getInjectionPoint();
/**
* Clarify bean resolution by specifying the bean to inject.
*
* @param bean
*/
void resolve(Bean<?> bean);
}
/**
* The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean
* type cannot be obtained because the bean type cannot be proxied by the container.
*/
public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation {
/**
* The unproxyable bean.
*
* @return
*/
Bean<?> getBean();
/**
* Suppres this problem and allow bean instances that are partially unproxied.
*/
void allowUnproxyable();
}
{code}
was:
With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start.
For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application.
> New lifecycle event to handle deployment/statup errors
> ------------------------------------------------------
>
> Key: CDI-599
> URL: https://issues.jboss.org/browse/CDI-599
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Mark Paluch
>
> With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start.
> For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application.
> An example API could look like:
> {code}
> /**
> * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a
> * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems.
> */
> public interface ProcessDeploymentValidation {
> }
> /**
> * The container fires an event of this type in case of multiple beans match a certain combination of required type and required
> * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}.
> */
> public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation {
> /**
> *
> * @return the affected InjectionPoint.
> */
> InjectionPoint getInjectionPoint();
> /**
> *
> * @return the set of matching beans for the InjectionPoint.
> */
> Set<Bean<?>> getMatchingBeans();
> /**
> * Clarify bean resolution by specifying the bean to inject.
> *
> * @param bean
> */
> void resolve(Bean<?> bean);
> }
> /**
> * The container fires an event of this type in case no bean matches a certain combination of required type and required
> * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}.
> */
> public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation {
> /**
> *
> * @return the affected InjectionPoint.
> */
> InjectionPoint getInjectionPoint();
> /**
> * Clarify bean resolution by specifying the bean to inject.
> *
> * @param bean
> */
> void resolve(Bean<?> bean);
> }
> /**
> * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean
> * type cannot be obtained because the bean type cannot be proxied by the container.
> */
> public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation {
> /**
> * The unproxyable bean.
> *
> * @return
> */
> Bean<?> getBean();
> /**
> * Suppres this problem and allow bean instances that are partially unproxied.
> */
> void allowUnproxyable();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
focusing on CDI 494 / PR277
by Antoine Sabot-Durand
Hi guys,
I think we should work on the example Martin created for this PR and come
to a decision. The PR is here:
https://github.com/cdi-spec/cdi/pull/277
I'm in favor of adopting this PR as all people who officially gave their
advice on this PR.
So I propose that people who have concern about this raise their hand and
give some feedback about the problem they see in adopting this PR.
Without feedback before the end of the week I'll consider that nobody is
against this feature.
Antoine
8 years
