tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajini Sivaram" <rajinisiva...@googlemail.com>
Subject Re: Classloading code in core contribution processing
Date Tue, 04 Mar 2008 09:11:59 GMT

Thank you for the clarification. A few comments inline.

On 3/4/08, Jean-Sebastien Delfino <jsdelfino@apache.org> 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.

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 :-).

> > 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.

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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Thank you...



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message