camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject [Question] how to proceed for websocket
Date Mon, 17 Feb 2014 10:28:00 GMT
Hi Camel-team,

I would like to integrate the atmosphere based websocket component to
camel. I posted messages regarding this topic several times and most
recent one some months ago [1].

I would like to briefly summarize the current status and propose a few
options about how we can proceed. I would appreciate your feedback.

The current camel-websocket component uses jetty's native API and also
starts an embedded jetty server automatically even when the endpoint
is given as eg. "websocekt://echo".

I needed a websocket component that can be used also with tomcat and
also in a container environment to use its provided servlet
environment. And this was the atmosphere based websocket that I
mentioned earlier. The implementation is analogue to camel-servlet and
it uses the provdied servlet environment and can be used with jetty
and tomcat in the container mode or also in the embedded mode when you
start an embedded server to attach to it.

My question is how to integrate this component into camel.

Currently, the component is named as wsservlet and it is analogue to
component servlet but differs in its operation to run duplex
communication to the servlet side socket similar to the existing
websocket component. It uses the current atmosphere version 2.1.0 and
located at my sandbox repo [2].

Option 1:
Keep this component as it. In this case, the endpoint is given as,
e.g.,  wsservlet:///echo.

Option 2:
Rename it to websocket2 and make it start the embedded jetty
automatically when the endpoint is given with host:port info and use
the provided server otherwise. In other words, if the endpoint is
given as "websocket2://localhsot:8989/echo", it will  start a server
at port 8989 and if it is given as "websocket2:///echo", it will use
the container's server.

Option 3:
Rename it to websoket and replace the existing jetty based websocket
component. The concern that I had in this option was that this would
introduce an incompatibility to the behavior of the original websocket

So I am prefering options 1 or 2 for the moment. But if people say
it's okay to change the behavior of the existing component, we can go
for option 3.

If no one expresses preferences, I am thinking about going for option 2.

Please let me know.



View raw message