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]
