[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 updated CDI-546:
-----------------------------
Fix Version/s: 2.0 (discussion)
> 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, 1 month
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-473:
----------------------------------
The other problem with {{@Initialized/(a)Destroyed(ApplicationScoped.class)}} is that different EE modules usually receive different payloads, e.g. web modules receive a concrete {{ServletContext}}, EJB modules any {{Object}}. So there might be multiple events with different timing. I know it's only relevant for EARs, but still might complicate things.
{{BeforeShutdown}} must be fired after all contexts are destroyed. It's true the container must provide a bean of scope {{@ApplicationScoped}} for each extension so it sounds like a contradiction. But in Weld we have a special handling of extension observer methods where contexts do not have to be active.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-473:
-----------------------------------
TL;DR: imo we don't need any @Startup
here for the long explanation:
*) As Jozef already explained there is @Observers @Initialized(ApplicationScoped.class).
*) [~meetoblivion] good point, but one could check that in the code easily. (if bla==null..)
*) the @Startup + @Postconstruct has one HUGE downside:
As JSR-250 defines a bean must only be made available _after_ PostConstruct did finish. That means that no other bean we call us before the init is finished. That causes tons of problems, e.g. defeats circular injection (which proxies usually solve), the boot order etc. THAT was the reason why EJB had to introduce the whole depends-on stuff in the first place. And it is really ugly and hard to get right.
With the eventing solution it's pretty smooth. The only 'problem' currently in this area that the @Initialized and @Destroyed events for ApplicationScoped does NOT reflect the real lifecycle of the ApplicationContext. [1]
[1] for those who like to dig deeper: All CDI Extensions are defined to be available as @ApplicationScoped beans. Thus the ApplicationContext hast to be available right after the CDI extensions get loaded, means way before we even fire the first @BeforeBeanDiscovery event. And the ApplicationContext must also exist until the last CDI Extension got the @BeforeShutdown event. In OWB we first fire the @Destroyed(ApplicationContext.class) then destroy the 'user' beans and only then fire all the BeforeShutdown. And only after that we really destroy the ApplicationContext. Not sure if Weld does something similar, but that's what worked best so far...
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[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:
----------------------------------------
[~mkouba] indeed.
Ordering is an extension of the use case, but often you just need:
{code}
@Startup
@ApplicationScoped
public class Foo {
@PostConstruct
public void init() {
//...
}
}
{code}
This would be an equivalent to Spring that eagerly pre-instantiates all singleton beans at startup.
It would be very useful in Java SE so that you can bind the lifecycle of beans that deal for example with external resources, pools, executors to that of the container. In Java EE, these tend to be resources managed by the application containers as opposed to Java SE.
A number of extensions already do it (Camel CDI for example to start endpoints, consumers, ...). But it looks like the need exists at application developer level as well.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-473:
----------------------------------
[~meetoblivion] [~stefanutti] [~davsclaus] [~agoncal] So this the best we can do today, right? And in 2.0 it should be possible to add {{@Priority}} to the observer method...
{code:java}
@ApplicationScoped
public class Initializer {
@Inject
private Service1 service1;
@Inject
private Service2 service2;
void init(@Observes @Initialized(ApplicationScoped.class) Object event) {
}
@PostConstruct
void postConstruct() {
service1.start();
service2.start();
}
}
{code}
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-473:
--------------------------------
I'm a bit puzzled about start up needs to be honest. Typically when bringing up something like this, I have a single start up entry point. That one entry point starts components in the right order. While it would be cool to have the container start things in the right order, its sometimes considered to be voodoo magic for that to happen in an unclear way, as well as question the testability of such a process.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata
by Martin Kouba (JIRA)
Martin Kouba created CDI-592:
--------------------------------
Summary: Consider adding ObserverMethod.notify() method which also accepts EventMetadata
Key: CDI-592
URL: https://issues.jboss.org/browse/CDI-592
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Events
Reporter: Martin Kouba
Fix For: 2.0 (discussion)
{code:java}
// Make the original method also default so that new impls don't need to implement two methods
default void notify(T event) {
// No-op
}
// The container should always call this method...
default void notify(T event, EventMetadata metadata) {
notify(event);
}
{code}
This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Claus Ibsen (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Claus Ibsen commented on CDI-473:
---------------------------------
> That request should ideally be moved forward as part of bringing better Java SE support in CDI 2.0.
+1
Yeah I would love to see CDI 2.0 being able to do all the needed stuff on plain Java SE. There is a lot of movement to MSA and plain old java main apps. So lets try to make CDI 2.0 the best DI library for that. Its almost there.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[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:
---------------------------------------
At the last face to face we even mentioned being able to startup, shutdown and prioritize bean initialization. For example :
{code}
@ApplicationScoped
@Startup @Priority(1000)
public class Foo {
@PostConstruct
public void m() {
}
}
{code}
Or even do :
{code}
@ApplicationScoped
public class Foo {
@Startup
public void init() {
}
@Shutdown
public void clear() {
}
}
{code}
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month
[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:
----------------------------------------
That request should ideally be moved forward as part of bringing better Java SE support in CDI 2.0.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.4.11#64026)
8 years, 1 month