[
https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba edited comment on CDI-702 at 5/19/17 7:27 AM:
-----------------------------------------------------------
For the record: the *Observer resolution* section in the CDI spec does not mention
"accessibility" or "observability" at all (unlike dependency
injection). An event is delivered to an observer method if it belongs to an enabled bean
and an event type is assignable. Also accessibility rules do not help e.g. if there is an
extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
if (event.getAnnotatedType().isAnnotationPresent(Named.class)) {
event.veto();
}
}
{code}
It should be able to observe all PAT events for all types in a CDI application (of course,
we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec
currently requires.
So this issue is more about defining boundaries for events delivery.
was (Author: mkouba):
For the record: the *Observer resolution* section in the CDI spec does not mention
"accessibility" or "observability" at all (unlike dependency
injection). An event is delivered to an observer method if it belongs to an enabled bean
and an event type is assignable. Also accessibility rules do not help e.g. if there is an
extension with a similar observer:
{code:java}
void observe(ProcessAnnotatedType<?> event) {
if (event.getAnnotatedType().isAnnotationPresent(Foo.class)) {
event.veto();
}
}
{code}
It should be able to observe all PAT events for all types in a CDI application (of course,
we assume the Weld interpretation of {{@ApplicationScoped}}). That's what CDI spec
currently requires.
So this issue is more about defining boundaries for events delivery.
Observers in CDI extensions can see classes they should not be able
to
----------------------------------------------------------------------
Key: CDI-702
URL:
https://issues.jboss.org/browse/CDI-702
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 1.2.Final, 1.1.Final, 2.0 .Final
Reporter: Emily Jiang
Priority: Critical
We observe a undesired behavior on Weld, which is during CDI bootstrap, all classes from
both the EAR lib folder and all WAR lib folders are available to CDI extensions in the EAR
lib folder as well as to CDI extensions in all WAR lib folders. Basically, the extension
class can see everything in an .ear regardless where the extension class resides. It
completely ignores classloading hierarchy.
This kind of contradicts with the classloading rules, where separate .war archives
packaged under the same .ear should not be able to see each other's class by default,
unless they both use the same classloader.
We discussed with Weld dev team (Martin, Thomas, Matej) and Anotine. The feedback is that
CDI spec is unclear on the "observer resolution". I would like to relaunch the
discussion to make this clarified and fixed. Please comment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)