[
https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-518:
-----------------------------------
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.
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)