I just finished committing Import/Export resource support, more details on following thread [1].
[1] http://www.mail-archive.com/[email protected]/msg28457.html On Fri, Feb 29, 2008 at 11:10 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > > On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > >> Rajini Sivaram wrote: > >>> On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
