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" <tuscany-dev@ws.apache.org> > 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] > >
