You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by "Ciot, Thierry" <th...@compuware.com> on 2007/06/07 19:02:52 UTC
Compile error on
<wsdl:import> does not seem to be supported correctly. This BPEL file
works in another BPEL engine, I'm just trying to deploy it to ODE.
I get the error ":invalid scheme (should be urn:) " when compiling a
BPEL file that imports a wsdl file that itself imports some wsdl.
Here are the relevant fragments:
1) BPEL File contains:
<bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
location="file:C:\AxisAppDev\ActiveBEPLDev\LoanApproval\LoanApproverPart
nerLinkType.wsdl"
namespace="http://loanApprover.thierry/PartnerLinkType"/>
2) LoanApproverPartnerLinkType.wsdl imports wsdl definitions via
<wsdl:import>
<wsdl:import namespace="http://loanApproval.thierry"
location="http://localhost:8180/axis2/services/LoanApprover?wsdl"/>
The error stack is listed below.
Should I enter a bug somewhere or is development watching this list?
Thanks, Thierry.
FATAL - 2007-06-07 12:23:30,037 -
<org.apache.ode.bpel.compiler.DefaultResourceFinder> openResource:
invalid scheme (should be urn:)
http://localhost:8180/axis2/services/LoanApprover?wsdl
java org.apache.ode.tools.bpelc.cline.BpelC: Invalid BPEL document;
import contains malformed location URI.
java.lang.IllegalStateException: Invalid BPEL document; import contains
malformed location URI.
at
org.apache.ode.bpel.compiler.bom.Import.getLocation(Import.java:76)
at
org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:767)
at
org.apache.ode.bpel.compiler.BpelCompiler.compile(BpelCompiler.java:628)
at org.apache.ode.bpel.compiler.BpelC.compile(BpelC.java:252)
at org.apache.ode.bpel.compiler.BpelC.compile(BpelC.java:322)
at
org.apache.ode.tools.bpelc.BpelCompileCommand.execute(BpelCompileComm
and.java:121)
at org.apache.ode.tools.bpelc.cline.BpelC.main(BpelC.java:99)
Caused by: java.net.URISyntaxException: Illegal character in opaque part
at index 7:
file:C:\AxisAppDev\ActiveBEPLDev\LoanApproval\LoanApproverPartnerLinkTyp
e.wsdl
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parse(URI.java:3019)
at java.net.URI.<init>(URI.java:578)
at
org.apache.ode.bpel.compiler.bom.Import.getLocation(Import.java:74)
... 6 more
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
Re: Compile error on
Posted by Paul Brown <pa...@gmail.com>.
On 7/25/07, Rich Taylor <bh...@gmail.com> wrote:
> Hi Alex and Gang, do you know if this was an intentional design decision to
> not support remote wsdl/xsd/etc. references or is it something that simply
> hasn't been done yet? I can see the pros and cons of each, just trying to
> understand why "it is how it is". Thanks! Rich
At least from a historical perspective, this was a bit of a mess.
Once upon a time, PXE (which merged with BPE to become Ode) had a
resource repository where external resources (e.g., WSDL documents,
schema, etc.) could be stored by URI. The repository would get loaded
over the course of a WSDL parse, but this had a host of issues, not
the least of which was usability -- which URIs are equal? what
encoding is used?
On the flip side, resolving resources at runtime has reliability and
security issues -- can you see it? Do you see the right one? Is the
host up? Did it change since the last deploy?
The easiest thing to do (for everyone) is to force the user to
assembly a definitive collection of artifacts with correct
cross-references and go from there.
-- Paul
Re: Compile error on
Posted by Rich Taylor <bh...@gmail.com>.
I appreciate the insight/history. You both pointed out more cons than came
to mind for me. For our situation, all of these cons do definitely
outweigh the pros. We're leaning towards the gathering of these files
before deployment to Ode, but wanted to explore pulling them down at
runtime. Sounds like that option has already been explored in depth. The
correct path is even clearer now. Thank you, Rich
On 7/25/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Hi Rich,
>
> We had some support for it at some point in time but it was partial, which
> is a way to say mostly broken. There are many hidden hurdles when
> implementing this on non trivial cases (which is actually most of the
> cases
> we have to support). Here are a few examples:
>
> * So you start getting the remote file but it imports other files, what do
> you do with them? You obviously have to download them as well so you start
> with a recursive problem.
> * What do you do with everything you download? Keep them in memory and
> download every time? Not so nice (especially when one of the servers you
> download from isn't reliable). You save them locally? Now you have a URL
> rewriting problem as well as all import locations have to be changed and
> you
> have a repository of documents to maintain.
> * Alternatively when downloading you can start in-lining things to get a
> single file locally, that solve the import location rewriting problem but
> in-lining itself is not really trivial either.
> * What do you do when somewhere along the way of imports is either not
> there
> or the server is down? HTTP is not a very reliable protocol. You have no
> choice but to fail the whole thing, which is not always the smartest thing
> to do. And the files you saved along the way? Keep them? Damp them?
>
> And these are just on top of my head, I'm sure you can find many others.
> Implementing this, you end up with a pretty big, hard to test, piece of
> code. So when we refactored our deployment model we decided to save
> ourselves some time and pain and not support it.
>
> But that doesn't mean we're against it or anything. It's just that it
> would
> have required far more effort than what we were ready to give for this
> feature, so it's more on the "hasn't been done yet" side. If somebody is
> very interested in it and is ready to give it a shot (including tests),
> we'd
> welcome this contribution in ODE with open arms :-)
>
> Cheers,
> Matthieu
>
> On 7/25/07, Rich Taylor <bh...@gmail.com> wrote:
> >
> > Hi Alex and Gang, do you know if this was an intentional design decision
> > to
> > not support remote wsdl/xsd/etc. references or is it something that
> simply
> > hasn't been done yet? I can see the pros and cons of each, just trying
> to
> > understand why "it is how it is". Thanks! Rich
> >
> > On 7/2/07, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > On 7/2/07, RichTaylor <bh...@gmail.com> wrote:
> > > >
> > > > Am I reading this correctly that Ode does not currently support the
> > > > importing
> > > > of remote WSDL files (and XSD, etc.)? The WSDL files must be
> > available
> > > > and
> > > > referenced on the local disk?
> > >
> > >
> > > Correct.
> > >
> > > alex
> > >
> >
>
Re: Compile error on
Posted by Matthieu Riou <ma...@gmail.com>.
Hi Rich,
We had some support for it at some point in time but it was partial, which
is a way to say mostly broken. There are many hidden hurdles when
implementing this on non trivial cases (which is actually most of the cases
we have to support). Here are a few examples:
* So you start getting the remote file but it imports other files, what do
you do with them? You obviously have to download them as well so you start
with a recursive problem.
* What do you do with everything you download? Keep them in memory and
download every time? Not so nice (especially when one of the servers you
download from isn't reliable). You save them locally? Now you have a URL
rewriting problem as well as all import locations have to be changed and you
have a repository of documents to maintain.
* Alternatively when downloading you can start in-lining things to get a
single file locally, that solve the import location rewriting problem but
in-lining itself is not really trivial either.
* What do you do when somewhere along the way of imports is either not there
or the server is down? HTTP is not a very reliable protocol. You have no
choice but to fail the whole thing, which is not always the smartest thing
to do. And the files you saved along the way? Keep them? Damp them?
And these are just on top of my head, I'm sure you can find many others.
Implementing this, you end up with a pretty big, hard to test, piece of
code. So when we refactored our deployment model we decided to save
ourselves some time and pain and not support it.
But that doesn't mean we're against it or anything. It's just that it would
have required far more effort than what we were ready to give for this
feature, so it's more on the "hasn't been done yet" side. If somebody is
very interested in it and is ready to give it a shot (including tests), we'd
welcome this contribution in ODE with open arms :-)
Cheers,
Matthieu
On 7/25/07, Rich Taylor <bh...@gmail.com> wrote:
>
> Hi Alex and Gang, do you know if this was an intentional design decision
> to
> not support remote wsdl/xsd/etc. references or is it something that simply
> hasn't been done yet? I can see the pros and cons of each, just trying to
> understand why "it is how it is". Thanks! Rich
>
> On 7/2/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > On 7/2/07, RichTaylor <bh...@gmail.com> wrote:
> > >
> > > Am I reading this correctly that Ode does not currently support the
> > > importing
> > > of remote WSDL files (and XSD, etc.)? The WSDL files must be
> available
> > > and
> > > referenced on the local disk?
> >
> >
> > Correct.
> >
> > alex
> >
>
Re: Compile error on
Posted by Rich Taylor <bh...@gmail.com>.
Hi Alex and Gang, do you know if this was an intentional design decision to
not support remote wsdl/xsd/etc. references or is it something that simply
hasn't been done yet? I can see the pros and cons of each, just trying to
understand why "it is how it is". Thanks! Rich
On 7/2/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 7/2/07, RichTaylor <bh...@gmail.com> wrote:
> >
> > Am I reading this correctly that Ode does not currently support the
> > importing
> > of remote WSDL files (and XSD, etc.)? The WSDL files must be available
> > and
> > referenced on the local disk?
>
>
> Correct.
>
> alex
>
Re: Compile error on
Posted by Alex Boisvert <bo...@intalio.com>.
On 7/2/07, RichTaylor <bh...@gmail.com> wrote:
>
> Am I reading this correctly that Ode does not currently support the
> importing
> of remote WSDL files (and XSD, etc.)? The WSDL files must be available
> and
> referenced on the local disk?
Correct.
alex
Re: Compile error on
Posted by RichTaylor <bh...@gmail.com>.
Am I reading this correctly that Ode does not currently support the importing
of remote WSDL files (and XSD, etc.)? The WSDL files must be available and
referenced on the local disk?
I'm running into this issue as well (trying to import a remote WSDL) and am
wondering if this is supported or not.
Thanks,
Rich
Alex Boisvert wrote:
>
> On 6/7/07, Ciot, Thierry <th...@compuware.com> wrote:
>>
>> <wsdl:import> does not seem to be supported correctly. This BPEL file
>> works in another BPEL engine, I'm just trying to deploy it to ODE.
>>
>> I get the error ":invalid scheme (should be urn:) " when compiling a
>> BPEL file that imports a wsdl file that itself imports some wsdl.
>>
>> Here are the relevant fragments:
>>
>>
>>
>> 1) BPEL File contains:
>>
>> <bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
>> location="file:C:\AxisAppDev\ActiveBEPLDev\LoanApproval\LoanApproverPart
>> nerLinkType.wsdl"
>> namespace="http://loanApprover.thierry/PartnerLinkType"/>
>
>
> It looks like the Java URI parser doesn't like the syntax of your URI. Can
> you try replacing the backslashes by slashes?
> e.g.
> file:C:/AxisAppDev\ActiveBEPLDev/LoanApproval/LoanApproverPartnerLinkType.wsdl
>
> Or use a relative path. (either file, or something like
> "../path/to/My.wsdl")
>
>
> 2) LoanApproverPartnerLinkType.wsdl imports wsdl definitions via
>> <wsdl:import>
>>
>> <wsdl:import namespace="http://loanApproval.thierry"
>> location="http://localhost:8180/axis2/services/LoanApprover?wsdl"/>
>
>
>
> We currently only support "file:", "urn:" (assume to point to a file) and
> by
> default assume the location is a local path.
>
> I recommend you download the file and place it next to your BPEL process.
>
> regards,
> alex
>
>
--
View this message in context: http://www.nabble.com/Compile-error-on-%3Cwsdl%3Aimport%3E-tf3885156.html#a11402684
Sent from the Apache Ode User mailing list archive at Nabble.com.
Re: Compile error on
Posted by Alex Boisvert <bo...@intalio.com>.
On 6/7/07, Ciot, Thierry <th...@compuware.com> wrote:
>
> Thanks for your response. I'll try making all files locals.
>
> Does your comment "We currently only support "file:", "urn:" (assume to
> point to a file) and by
> default assume the location is a local path" applies to <bpel:import> or
> <wsdl:import> or both?
Both. (and xsd:import)
alex
RE: Compile error on
Posted by "Ciot, Thierry" <th...@compuware.com>.
Thanks for your response. I'll try making all files locals.
Does your comment "We currently only support "file:", "urn:" (assume to
point to a file) and by
default assume the location is a local path" applies to <bpel:import> or
<wsdl:import> or both?
-----Original Message-----
From: Alex Boisvert [mailto:boisvert@intalio.com]
Sent: Thursday, June 07, 2007 1:40 PM
To: ode-user@incubator.apache.org
Subject: Re: Compile error on <wsdl:import>
On 6/7/07, Ciot, Thierry <th...@compuware.com> wrote:
>
> <wsdl:import> does not seem to be supported correctly. This BPEL file
> works in another BPEL engine, I'm just trying to deploy it to ODE.
>
> I get the error ":invalid scheme (should be urn:) " when compiling a
> BPEL file that imports a wsdl file that itself imports some wsdl.
>
> Here are the relevant fragments:
>
>
>
> 1) BPEL File contains:
>
> <bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
>
location="file:C:\AxisAppDev\ActiveBEPLDev\LoanApproval\LoanApproverPart
> nerLinkType.wsdl"
> namespace="http://loanApprover.thierry/PartnerLinkType"/>
It looks like the Java URI parser doesn't like the syntax of your URI.
Can
you try replacing the backslashes by slashes?
e.g.
file:C:/AxisAppDev\ActiveBEPLDev/LoanApproval/LoanApproverPartnerLinkTyp
e.wsdl
Or use a relative path. (either file, or something like
"../path/to/My.wsdl")
2) LoanApproverPartnerLinkType.wsdl imports wsdl definitions via
> <wsdl:import>
>
> <wsdl:import namespace="http://loanApproval.thierry"
> location="http://localhost:8180/axis2/services/LoanApprover?wsdl"/>
We currently only support "file:", "urn:" (assume to point to a file)
and by
default assume the location is a local path.
I recommend you download the file and place it next to your BPEL
process.
regards,
alex
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
Re: Compile error on
Posted by Alex Boisvert <bo...@intalio.com>.
On 6/7/07, Ciot, Thierry <th...@compuware.com> wrote:
>
> <wsdl:import> does not seem to be supported correctly. This BPEL file
> works in another BPEL engine, I'm just trying to deploy it to ODE.
>
> I get the error ":invalid scheme (should be urn:) " when compiling a
> BPEL file that imports a wsdl file that itself imports some wsdl.
>
> Here are the relevant fragments:
>
>
>
> 1) BPEL File contains:
>
> <bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
> location="file:C:\AxisAppDev\ActiveBEPLDev\LoanApproval\LoanApproverPart
> nerLinkType.wsdl"
> namespace="http://loanApprover.thierry/PartnerLinkType"/>
It looks like the Java URI parser doesn't like the syntax of your URI. Can
you try replacing the backslashes by slashes?
e.g.
file:C:/AxisAppDev\ActiveBEPLDev/LoanApproval/LoanApproverPartnerLinkType.wsdl
Or use a relative path. (either file, or something like
"../path/to/My.wsdl")
2) LoanApproverPartnerLinkType.wsdl imports wsdl definitions via
> <wsdl:import>
>
> <wsdl:import namespace="http://loanApproval.thierry"
> location="http://localhost:8180/axis2/services/LoanApprover?wsdl"/>
We currently only support "file:", "urn:" (assume to point to a file) and by
default assume the location is a local path.
I recommend you download the file and place it next to your BPEL process.
regards,
alex