You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Wayne Keenan <wa...@gmail.com> on 2008/04/28 16:05:58 UTC
XSD REpository
Hi,
I have a WSDl that tries to pull in XSD from the network. I understand that
this is not supported in ODE and the suggested practice is to assemble
the XSDs locally.
http://markmail.org/search/?q=openResource%3A%20invalid%20scheme%20%28should%20be%20urn%3A%29#query:openResource%3A%20invalid%20scheme%20%28should%20be%20urn%3A%29%20from%3A%22Ciot%2C%20Thierry%22+page:1+mid:jn6yqmkatdvvfmjl+state:results
I will do so, but I would like to avoid altering the WSDL at all costs, as
it includes many XSD's, and those XSD's pull in further XSD's recursively.
I was thinking it would be ideal if ODE supported mapping of the imports
URN's to local files, similarly to Apache Synapse. Or is there something
that does this currently that I am missing? or is it in the works?
Also, can anyone recommend a tool to pull down the whole lot in the 1st
place?
Regards
Wayne
Re: XSD REpository
Posted by Wayne Keenan <wa...@gmail.com>.
That's exactly the type of thing I had in mind (Although I'm still using the
built in Synapse one, for now, with a plan to move to the WSo2 repo. in the
not too distant future).
I'm currently importing the FaultReporting OSSJ WSDL in Synapse fine,
unfortunately ODE complains, hence my original post.
I agree there will be lots of cases in which worms may appear out of can,
but many will hopefully be avoided thru sensible design and implementation
of the XSD imports. I reckon that if Synapse is able to import the OSSJ WSDL
okay then there is hope for this particular case elsewhere.
My question about if anyone is looking at it was to understand if I should
embark on something isolated and tactical or something longer ranging and
shared, should my current project time scales allow it.
Regards
Wayne
On Mon, Apr 28, 2008 at 11:07 PM, Tammo van Lessen <tv...@gmail.com>
wrote:
> Hi,
>
> Paul Brown wrote:
>
> >
> > Hi, Wayne --
> >
> > I have a WSDl that tries to pull in XSD from the network. I understand
> > > that
> > > this is not supported in ODE and the suggested practice is to assemble
> > > the XSDs locally.
> > >
> >
> > It isn't the way that users would necessarily like to have the feature
> > ("Just find my stuff!"), but if you believe in "least surprise" as a design
> > constraint, it's the best choice. Resources can move, be unavailable,
> > change, etc. It's better to have the user make explicit choices.
> >
> > You *could* try to engineer in a feature that would supply a different
> > ResourceFinder implementation to the compiler (via the
> > BpelC#setResourceFinger) and actually fetch WSDL/schema, but that will
> > surely open at least one can of worms. Maybe a
> > --resource-finder-fqcn=org.foo.Finder and then require a default
> > constructor?
> >
>
> An interesting variant of this could be an integration with e.g. WSO2's
> repository. AFAIK they are storing WSDLs/XSDs and perhaps also BPEL files,
> with versioning etc. If the repository supports a flattening (i.e. fetching
> and storing all includes and dependencies) that would make a good supplement
> to Ode, wouldn't it?
>
> Tammo
>
Re: XSD REpository
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Paul,
Paul Brown wrote:
> I like anything that doesn't bloat our required libraries. As long as
> it is something that could get pulled in off the classpath, then a
> wrapper for the WSO2 repository (or Mule Galaxy or
> YourFavoriteRegistryHere) would be a good thing.
AFAIK both provide RESTful APIs so such an integration should not bloat
the classpath. However, regarding the worms, it just shifts the
complexity of dependency management to the repository (under the
assumption that this is exactly its purpose). Therefore, it must always
be available.
> Did we ever make a firm decision about a set of ext components and a
> location in the source tree?
Not sure whether there was a firm decision but we have a) the sandbox
for experiments and b) the extensions directory in trunk for
self-contained extensions (i.e. those who make use of extension points
like event listeners and extension activities). The others will correct
me if I'm wrong.
Cheers,
Tammo
Re: XSD REpository
Posted by Paul Brown <pa...@gmail.com>.
Hi, Tammo --
> An interesting variant of this could be an integration with e.g.
> WSO2's repository. AFAIK they are storing WSDLs/XSDs and perhaps
> also BPEL files, with versioning etc. If the repository supports a
> flattening (i.e. fetching and storing all includes and dependencies)
> that would make a good supplement to Ode, wouldn't it?
I like anything that doesn't bloat our required libraries. As long as
it is something that could get pulled in off the classpath, then a
wrapper for the WSO2 repository (or Mule Galaxy or
YourFavoriteRegistryHere) would be a good thing.
Did we ever make a firm decision about a set of ext components and a
location in the source tree?
-- Paul
Re: XSD REpository
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
Paul Brown wrote:
>
> Hi, Wayne --
>
>> I have a WSDl that tries to pull in XSD from the network. I
>> understand that
>> this is not supported in ODE and the suggested practice is to assemble
>> the XSDs locally.
>
> It isn't the way that users would necessarily like to have the feature
> ("Just find my stuff!"), but if you believe in "least surprise" as a
> design constraint, it's the best choice. Resources can move, be
> unavailable, change, etc. It's better to have the user make explicit
> choices.
>
> You *could* try to engineer in a feature that would supply a different
> ResourceFinder implementation to the compiler (via the
> BpelC#setResourceFinger) and actually fetch WSDL/schema, but that will
> surely open at least one can of worms. Maybe a
> --resource-finder-fqcn=org.foo.Finder and then require a default
> constructor?
An interesting variant of this could be an integration with e.g. WSO2's
repository. AFAIK they are storing WSDLs/XSDs and perhaps also BPEL
files, with versioning etc. If the repository supports a flattening
(i.e. fetching and storing all includes and dependencies) that would
make a good supplement to Ode, wouldn't it?
Tammo
Re: XSD REpository
Posted by Wayne Keenan <wa...@gmail.com>.
>
> Also, can anyone recommend a tool to pull down the whole lot in the 1st
> > place?
> >
>
> I've used wget with the --recursive flag for that purpose.
>
> -- Paul
>
>
I have found that SoapUI 2.0.1 being XML aware can export the WSDL and the
tree of XSD it imports as a set of local files, re-writing the XSD imports
in the proceess, which does me , for now.
Re: XSD REpository
Posted by Paul Brown <pa...@gmail.com>.
Hi, Wayne --
> I have a WSDl that tries to pull in XSD from the network. I
> understand that
> this is not supported in ODE and the suggested practice is to assemble
> the XSDs locally.
It isn't the way that users would necessarily like to have the feature
("Just find my stuff!"), but if you believe in "least surprise" as a
design constraint, it's the best choice. Resources can move, be
unavailable, change, etc. It's better to have the user make explicit
choices.
You *could* try to engineer in a feature that would supply a different
ResourceFinder implementation to the compiler (via the
BpelC#setResourceFinger) and actually fetch WSDL/schema, but that will
surely open at least one can of worms. Maybe a --resource-finder-
fqcn=org.foo.Finder and then require a default constructor?
> I will do so, but I would like to avoid altering the WSDL at all
> costs, as
> it includes many XSD's, and those XSD's pull in further XSD's
> recursively.
> I was thinking it would be ideal if ODE supported mapping of the
> imports
> URN's to local files, similarly to Apache Synapse. Or is there
> something
> that does this currently that I am missing? or is it in the works?
Once upon a time, one of ODE's forbears (PXE) did exactly this,
although it used a URI mapping scheme to pack the WSDLs and schemas
all into a big JAR file. Even after you get over the obvious
obstacles (circular references), it's still fraught with peril around
target namespace versus location URIs for schema references, relative
versus absolute URIs and base URIs, etc.
Ode uses the import functionality native to WSDL and BPEL to get the
job done; deploy.xml references processes that reference WSDL and
schema documents, and the default there is to relativize all URIs and
omit anything that doesn't fit that mold. (Matthieu or Alex correct
me if I'm wrong.)
> Also, can anyone recommend a tool to pull down the whole lot in the
> 1st
> place?
I've used wget with the --recursive flag for that purpose.
-- Paul