On Apr 29, 2013, at 5:27 AM, Pampolini Matteo <matteo.pampol...@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.pampol...@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 <dk...@apache.org> wrote:
>>>>
>>>>> Hit send too soon….
>>>>>
>>>>> On Apr 4, 2013, at 1:25 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>
>>>>>> On Apr 4, 2013, at 10:06 AM, Pampolini Matteo
>>>>>> <matteo.pampol...@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
>>>>> dk...@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
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
