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
