Hello Dan,
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!
Will you add another API to configure the return value of
getSoapVersion() or do you have a better solution in mind?
Best regards,
Matteo
On 26/04/2013 17:11, Daniel Kulp wrote:
On Apr 23, 2013, at 11:05 AM, Pampolini Matteo <[email protected]>
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 <[email protected]> wrote:
Hit send too soon….
On Apr 4, 2013, at 1:25 PM, Daniel Kulp <[email protected]> wrote:
On Apr 4, 2013, at 10:06 AM, Pampolini Matteo <[email protected]>
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
[email protected] - 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
