Rajini Sivaram wrote:
Sebastien,
Thank you for the clarification. A few comments inline.
On 3/4/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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.
I suspected that if contribution A and contribution B provided entries of
the package a.b.c, A and B would both import and export the package a.b.c,
resulting in a cycle. Maybe I was wrong. Anyway, I would expect a solution
for (a) to fix (b) as well.
Ah, yes, the configuration you describe requires both (a) and (b) to
work. I suspect that (b) currently works, so as you say fixing (a)
should solve everything.
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?
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.
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.
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.
Hence ClassReferenceModelResolver currently delegates to
OSGiClassReferenceModelResolver to force classes from OSGi contributions to
be loaded by the OSGi bundle (using OSGi import/export statements with
support for versioning etc). OSGi contributions also support SCA
import/exports, to enable OSGi contributions to import classes from non-OSGi
contributions. These SCA import/exports are handled by installing dummy
bundles into OSGi, and hence class resolution for an OSGi bundle should be
based purely on that bundle, with OSGi handling all import/exports.
Yeah I saw that hack, I'll watch out :). I think it won't be bad though
as one of the benefits I'm expecting from the changes described here is
to allow extensions to handle class loading from a graph of
contributions the way they want, without necessarily having to go
through a graph of model resolvers (since they won't have to delegate to
model resolvers or be invoked by model resolvers anymore).
BTW I completely agree with your earlier statement in this thread:
"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 don't think common code is needed either, actually common code would
probably complicate things by getting in the way of frameworks like OSGi
which can load classes from a graph of bundles themselves.
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
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
