cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: WS-Discovery of ONVIF devices - Update
Date Mon, 29 Apr 2013 15:12:50 GMT

On Apr 29, 2013, at 5:27 AM, Pampolini Matteo <matteo.pampolini@selex-es.com> wrote:

> I've just completed the tests: one of my ONVIF devices answers with a
> SOAP 1.2 message, that's the cause of the exception.
> 
> But doing as you suggested, i.e. changing the return value of
> getSoapVersion(), fixes the issue and all the devices are discovered
> without any exception, really great, many thanks again!

Major thanks for testing that.   That's great news.  The WS-Discovery spec does allow SOAP
1.2, but the examples for ONVIF were all using 1.1 which is why I set it to 1.1.  Glad to
see it's not needed. 

> Will you add another API to configure the return value of
> getSoapVersion() or do you have a better solution in mind?

I just updated the code to use 1.2 by default in all cases, but did add a new flag to force
the use of 1.1 if needed.   It sounds like it won't be needed though.

Can you do a quick double check to make sure that all works and I didn't screw something up?


Dan


> 
> Best regards,
> 
> Matteo
> 
> On 26/04/2013 17:11, Daniel Kulp wrote:
>> On Apr 23, 2013, at 11:05 AM, Pampolini Matteo <matteo.pampolini@selex-es.com>
wrote:
>> 
>>> Hi again Daniel,
>>> 
>>> I compiled 2.7.5 snapshot from scratch on Linux and worked on the
>>> resulting distribution, everything went fine.
>>> 
>>> And, most important, WS-Discovery works, setting version to 1.0 I was
>>> able to find all the Onvif devices in my subnet,
>>> great work, many thanks once again.
>> That is really really cool.  Major thanks for testing that.
>> 
>> 
>>> However an exception is thrown,
>>> please find it below:
>> Hmm… Is there any chance you could do a  wireshark capture of the incoming packets?
 (or maybe enable logging interceptors on the bus or something)  When we switch to WS-Discovery
1.0, I also flip from soap 1.2 to soap 1.1 since the ONVIF docs all use SOAP 1.1 in the examples.
  However, this looks like some device or something is responding with a 1.2 soap message
instead of a 1.1 message.   I'd like to see that particular message to see if it's coming
from an ONVIF device or something else (certainly want to make sure it's not a CXF endpoint).
   Normally, an endpoint should definitely not response to 1.1 based request with a 1.2 based
message.   However, if you view WS-Discovery as a series of one-ways instead of a request/response,
it could possibly make some sense.
>> 
>> Since you already figured out how to build CXF, could you try something else?  In:
>> services/ws-discovery/ws-discovery-api/src/main/java/org/apache/cxf/ws/discovery/WSDVersion.java
>> 
>> can you edit the WSDVersion10.getSoapVersion() call to return SOAPBinding.SOAP12HTTP_BINDING
instead?  That would keep it 1.2, but that SHOULD be OK according to the WS-Discovery 1.0
spec.   I'd like to see if the ONVIF devices can respond to that.  If so, I'd keep it 1.2
as then the CXF can process both 1.1 and 1.2 responses.   However, if the devices don't support
1.2, I'd need to figure something else out.
>> 
>>> Which is the release plan for 2.7.5?
>> I'm actually thinking sometime either next week or the week after due to some issues
around the woodstox requirements and such that are now fixed.   Thus, if this could be tested
quickly, we could get this added to it.
>> 
>> 
>> Thanks!
>> Dan
>> 
>> 
>> 
>>> WARNING: Interceptor for
>>> {http://schemas.xmlsoap.org/ws/2005/04/discovery}DiscoveryProxy#{http://cxf.apache.org/jaxws/dispatch}Invoke
>>> has thrown exception, unwinding now
>>> org.apache.cxf.binding.soap.SoapFault: A SOAP 1.2 message is not valid
>>> when sent to a SOAP 1.1 only endpoint.
>>>    at
>>> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:159)
>>>    at
>>> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:62)
>>>    at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
>>>    at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:782)
>>>    at
>>> org.apache.cxf.transport.udp.UDPConduit.dataReceived(UDPConduit.java:106)
>>>    at
>>> org.apache.cxf.transport.udp.UDPConduit.access$000(UDPConduit.java:59)
>>>    at
>>> org.apache.cxf.transport.udp.UDPConduit$UDPBroadcastOutputStream.close(UDPConduit.java:290)
>>>    at
>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>>>    at org.apache.cxf.transport.udp.UDPConduit.close(UDPConduit.java:118)
>>>    at
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>    at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
>>>    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
>>>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:456)
>>>    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434)
>>>    at
>>> org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:427)
>>>    at org.apache.cxf.jaxws.DispatchImpl.invokeAsync(DispatchImpl.java:416)
>>>    at
>>> org.apache.cxf.ws.discovery.WSDiscoveryClient.probe(WSDiscoveryClient.java:333)
>>>    at
>>> org.apache.cxf.ws.discovery.WSDiscoveryClient.probe(WSDiscoveryClient.java:283)
>>>    at org.apache.cxf.samples.discovery.Client.main(Client.java:46)
>>>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>    at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>    at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>    at java.lang.reflect.Method.invoke(Method.java:601)
>>>    at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291)
>>>    at java.lang.Thread.run(Thread.java:722)
>>> 
>>> Which is the release plan for 2.7.5?
>>> 
>>> Best regards,
>>> 
>>> Matteo
>>> 
>>> On 08/04/2013 20:36, Daniel Kulp wrote:
>>>> I just committed a bunch of updates to the WS-Discovery stuff that adds a
setVersion10() method onto the WSDiscoveryClient that should allow it to flip to the older
WS-Discovery spec (and SOAP 1.1 and the older WS-Addressing version).   It also fixes a bunch
of things with the wsa Actions and other bugs.    I'm hoping that will allow this to work.
  Is there any way you could grab tomorrows snapshots (or build from the latest branches)
