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