Classloading : Application contribution classloaders
----------------------------------------------------
Key: TUSCANY-1871
URL: https://issues.apache.org/jira/browse/TUSCANY-1871
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Core Runtime
Reporter: Rajini Sivaram
Details of the discussion on classloading changes for Tuscany are on the dev
mailing list on this thread:
http://www.mail-archive.com/[email protected]/msg24774.html
And on the WIKI
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java
Changes in this patch introduce separate classloaders for each contribution.
SCA contribution import/export spec cannot be implemented using a standard Java
parent-child classloader delegation model. But SCA contribution import/export
spec is a subset of OSGi package import/export (wiring of import/export is more
complex in OSGi since it includes versions and other attributes). Hence an
OSGi-style classloader is ideal for Tuscany to enforce SCA contribution spec.
Each contribution will have an associated classloader. This will be an subclass
of URLClassLoader, and will have the Java application classloader based on
CLASSPATH as its parent (the parent classloader will be obtained from the
thread context). The defining classloader for any application class will be the
classloader corresponding to the SCA contribution containing the class.
ContributionClassLoader.findClass will search the contribution for the class,
and if not found, it will search other classloaders of other contributions
wired using SCA import/export. Like OSGi, an overlapping class space will be
defined for each contribution which consists of the classes in the contribution
and imported packages from other contributions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
