[snip]
Raymond Feng wrote:
Hi,
I created a WIKI page
(http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts)
to track discussions around this area.
I have also checked in the following algorithm in trunk for WSDL/XSDs.
1) For each WSDL file in a SCA contribution, the
WSDLDocumentProcessor.read() method will only read the target
namespaces for the WSDL definition and inline schemas using StAX. An
instance of WSDLDefinition with the namespace and location is
returned. The definition is null because the it's not fully loaded
yet. The model is then added to the WSDLModelResolver by the
ContributionServiceImpl.
2) During the resolve phase, when a reference to a WSDL Definition
(from <interface.wsdl> or <binding.ws>) is resolved by an artifact
processor (for example, WSDLInterfaceProcessor), it will be delegated
to the WSDLModelResolver.
3) The WSDLModelResolver looks up all the WSDLDefinition(s) created
under step 1 using the namespace of the WSDLDefintion (proxy) to be
resolved. It then fully loads the model using WSDL4J. If there are
multiple WSDLDefintions under the same namespace, the definitions are
aggregated. It's achieved by creating a Definition with Import(s) for
each of the Definitions.
4) The import/include among WSDL/XSD files follow the document-based
resolving strategy:
a) If the location/schemaLocation attribute is an absolute URI (for
example, http://www.example.com/a.wsdl), it will be used as is.
b) If the location/schemaLocation attribute is a relative URI
without a leading / (for example, ../xsd/a.xsd), then it will be
resolved against the base document URI.
c) If the location/schemaLocation attribute is a relative URI with
a leading / (for example, /wsdl/b.wsdl), then it will be resolved
against the base URI of the containing SCA contribution.
d) If the location/schemaLocation attribute is absent, it's not
supported (or we can pick the 1st document in the contribution that
matches the namespace?)
I think the sample strategy can apply to other XML documents such as
SCA componentType files and BPEL files.
What do you guys think?
Thanks,
Raymond
I took a look at what you did and it looks good to me. I'm going to try
to apply the same technique to Composites, ConstrainingTypes and
ComponentTypes. Loading them dynamically will improve footprint, startup
time and overall experience as we won't be broken anymore by erronenous
but unused files, because we won't be loading them aggressively any more.
I also noticed that you had to hardcode some of the factories in the
WSDLModelResolver for example. I'm in the middle of fixing that simply
by passing the ModelFactory extension point to ModelResolvers. This is
going to be a pretty common requirement as ModelResolvers will have to
dynamically create instance model objects as they are resolved
(Composite, ConstainingType and ComponentType resolvers will need the
factories too).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
