[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti commented on CDI-473:
----------------------------------------
Indeed, {{@Startup}} may be a candidate. I see two questions in order to determine the best way to capture that:
* Does that apply to {{ApplicationScoped}} bean only?
* It that worth enough to depend on an other specification for that purpose only?
> Standardize eager initialisation of ApplicationScoped bean
> ----------------------------------------------------------
>
> Key: CDI-473
> URL: https://issues.jboss.org/browse/CDI-473
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Antonin Stefanutti
>
> Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
> While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
> {code}
> void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
> for (AnnotatedType<?> type : eagerBeans)
> // Calling toString is necessary to force the initialization of normal-scoped beans
> BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
> }
> {code}
> There should be a concise way to declare that intent which would then be address by the CDI container, for example:
> {code}
> @ApplicationScoped(eager = true}
> class EagerApplicationScopedBean {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-473:
---------------------------------------
What about using {{@Startup}} in this case ?
One idea in Java EE 7 was to take the [{{javax.ejb.Startup}}|http://docs.oracle.com/javaee/7/api/javax/ejb/Startup.html] annotation out of the EJB spec, and give this functionality to every managed bean (even a servlet). This wasn't done... unfortunately.
For Java EE 8, hopefully, we will be able to have such startup behavior back into the [Concurrency Utilities for Java EE|https://jcp.org/en/jsr/detail?id=236] where it would make more sense.
> Standardize eager initialisation of ApplicationScoped bean
> ----------------------------------------------------------
>
> Key: CDI-473
> URL: https://issues.jboss.org/browse/CDI-473
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Antonin Stefanutti
>
> Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
> While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
> {code}
> void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
> for (AnnotatedType<?> type : eagerBeans)
> // Calling toString is necessary to force the initialization of normal-scoped beans
> BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
> }
> {code}
> There should be a concise way to declare that intent which would then be address by the CDI container, for example:
> {code}
> @ApplicationScoped(eager = true}
> class EagerApplicationScopedBean {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-470:
-------------------------------
It only applies to the current package, and not to subpackages. Taxonomically, Java does not define subpackages as a type of package, but as a unique indentity - take a look the Java Language Specification. However, in common usage, this definition has become blurred, so I think we could add a note to the spec here, that makes this point.
Recursive vetoing is possibly interesting, but note that the note
{quote}
When placed on package, all beans in the package are prevented from being installed. If packages are split across jars, non-portable behavior results. An application can prevent packages being split across jars by sealing the package
{quote}
would need to apply to subpackage. IOW all packages and subpackages must be in the same JAR. Java provides no way to enforce this unfortunately.
> Clarify @Vetoed on recursive package
> ------------------------------------
>
> Key: CDI-470
> URL: https://issues.jboss.org/browse/CDI-470
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Antonio Goncalves
>
> It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} :
> {code:title=package-info.java}
> @Vetoed(recursive=true)
> package my.parent.package;
> import javax.enterprise.inject.Vetoed;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Antonin Stefanutti (JIRA)
Antonin Stefanutti created CDI-473:
--------------------------------------
Summary: Standardize eager initialisation of ApplicationScoped bean
Key: CDI-473
URL: https://issues.jboss.org/browse/CDI-473
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts
Reporter: Antonin Stefanutti
Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
{code}
void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
for (AnnotatedType<?> type : eagerBeans)
// Calling toString is necessary to force the initialization of normal-scoped beans
BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
}
{code}
There should be a concise way to declare that intent which would then be address by the CDI container, for example:
{code}
@ApplicationScoped(eager = true}
class EagerApplicationScopedBean {
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-472) Support @WithAnnotations as type annotation of lifecycle events
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-472?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti updated CDI-472:
-----------------------------------
Description:
As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events.
For example, instead of having to write that in a CDI extension:
{code}
Set<AnnotatedType<?>> camelBeans = new HashMap<>();
void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType<?> pat) {
camelBeans.add(pat.getAnnotatedType());
}
<T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
if (camelBeans.contains(pit.getAnnotatedType()))
pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
}
{code}
One could write directly:
{code}
<@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
}
{code}
was:
As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events.
For example, instead of having to write that in a CDI extension:
{code}
Set<AnnotatedType<?>> camelBeans = new HashMap<>();
void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType<?> pat) {
camelBeans.add(pat.getAnnotatedType());
}
<T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
if (camelBeans.contains(pit.getAnnotatedType()))
pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
}
{code}
One could write directly:
{code}
<@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
}
{code}
> Support @WithAnnotations as type annotation of lifecycle events
> ---------------------------------------------------------------
>
> Key: CDI-472
> URL: https://issues.jboss.org/browse/CDI-472
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antonin Stefanutti
>
> As Java 8 introduces type annotations, generalizing the benefit of {{@WithAnnotations}} by using it as type annotation could improve a lot of recurring patterns that are usually implemented as a combination of {{ProcessAnnotatedType}} and other lifecycle events.
> For example, instead of having to write that in a CDI extension:
> {code}
> Set<AnnotatedType<?>> camelBeans = new HashMap<>();
> void camelAnnotations(@Observes @WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) ProcessAnnotatedType<?> pat) {
> camelBeans.add(pat.getAnnotatedType());
> }
> <T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
> if (camelBeans.contains(pit.getAnnotatedType()))
> pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
> }
> {code}
> One could write directly:
> {code}
> <@WithAnnotations({BeanInject.class, Consume.class, EndpointInject.class, Produce.class, PropertyInject.class}) T> void camelBeansPostProcessor(@Observes ProcessInjectionTarget<T> pit, BeanManager manager) {
> pit.setInjectionTarget(new CdiCamelInjectionTarget<>(pit.getInjectionTarget(), manager));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-471:
-------------------------------
+1 this will make CDI easier to use.
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months