[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] resolveBPELPartnerLinkType() trouble
|
I put in a check for import.getLocation() == null on WSLDResolver and
XSDResolver. This way, these should fall out as noops and you should not
get the NPE ... let me know.
The issue with putting the location-less import is another story, but at
least you ought to be able to get passed this problem.
-m
Michal Chmielewski wrote:
Bruno,
There is a bug here. What I have done is as follows:
1) Create a brand new BPEL file.
2) Add new Partner Link
3) Browse for a WSDL for that partner link.
4) Select that WSDL which has portTypes but no PLT.
5) Go through the little wizard that creates the PLT (in the
artifacts file).
The problem seems to be that after creating this PLT an import without
location is added to the process.
On save of the BPEL file another import is added which contains the
correct import pointing to the just created artifacts file (which is
created on save).
The import being unset is not a bug per se (the spec allows it), but
the code should not barf on it during resolution of the pl proxies.
I'll take a looksie ...
-michal
Bruno Wassermann wrote:
Hi all,
Working on improving the generation of deployment descriptors for the
ActiveBPEL runtime integration, I have been stuck for a few days
trying to
figure out what might be a bug (?).
Here's the setup:
We have a simple BPEL process with two partnerLinks. One partnerLink
refers
to a PLT defined in the automatically generated *Artifacts.wsdl file,
which
in turn imports the <processName>.wsdl file to resolve the portType
referred
to in its PLT. This PLT will be represented by EMF as a proxy.
Here's what we are trying to do:
During PDD generation, we need to getPartnerLinkType().getID() or
getName(),
etc. The first getter tries to resolve the proxy and return a
PartnerLinkType, but that's where the trouble starts.
Here's the problem:
The getter makes use of
org.eclipse.bpel.model.util.WSDLUtil.resolveBPELPartnerLinkType(). As
we are
dealing with a proxy object, this method decides to inspect the imports.
Problem is (or seems to be), it encounters a bpws:import with a no
location
attribute (null), which is represented in our BPEL file by the following
line:
<bpws:import importType="http://schemas.xmlsoap.org/wsdl/";
namespace="http://test.comArtifacts"/>
which, in the BPEL, is followed by:
<bpws:import importType="http://schemas.xmlsoap.org/wsdl/";
location="ArtifactsServiceProcessArtifacts.wsdl"
namespace="http://test.comArtifacts"/>
Now, my understanding is that trying to import the definition
indicated by
the first bpws:import above, we encounter a NPE caused by trying to
create a
URI on a null location. The effect is that the
resolveBPELPartnerLinkType()
method never gets to look at the second import and it all fails
miserably.
Can someone please tell me: a) is this a known limitation of the
code? b) why does our BPEL feature this import with no location
attribute? c) is there something I am missing here? Is there maybe
something the PDD
generation should do before trying to resolve a proxy and I am just
being
ignorant?
This is driving me nuts (there is some nice recursion going on -
forgot to
mention) and keeping me from making any progress. So please, if
anyone could
lend me a few minutes of brainpower, it would be greatly appreciated.
-- Bruno
______________________________________________
Bruno Wassermann Research Fellow
University College London Tel:
+44 (0)20 7679 0369 (Direct Dial)
Dept. of Computer Science Fax: +44 (0)20 7387 1397
Gower Street London WC1E 6BT
http://www.cs.ucl.ac.uk/staff/B.Wassermann
United Kingdom ______________________________________________
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
