RE: [bpel-dev] resolveBPELPartnerLinkType() trouble

[Bruno Wassermann <B.Wassermann@xxxxxxxxxxxx>]

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."