On Tue, Jan 10, 2012 at 10:02 AM, Millies, Sebastian <[email protected]> wrote: > From: Simon Laws [mailto:[email protected]] > Sent: Tuesday, January 10, 2012 9:56 AM > To: [email protected] > Subject: Re: Possible bug resolving resource imports >> >>On Mon, Jan 9, 2012 at 5:07 PM, Millies, Sebastian >><[email protected]> wrote: >>Hello there, >> >>The following is related to Tuscany 1.6. >> >>I am seeing a problem resolving resource imports when loading multiple >>contributions. >>In particular, I’m seeing error messages like this: >>09.01.2012 17:40:59 org.apache.tuscany.sca.databinding.sdo.ImportSDOProcessor >>SCHWERWIEGEND: Fail to resolve location: SDOTypes/job.xsd >> >>The error occurs when extension elements in the composite file like >> <dbsdo:import.sdo location="SDOTypes/job.xsd"/> >>are processed. >> >>I do not have a small test case ready, but maybe this exposition is enough to >>see what the >>cause of the problem may be. I use the following node API to create nodes: >> >> SCANodeFactory factory = SCANodeFactory.newInstance(); >> SCAContribution[] contributions = new SCAContribution{ c1, c2, c3 } ; >> SCANode node = factory.createSCANode( compositeURI, contributions ); >> >>The order of c1, c2, c3 is in decreasing order of independence, i. e. c3 >>depends on c2 and c1 etc. >>Each contribution may have its own sca-contribution.xml. Indeed, the >>sca-contribution.xml >>containing the resource imports that cannot be resolved sits in c2. >>> >>>Tuscany defers reading the composite content until the contributions have >>>been loaded. However, >>>when the ArtifactModelResolver#resolveModel() kicks in and delegates the >>>resolution to the >>>resource imports, the contribution member in that resolver is c3, which has >>>no imports. >>> >>>I suspect that is a bug. The ArtifactModelResolver should rather consider >>>imports from all the >>>contributions. Has anyone else observed similar behaviour? Is it perhaps >>>related to >>>what Simon Laws observes in TUSCANY-4004 with respect to the loading of wsdl >>>imports? >>> >>><quote> >>>As an aside, while looking that this, I notices that in >>>WSDLModelResolver.loadDefinition() there is a >>>loop over the imports in order to resolve the WSDLDefinition. All the >>>unresolved definitions are >>>represented by the same WSDLDefinition object and the unresolved object >>>becomes the resolved >>>object. This is likely to end in tears if there is more than one import. >>></quote> >>> >>>-- Sebastian >>> >>>PS: As a workaround, I now load c2 twice, i. e. I add it a second a time at >>>the end of the >>>contribution array. >>> >>> >>>IDS Scheer Consulting GmbH >>>Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev >>>Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany >>>- Registergericht/Commercial register: Saarbrücken HRB 19681 >>>http://www.softwareag.com >>> >> >>Hi Sebastien >> >>I don't think it's related to 4004 as that's WSDL specific. >> >>If I remember correctly in 1.x there is a restriction which means that >>contributions have to be loaded in the order dictated by the dependencies >>between them. If I understand your scenario you have; >> >>c3 dependens on c2 which depends on c1 >> >>and hence you load then backwards >> >>c1 followed by c2 followed by c3 >> >>Which contribution contains the composite which has <dbsdo:import.sdo >>location="SDOTypes/job.xsd"/> ? >> >>Which contribution contains SDOTypes/job.xsd ? >> >>Regards >> >>Simon >> >>-- >>Apache Tuscany committer: tuscany.apache.org >>Co-author of a book about Tuscany and SCA: tuscanyinaction.com > > c1 contains SDOTypes/job.xsd and an sca-contribution.xml with a resource > export for it. > c2 contains the composite which has <dbsdo:import.sdo > location="SDOTypes/job.xsd"/> plus > an sca-contribution.xml with the corresponding resource import. c3 only > contains some > additional stuff that depends on c2 and c1. c3 does NOT depend on > SDOTypes/job.xsd and > therefore has no resource import for it. > > The problem is that the presence of c3 HIDES the imports that are present in > c2 at the > time the composite is resolved. > > The reason this can happen is twofold (this is guesswork): > a) Resolving the composite is deferred until after ALL contributions have > been loaded. > b) The ArtifactModelResolver has a member variable called "contribution". The > imports of this > contribution are delegated to when resolving the import.sdo. However, the > variable always > seems to be the LAST contribution that was loaded before the composite is > resolved. (For > which reason the hack of adding c2 once again at the end of the array works > in this > particular case.) > > One could change either a) or b). > > For changing b) I guess one would either need to have a chain of > ArtifactModelResolver instances, > or have a re-usable instance that keeps a list of contributions or > accumulates the imports over > the contributions. > > As for a) one could resolve the composite IMMEDIATELY after loading the > parent contribution that > contains it. Because of the restriction on the load order (dependencies) no > contribution that > is loaded later could conceivably have an impact on resolving the composite, > anyway. > > -- Sebastian > IDS Scheer Consulting GmbH > Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev > Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - > Registergericht/Commercial register: Saarbrücken HRB 19681 > http://www.softwareag.com >
Hi Sebastien As a matter of interest how have you constructed the import/export statements in the sca-contribution.xml files. I'm interested that you mention ArtifactModelResolver. I'd assumed you would be using, for example, <import uri="namespace of xsd/>. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