and give it a spin and see?
>>>> 
>>>> On the server side, CXF services will now response to a 1.0 Probe as well
as the 1.1 probe.  However, I do still have a bit of mapping to do to map the various scopes.
 Right now, they only look at the 1.1 scope names.
>>>> 
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>> On Apr 4, 2013, at 1:27 PM, Daniel Kulp <dkulp@apache.org> wrote:
>>>> 
>>>>> Hit send too soon….
>>>>> 
>>>>> On Apr 4, 2013, at 1:25 PM, Daniel Kulp <dkulp@apache.org> wrote:
>>>>> 
>>>>>> On Apr 4, 2013, at 10:06 AM, Pampolini Matteo <matteo.pampolini@selex-es.com>
wrote:
>>>>>>> Hello there,
>>>>>>> 
>>>>>>> I'm trying to write a simple application to discover ONVIF devices
in my network.
>>>>>> Very interesting…  Wasn't even aware of them.   If anyone would
like to buy me one, I'd be more that happy to experiment more to get it working….   :-)
>>>>>> 
>>>>>> 
>>>>>>> Code is mainly based on ws_discovery sample with the following
simple difference:
>>>>>>> 
>>>>>>> List<EndpointReference> references = client.probe(new QName("http://www.onvif.org/ver10/network/wsdl"<http://www.onvif.org/ver10/network/wsdl>,
"NetworkVideoTransmitter"));
>>>>>>> 
>>>>>>> I'm writing because it does not work, of course. I do not even
see (through WireShark) multicast packets being sent over my network interface,
>>>>>>> can anyone please help me? Please note that ONVIF is based on
WS-Discovery version 2005/04.
>>>>>> There's two parts to this:  1) getting the UDP packets out    2)
WS-Discovery 2005/04.
>>>>>> 
>>>>>> No idea what to do about (1).
>>>>> Does the ws-discovery sample work?    If you run the sample with wireshark,
does that get the packets?   I guess that would be the starting point for looking at that.
>>>>> 
>>>>> (2) is definitely a big issue.  I'd likely try and use the CXF transformation
feature to map the namespaces and see if that works, but it obviously won't work if (1) cannot
be resolved.
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>> 
>>> 
>>> --
>>> Write once, compile everywhere
>>> Compile once, run somewhere...
>>> 
>>> 
>>> This email and any attachments are confidential to the intended recipient and
may also be privileged. If you are not the intended recipient please delete it from your system
and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
>>> Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via riservata
all'effettivo destinatario e possono essere soggetti a restrizioni legali. Se non siete l'effettivo
destinatario o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro
sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la
divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.
>>> 
>>> Prima di stampare questa comunicazione consideratene, per favore, l'impatto ambientale
>>> Please consider the environment before printing this email
> 
> 
> --
> Write once, compile everywhere
> Compile once, run somewhere...
> 
> This email and any attachments are confidential to the intended recipient and may also
be privileged. If you are not the intended recipient please delete it from your system and
notify the sender. You should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
> Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via riservata all'effettivo
destinatario e possono essere soggetti a restrizioni legali. Se non siete l'effettivo destinatario
o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro sistema e
di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la divulgazione
o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.
> 
> Prima di stampare questa comunicazione consideratene, per favore, l'impatto ambientale
> Please consider the environment before printing this email

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message