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

Hi Mike,

 

I agree that this is a step forward. Instead of an NPE we get an IllegalArgumentException now, when calling getID() on a PartnerLinkType (local part cannot be null when creating a QName). The stack trace is below.

I have tried out your suggestion and a few other things, but didn’t detect any difference. I have tested it on BPEL and WSDL generated by the editor and all the files are available, which means that most of the good reasons for getting a proxy back do not apply.

 

The only thing I can think of at the moment is that something about the format of the generated WSDLs maybe, makes the code throw up proxies. I just don’t see what it is. Can you spot a problem with the attached WSDL?

I also checked to see whether my test code was somehow messing things up, but couldn’t find anything.

 

I am bit stuck at the moment, so will leave this for a few days and come back to it later.

 

-- Bruno

 

I think I am going to use this as my new mail signature J

 

java.lang.IllegalArgumentException: local part cannot be "null" when creating a QName

            at javax.xml.namespace.QName.<init>(QName.java:214)

            at javax.xml.namespace.QName.<init>(QName.java:163)

            at org.eclipse.bpel.model.util.BPELServicesUtility.getIdForExtensibilityElement(BPELServicesUtility.java:73)

            at org.eclipse.bpel.model.partnerlinktype.impl.PartnerLinkTypeImpl.getID(PartnerLinkTypeImpl.java:150)

            at uk.ac.ucl.sse.omii.bpel.abr.generation.util.DeploymentDataProvider.getNsFromPartnerLink(DeploymentDataProvider.java:386)

            at uk.ac.ucl.sse.omii.bpel.abr.generation.util.DeploymentDataProvider.getWsdlImportsForPartnerLinkType(DeploymentDataProvider.java:279)

            at uk.ac.ucl.sse.omii.bpel.abr.generation.util.tests.DeploymentDataProviderTest.testFindPartnerLinkType_ArtifactsService(DeploymentDataProviderTest.java:638)

           

 

 

From: Michal Chmielewski [mailto:michal.chmielewski@xxxxxxxxxx]
Sent: 05 March 2007 19:21
To: B.Wassermann
Cc: 'BPEL Designer project developer discussions.'
Subject: Re: [bpel-dev] Test case for WSDLUtil.resolveBPELPartnerLinkType bug

 

Comments in line ....

Bruno Wassermann wrote:

Hi Mike,

 

I am very sorry, but unfortunately this doesn’t really help that much, so I will try to explain the problem more clearly and ask one final question about this. Further clarifications/confusions are inlined below.

I think there is a gremlin here someplace and we'll need to nail it so feel free to ask away ...

 

Calling this

 

bpelPartnerLink.getPartnerLinkType();

 

where bpelPartnerLink is an org.eclipse.bpel.model.PartnerLink, we get back a PartnerLinkTypeProxy in case the PLT is defined in one of these *Artifacts.wsdl files. Then, when we try to get the value of any of the fields of the PartnerLinkType, we just get null.

If you get a proxy it usually means that the reference cannot be resolved. Meaning, a PL has a PLT for example and the value of the PLT is wrapped in a proxy which is not resolved and is returned to you. Or a variable has a type (element,messageType, or type) and that cannot be resolved (even though it is set to some value).  During reading of the process, the reader wraps all the "referenced entities" (plt, types, elements) in proxies and these are lazily resolved on demand when needed. This happens at different times for different things. So when you call any of the get* methods that return these external references and if these references are still proxies then these are resolved during the call (so exactly your case).

While the code in the editor should not produce problems of that nature, one could always assume that a BPEL process that is read by the editor which was not necessarily generated by it ought to not barf on the content it is fed.

The "why is the PLT  not resolved" is the puzzle here ...


 

This is not very good as the code generating a deployment descriptor is not very imaginative and doesn’t really know how to turn null into useful output ;-)

You can create a simple process using the editor and cause it to generate an artifacts file and try this out yourself.




 

My (maybe) final question: Why is it reasonable to get a proxy back in response to calling the getter (which then tries to resolve the BPEL partnerlinkType) in the scenario involving an *Artifacts file?

I think it is reasonable to assume that you might be getting a proxy object because any external references may be unresolvable because the documents they point to may be unavailable in some way. Or because someone edited the BPEL and forgot to include the import for example.

If there is a good reason why we should get back a proxy in this scenario, then I promise to solve the problem differently and leave you in peace.

Your code could deal with that case by simply asking the EObject (the returned partner link type object) if it is a proxy by asking
   obj.eIsProxy()
If that's the case, your code could nicely assume that something is really screwed and that a reference it needs cannot be resolved and just die there with some meaningful error message.

