Luciano, Comments inline.
On 2/19/08, Luciano Resende <[EMAIL PROTECTED]> wrote: > > 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 ClassReferenceModelResolver delegates to OSGiClassReferenceModelResolver only for OSGi bundle contributions. This was necessary to implement bundle contributions since a single model resolver is chosen by ExtensibleModelResolver based on the type of artifact being resolved. A chained set of model resolvers where OSGiClassReferenceModelResolver was searched before ClassReferenceModelResolver to resolve classes would have been better, but it required more extensive changes. > > > > > 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] > > -- Thank you... Regards, Rajini
