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.
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.
- 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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
