Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Test case for WSDLUtil.resolveBPELPartnerLinkType bug
Bruno,

1) The only way you will get a stack overflow exception as it stands, is if the WSDLs include each other (cyclic includes) ... and that in fact does happen (the stack overflow).

2) I was able to create this and I re-wrote some of the code in WSDLUtil to make sure that includes like this do not cause a problem anymore. I've checked it in ... so update and check your code to see if that exception still happens or not.

3) Regarding the partner link type definition in the model, they use
      http://schemas.xmlsoap.org/ws/2003/05/partner-link/

So rewriting the PLT would not solve the problem as you hope ....

4) In WSDL and BPEL, on the import, the targetNamepsace of the WSDL must be the same as the namespace attribute on the import. That's just required. If you need types from another namespace, you will need to import them into the BPEL process separately (as another import).

5) You may be really wanting to lookup (or resolve) things like portTypes, types, element, partner links, etc. from the perspective of the BPEL process. WSDLUtil only allows you to look them up from the WSDL being the starting point. At some point, you may want to ask, given a process defn, does a portType "foo:bar" exist for example, or does a partnerLinkType "bar:foo" exists within all the imports.

So I added a simple BPELUtils.lookup() method that should take care of this. Not sure if this is what you need or want, but perhaps it will solve the problem you are facing ...


I hope that covers it.

-m

Bruno Wassermann wrote: 
Just a quick thought. What do you think?

For example, in jobmanager.wsdl:
- update plnk schema to http://schemas.xmlsoap.org/ws/2004/03/partner-link/
- change partnerLinkType definitions to this format:
<plnk:partnerLinkType name="jobmanagerPartner">
     <plnk:role name="jobmanagerProvider">
       <plnk:portType name="tns:jobmanager"/>
     </plnk:role>
   </plnk:partnerLinkType>

Would this solve the problem (in part)?

-- Bruno


-----Original Message-----
From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On
Behalf Of Bruno Wassermann
Sent: 24 February 2007 14:59
To: 'BPEL Designer project developer discussions.'
Subject: RE: [bpel-dev] Test case for WSDLUtil.resolveBPELPartnerLinkType
bug

Hi,

I have come across at what looks like another issue in the resolveX methods
in WSDLUtil. 
This time it tries to resolveBPELRole, which in turn uses
resolveBPELPartnerLinkType. 

Here is the WSDL that causes it to trip up:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="jobmanager"
targetNamespace="http://sse.cs.ucl.ac.uk/omii-bpel/2.0.0/polymorph/jobmanage
r" xmlns:tns="http://sse.cs.ucl.ac.uk/omii-bpel/2.0.0/polymorph/jobmanager"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:gridsam="http://www.icenigrid.org/service/gridsam"
xmlns="http://schemas.xmlsoap.org/wsdl/"> 
  <import namespace="http://www.icenigrid.org/service/gridsam"
location="gridsam.wsdl"/>
  <!-- 
  <portType name="jobmanager">
    <operation name="submitjob">
      <input message="gridsam:SubmitJobRequest"/>
      <output message="gridsam:GetJobStatusResponse"/>
    </operation>
  </portType>
    <plnk:partnerLinkType name="jobmanagerPartner">
      <plnk:role name="jobmanagerProvider" portType="tns:jobmanager"/>
   </plnk:role>
</plnk:partnerLinkType>
 -->
</definitions>

As you can see the messages in the operation make use of types defined in
another WSDL via an import (gridsam.wsdl).


In resolveBPELPartnerLinkType(), when trying to get the imports of the
jobmanager.wsdl definition (see attachment), it will do
DefinitionImpl.getImports. In line 947 of DefinitionImpl only adds an Import
(for resolveBPELPartnerLinkType to do its magic on) if the namespace of the
WSDL definition (jobmanager.wsdl) matches that of the import. 

In this scenario though the import we need to look at to resolve correctly
is in a different namespace?

My question: does the check on namespaces in DefinitionImpl make good sense
and is it just a case of bad, bad WSDL or is this a bug? Do I need to change
the WSDL or do I need to change the code? 

Wrt the WSDLUtil issues I am currently at a loss; I am not 100% certain
whether it is my code exercising WSDLUtil, the resources I am using it on or
whether we have some genuine bugs in there. 


-- Bruno


-----Original Message-----
From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On
Behalf Of Bruno Wassermann
Sent: 24 February 2007 14:45
To: 'BPEL Designer project developer discussions.'
Subject: [bpel-dev] Test case for WSDLUtil.resolveBPELPartnerLinkType bug

Hi Mike,

I tried to send this to you, but the mail keeps bouncing back (maybe it
doesn't like the attachments?), so I am trying to get this to you via the
list. 

Maybe it's not a bug and is just due to the resources I am using or due to
the way I exercising the code, but in case it's not, here is what I have
figured out so far.

In its current form, the code in question will throw a NPE. We have
discussed the reasons for that already (it's to do with the bpws:import with
null location, I think). 

If I take care of this by catching the exception, like that:
 
public static PartnerLinkType resolveBPELPartnerLinkType(Definition
definition, QName qname)

{
. 
// second for loop
for (Iterator.) {

  ImportImpl imp = (ImportImpl) impIterator.next();


  try {

    imp.importDefinitionOrSchema(); // if (location == null) will throw NPE
when trying to create URI
  

  } catch (NullPointerException e) {

    continue;

  }
 
  Definition importedDefinition = (Definition) imp.getDefinition();
  .
  // enter recursion on importedDefinition
  .
}

The result will be a StackOverflowException. And the reason for this seems
to be that importedDefinition always represents the BPEL file! It never
actually represents the definition that is being imported (and imp seems to
represent the correct WSDL resource), but just the same resource over and
over again. 

I haven't had time to figure out why this happens. Maybe the stack trace
will reveal an answer to you. So far it hasn't for me.  

Take care,

-- Bruno

P.S.:
I am using
Java 1.5.0_07
Eclipse 3.2.1
EMF 2.2.0
WST 1.5.1
Revision of org.eclipse.bpel.model.util.WSDLUtil is 1.2




______________________________________________
Bruno Wassermann 
           
Research Student                
                               
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."

Back to the top