cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asi Lev (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-7360) Creating a proxy from another proxy does not produce the same parameters as expected
Date Wed, 03 May 2017 19:14:04 GMT
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)

Mime
View raw message