camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: update of websocket
Date Tue, 29 Oct 2013 12:11:05 GMT
Hi all,
I would like to get back to this websocket topic and I was wondering
if you could give feedback/direction toward how we can proceed.

Concretely, I think these components do not fit naturally into the
existing related components camel-servlet and camel-ahc because these
components have only either the consumer-side mode or the
producer-side mode, respectively. For the websocket scenario, it's
good to have both in the server side as well as the client side so
that you can pass data to the socket in the duplex mode.

and so on with further questions...

feedback appreciated.

regards, aki

2013/9/30 Aki Yoshida <>:
> Hi,
> A few weeks ago, I posted to this list about my thought on the camel-websocket
> I did some prototyping and I wanted to share this with you to get some
> feedback.  But I will be on vacation and not brining my notebook with
> me, so I'll be making a break for a while and get back working on it
> after I come back.
> And here it goes. I created two endpoints. One is for the server side
> websocket handling based on Atmosphere. It supports both the consumer
> and producer modes to have an asynchronous duplex data transfer on the
> socket, as done in the current camel-websocket component.
> The implementation is based on the camel-servlet component and uses
> its own servlet that delegates calls to the Atmosphere's websocket
> handler that is connected to the camel component.
> This code [1] is available at my github. Please note that I just used
> an apache camel package name and version during this prototyping and I
> hope this was okay for this kind of work.
> I prepared a test scenario [2] that can be executed on karat. This
> requires a service bundle [3] that publishes camel-websocket2's
> CamelWebSocketServlet to the OSGi registry. There is a short
> instruction [4] for setting up karaf for running this scenario.
> This scenario is written in Blueprint but I made also the
> corresponding Spring version (see those without "_bp"). In either
> case, the scenario has two routes: one performing a single websocket
> echoing and the other performing a broadcast websocket echoing.
> The second endpoint component is for the client side websocket based
> on async-http-client. This also supports both consumer and producer to
> have a duplex data transfer on the socket as in the server side
> processing. I put this endpoint in another component [5], but we could
> consider consolidating these two into one or maybe with others.
> As I mentioned at the beginning, I am going on vacation, so I just put
> together all this before making a break. There is some stuff that I
> will clean up or refactor or consolidate after I come back from my
> vacation.
> I would appreciate if you can look at it and give some feedback.
> Thanks.
> [1]
> [2]
> [3]
> [4]
> [5]
> regards, aki

View raw message