Simon,
Comments inline.
On 2/25/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> Hi Rajini
>
> I'm covering old ground here but trying to make sure I'm looking at this
> in
> the right way.
>
> A - How closely class loading should be related to model resolution, i.e.
> options 1 and 2 from previously in this thread
> A1 (classloader uses model resolver) - standardizes the artifact
> resolution process but make classloading more complex
I am not sure A1 really "standardizes" artifact resolution. In both A1 and
A2, import/export matching is done in contribution-java, in exactly the same
import.java/export.java-related classes. The difference between A1 and A2 is
purely in who iterates through the import/export list. In both cases, the
code is in contribution-java. In A1, the iteration is in
ClassReferenceModelResolver, and in A2, the iteration code is in
ContributionClassLoader. I dont see any reason why
ClassReferenceModelResolver should look similar to any other model resolver
- after all it uses a classloader, unlike other model resolvers. I am not
convinced A1 actually adds any real value, apart from removing the
get/setClassLoader method from Contribution.java.
> A2 (classloader doesn't use model resolver) - simplifies the
> classloading
> process but leads to multiple mechanisms for artifact resolution
A2 has the advantage that classloading is done by classloaders, and
classloaders alone. You might have got to the first classloader through a
model resolver in the first place (when Tuscany is resolving a class whose
name was found in a composite/componentType file), but in all other cases
(and most application classloading is not triggered by Tuscany),
classloading is (and IMHO should be) the job of a classloader.
For loading of an imported class,
A1 uses the call stack:
1.1ExtensibleModelResolverA->ClassReferenceModelResolverA->ClassLoaderA->ExtensibleModelResolverB->ClassReferenceModelResolverB->ClassLoaderB
(for class loading triggered by Tuscany)
OR
1.2ClassLoaderA->ExtensibleModelResolverB->ClassReferenceModelResolverB->ClassLoaderB
(For application classloading)
A2 uses the call stack:
2.1ExtensibleModelResolverA->ClassReferenceModelResolverA->ClassLoaderA->ClassLoaderB
(For classloading initiated by Tuscany)
OR
2.2 ClassLoaderA->ClassLoaderB (For application classloading)
While I think 1.1 is fine, even with a deeper stack compared to 2.1, I think
1.2 is unnecessary, and I would very much prefer to use 2.2, unless there
was a very good reason why it couldn't be.
> B - Support for split namspaces/shared packages
> Supporting this helps when consuming Java artifacts in the case where
> there is legacy code and for some java patterns such as localization. I
> expect this
> could apply to other types of artifacts also, for example, XML schema
> that use library schema for common types.
> C - Recursive searching of contributions
> It's not clear that we have established that this is a requirement
> D - Handling non-existent resources, e.g by spotting cycles in
> imports/exports.
> It would seem to me to be sensible to guard against this generally. Is a
> specific requirement if we have C
>
> It seems to me that there we are talking about two orthogonal pieces of
> work. Firstly B, C & D describe behaviour of artifact resolution in
> general.
Yes, we do need to agree on the semantics of import/export statements, and
ideally they should be the same regardless of whether they refer to
import.java/export.java or some other types of import/export statements.
Then, given the artifact resolution framework, how does Java classloading
> fit in, I.e. A1 or A2.
>
> Can we agree the general behaviour first and then agree javal classloading
> as a special case of this.
I dont think Java classloading should be seen as a special case of model
resolution, at least I dont think Java classloading should be dependent on
model resolution (model resolution involving classes is dependent on Java
classloading, I think the reverse dependency should be avoided if possible).
Loading of classes differs from artifact resolution in many ways:
1. Model resolution is used to resolve artifacts from SCA
contributions, while classloading is used to resolve classes from
contributions, Tuscany runtime, or indeed from anywhere on the CLASSPATH.
2. Model resolution is explicitly triggered through Tuscany. Most
classloading is implicitly triggered by the VM. Application classloading may
be explicitly triggered, again without going through Tuscany.
3. Artifacts loaded by Tuscany using model resolution can be loaded by
the application in some other way (classLoader.getResource or
file.read). Applications loaded by Tuscany are forced to use the
Tuscany contribution classloader to load all application classes, whether
they like it or not. Classloading is far more pervasive than other Tuscany
model resolution, and its implications extend beyond the Tuscany runtime.
4. Multiple artifacts of the same name can easily coexist across
contributions without affecting each other. For classes, it is absolutely
essential for a consistent class space to consist at most one class of any
name.
5. Classloaders cannot violate Java classloading constraints, while
there are no such constraints on any other model resolution. These
constraints which are outside of the SCA specification make classloading
different from SCA model resolution. While it may be necessary to use OSGi
bundle contributions in cases where the dependency across contributions
requires the specification of complex classloading constraints, SCA
contribution classloading needs to be kept simple to enable the analysis of
constraint violation errors.
6. Attempting to load a non-existent artifact during model resolution
is probably an error condition, where recovery is not very important.
Attempting to load a non-existent class is not always an error condition
since ClassNotFoundExceptions are often caught and handled in Java code.
Regards
>
> Simon
>
--
Thank you...
Regards,
Rajini
