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

[Emily Jiang (JIRA)]

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

Emily Jiang commented on CDI-702:
---------------------------------

Here are Martin's and Antoine's comments during our previous discussion:
Martin:

{noformat}
1. I'm not talking about class loading and using classes but observing 
ProcessAnnotatedType event -> any WAR can see PAT type and is able to 
observe it.
2. The CDI spec does not define any visibility boundaries for events 
(unlike for typesafe resolution). See for example CDI-518.

So yes, from EE.8.3.1 Web Container Class Loading Requirements it is 
clear that portable apps must not depend on having access to classes 
from the second WAR.

On the other hand, CDI extensions are defined as application wide 
components which should be imho able to process container lifecycle 
events from all bean archives.

{noformat}

Antoine:
{noformat}
Class loading in Java EE platform is far from being a consensus. Vendors are doing different things here, so definition of class visibility is not universal.
Visibility problem in EAR were never solved in CDI for this reason, see https://issues.jboss.org/browse/CDI-129 to have an history on that.


When we relaunched this discussion during CDI 2.0, conclusion was that we agreed on our disagreement with OWB team and that clarification should be done at Java EE spec level (I let you dig in ML archive to check the discussion we had with Mark Struberg at that time).


Even if CDI spec tries to cover all, there are still small differences between Weld and OWB making the switch from one to the other not transparent every time.
I’m sorry you fall in one of these gap, but that doesn’t make Weld buggy, only put one of this difference into light.


Antoine
{noformat}



> 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.2.3#72005)