ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphael Parree" <rpar...@triveratech.com>
Subject Re: Problem resolving schema relative to wsdl (JAXWS)
Date Fri, 25 Jul 2008 19:18:50 GMT
Matthieu,

Makes sense and it is no problem for me. However i can image for many
Java/JAX-WS developers it will be a nuisance; again i am with you regarding
focussing on first things first. This acknowledgement helps me (could i have
read this somewhere BTW, i have neglected an ODE web page content in one
post before don't want to be a donkey here ;) )

Thanks,

Raphael


On Fri, Jul 25, 2008 at 4:28 PM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> 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?
>
> Thanks,
> Matthieu
>
>
> >
> > Tx.,
> >
>



-- 
Raphael Parree
CTO
SOA Evangelist

Trivera Technologies Global J2EE Education, Mentoring, Courseware &
Consulting Services
phone:+31 152600 448
phone +33 683 468663
Disclaimer...
"The information contained in this message may be confidential and is
intended to be exclusively for the addressee. Sender's written permission is
needed prior to forwarding or otherwise using the content of the message,
whether completely or partially. Should you receive this message
unintentionally, please do not use the contents herein and notify the sender
immediately by return e-mail. Please rely on your own virus checking, no
responsibility is taken by the sender for any damage rising out of any bug
or virus infection."

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