tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: Classloading code in core contribution processing
Date Sat, 01 Mar 2008 01:21:47 GMT
I just finished committing Import/Export resource support, more
details on following thread [1].

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28457.html

On Fri, Feb 29, 2008 at 11:10 AM, 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).
>  Rajini raised (a), (b), (d), (g) (and maybe (f) too?).
>  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 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
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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