Jean-Sebastien Delfino wrote:
I completely agree with you that having a ClassLoader delegate to a
ModelResolver delegating to a ClassLoader etc will cause confusion.
So, how about having ContributionClassLoader implement the ModelResolver
interface?
Yes, that sounds like a good idea - if it can be made to work :-).
OK, I'll do some experiments with that approach in sandbox, and then you
and others too can look and jump in with any ideas. This is a complex
area so the more eyes can look at code and help improve it with new
ideas the better.
...
I'm proposing the following:
- Have ContributionClassLoader implement the ModelResolver interface,
allowing it and its other ClassLoader friends to be associated with
Contribution, Imports, Exports, everywhere we can store ModelResolvers
right now.
- Merge ClassReferenceModelResolver into ContributionClassLoader, as we
don't need to have a ModelResolver delegating to a ClassLoader, and they
can be a single object.
- Remove get/setClassLoader from Contribution, making it independent of
the support for Java artifacts as it should be.
...
When you make the changes, could you watch out for support for OSGi
contributions? Classloading for OSGi contributions is currently a hack
since
only one model resolver can be associated with each model type in
Tuscany.
I'm finally finding a little bit of time to work on this. We have more
OSGi samples and test cases now, I'm hoping that they'll help validate
the approach.
Also I'm trying to see how to reconcile the way we bootstrap code in the
domain manager and the node runtime and that will require a common
approach to classloading (right now the domain manager and the runtime
are using completely different classloader implementations).
I'll start to hack and experiment around that classloading code in a
sandbox to not break the trunk.
--
Jean-Sebastien
