[This is a continuation of https://issues.apache.org/jira/browse/PROTON-1569 ]
Thanks for the response Robbie. Given that I already use reactor model for my client, is there a plan for proxy server support with the existing proton - reactor? Original Discussion: Description: Is there a way to use web sockets as a transport layer for proton-j? My main use cases for this request - 1. Being able to route traffic through 443 port instead of AMQP ports. 2. Being able to connect to messaging brokers from a machine behind a proxy server. I see that there are already two issues for the same which are closed right now. I also see that through "TransportInternal" interface, we can extend our own transport layer. But this requires me to implement my own frame handling for web sockets. Instead, what I'm looking for is being able to integrate a third party java websocket implementation (say jetty) as the transport layer which takes care of all web-socket intricacies. Is there a way I can replace the transport layer to something else? [Reply by Robbie Gemmell] Questions should go on the users mailing list http://qpid.apache.org/discussion.html I assume you are talking about with the 'reactor' here as direct use of the protocol engine wouldn't care where the bytes were coming from / going to. It seems theoretically possible to replace the reactors IO layer, its 'global handler' (in IoHandler) which can be set, but it looks like you would have to redo so much of the related handling that you would be better just using the engine directly at that point (which is how proton-j sees most of its use) instead of using the reactor. You might want to look at https://github.com/Azure/azure-iot-sdk-java/tree/master/deps/src/main/java/com/microsoft/azure/sdk/iot/deps/ws, which is actually the reason the TransportInternal interface was added to begin with. It seems to have been published at http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22iot-deps%22 and prior to that at http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22websocket-transport-layer%22. Thanks Neeraj Makam
