[
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)
