On Feb 19, 2008 11:19 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Rajini Sivaram wrote: > > 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. > > That's all good, I'm happy with that isolation support, but would like > to see it in the module implementing support for import/export.java. > > > > > 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. > > Agreed that classloading should go through a ModelResolver but that does > not mean "tied with a single ModelResolver in contribution-impl", IMO > contribution-java should provide an implementation of a ModelResolver > that handles classloading as specified in the import.java export.java > statements. >
+1, We had classReferenceModelResover in contribution-java, but it looks like it now delegate to a OSGIClassReferenceModelResolver outside import/export java module > > > > 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. > > > > Sorry, I may be missing something, but I'm a little lost here: > > - import.resource is not implemented yet, Luciano is just starting to > implement it. > > - its syntax should not be uri="a.b.c" as this is a Java package syntax, > I'd expect to see something like a/b/c.html instead. > Yes, this is how I have it locally for now. > - when it gets implemented I fail to see why it should be tied to or > require a class loader. > > - what can be loaded by a Java classloader, .class files, .gif files or > whatever should be controlled by import/export.java. > > - finally, import.resource should be in a contribution-resource > extension like the other extensions... not in contribution-impl. > +1, this is what I have locally... BTW, if people are looking for contribution-resource I could commit the pieces that I have and not add to the build, just in case it gets easier for people to look at it and comment. > -- > > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