With the fix I put in last week the code ought to do exactly what it is doing now. Unresolved items ought to be returned as proxies - you should not get NPE or stack overflows. So to me this is a step forward.

Now the problem is "why" this happens, and the only thing that I can think of is to follow the path of the resolver and see why it fails.

Try this for me ...

1) In your process that has the problem, look at the imports of the BPEL process. Does it import the *Artificats.wsdl file twice, once with a location, once without ?
You can do this in examining the properties of the process under the Imports section. If so remove the entry without the location and then save the process.

2) Try your code now. Any change ?

[ snip ]


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

 

The stack overflow occurred due to the try-catch that I added (as described) due to looking at the same Definition over and over again (the BPEL definition, if I remember correctly, which was in a list of three objects, one of which would have been the WSDL the code should have looked at to make me happy).

Nevertheless, the check you put in to prevent looking at the same definition over and over again definitely makes good sense.

Well there was a clear case of the resolution logic not checking cyclical imports. So that ought to take care of that little oversight. That's why I think you are getting the proxies.


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

 

Pity



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

 

Agreed. But this doesn’t mean that you can only import “stuff” into a WSDL (tns A) from a WSDL with the same namespace (tns A). Or does it? In the example below we want to import something from gridsam.wsdl and the ns on the import matches the tns of gridsam.wsdl.

Correct. Just that on the import statement itself, the nsURI (the namespace attribtue) is the tns of the imported document. So you can  have a document with tnsA importing a document of tnsB which itself imports tnsC etc.

 

However, I am not 100% certain anymore whether the code actually supplied the wrong namespaceURI or not. Would need to debug it again to see L



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.

 

I am (in my code) just calling a getter on a org.eclipse.bpel.model.PartnerLink (i.e. getPartnerLinkType()). That’s all. I didn’t use WSDLUtil or BPELUtil directly; during the course of debugging this problem I just realized that, to do the resolution, the methods in WSDLUtil were called for (ECoreUtil.resolve(), etc.) (if you run the test case and follow the stack trace…). I was just trying to illuminate matters a bit.


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

Thank you. I think I should be able to do some DOM/XPath processing (because as described above we can’t get, for example, a QName from the model when the artifacts scenario is present) that would then allow me to get all the parameters I need to use that method. I was just hoping that as the getter (getPartnerLinkType()) was doing resolution, I wouldn’t have to resort to do that.

 



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




-- 
Michal Chmielewski, CMTS, Oracle Corp, 
W:650-506-5952 / M:408-209-9321 
 
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know." 
<?xml version="1.0"?>
<definitions name="ArtifactsServiceProcess"
        targetNamespace="http://test.com";
        xmlns:tns="http://test.com";
        xmlns:plnk="http://schemas.xmlsoap.org/ws/2004/03/partner-link/";
        xmlns="http://schemas.xmlsoap.org/wsdl/";
        >

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     TYPE DEFINITION - List of types participating in this BPEL process 
     The BPEL Designer will generate default request and response types
     but you can define or import any XML Schema type and use them as part 
     of the message types.
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    
    <types>
        <schema attributeFormDefault="unqualified" elementFormDefault="qualified" 
                targetNamespace="http://test.com"; 
                xmlns="http://www.w3.org/2001/XMLSchema";>

            <element name="ArtifactsServiceProcessRequest">
                <complexType>
                    <sequence>
                        <element name="input" type="string"/>
                    </sequence>
                </complexType>
            </element>

            <element name="ArtifactsServiceProcessResponse">
                <complexType>
                    <sequence>
                        <element name="result" type="string"/>
                    </sequence>
                </complexType>
            </element>
        </schema>
    </types>


<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     MESSAGE TYPE DEFINITION - Definition of the message types used as 
     part of the port type defintions
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    
    <message name="ArtifactsServiceProcessRequestMessage">
        <part name="payload" element="tns:ArtifactsServiceProcessRequest"/>
    </message>
    <message name="ArtifactsServiceProcessResponseMessage">
        <part name="payload" element="tns:ArtifactsServiceProcessResponse"/>
    </message>

<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     PORT TYPE DEFINITION - A port type groups a set of operations into
     a logical service unit.
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->    

    <!-- portType implemented by the ArtifactsServiceProcess BPEL process -->
    <portType name="ArtifactsServiceProcess">
        <operation name="process">
            <input  message="tns:ArtifactsServiceProcessRequestMessage" />
            <output message="tns:ArtifactsServiceProcessResponseMessage"/>
        </operation>
    </portType>
  

    
</definitions>

Back to the top