You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Asi Lev (JIRA)" <ji...@apache.org> on 2017/05/03 19:14:04 UTC

[jira] [Created] (CXF-7360) Creating a proxy from another proxy does not produce the same parameters as expected

Asi Lev created CXF-7360:
----------------------------

             Summary: Creating a proxy from another proxy does not produce the same parameters as expected
                 Key: CXF-7360
                 URL: https://issues.apache.org/jira/browse/CXF-7360
             Project: CXF
          Issue Type: Bug
    Affects Versions: 3.1.10
            Reporter: Asi Lev
            Priority: Minor


I'm working on an ONVIF web service client program that manages ONVIF devices.
I've used wsdl2java as follows:
wsdl2java -d C:\onvif\onvifMedia -client -exsh false -dns true -dex true -verbose media.wsdl
I've used the same command for device.wsdl and events.wsdl
The files were downloaded from https://www.onvif.org/profiles/specifications/
In my project, I've used the following code in order to pull events from an ONVIF device:
CreatePullPointSubscriptionResponse pullPointSubscriptionResponse = event.createPullPointSubscription(parameters);
            PullPointSubscription pullPointSubscription = pullPointSubscriptionResponse.getSubscriptionReference().getPort(PullPointSubscription.class);
            PullMessages pullMessagesParameters = new PullMessages();
            pullMessagesParameters.setMessageLimit(1);
            javax.xml.datatype.Duration duration = DatatypeFactory.createDuration("PT1M"); 
            pullMessagesParameters.setTimeout(duration);
            try {



            PullMessagesResponse pullMessageResponse = pullPointSubscription.pullMessages(pullMessagesParameters);
        } catch (PullMessagesFaultResponse_Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }           
        int d=1;
    } catch (TopicNotSupportedFault | TopicExpressionDialectUnknownFault | InvalidTopicExpressionFault
            | InvalidMessageContentExpressionFault | InvalidProducerPropertiesExpressionFault
            | UnacceptableInitialTerminationTimeFault | NotifyMessageNotSupportedFault | ResourceUnknownFault
            | UnsupportedPolicyRequestFault | InvalidFilterFault | SubscribeCreationFailedFault
            | UnrecognizedPolicyRequestFault e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

According to ONVIF specification, the first proxy "event.createPullPointSubscription" should send a "CreatePullPointSubscription" message to the device, and the device should send back CreatePullPointSubscription response.
Inside the response there are parameters that should be sent to the device in order to pull the events, as "reference parameters" in the WS header.
The response is returned successfully for this code, and the parameters are given in the returned object. I can verify this with the debugger, but they are declared as private so I can't access them using code.
As I understand, there is supposed to be a way to create the pullMessages service message, with the encapsulated parameters, using the response.
My attempt to do that is also in the above code. On the second line I attempt to create the object from the response. After I initialize some parameters for the pullMessages object, I issue the command to send the pullMessages service message.
There are two problems I encounter in this step:
1. While the original object was created from factory as a SOAP1.2 service client, the new object is a SOAP1.1 client, and I can't figure out how to change that to 1.2. I would expect that an object that was generated from another object would have the same SOAP version.
2. When the new object sends its message, there are no reference parameters in its header as I expected. The parameters were suppose to be transformed from the originating object.

A work around could have been to create the second object manually and add the parameters manually, but the parameters are not visible by code, as they are encapsulated and declared as private.
Another workaround (which I used and worked fine) is using the .toString() method on the first object, and parsing this string which just happens to contain the values of the private members which I needed...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)