You do not have to use StreamingOutput, see
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/websocket/BookStoreWebSocket.java#L70
or if StreamingOutput like behavior is needed then:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/websocket/BookStoreWebSocket.java#L111
Sergey
On 12/08/16 10:01, CLEMENT Jean-Philippe wrote:
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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : vendredi 12 août 2016 10:15
À : users@cxf.apache.org
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:elak...@gmail.com] Envoyé : jeudi 11 août 2016 19:00 À
: users@cxf.apache.org 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
<jean-philippe.clem...@fr.thalesgroup.com>:
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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : mercredi 10 août 2016 17:48
À : users@cxf.apache.org
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:elak...@gmail.com] Envoyé : mercredi 10 août
2016 16:57 À : users@cxf.apache.org 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
<jean-philippe.clem...@fr.thalesgroup.com>:
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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : mardi 9 août 2016 10:30
À : users@cxf.apache.org
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:niti...@hcl.com] Envoyé : mardi 9 août
2016 01:25 À : users@cxf.apache.org 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:elak...@gmail.com]
Sent: Monday, August 08, 2016 3:52 PM
To: users@cxf.apache.org
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 <elak...@gmail.com>:
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
<jean-philippe.clem...@fr.thalesgroup.com>:
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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : lundi 8 août 2016 14:54
À : Aki Yoshida
Cc : users@cxf.apache.org
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:elak...@gmail.com] Envoyé : vendredi 29
juillet 2016 15:34 À : CLEMENT Jean-Philippe Cc :
users@cxf.apache.org 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 <elak...@gmail.com>:
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
<jean-philippe.clem...@fr.thalesgroup.com>:
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:elak...@gmail.com] Envoyé : vendredi 29
juillet 2016 00:32 À : CLEMENT Jean-Philippe Cc :
users@cxf.apache.org 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
<jean-philippe.clem...@fr.thalesgroup.com>:
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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : jeudi 28 juillet 2016 10:53 À : users@cxf.apache.org
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:elak...@gmail.com] Envoyé : mercredi 27
juillet 2016 17:58 À : users@cxf.apache.org 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
<jean-philippe.clem...@fr.thalesgroup.com>:
Sure, could you please provide the URL where I may find your WebSocket demo?
Regards,
JP
-----Message d'origine-----
De : Sergey Beryozkin [mailto:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 16:39 À : users@cxf.apache.org 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:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 15:46 À : users@cxf.apache.org 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:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 15:34 À : users@cxf.apache.org 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:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 15:07 À : users@cxf.apache.org 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:jean-philippe.clem...@fr.thalesgroup.com]
Envoyé : mercredi 27 juillet 2016 14:44 À :
users@cxf.apache.org 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:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 14:35 À : users@cxf.apache.org 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:sberyoz...@gmail.com] Envoyé :
mercredi
27 juillet 2016 12:34 À : users@cxf.apache.org 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.
---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
--------
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
