I had a chat with Raymond offline on Friday and the bottom line is I think we need to switch to a classloader strategy that can very depending on the contribution type as follows.
1/ valid contribution structures (The letters and numbers here refer to scenarios from the list at [1]) B - EAR is artifact in some contribution (dir, zip, jar etc.) (nested) E - EAR (WAR or EJB Jar) is a self contained contribution (contrib) C - EAR is another contribution (other) - same effect as B re. classloading The implication here is that, as per previous notes on this thread, we don't deal with the case where a WAR or an EJB Jar appear independently inside an SCA contribution. Scenarios 1, 2, 4, 7, 8 & 10 are therefore not supported and documented as a restriction 2/ in the case of scenario B the contribution format will be jar, zip, folder etc and the classloader strategy will be set to be appropriate to those formats. I.e. similar to what we have at the moment where all classes are the root of the contribution are loaded. If you need to reference java resource from interface.java then they need to be packaged in the contribution itself. We won't pull then from the nested JEE artifact which is considered isolated from a classloading point of view. Local message passing is likely to be problematic in this scenario so should we disallow it? 3/ in the case of scenario E JEE class loader strategies will be in force for the entire contribution. 4/ The contribution classloader extension point needs to be driven by the contribution type. We need to record the type of the contribution based on the extension and possible its contents. 5/ Any classloaders that are provided to load JEE classloaders during Read/Resolve phases must be the same classloaders as are used by the JEE container at runtime. This is an opportunity to remove the contribution structures dependency on the Java classloader but that may be a change too far for 1.x so the proposition at the moment is to simply allow the runtime to choose an appropriate classloader rather than replace the classloader structures in the runtime. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
