Rajini Sivaram wrote:
> Jean-Sebastien Delfino wrote:
>> ...
I think that the following issues have been raised in this thread:
a) contribution dependency cycles
b) partial package contributions
c) ability to use contributions without providing a ClassLoader
d) error handling (handling of ClassNotFound and related errors)
e) function layering (contribution code depending on Java support)
f) increased complexity of the classloading path
g) differences between model resolving and classloading semantics
h) reliance on specific classloader implementations
I initially raised (c) and (e) and was really struggling with (f).
(c) has already been fixed (as a response to your first note in the thread)
- contributions do not require a classloader anymore, only
ClassReferenceModelResolver which loads classes requires a classloader.
Yes, Thanks for fixing that.
(e) has also been (almost) fixed. There is still a classloader object
associated with contributions, but it is set/get only by contribution-java.
That's the next thing that I think we could fix, as it is odd to have
both a ModelResolver and a ClassLoader in Contribution, and Contribution
should really be independent of the support for Java artifacts.
Rajini raised (a), (b), (d), (g) (and maybe (f) too?).
I raised (a) and (b) as problems with the model resolver.
(a) is definitely an issue, demonstrated in the test case that I've
added to the contribution-multiple module, and there is a simple fix for
it. I think that we just need to detect cycles in one of the "import"
resolvers.
Unless I'm mistaken, (b) seems to work though. I'll investigate more
tomorrow.
These are
currently not issues with contribution classloading since the contribution
classloader does not use model resolvers.
Right, but I'm hoping that after fixing (a) we can get class loading and
model resolution to converge a bit more (more on this below).
I raised (g) and I would like the semantics of import/export to be more
consistent across model resolution and class resolution. I am less keen on
the solution involving common code.
I did raise (f) as well, but I was looking at complexity from a different
point of view. I think most classloading is not initiated by Tuscany, and
classloading errors are inevitable. It doesn't matter how good contribution
classloading is, I can always create a set of contributions with
import/export statements which result in class validation errors as a result
of consistency failures. IMHO, adding model resolver to the classloading
path might make it easier for Tuscany developers to understand classloading
errors, but it will make it much harder for application developers to walk
through and debug a NoClassDefFound error, since most application developers
will have some understanding of classloaders, but little or no understanding
of Tuscany model resolution code.
I'd like to actually write code for this... as it's difficult to go
through code details in email, but I was thinking that a small change
could help.
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?
Looks like Luciano is providing an <import.resource>, which will allow
resources to be loaded without depending in <import.java>.
Simon has helped organize the discussion with valid questions on the
actual requirements and scenarios.
Raymond proposed a classloader extensibility mechanism, which should
help with (h).
Please, anybody jump in if you disagree with this summary or think I've
missed or mis-interpreted anything :)
I still dont understand the changes that you are proposing for contribution
classloading.
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.
I do completely agree that model resolution needs to be fixed.
I'm glad to see that we agree :). I think that we should fix (a), and
maybe (b) when we understand whether it's actually an issue or if it
just already works :)
I was proposing to help with simple fixes for (a) and (b), and a more
involved fix for (c), (e) and (f). I'm going to hold off on these fixes
since you're asking for it. Instead I will contribute test cases for
(a) and (b), hoping that it will help people understand what's broken.
Ant, do you want to help fix any of this?
--
Jean-Sebastien
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
