An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
when the application is destroyed. The event payload is:
• the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
• any java.lang.Object for other types of application.
Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
- relates to
-
WELD-1821 Revisit how @Initialized/@Destroyed events are fired for @ApplicationScoped
-
- Resolved
-
[CDI-518] Clarify boundaries of the ServletContext event
Mark Struberg (Inactive)
added a comment - Oki, getting tricky now. I think we should take a step back and finally do our homework regarding EAR handling.
- What classes are seen where.
- How do we handle/deal with isolation and visibility constraints of CDI running in EARs.
- How does Extension visibility look like
- Which classes should get delivered to which Extension
- getBeans in EARs
- @Named in EARs (thats a TOTAL mess right now)
- getInterceptors, decorators etc in EARs
...
After that the observer resolution will solve itself pretty quickly.
Mark Struberg (Inactive)
added a comment - Oki, getting tricky now. I think we should take a step back and finally do our homework regarding EAR handling.
What classes are seen where.
How do we handle/deal with isolation and visibility constraints of CDI running in EARs.
How does Extension visibility look like
Which classes should get delivered to which Extension
getBeans in EARs
@Named in EARs (thats a TOTAL mess right now)
getInterceptors, decorators etc in EARs
...
After that the observer resolution will solve itself pretty quickly. Do you mean "8.3 Class Loading Requirements"? If so then don't forget that ServletContext is not an application class. Therefore, this needs to be defined explicitly.
Mark Struberg (Inactive)
added a comment - The JavaEE umbrella spec says so in the isolation chapter. They are not referring to Bean<T> of course, but class visibility. But it essentially boils down to the same.
Mark Struberg (Inactive)
added a comment - The JavaEE umbrella spec says so in the isolation chapter. They are not referring to Bean<T> of course, but class visibility. But it essentially boils down to the same. In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.
Based on what? Your conclusion is reasonable but the spec does not say so. Therefore, I raised this clarification issue.
Mark Struberg (Inactive)
added a comment - I don't think we need to change anything. Section "10.3 Observer resolution" defines
An event is delivered to an observer method if:
• The observer method belongs to an enabled bean.
In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.
Also see 10.5 "Observer notification"
• If there is no context active for the scope to which the bean declaring the observer method belongs, then the observer method should not be called.
We can assume that the 'ApplicationContext' of beans from the other webapp (e.g. WAR2) is not active during a request to WAR1. This might be a bit too implicit, but there are already multiple other reasons why observers from WAR2 should not get this event from WAR1.
Mark Struberg (Inactive)
added a comment - I don't think we need to change anything. Section "10.3 Observer resolution" defines
An event is delivered to an observer method if:
• The observer method belongs to an enabled bean.
In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.
Also see 10.5 "Observer notification"
• If there is no context active for the scope to which the bean declaring the observer method belongs, then the observer method should not be called.
We can assume that the 'ApplicationContext' of beans from the other webapp (e.g. WAR2) is not active during a request to WAR1. This might be a bit too implicit, but there are already multiple other reasons why observers from WAR2 should not get this event from WAR1.
The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.
If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.
For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues