Simon, A few comments inline.
On 2/25/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > Hi Rajini > > just back in from vacation and catching up. I've put some comments in line > but the text seems to be circling around a few hot issues: > > - How closely class loading should be related to model resolution, i.e. > options 1 and 2 from previously in this thread > - Support for split namsepaces/shared packages > - Recursive searching of contributions > - Handling non-existent resources, e.g by spotting cycles in > imports/exports. > > These are of course related but it may be easier if we address them > independently. > > Simon > > > > > > > > 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. > > > The split packages across the various node/domain module was not by > design. > The code moved around and that was the result. We could go ahead and fix > this. Are there any other explicit examples of split packages that you > happen to know about No, as far as I know, in Tuscany modules, the only packages that are split across multiple modules are o.a.t.s.node and o.a.t.s.domain. I was just using it as an example to show that there may be existing code which use split-packages, and the test case for classloading in the presence of split-packages is not just a fabricated test case. For Tuscany, I agree that it would be easy to fix domain and node to use different package names, but that may not always be the case with 3rd party code already packaged as jars which need to be imported as contributions. Split-packages are not good practice (according to OSGi), but there are valid use-cases for them. The most commonly cited example in OSGi is Java localization classes. > > 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'm not sure if you are suggesting that we implement a wildcard mechanism > or > that we impose some restrictions, for example, to mandate that > import.javashould use fully qualified package names (as it says in > line 2929 of the > assembly spec). Are wildcards already supported? I thought Sebastien added support for wildcards in import.java since I remember seeing .* in the tutorials (maybe I am wrong). The assembly spec seems to recognize that artifacts from the same namespace > may appear in several places (line 2946) but it is suggesting that these > multiple namespace references are included explicitly as distinct import > declarations. If import statements specify location, I would expect distinct import statements, but I am not sure I would expect to find two separate import declarations when importing a split-package where location is not specified. > > > > 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.... > > > > Looking at the assembly spec there is not much discussion of recursive > inclusion. I did find line 3022 which describes the behaviour > w.r.t"indirect dependent contributions" which to me implies that > contributions > providing exports should be recursively searched If exports are recursively searched during model resolution, there needs to be explicit support for handling cyclic dependencies. And I would much rather not have classloading intertwined with a recursive model resolver, unless it is absolutely necessary. > > > > > > 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 :-). > > > > > > > -- > > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Thank you... > > > > Regards, > > > > Rajini > > > -- Thank you... Regards, Rajini
