[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.s... ] Marius Bogoevici commented on WELD-778: --------------------------------------- A few points to consider when investigating this issue: 1. Extensions are loaded via org.jboss.weld.bootstrap.WeldBootstrap#loadExtensions(Classloader), so an integrator would have to call this multiple times, making sure that extensions are not duplicated (i.e. extensions visible to both a module and submodule CL are processed only once) 2. org.jboss.weld.bootstrap.ExtensionBeanDeployer#deployBeans() is using the Container ClassTransformer - again, extensions in sub-modules will not be visible Generally speaking, the extension processing model is taking place at deployment level, but could allow for more granular processing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.s... ] Mark Struberg commented on WELD-778: ------------------------------------ The whole BDA definition is completely against any other EE spec out in the wild anyway. So please let's just get rid of this whole BDA nightmare. There is one really well working classloader configuration available with 1 CL for the EAR + 1 child classloader for each webapp. But this (and other classloader scenarios) is afaik not specified in any EE spec. The problem starts that there is are old and very insane classloader configurations which just share classes even amongst different EARs (figured recently on JBossAS5), etc. This is imo pretty sick and every little jetty and tomcat offer better (== more secure) classloader isolation. We imo should _not_ propagate those _bad_ classloader habits but instead either a) kill all the BDA definition (which currently infringes other EE specs) or b) finally start defining a (default) standard ClassLoader schema in EE7 and build our behaviour upon this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on WELD-778: -------------------------------- Mark, can you expand on (a) BDAs infringe on other EE specs? This sounds like a problem. Otherwise most of what you say is somewhat circular as you complain about the lack of classloading structure definition in EE, and then go on to complain about the way CDI get's around this lack of structure. In neither CDI nor Weld can we define the classloader structure for EE, so we need to be able to get around it. I am happy to listen to alternative proposals which could augment/replace bean archives, however I don't see them as that much of a problem (yes, it has been hard to impl and hard to get consistent behavior across platforms, but I think this has little to do with bean archives, and everything to do with the variations in classloading). It is clearly defined what an application is in Java EE, please refer to chapter 8 of the Java EE specification. Figure EE.8-1 gives a clear overview of this, describing the EAR as the Java EE application. Of course, when a war is deployed outside of an EAR, it constitutes an application as defined by the servlet spec. This area is not in doubt, and AFAIK there is no confusion here, I have never seen a general concern about this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on WELD-778: -------------------------------- Hi Mark, thanks for clarifying. To be pedantic, Java EE does define some classloading visibility rules, however it only defines a minimum set of requirements, not a full system. Can you explain in more detail how the bean archive definition relies on "such things" - best is if you can can quote sentences you think need cleaning up. We can then do this no problem in CDI 1.1 Now I understand about what you mean about the "what does application mean" - and your point makes sense. Suggest you raise a CDI issue for this and include that quote in it. IMO this was an error in CDI, it needs to mention the Java EE spec here too, but we can debate that on the EG. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira