That said, I did not find an easy way to serialize objects when sending them
from the server through the web socket. I mean, the StreamingOutput.write()
provides an OutputStream; the OutputStream object is very low level / basic.
Could be great to have instead something like a SocketOutputStream which allows
to write objects.
The SocketOutputStream would be tied to the type defined in the @Produces tag:
* StreamingOutput would evolve to
StreamingOutput.write(SocketOutputStream output) throws ...
* where SocketOutputStream would contain the extra method
SocketOutputStream.write(Object obj) throws ...
* for instance:
@GET
@Path("websocket/sample")
@Produces(MediaType.APPLICATION_JSON) // transformation to be
used for SocketOutputStream.write(Object)
public StreamingOutput wsSample(....) { ... } //
SocketOutputStream registration
* then the server could easily sent events using SocketOutputStream:
socketOS.write(someObjectInstance), someObjectInstance which would be
serialized as JSON in the example above.
Do you think this is relevant and can be added to CXF?
Regards,
JP
-----Message d'origine-----
De : CLEMENT Jean-Philippe [mailto:[email protected]]
Envoyé : vendredi 12 août 2016 10:15
À : [email protected]
Objet : RE: Error during WebSocket handshake: Unexpected response code
Good. I'm wondering whether the socket.binaryType="blob" is local to the client
or also send to the server. If sent, CXF may use it so it would be "automatic"
(set by the client) with no extra server configuration. That said, if the
binaryType is not sent then that option could be sent in the request header:
Request = Request-Line CRLF
*(( header ) CRLF)
CRLF
[ body ]
...so something like
ws://host:port/cxf/some/sample/r/norg.atmosphere.websocket.binaryWrite=true
or
ws://host:port/cxf/some/sample/r/nmode=binary
or - if that makes sense
ws://host:port/cxf/some/sample/r/nmode=blob
ws://host:port/cxf/some/sample/r/nmode=arraybuffer
JP
-----Message d'origine-----
De : Aki Yoshida [mailto:[email protected]] Envoyé : jeudi 11 août 2016 19:00 À
: [email protected] Objet : Re: Error during WebSocket handshake: Unexpected
response code
This (i.e., customizing atmosphere framework configuration) was on the todo
list...
The atmosphere framework in CXF is currently set up with some predefined
options and there is no way to change this setting.
The only customizable setting is to add or change atmosphere interceptors.
For your particular case, you will need to set property
org.atmosphere.websocket.binaryWrite to true.
That means, we will need either
- a way to pass some property bag from cxf bus to set these properties or
- a new AtmosphereFeature that will allow those parameters plus the
interceptors/handlers to be customized.
I created CXF-7007 to track this issue.
regards, aki
2016-08-11 16:36 GMT+02:00 CLEMENT Jean-Philippe
<[email protected]>:
> The browser seems ok, so it would mean that CXF does not support WebSocket
> binary mode.
>
> Is there a plan for CXF to support the binary mode?
>
> Regards,
> JP
>
> -----Message d'origine-----
> De : CLEMENT Jean-Philippe
> [mailto:[email protected]]
> Envoyé : mercredi 10 août 2016 17:48
> À : [email protected]
> Objet : RE: Error during WebSocket handshake: Unexpected response code
>
> Aki,
>
> Your support is a great relief :) I succeeded in having strings flowing from
> CXF server to WebSocket clients!
>
> I would like to do the same with bytes instead of strings. So I changed the
> server code to @Produces(MediaType.APPLICATION_OCTET_STREAM), and, on the
> client side I set socket.binaryType="blob" (also tried "arraybuffer").
>
> Unfortunately the client events are still strings. I'm wondering where the
> problem comes from, client/browser or server/CXF. Does CXF support binary
> WebSocket communication? How?
>
> Regards,
> JP
>
> -----Message d'origine-----
> De : Aki Yoshida [mailto:[email protected]] Envoyé : mercredi 10 août
> 2016 16:57 À : [email protected] Objet : Re: Error during WebSocket
> handshake: Unexpected response code
>
> Hi JP,
> CXF's websocket transport uses one of the atmosphere protocol interceptors to
> support the jaxrs calls. The protocol interceptor makes sure the necessary
> meta information is included in the websocket message so that the correct
> operation is found. This is similar to what a plain jaxrs rest call consists
> of the content part and the header part (i.e.g, the http method and the
> request path). Without this information, you cannot choose the correct jaxrs
> operation if there are more than one under the root resource path or have
> specific produces/consumes options.
>
> Depending on which protocol handlers that you use, you have to format the
> message differently. For the default websocket protocol binding, you can look
> at this document http://cxf.apache.org/docs/websocket.html and also look at
> the node.js client and the plain javascript client in
> samples/jax_rs/websocket.
> The other atmosphere jaxrs protocol interceptors available are
> Swaggersocket's
> io.swagger.swaggersocket.server.SwaggerSocketProtocolInterceptor and
> atmosphere's org.atmosphere.interceptor.SimpleRestInterceptor.
>
> regards aki
>
> 2016-08-10 14:31 GMT+02:00 CLEMENT Jean-Philippe
> <[email protected]>:
>> Hi Aki,
>>
>> A little step closer to get the WebSocket running with CXF. CFX 3.1.7 does
>> not display the " Websocket protocol not supported" error anymore. But I
>> don't understand how CXF works and what is expected.
>>
>> Browser side, examples sends a string when the web socket is connected, for
>> instance ws.send("Hello"), which fails with CXF with the IOException:
>> invalid request: Hello
>>
>> Looking at CXF code (WebSocketUtils.readHeaders()), the string is analyzed
>> instead of being sent as is to my handling method; CXF expects a string
>> formatted as "<method> <URI>". Do you understand why? Is there a doc for
>> this?
>>
>> Regards,
>> JP
>>
>> -----Message d'origine-----
>> De : CLEMENT Jean-Philippe
>> [mailto:[email protected]]
>> Envoyé : mardi 9 août 2016 10:30
>> À : [email protected]
>> Objet : RE: Error during WebSocket handshake: Unexpected response
>> code
>>
>> Hi Niten,
>>
>> Yes right, I went back to Karaf 4.0.4 and my sample starts properly, and I
>> don't get the "src-resolve: Canot resolve the name 'ptp:ParameterizedInt' to
>> a(n) 'type definition' component." error anymore.
>>
>> Thanks!
>>
>> Regards,
>> JP
>>
>> -----Message d'origine-----
>> De : Niten Aggarwal [mailto:[email protected]] Envoyé : mardi 9 août
>> 2016 01:25 À : [email protected] Objet : RE: Error during
>> WebSocket
>> handshake: Unexpected response code
>>
>> It's working for me with Karaf 4.0.4 which I reported in same aries ticket.
>> Issue is fixed with blueprint-core 1.6.2 but karaf 4.0.5 points to 1.6.1.
>> It doesn’t fail for all blueprint bundles but not able to figure out root
>> cause.
>>
>> Thanks,
>> Niten Aggarwal
>>
>>
>> -----Original Message-----
>> From: Aki Yoshida [mailto:[email protected]]
>> Sent: Monday, August 08, 2016 3:52 PM
>> To: [email protected]
>> Subject: Re: Error during WebSocket handshake: Unexpected response
>> code
>>
>> Hi JP,
>> regarding the firewall issue, I just saw people are talking about some issue
>> with karaf-4.0.5 with cxf.
>> http://cxf.547215.n5.nabble.com/Blueprint-NamespaceHandler-issue-with
>> - karaf-4-0-5-td5770550.html You might want to use an older Karaf
>> until the issue has been clarified and resolved.
>>
>> 2016-08-09 0:45 GMT+02:00 Aki Yoshida <[email protected]>:
>>> Hi JP,
>>> If you are using Karaf behind a firewall, you will have to make sure
>>> all the referenced artifacts are either locally available or
>>> accessible over the http proxy (and this needs to be told to Karaf
>>> via etc/org.ops4j.pax.url.mvn.cfg).
>>>
>>> I can't tell what is happening in your setup. Which bundle is not
>>> starting? All the cxf schemas should be loadable from the relevant
>>> cxf bundles themselves without accessing their real physical schema
>>> locations. So, once the bundles are all available, you don't even
>>> need an external network connection to run cxf samples. Have you
>>> tried a plan cxf sample on your Karaf instance?
>>>
>>> atmosphere.js and node.js won't be interfered by a firewall. What
>>> you need to make sure is that you will have to set up your http
>>> proxy for npm, so that you can install the required node.js
>>> libraries via the npm install command.
>>>
>>> Regarding the protocol setting of atmosphere where you saw
>>> "websocket", that is not the url but just the name to tell
>>> atmosphere to use websocket as the preferred protocol. You can also
>>> use a plain javascript client. See the README file of the standalone
>>> websocket sample.
>>>
>>> regards, aki
>>>
>>> 2016-08-08 15:37 GMT+02:00 CLEMENT Jean-Philippe
>>> <[email protected]>:
>>>> I went a little further. I changed the demo pom.xml file and changed
>>>> 3.1.7-SNAPSHOT to 3.1.7. The demo compiles and installs properly. So I
>>>> went to the test part which is a javascript which depends on
>>>> atmosphere.js... unfortunately once again I experience firewall issues.
>>>>
>>>> I opened the javascript file and tried to understand how it works. It
>>>> seems the test makes no use of the WebSocket API but uses a URL with a
>>>> "websocket" protocol. I'm not too sure the URL is the standard way of
>>>> getting a web socket (?).
>>>>
>>>> Then I tried my CXF example as long with CXF 3.1.7 but now the service
>>>> fails to start with the error:
>>>> src-resolve: Canot resolve the name 'ptp:ParameterizedInt' to a(n)
>>>> 'type definition' component.
>>>> org.xml.sax.SAXParseException; systemId:
>>>> bundleresource://85.fwk17319689/schemas/blueprint/core.xsd;
>>>> lineNumber: 76; columnNumber: 87
>>>>
>>>> Where bundle 85 is "Apache CXF Core" (3.1.7). Seems I have no luck with
>>>> web sockets and CXF :) ...could you please help?
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>> JP
>>>>
>>>> -----Message d'origine-----
>>>> De : CLEMENT Jean-Philippe
>>>> [mailto:[email protected]]
>>>> Envoyé : lundi 8 août 2016 14:54
>>>> À : Aki Yoshida
>>>> Cc : [email protected]
>>>> Objet : RE: Error during WebSocket handshake: Unexpected response
>>>> code
>>>>
>>>> Hello Aki,
>>>>
>>>> The CXF-3.1.7 was released and installs properly in Karaf. So I went to
>>>> the demo but I failed to find the 3.1.7 version.
>>>>
>>>> The "3.1.x-fixes" branch contains the 3.1.8-SNAPSHOT and the "cxf-3.1.7"
>>>> tag contains the 3.1.7-SNAPSHOT. We still do have issues with the snapshot
>>>> repos proxies so the snapshot versions fail to compile.
>>>>
>>>> Is there a way to get the 3.1.7 demo?
>>>>
>>>> Thank you.
>>>>
>>>> Regards,
>>>> JP
>>>>
>>>> -----Message d'origine-----
>>>> De : Aki Yoshida [mailto:[email protected]] Envoyé : vendredi 29
>>>> juillet 2016 15:34 À : CLEMENT Jean-Philippe Cc :
>>>> [email protected] Objet : Re: Error during WebSocket handshake:
>>>> Unexpected response code
>>>>
>>>> or wait a few days and try cxf-3.1.7's feature.
>>>>
>>>>
>>>> 2016-07-29 15:14 GMT+02:00 Aki Yoshida <[email protected]>:
>>>>> My mistake cxf-3.1.x uses atmosphere 2.3.x.
>>>>>
>>>>> But cxf-3.1.6 doesn't come with the jax_rs_websocket_osgi sample,
>>>>> so there is no
>>>>> mvn:org.apache.cxf.samples/jax_rs_websocket_osgi/3.1.6
>>>>> unless you have taken the 3.1.x-SNAPSHOT version and renamed it
>>>>> and built it locally.
>>>>> Please try the whole procedure using either 3.2.0-SNAPSHOT or
>>>>> 3.1.8-SNAPSHOT.
>>>>> regards, aki
>>>>>
>>>>> 2016-07-29 10:38 GMT+02:00 CLEMENT Jean-Philippe
>>>>> <[email protected]>:
>>>>>> Thank you Aki for your support. I strictly followed the instructions
>>>>>> contained in the demo readme, i.e.:
>>>>>> feature:repo-add cxf 3.1.6
>>>>>> feature:install cxf-jaxrs cxf-transports-websocket-server
>>>>>> install -s
>>>>>> mvn:org.apache.cxf.samples/jax_rs_websocket_osgi/3.1.6
>>>>>>
>>>>>> It's when installing the "cxf-transports-websocket-server" feature that
>>>>>> the org.atmosphere.runtime 2.3.5 is added. So, it would mean that the
>>>>>> feature has a problem, right?
>>>>>>
>>>>>> On the other hand we do have a problem with our Maven proxy here, and I
>>>>>> can't get CXF 3.2.0-SNAPSHOT yet. Will try asap.
>>>>>>
>>>>>> Regards,
>>>>>> JP
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Aki Yoshida [mailto:[email protected]] Envoyé : vendredi 29
>>>>>> juillet 2016 00:32 À : CLEMENT Jean-Philippe Cc :
>>>>>> [email protected] Objet : Re: Error during WebSocket handshake:
>>>>>> Unexpected response code
>>>>>>
>>>>>> I don't know how you got atmosphere 2.3.5 deployed.
>>>>>> both cxf 3.2.x and 3.1.x are compatible with atmosphere 2.4.x but not
>>>>>> with 2.3.x.
>>>>>> I just verified both cxf master (3.2.0-SNAPSHOT) and 3.1.x
>>>>>> (3.1.8-SNAPSHOT) on both karaf 3.0.6 and 4.0.5.
>>>>>> regards, aki
>>>>>>
>>>>>> 2016-07-28 11:23 GMT+02:00 CLEMENT Jean-Philippe
>>>>>> <[email protected]>:
>>>>>>> Also in Karaf logs I found a warn trace which corresponds to the 501
>>>>>>> code:
>>>>>>> AsynchronousProcessor | 106 - org.atmosphere.runtime -
>>>>>>> 2.3.5
>>>>>>> | Websocket protocol not supported
>>>>>>>
>>>>>>> Does CXF 3.1.6 support Websocket? Is there anything extra to configure
>>>>>>> or add?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Regards,
>>>>>>> JP
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : CLEMENT Jean-Philippe
>>>>>>> [mailto:[email protected]]
>>>>>>> Envoyé : jeudi 28 juillet 2016 10:53 À : [email protected]
>>>>>>> Objet
>>>>>>> : RE: Error during WebSocket handshake: Unexpected response code
>>>>>>>
>>>>>>> Hello Aki,
>>>>>>>
>>>>>>> As I don't have access to GIT (company internet access restriction), I
>>>>>>> downloaded CXF as long with your demo.
>>>>>>>
>>>>>>> My first trial using the tag 3.1.6 leaded to an archive which does not
>>>>>>> contain the demo for OSGi.
>>>>>>> My second trial was using the branch 3.1.x which contains the
>>>>>>> demo in version 3.1.7-SNAPSHOT but fails to compile
>>>>>>>
>>>>>>> My last attempt was using the trunk which contains the demo in version
>>>>>>> 3.2.0-SNAPSHOT and compiles :) ...but fails to start with CXF 3.1.6
>>>>>>> (for some reason the feature:repo-add cxf 3.2.0-SNAPSHOT fails).
>>>>>>>
>>>>>>> Still, I'm close to have my test working. Just blocked on the
>>>>>>> acknowledgement 501 issue (still with CXF 3.1.6).
>>>>>>>
>>>>>>> JP
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Aki Yoshida [mailto:[email protected]] Envoyé : mercredi 27
>>>>>>> juillet 2016 17:58 À : [email protected] Objet : Re: Error
>>>>>>> during WebSocket handshake: Unexpected response code
>>>>>>>
>>>>>>> As Sergey mentioned already, you will need to build the websocket
>>>>>>> sample on your own.
>>>>>>> And this is all described in README.txt of the websocket sample code
>>>>>>> folder.
>>>>>>> You must have read it partially as you knew the sample artifact name.
>>>>>>> But you will have to go through the build part described in that
>>>>>>> document and shouldn't just jump into the middle of the document.
>>>>>>>
>>>>>>> 2016-07-27 16:56 GMT+02:00 CLEMENT Jean-Philippe
>>>>>>> <[email protected]>:
>>>>>>>> Sure, could you please provide the URL where I may find your WebSocket
>>>>>>>> demo?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> JP
>>>>>>>>
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : Sergey Beryozkin [mailto:[email protected]] Envoyé :
>>>>>>>> mercredi
>>>>>>>> 27 juillet 2016 16:39 À : [email protected] Objet : Re:
>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>
>>>>>>>> jax_rs_websocket_osgi is the demo itself, you need to build it.
>>>>>>>>
>>>>>>>> If you feel the whole CXF and Websockets/etc is new then perhaps you
>>>>>>>> can start with a websocket demo which I have built and confirmed is
>>>>>>>> working, test the actual WebSocket support, see if it works the way
>>>>>>>> you expect it and then finish off with making a websocket_osgi demo
>>>>>>>> work.
>>>>>>>>
>>>>>>>> websocket_osgi demo needs to be built manually - it won;t be in
>>>>>>>> Central.
>>>>>>>> Download the appropriate CXF distribution - and build this demo inside
>>>>>>>> that distribution. Or checkout CXF master or 3.1.6 from GIT.
>>>>>>>> I've just built this demo in my 3.2.0-SNAPSHOT and it is avail in the
>>>>>>>> local Maven repo.
>>>>>>>>
>>>>>>>> But may be it will be simpler to start from a 'plain' websockets demo.
>>>>>>>>
>>>>>>>> Sergey
>>>>>>>>
>>>>>>>> On 27/07/16 17:12, CLEMENT Jean-Philippe wrote:
>>>>>>>>> Yes you are right. Also I'm a CXF and webstuff newbie which
>>>>>>>>> does not help :P
>>>>>>>>>
>>>>>>>>> I made a clean installation of our Karaf assembly, then followed the
>>>>>>>>> readme. The CXF 3.2.0-SNAPSHOT was not found, but the installation
>>>>>>>>> succeeded with the 3.1.6. Then the demo was not found (neither 3.1.6
>>>>>>>>> nor 3.2.0):
>>>>>>>>> install -s
>>>>>>>>> mvn:org.apache.cxf.samples/jax_rs_websocket_osgi/3.1.6
>>>>>>>>>
>>>>>>>>> I was not able to find the jax_rs_websocket_osgi in maven central
>>>>>>>>> either. As a fallback, I installed my test and went back to the
>>>>>>>>> client trace stating that the WebSocket connection failed due to the
>>>>>>>>> unexpected response 501.
>>>>>>>>>
>>>>>>>>> Maybe it is due to the CXF version 3.1.6 instead of 3.2.0-SNAPSHOT?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> JP
>>>>>>>>>
>>>>>>>>> -----Message d'origine-----
>>>>>>>>> De : Sergey Beryozkin [mailto:[email protected]] Envoyé :
>>>>>>>>> mercredi
>>>>>>>>> 27 juillet 2016 15:46 À : [email protected] Objet : Re:
>>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>>
>>>>>>>>> See may last email on the rel address and please do work with
>>>>>>>>> the demo first. Sometimes users need to dive a bit into the
>>>>>>>>> details of a given demo :-)
>>>>>>>>>
>>>>>>>>> Sergey
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 27/07/16 16:42, CLEMENT Jean-Philippe wrote:
>>>>>>>>>> I had to add cxf-http-jetty which is not described in the
>>>>>>>>>> readme
>>>>>>>>>> - I'm not too sure this sample was tested on Karaf 4 (4.0.4)...
>>>>>>>>>> now I'm getting error 501 ... :D
>>>>>>>>>>
>>>>>>>>>> JP
>>>>>>>>>>
>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>> De : Sergey Beryozkin [mailto:[email protected]] Envoyé :
>>>>>>>>>> mercredi
>>>>>>>>>> 27 juillet 2016 15:34 À : [email protected] Objet : Re:
>>>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>>>
>>>>>>>>>> Look at that demo and check README/etc, and make it work in Karaf.
>>>>>>>>>> I haven't written it but looks like it has all the info
>>>>>>>>>> needed
>>>>>>>>>>
>>>>>>>>>> Sergey
>>>>>>>>>> On 27/07/16 16:25, CLEMENT Jean-Philippe wrote:
>>>>>>>>>>> Good, I went to
>>>>>>>>>>> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/websocket_osgi
>>>>>>>>>>> and added the missing cxf-transports-websocket-server feature.
>>>>>>>>>>>
>>>>>>>>>>> Things get better :) ... now I get NoClassDefFoundError:
>>>>>>>>>>> org/apache/cxf/transport/http_jetty/JettyHTTPServerEngineFactory.
>>>>>>>>>>>
>>>>>>>>>>> Well, starting from a Karaf basic custom assembly, what features am
>>>>>>>>>>> I expected to add as bootFeatures in order to get CXF+WebSockets
>>>>>>>>>>> running?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> JP
>>>>>>>>>>>
>>>>>>>>>>> -----Message d'origine-----
>>>>>>>>>>> De : Sergey Beryozkin [mailto:[email protected]] Envoyé :
>>>>>>>>>>> mercredi
>>>>>>>>>>> 27 juillet 2016 15:07 À : [email protected] Objet : Re:
>>>>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>>>>
>>>>>>>>>>> Look at the websocket_osgi demo done by Aki
>>>>>>>>>>>
>>>>>>>>>>> Sergey
>>>>>>>>>>>
>>>>>>>>>>> On 27/07/16 15:55, CLEMENT Jean-Philippe wrote:
>>>>>>>>>>>> Haha, it seems I'm in the "servlet container mode" and not the
>>>>>>>>>>>> "Jetty embedded mode"... so I would have, as far as I understood,
>>>>>>>>>>>> set both the address as a path and the transportId to
>>>>>>>>>>>> http://cxf.apache.org/transports/websocket.
>>>>>>>>>>>>
>>>>>>>>>>>> I did try but I get the following exception:
>>>>>>>>>>>> BusException: No DestinationFactory was found for the
>>>>>>>>>>>> namespace http://cxf.apache.org/transports/websocket
>>>>>>>>>>>>
>>>>>>>>>>>> What should I add to get rid of this exception?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> JP
>>>>>>>>>>>>
>>>>>>>>>>>> -----Message d'origine----- De : CLEMENT Jean-Philippe
>>>>>>>>>>>> [mailto:[email protected]]
>>>>>>>>>>>> Envoyé : mercredi 27 juillet 2016 14:44 À :
>>>>>>>>>>>> [email protected] Objet
>>>>>>>>>>>> : RE: Error during WebSocket handshake: Unexpected response
>>>>>>>>>>>> code
>>>>>>>>>>>>
>>>>>>>>>>>> I don't find the issue but something is strange; the /cxf page
>>>>>>>>>>>> displays:
>>>>>>>>>>>> Endpoint address:
>>>>>>>>>>>> http://localhost:8181/cxfws://localhost/socket
>>>>>>>>>>>>
>>>>>>>>>>>> My blueprint is:
>>>>>>>>>>>> <jaxrs:server id="something"
>>>>>>>>>>>> address="ws://localhost/socket">
>>>>>>>>>>>>
>>>>>>>>>>>> The address parsing seems strange isn't it?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> JP
>>>>>>>>>>>>
>>>>>>>>>>>> -----Message d'origine----- De : Sergey Beryozkin
>>>>>>>>>>>> [mailto:[email protected]] Envoyé :
>>>>>>>>>>>> mercredi
>>>>>>>>>>>> 27 juillet 2016 14:35 À : [email protected] Objet : Re:
>>>>>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>>>>>
>>>>>>>>>>>> I've run a demo which Aki did and it works fine.
>>>>>>>>>>>> Yes make sure 'ws:' (or wss:) is used, it enables the
>>>>>>>>>>>> loading of the CXF WebSocket transport which can support both
>>>>>>>>>>>> WebSocket and 'plain'
>>>>>>>>>>>> HTTP
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers, Sergey
>>>>>>>>>>>> On 27/07/16 13:49, CLEMENT Jean-Philippe wrote:
>>>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I added "socket.binaryType= 'arraybuffer';" but I get the same
>>>>>>>>>>>>> error. I'm not too sure if it is used or not as I don't know when
>>>>>>>>>>>>> WebSocket tries to connect, and setting socket.binaryType or
>>>>>>>>>>>>> socket.binarytype or socket.whatEver does not display any error.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, I'm wondering about the CXF configuration, is the binding
>>>>>>>>>>>>> to a separate server configured with a "ws://..." (the "ws" part)
>>>>>>>>>>>>> address mandatory?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> JP
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Message d'origine----- De : Sergey Beryozkin
>>>>>>>>>>>>> [mailto:[email protected]] Envoyé :
>>>>>>>>>>>>> mercredi
>>>>>>>>>>>>> 27 juillet 2016 12:34 À : [email protected] Objet : Re:
>>>>>>>>>>>>> Error during WebSocket handshake: Unexpected response code
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>> On 27/07/16 12:26, CLEMENT Jean-Philippe wrote:
>>>>>>>>>>>>>> Dear CXF experts,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm trying to connect a web client to a CXF WebSocket. The
>>>>>>>>>>>>>> browser logs the error "WebSocket connection failed: Error
>>>>>>>>>>>>>> during WebSocket handshake: Unexpected response code: XXX". The
>>>>>>>>>>>>>> XXX response code changes depending on the @Produces annotation:
>>>>>>>>>>>>>> 200 when text/plain, 406 when text/*.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 406 with text/* can be explained by the fact the websocket
>>>>>>>>>>>>> client does not know what HTTP Accept is and the spec
>>>>>>>>>>>>> requires that when the final response type has a wildcard
>>>>>>>>>>>>> subtype (with the only exception being
>>>>>>>>>>>>> application/*) then it is 406.
>>>>>>>>>>>>>> The server Java looks like this:
>>>>>>>>>>>>>> @GET
>>>>>>>>>>>>>> @Path("monitor")
>>>>>>>>>>>>>> @Produces("text/*")
>>>>>>>>>>>>>> public StreamingOutput greetMonitor() {
>>>>>>>>>>>>>> return stream -> {
>>>>>>>>>>>>>> stream.write("Ok".getBytes());
>>>>>>>>>>>>>> stream.flush();
>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The client Javascript looks like this:
>>>>>>>>>>>>>> var socket= new
>>>>>>>>>>>>>> WebSocket("ws://myurlwithsameportaswebservice/cxf/test/monitor"
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>> ;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> socket.onmessage= function(e) { console.log(e.data); };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What's wrong?
>>>>>>>>>>>>> Can you please look at
>>>>>>>>>>>>> https://github.com/apache/cxf/blob/master/distribution/src
>>>>>>>>>>>>> /
>>>>>>>>>>>>> m
>>>>>>>>>>>>> ai
>>>>>>>>>>>>> n/
>>>>>>>>>>>>> r
>>>>>>>>>>>>> e l e a s
>>>>>>>>>>>>> e/samples/jax_rs/websocket/src/main/resources/index.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> may be you need to set a socket type
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers, Sergey
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> JP
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sergey Beryozkin
>>>>>>>>>>>>>
>>>>>>>>>>>>> Talend Community Coders
>>>>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sergey Beryozkin
>>>>>>>>>>>>
>>>>>>>>>>>> Talend Community Coders
>>>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sergey Beryozkin
>>>>>>>>>>>
>>>>>>>>>>> Talend Community Coders
>>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sergey Beryozkin
>>>>>>>>>>
>>>>>>>>>> Talend Community Coders
>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sergey Beryozkin
>>>>>>>>>
>>>>>>>>> Talend Community Coders
>>>>>>>>> http://coders.talend.com/
>>>>>>>>>
>>>>>>>>
>>
>>
>> ::DISCLAIMER::
>> ---------------------------------------------------------------------
>> -
>> ---------------------------------------------------------------------
>> -
>> --------
>>
>> The contents of this e-mail and any attachment(s) are confidential and
>> intended for the named recipient(s) only.
>> E-mail transmission is not guaranteed to be secure or error-free as
>> information could be intercepted, corrupted, lost, destroyed, arrive late or
>> incomplete, or may contain viruses in transmission. The e mail and its
>> contents (with or without referred errors) shall therefore not attach any
>> liability on the originator or HCL or its affiliates.
>> Views or opinions, if any, presented in this email are solely those of the
>> author and may not necessarily reflect the views or opinions of HCL or its
>> affiliates. Any form of reproduction, dissemination, copying, disclosure,
>> modification, distribution and / or publication of this message without the
>> prior written consent of authorized representative of HCL is strictly
>> prohibited. If you have received this email in error please delete it and
>> notify the sender immediately.
>> Before opening any email and/or attachments, please check them for viruses
>> and other defects.
>>
>> ---------------------------------------------------------------------
>> -
>> ---------------------------------------------------------------------
>> -
>> --------
