[cdi-dev] [JBoss JIRA] (CDI-702) Observers in CDI extensions can see classes they should not be able to

[Mark Struberg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571364#comment-13571364 ] 

Mark Struberg edited comment on CDI-702 at 5/4/18 6:41 AM:
-----------------------------------------------------------

{quote}From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec.{quote}

No, The spec defines that Beans must adhere to isolation rules. 

But 
1.) The spec says nothing about ProcessAnnotatedType and scanning in general. So this is undefined (ternary logic applies).
2.) According to the rules you pointed to (5.1.4) ProcessBean<T> must also not get fired for a Bean of a foreign WAR. So at least this one is rather likely an impl bug, isn't?

{quote}I am pretty sure other users would come back saying they have real world problem because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems).{quote}
That's not portable right now anyway.

There are 2 possible ways a container could treat this:
a.) send the container events to extensions which are shared (an Extension in the ear lib/*.jar or an/ejb.jar would get all classes)
b.) do a proper hierarchic BeanManager setup.

To make it more clear: my main worry is about having an Extension in WAR1 which also gets all events for a class in WAR2. This should clearly not happen.
Extensions in a shared classpath might also be a problem, but we might probably be able to split those 2 cases.


was (Author: struberg):
{quote}From the comments I gather that people agree on current spec interpretation (that extensions are now allowed to observe everything) and the discussion is about changing that in spec.{quote}

No, The spec defines that Beans must adhere to isolation rules. 

But 
1.) The spec says nothing about ProcessAnnotatedType and scanning in general. So this is undefined (ternary logic applies).
2.) According to the rules you pointed to (5.1.4) ProcessBean<T> must also not get fired for a Bean of a foreign WAR. So at least this one is rather likely an impl bug, isn't?

{quote}I am pretty sure other users would come back saying they have real world problem because they now cannot observe events "globally" where they previously could (say hello to backwards compat. problems).{quote}
That's not portable right now anyway.

There are 2 possible ways a container could treat this:
a.) send the container events to extensions which are shared (an Extension in the ear lib/*.jar or an/ejb.jar would get all classes)
b.) do a proper hierarchic BeanManager setup.

> 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.
> e.g.
> myApp.ear
>   lib\myLib.jar (LibExtensionA.class, LibOne.class)
>   myWarA.war (WarAExtension.class, myWarAServlet.class)
>   myWarB.war (WarBExtension.class, myWarBServlet.class)
> In this example,LibExtensionA, WarAExtension and WarBExtension can observe the classes of 
> LibOne, myWarAServlet and myWarBServlet.
> 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.5.0#75005)