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 Mon, 03 Mar 2008 20:13:44 GMT
On 2/29/08, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>
> ant elder wrote:
> > On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> >> Rajini Sivaram wrote:
> >>> On 2/22/08, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
> >>>>>> Jean-Sebastien Delfino wrote:
> >>>>>> Great to see a *test* case for cycles, but my question was:
Do you
> >>>>>> have a *use* case for cycles and partial packages right now
or can
> >>>> it >> be fixed later?
> >>>>
> >>>>> Rajini Sivaram wrote:
> >>>>> No, I dont have an use-case, at least not an SCA one. But there
are
> >>>> plenty
> >>>>> of them in OSGi - eg. Tuscany modules cannot run in OSGi without
> >> support
> >>>> for
> >>>>> split-packages.  Of course you can fix it later.
> >>>> I'm not arguing for or against fixing it now or later, I'm trying to
> >> get
> >>>> the real use case to make a decision based on concrete grounds. Can
> you
> >>>> point me to your OSGi use cases, or help me understand "Tuscany
> modules
> >>>> cannot run in OSGi without support for split packages"?
> >>>
> >>>  Tuscany node and domain code are split into three modules each for
> API,
> >> SPI
> >>> and Implementation eg. tuscany-node-api, tuscany-node and
> >> tuscany-node-impl.
> >>> The API module defines a set of classes in
> org.apache.tuscany.sca.nodeand
> >>> the SPI module extends this package with more classes. So the package
> >>> org.apache.tuscany.sca.node is split across tuscany-node-api and
> >>> tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest
> >>> entries for Tuscany modules, we would get three OSGi bundles
> >> corresponding
> >>> to the node modules. And the API and SPI bundles have to specify that
> >> they
> >>> use split-packages. It would obviously have been better if API and SPI
> >> used
> >>> different packages, but the point I am trying to make is that
> splitting
> >>> packages across modules is not as crazy as it sounds, and split
> packages
> >> do
> >>> appear in code written by experienced programmers.
> >>>
> >>> IMO, supporting overlapping package import/exports is more important
> >> with
> >>> SCA contributions than with OSGi bundles since SCA contributions can
> >> specify
> >>> wildcards in import.java/export.java. eg. If you look at packaging
> >>> tuscany-contribution and tuscany-contribution-impl where
> >>> tuscany-contribution-impl depends on tuscany-contribution, there is no
> >> clear
> >>> naming convention to separate the two modules using a single
> >> import/export
> >>> statement pair. So if I could use wildcards, the simplest option that
> >> would
> >>> avoid separate import/export statements for each subpackage (as
> required
> >> in
> >>> OSGi) would be to export org.apache.tuscany.sca.contribution* from
> >>> tuscany-contribution and import org.apache.tuscany.sca.contribution*in
> >>> tuscany-contribution-impl. The sub-packages themselves are not shared
> >> but
> >>> the import/export namespaces are. We need to avoid cycles in these
> >> cases.
> >>> Again, there is a way to avoid sharing package spaces, but it is
> simpler
> >> to
> >>> share, and there is nothing in the SCA spec which stops you sharing
> >> packages
> >>> across contributions.
> >>>
> >>> I dont think the current model resolver code which recursively
> searches
> >>> exporting contributions for artifacts is correct anyway - even for
> >> artifacts
> >>> other than classes. IMO, when an exporting contribution is searched
> for
> >> an
> >>> artifact, it should only search the exporting contribution itself, not
> >> its
> >>> imports. And that would avoid cycles in classloading. I would still
> >> prefer
> >>> not to intertwine classloading and model resolution because that would
> >>> unnecessarily make classloading stack traces which are complex anyway,
> >> even
> >>> more complex that it needs to be. But at least if it works all the
> time,
> >>> rather than run into stack overflows, I might not have to look at
> those
> >>> stack traces....
> >>>
> >>>
> >>>
> >>> and this will convince me to help fix it now :) Thanks.
> >>>
> >>>
> >>> It is not broken now - you have to break it first and then fix it :-).
> >>>
> >> I have reviewed the model resolution and classloading code and found
> the
> >> following:
> >>
> >> - Split namespaces are currently supported (for example by the WSDL and
> >> XSD resolvers). The model resolver mechanism does not have an issue
> with
> >> split namespaces.
> >>
> >> - The Java import/export resolvers do not seem to support split
> packages
> >> (if I understood that code which was quite tricky), but that's an issue
> >> in that Java import/export specific code, which just needs to be fixed.
> >> I'll work on it.
> >>
> >> - The interactions between the Java import/export listener, the model
> >> resolvers and the ContributionClassLoader are way too complicated IMHO.
> >> That complexity is mostly caused by ContributionClassLoader, I'll try
> to
> >> show a simpler implementation in a few days.
> >>
> >> - Dependency cycles are an exception in Java as build tools like Maven
> >> don't support them, but can exist in XSD for example. Supporting cycles
> >> just requires a simple fix to the import model resolvers, I'll help fix
> >> that too.
> >>
> >> Hope this helps.
> >> --
> >> Jean-Sebastien
> >>
> >>
> > It doesn't feel like there is agreement on the approach yet so would you
> > hold off committing changes to see if we can get better consensus?
> >
> > Reading through the thread I'm not sure that I properly understand
> exactly
> > what it is thats broken with the code as it is, would you be able to
> create
> > a testcase that shows what it is that is broken to help us better
> > understand?
> >
>
> 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.

(e) has also been (almost) fixed. There is still a classloader object
associated with contributions, but it is set/get only by contribution-java.

Rajini raised (a), (b), (d), (g) (and maybe (f) too?).


I raised (a) and (b) as problems with the model resolver. These are
currently not issues with contribution classloading since the contribution
classloader does not use model resolvers.

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.


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 do completely agree that model resolution needs to be fixed.

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


-- 
Thank you...

Regards,

Rajini

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