Sebastien, Contribution classloader was introduced to force isolation of contributions. Prior to this, all classes were loaded using a single CLASSPATH-based classloader, which meant that Java classes had visibility of all classes and resources that could be loaded using CLASSPATH, regardless of whether they were imported explicitly from other contributions.
For Java classes in contributions, it is essential for classloading to be tied with ModelResolver to ensure that classes inside contributions can see classes imported from other contributions, and use the exporting contribution's classloader to load imported classes. This is absolutely necessary to avoid ClassCastExceptions and NoClassDefFoundErrors. I assumed (probably wrongly) when I wrote the contribution classloader that Java classes inside contributions also have visibility of resources that are imported using import statements other than import.java. For example, if I have Contribution A: <import.java package="x.y.z" /> <import.resource uri="a.b.c" /> Contribution B: <export.java package="x.y.z" /> Contribution C: <export.resource uri="a.b.c" /> Is there a difference between what is visible to ContributionA (everything from A, package x.y.z from B and resource a.b.c from C) and what is visible to classes from Contribution A? I assumed that they should be the same. If classes from ContributionA should not be allowed to load the resource a.b.csince there is no < import.java/> statement for the package containing the resource, classloading code can be moved to contribution.java. Thank you... Regards, Rajini On 2/16/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > The last 2 weeks I've been working with the contribution processing code > and am bumping into the following issues: > > - ContributionImpl is tied to a ClassLoader > > - ModelResolver as well, and it seems to be used to resolve classes in > some cases. > > - We're now using a special ContributionClassLoader implementation. > > - The ContributionService depends on it and assumes that it should be > used on all contributions. > > - ContributionClassLoader contains code to navigate the imports/exports, > assumes that all contributions are using such a ContributionClassLoader, > calls implementation methods on it to match imports and exports and > resolve classes, going around the regular model resolver based scheme > used for everything else. > > - contribution-impl depends on contribution-java, this is going > backwards IMO and breaks modularity and pluggability, as a core module > should not have dependencies on extensions. > > - I don't fully understand what JavaImportExportListener does but it > looks like an attempt to implement a fancy domain update scheme, > bringing another way to match Java imports/exports. Unfortunately it's > only half implemented. > > All this complexity related to classloading makes my head spin, prevents > me from using the contribution service outside of a running runtime > (where I don't have a classloader at all) and should not be in the core > contribution code in the first place, as processing of Java classes > should be handled in a Java specific extension and not in the core. > > For now I have to make a copy of the contribution code without this > stuff to make progress. Could the people who worked on this classloading > code please help clean it up and move it out of the core contribution > modules? > > Thanks. > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
