[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=13571800#comment-13571800 ] 

Mark Struberg commented on CDI-702:
-----------------------------------

But that also would mean that em.fire in WAR1 would also be observed in WAR2?
That's maybe in sync with the spec but it doesn't seem correct from a user pov.
And then again IF em.fire is isolated, then this would contradict the spec according to your interpretation.

Maybe my words have not been chosen carefully enough. So I try to describe my pov again:
Our main concern should not be whether something is guaranteed by the spec but rather whether it makes sense from a real world user scenario. And only then we should check whether we could implement this in a useful way and whether this might contradict older versions of the spec. 

I know we kind of left this out until very late in CDI 1.0 where we mainly focused in webapps only.  
But even in CDI 1.0 we have the following sentence in our spec which allowed for adopting to modularity:
{quote}Support for Java EE modularity and the Java EE component architecture—the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components{quote}

> 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)