[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [bpel-dev] resolveBPELPartnerLinkType() trouble
|
Hi Michal,
This doesn't seem to solve the problem. ImportImpl.resolveLocation() is
where it goes wrong in the end. It doesn't like the part where it tries to
create a URI on a schemaLocation attribute (which is null).
I have tried adding 'if (imp.getLocation() == null) continue;' to the second
for-loop in resolveBPELPartnerLinkType(), but this results in me getting a
StackOverflow as the recursive bit never terminates :(
I don't understand why this is and need to debug it a bit further, but if
you have time to have another looksie, maybe the problem is more apparent to
your eye?
Thanks,
-- Bruno
-----Original Message-----
From: Michal Chmielewski [mailto:michal.chmielewski@xxxxxxxxxx]
Sent: 11 January 2007 19:28
To: BPEL Designer project developer discussions.
Cc: B.Wassermann
Subject: 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."