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 Wed, 05 Mar 2008 07:04:27 GMT
Rajini Sivaram wrote:
> Sebastien,
> 
> 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.

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


Mime
View raw message