Possible bug resolving resource imports

["Millies, Sebastian" <Se...@softwareag.com>]

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

Re: Possible bug resolving resource imports

[Simon Laws <si...@googlemail.com>]

On Mon, Jan 9, 2012 at 5:07 PM, Millies, Sebastian <
Sebastian.Millies@softwareag.com> 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