Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion
"Implementing a non-flat deployment for Weld Integration" To view the discussion, visit: http://community.jboss.org/message/542347#542347 -------------------------------------------------------------- Pete and I had a face-to-face meeting where we discussed all my questions and what would be the best way to implement this. Regarding the assumptions I wanted to validate, both are correct. But, regarding visibility of deployments. He told me that the best approach is to mirror the ClassLoader structure. The point is that one BDA A can see another BDA B if the module it represents, say A', can see classes from the module B', that corresponds to BDA B. So, instead of reinventing the wheel, we should use the already existent ClassLoader structure to implement this correspondence in the BDA structure. These are the steps that Pete suggested: 1) Find Modules which are BDA's 2) List <Module>, List<ClassLoader>, Map<ClassLoader, Module> 3) Iterate over classes and build graph of modules 4) Module -> BDA a) Explore CL graph & for each CL & Module b) Convert A few examples of complex things that we would have to implement if we don't use the ClassLoader structure: - we would have to able to see if a deployment is scoped or not, so we can define the visibility it has from other modules and to which modules it is visible - we need to keep track of modules being deployed and undeployed, so to know when it becomes visible and when it becomes invisible - we need to support Class-path attributes in manifest files - we need to define when a previously defined archive is available to a archive being deployed now So, these features that we need to support provide the arguments as to why we should mirror the ClassLoader structure instead of implementing this from scratch. Pete also pointed out an important behaviour that should be fixed. In a nutshell, all archives visible to a BDA are scanned. In the given scenario: ejb.jar A reaches lib2. In lib2 we have a ClassPath reference in the manifest to lib3, which is not in the classpath of the server... it is somewhere in the filesystem. In this case, for what I understood from Pete's explanations, lib3 is going to be scanned for CDI stuff. But this shouldn't happen, so we would also need a way of differentiating lib3 from lib2. I'll stop my explanation here, as I think Pete can fill in the blanks and explain this much better :-) Anyway, this would be a future step, as the priority is to first mirror the CL structure effectively. So, Ales, how do you think this should be done? I think we have plenty of code in the ClassPools that do exactly that, mirror the ClassLoader structure in a way that allows us to find the classes and xml files in META-INF dirs. Maybe there is a way of reusing part of the ClassPool code to do this? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/542347#542347] Start a new discussion in JBoss Microcontainer Development POJO Server at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2116]
_______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
