Maybe the best approach is keep the physical artifacts in the list as-is
without aggregation. And we change the artifact resolving so that it only
happens at lower levels such as WSDL portType, binding, service or XSD
element, type. This way we can find the accurate artifact.
The current Tuscany code tries to resolve WSDLDefinition/XSDefinition first.
It seems to be causing ambiguity when there are multiple WSDLs/XSDs under
the same namespace.
Here are some examples of references to WSDL/XSD elements from SCA.
[EMAIL PROTECTED] --> WSDL portType
[EMAIL PROTECTED] --> WSDL portType, service, binding, etc.
property --> XSD element or type
In the above, we do have the information about what type of artifacts we're
trying to resolve. Do any of you see a case that we can only resolve at WSDL
Definition or XML Schema level?
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, February 14, 2008 9:25 AM
Subject: Re: Processing multiple WSDLs in the same namespace
hi Ramyond
Comments in line...
Simon
On Thu, Feb 14, 2008 at 4:57 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Let me explain what I thought in this example: a contribution with two
xsds
under the same tns (http://ns1): a.xsd and b.xsd.
When the XSDs are initially processed, we only create a XSDefinition
object
to hold the tns and URL of the xsd. The XSD is not fully loaded at this
point. The XSDefinition object is added to the definitions list. So we
end
up with two XSDefinition objects in the list, one for a.xsd and one for
b.xsd.
When the first request comes to resolve the XSDefinition for
"http"//ns1",
we create an aggregated XSDefinition which use "xsd:include" to reference
a.xsd and b.xsd. Both a.xsd and b.xsd are fully loaded. (I'm not sure if
the
XSD can include WSDLs for the inline schemas and we might have problems
here)
I observe that in the following case:
WSDL-A - namespace X
Inline XSD-A - namespace Y
WSDL-B - namespace X
Inline XSD-B - namespace Y
That XSD-A and XSD-B are both registered with the XSDModelResolver in
their
unresolved state. When WSDL-A is resolved is causes a request for XSD-A to
be resolved. This in turn causes the code to try and aggregate XSD-A and
XSD-B together. However the resolution process for XSD-B has not started
yet
and hence it is ommitted from the aggregation and, with the code as it
currently is, is lost when the definitions list is replaced with the
aggregated XSD.
The reason I replaced the list with the facade is to avoid reaggregation.
This way, we'll return the aggregated XSDefinition next time directly
from
the list.
Ah I see. Is there any function harm in re-doing the aggregation or if
this
a performance thing?
I'm not sure why you see the hierarchy. Can you tell me what you found
out?
I'm not sure either looking back. I don't see it now. It's possible I was
just confusing this with the effect of the disappearing XSD, i.e. I saw
the
result nest facade only having 1 object inside it and assumed,
incorrectly,
that is was another facade.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Thursday, February 14, 2008 6:15 AM
Subject: Processing multiple WSDLs in the same namespace
> re. https://issues.apache.org/jira/browse/TUSCANY-2043
>
> Part of the the fix for this involves removing a FIXME in
> org.apache.tuscany.sca.interfacedef.wsdl.xml.XSDModelResolver.
> Specifically
> at the bottom of the aggregate method I need to comment out two
> lines...
>
>
> // FIXME: [rfeng] This is hacky
> //definitions.clear();
> //definitions.add(aggregated);
> return aggregated;
>
> Raymond, do you recall why these were put in?
>
> Because the non-aggregated definition is replaces with the aggregated
> definition the effect of including them is to build a hierarchy of XSD
> that
> could end up looking like:
>
> facade
> facade
> facade
> xsd
>
> depending on how may WSDL/Schema there are in the same namespace.
>
> The other, possibly more dangerous, effect is that some schema are
omitted
> because the "aggregated" schema may not include all of the schema that
are
> in the original definitions list, for example, if many schema are in
> the
> same namespace then only the inline schema for WSDL that have been
> resolved
> so far will be present as opposed to all of the XSD that could be
> available.
> So the original list is cleared and replaced with a shortened list. The
> XSD
> that have now been remove will not be resolved.
>
> I get a clean build with these two lines removed, and with the other
> required changes in place, so will check my fix in unless someone
shouts.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
