[
https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-518:
-----------------------------------
I don't think we need to change anything. Section "10.3 Observer resolution"
defines
{quote}
An event is delivered to an observer method if:
• The observer method belongs to an enabled bean.
{quote}
In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from
WAR2 must not even get returned.
Also see 10.5 "Observer notification"
{quote}
• 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.
{quote}
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.
Clarify boundaries of the ServletContext event
----------------------------------------------
Key: CDI-518
URL:
https://issues.jboss.org/browse/CDI-518
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Reporter: Jozef Hartinger
{quote}
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.
{quote}
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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)