ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Problem resolving schema relative to wsdl (JAXWS)
Date Fri, 25 Jul 2008 14:28:10 GMT
On Thu, Jul 24, 2008 at 10:32 PM, Raphael Parree <rparree@gmail.com> wrote:

> Hi,
> I am encountering a problem which is very similar to
> http://markmail.org/message/l64te3iyibccxbct and to the resulting JIRA
> issue
> ODE-300 <https://issues.apache.org/jira/browse/ODE-300>. In this post and
> issue the problem was a relative schema location referenced from the WSDL.
> That is indeed fixed, and works.
> My problem however is where the WSDL contains a relative schema reference
> and is not saved locally, but fetched from a web server:
> <wsdl:import namespace="urn:myns" location="
> http://localhost:9090/services/MyService?wsdl"/>
> The MyService.wsdl contains a reference to the XSD using the following
> (standard JAXWS-RI/METRO)
> <xsd:schema>
>  <xsd:import namespace="urn:myns" schemaLocation="
> http://localhost:9090/services/MyService?xsd=1"/>
> </xsd:schema>
> This causes ODE to complain about "Attempt to reference undeclared XSD
> type"
> (the schema element referenced by the message parts.
> When i save the WSDL and the XSD local in two seperate files and update the
> xsd:import it works (which was the subject of the
> ODE-300<https://issues.apache.org/jira/browse/ODE-300>
> issue).

A long time ago we made the conscious decision of not supporting the
download of imported document from HTTP URIs. It seems to be an easy problem
to solve at first (just fetch the damn thing and keep it somewhere) but is
far from trivial when you try to implement it in a way that will always work
(if the damn thing has imports, you have to fetch them too, then rewrite the
URLs, if they're relative that's one more problem, then do you fetch all the
time or cache, if you cache what happens when the document changes, if you
don't cache and one server goes down you're toast, and it goes on and
on...). So we chose to spend our time on actually implementing a BPEL engine
instead :)

In my experience it's fairly easy for people to handle that themselves,
while automating it can't work for all cases. So what you should do here is
simply make sure that all resources needed by the process to run (and
imported) are bundled within your ODE deployment. This way it's clean, self
contained and there are no surprises. Makes sense?


> Tx.,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message