tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Classloading code in core contribution processing
Date Tue, 04 Mar 2008 01:24:55 GMT
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" 

Unless I'm mistaken, (b) seems to work though. I'll investigate more 

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 

> 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


To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message