cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-5339) Introduce WebSocket CXF Transport
Date Tue, 25 Feb 2014 19:08:21 GMT

    [ https://issues.apache.org/jira/browse/CXF-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911880#comment-13911880
] 

Aki Yoshida edited comment on CXF-5339 at 2/25/14 7:07 PM:
-----------------------------------------------------------

Hi Sergery, all,
just committed the early working code in master that uses cxf's http-jetty with an extended
jetty handler that can handle additionally websocket requests so that you can get the idea
of this usage pattern.

Currently, it allows you to open a websocket connection to the root service URL of the service
enabled for websockets, which is done in its destination configuration. Once the socket is
open, you can invoke various operations of that service. Currently, we have the following
assumptions:

1. to be able to select the operation and pass additional parameters to it, the request body
must include the request URL (e.g., GET /path…) and any additional headers and body entity
if any.

2. for the client to be able to interpret the response data, the response must return the
headers followed by any body entity. (In my initial commit, the response does not include
headers).

3. currently, if jetty-websocket-pkg is found, the extended jetty handler is instantiated
the destination even if the websocket feature is not enabled for that destination. This extended
handler can handle websocket-open requests but will reject opening sockets during the request
time if the websocket feature is not enabled for that destination. 

The reason for this behavior was to allow this enable/disable switching configurable when
using ServerFactoryBean to programatically create the destination. Allowing to pass this switching
parameter to the destination instantiation seems to require a change in its interface and
that appeared inappropriate. If there is a simple way to pass this parameter to the destination
before the handler is attached to it, we can separate the instantiation of the two handlers
clearly to force the extended handler to be only instantiated if indeed the websocket feature
is available and enabled for the destination. 

4. the unit test in systests/jaxrs performs some GET or POST operations returning some data
and one GET operation returning StreamingOutput where data can be pushed back to the client
continuously. This test is working, however, when it is executed, there seems to be some issue
that results in permGen error later at other tests (that indicates some memory leak). When
the test is not executed, this problem does not occur.  I observe this problem on my OSX setup
but not on a ubunthu desktop. And I am looking into this issue. Thus, this test is currently
disabled.

5. for non-jetty containers, we should add the atmosphere transport so that other web containers
are supported transparently. But for now, there are various questions regarding the websocket
usage patterns which we can discuss and try out with jetty.

regards, aki



was (Author: ay):
Hi Sergery, all,
just committed the early working code in master that uses cxf's http-jetty with an extended
jetty handler that can handle additionally websocket requests so that you can get the idea
of this usage pattern.

Currently, it allows you to open a websocket connection to the root service URL of the service
enabled for websockets, which is made in its destination configuration. Once the socket is
open, you can invoke various operations of that service. And we have the following assumptions:

1. to be able to select the operation and pass additional parameters to it, the request body
must include the request URL (e.g., GET /path…) and any additional headers and body entity
if any.

2. for the client to be able to interpret the response data, the response must return the
headers followed by any body entity. (In my initial commit, the response does not include
headers).

3. currently, if jetty-websocket-pkg is found, the extended handler is instantiated even if
the websocket feature is not enabled for the corresponding destination. This extended handler
can handle websocket open requests but rejects opening sockets during the request time if
the websocket feature is not enabled for that destination. 

The reason for this behavior was to allow this enable/disable switching when using ServerFactoryBean
to programatically configure the destination. Allowing to pass this switching parameter to
the destination instantiation seems to require a change in its interface and that appeared
inappropriate. If there is a simple way to pass this parameter to the destination before the
handler is attached, we can separate the instantiation of the handler clearly to force the
extended handler is only instantiated if indeed the websocket feature is available and enabled
for the destination. 

4. the unit test in systests/jaxrs  does simple GET or POST calls and one using StreamingOutput
to push data back to the client continuously. This test is working, however, when it is executed,
there seems to be some issue that results in permGen error later at other tests in systests/jarxs,
 I observed this problem on my OSX setup but not on a ubunthu desktop. So, I am looking into
this issue. Thus, this test is currently set disabled.

regards, aki


> Introduce WebSocket CXF Transport
> ---------------------------------
>
>                 Key: CXF-5339
>                 URL: https://issues.apache.org/jira/browse/CXF-5339
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>            Reporter: Sergey Beryozkin
>            Assignee: Aki Yoshida
>
> WebSocket transport will likely be supported on the server only. 
> It will allow users, specifically those not working directly with Camel, do Web-Socket
based Web UI targeting CXF endpoints returning some real time info.
> Additionally, hope is it will help revitalise LogBrowser project where having the log
or other events displayed for individual endpoints in real time can be quite cool; supporting
such a feature might help us basically move it into a sub-project   



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message