Sebastien, ContributionTestCase in itest/contribution-classloader contains a test which runs into stack overflow if classes are resolved using ModelResolver. I have added another test in there for testing for ClassNotFoundException in the same scenario. To trigger the failure, you need to modify ContributionClassLoader.findClass to use the model resolver of exporting contributions to resolve classes instead of their classloader.
On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Rajini Sivaram wrote: > ... > > I will commit some changes now which moves ContributionClassLoader into > > contribution-java. > > Great, Thanks. > > ... > > We have two choices for classloading: > > > > 1. ContributionClassLoader loads classes from its own contribution, > > and if it cannot find it, it can use the standard model resolver code > to > > search other contributions which export the package. This essentially > means > > that classloading will always go through ExtensibleModelResolver > (since > > there is no way to get to the contribution's > ClassReferenceModelResolver > > directly). And this affects not just classes loaded by Tuscany, but > all > > classloading inside applications loaded as contributions. > > 2. ContributionClassLoader loads classes from its own contribution > and > > also searches other exporting contributions using their contribution > > classloader, bypassing the model resolver. This relies on > contribution > > classloader being able to get to the classloaders of exporting > contributions > > (currently Contribution.getClassLoader()). > > > > At the moment, we use 2) rather than 1). Apart from the performance > impact > > of using extensible model resolver for all classloading, I don't believe > > that the Tuscany model resolvers handle cycles in import/exports > properly. > > This may not be an issue with other artifact resolution where the > artifacts > > are always expected to be found, and all resolution is explicitly > triggered > > by an application or Tuscany. For classloading, searching for > non-existent > > classes, expecting to obtain a ClassNotFoundException is used routinely > in > > Java code, including inside Tuscany. And classloading is implicitly > > trigerred by the VM. IMO, running into stack overflows in classloading > is > > unacceptable regardless of whether the import/export statements > contained > > unexpected cycles and regardless of the fact that an application was > trying > > to load a non-existent class. The current model resolution code cannot > > handle packages that are split across multiple contributions (and before > you > > say why would anyone want to split packages across contributions, this > was > > one of the problems I first ran into when trying to run Tuscany under > OSGi > > since Tuscany modules do use split-packages). > > > > In order to use 2), contribution-java needs some way of obtaining the > > classloader of exporting contributions. Since there is currently no way > for > > contribution-java to get directly to the ClassReferenceModelResolver > from a > > contribution, the classloader is still associated with the contribution. > So > > Contribution.java still contains getClassLoader and setClassLoader, but > > these are only used by contribution-java. Can you suggest a better way > to > > get/set classloaders for contributions which can be contained inside > > contribution-java? > > > > If I parsed all this correctly: > - we can use ModelResolvers (1) or bypass them (2) > - ModelResolvers don't handle import cycles and partial packages > > I think that (1) is better. Do you have a use case for cycles and > partial packages right now or can it be fixed later? > > ... > > the new code will allow applications to load resources using their > classloader only if there are explicit <import.java/> statements for > > the directory containing the resource. > > Sounds good. > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thank you... Regards, Rajini
