Mark you are absolutely right if you only talk about future applications
with latest technologies and only specific use cases like chat applications.
However there are billions of people whose browsers/phones will not be
upgraded for years. Also a lot of existing applications and existing web
libraries are built around requests and sessions.
As a practical example, I have an existing smartphone app that works
with a tomcat webapp. Firing a HTTP request for each action is slow and
I would like to use websockets, however I am faced with following options:
1. develop different versions of my app, one for users who have latest
phones/browsers and another one for users who do not. This means double
the cost of developing and maintaining.
2. manually try to retrofit websockets to existing app/libraries so I do
not end up maintaining two versions. Most web libraries/frameworks
assume presence of request/session. Even in JEE servlet classes, many
methods take httprequest as an input parameter. So this is also not easy.
3. stay with http as that works across all existing browsers/phones.
i.e. do not use websockets.
Websockets will be lot more useful if both client and server sides can
seamlessly fallback to http when websockets are not available. This will
make it easy to upgrade existing apps, support all kinds of users
(including IE6), develop single app that works on android (android has
no websocket support) and iphone ... and so on
I hope I was able to communicate what I was trying to do.
On 6/5/2012 4:33 PM, Mark Thomas wrote:
On 05/06/2012 21:28, Ravi wrote:
Thanks for the details Chris. Unfortunately I am building a web app and
all my frameworks/utilities/existing code is around requests/sessions.
It would have been a blessing if I could simply change transport layer
from http to websockets and have the app work much better. But that does
not seem to be possible.
Back to thinking how to refactor the whole app so it works with http and
websockets :(
You will never be able to access the request since that completes as
part of the upgrade process. Sessions are potentially possible, but not
yet supported and as yet, I don't really see the point. I can see two
possible uses:
a) maintaining state - just add a map to your MessageInbound object
b) communication with the rest of the app - this feels like an abuse of
the session but I'm not sure what the right solution is. Suggestions
welcome.
Mark
On 6/5/2012 4:10 PM, Christian Finckler wrote:
Hello Ravi,
I do not use Requests or sessions.
Since I have the Message-Inbound object I can directly store in it for
example with private fields any session attributes I want.
I do it this way, that the message Inbound implements my
GameSessionParticipant-interface which has access to a gameSession
Manager which is created by the servlet.
I need my own session handling because not just everybody talks to
everybody. Instead the users form groups and these are handled by the
session manager.
Bye,
Chris
Am 05.06.2012 21:37, schrieb Ravi:
Because
1. This article says tomcat websockets were implemented as servlets so
that users have access to request and session parameters. So I am
trying to find out what the mechanism is. If it is not possible, maybe
the author of that article is confused.
http://www.tomcatexpert.com/blog/2012/05/01/how-apache-tomcat-implemented-websocket
2. Most webapps do need sessions for any useful functionality. I am
trying to find if something is built in so I do not try to do my own
session management and reinvent the wheel.
regards
On 6/5/2012 3:26 PM, Mark Thomas wrote:
On 05/06/2012 20:18, Ravi wrote:
Thanks a lot Chris. It took a lot of work for me to get websockets to
work. I wonder if you can help me little further. Here is my issue:
1. I need to get access to request and session. However when I get a
message in MyMessageInboundImpl class, I do not have access to
either of
them.
Why? Those are HTTP concepts and you are using WebSocket.
Mark
2. I tried to override doGet and save request/session, however after
saving request/session when I call super.doGet, I get "unauthorized
request".
How can I get access to request and/or session when a message arrives?
thanks
On 6/2/2012 3:32 AM, Christian Finckler wrote:
Hello,
I had the same problem some time ago.
I could get jwesocket to work either.
But I then used autobahn:
http://autobahn.ws/developers/autobahnandroid/installation
That worked great for me.
I couldn't find out if the different client libraries do something
wrong
or tomcat but I was a bit disapointet, too.
Perhaps that gets better when the draft is finished.
Btw. for normal java I use asynch http with netty.
Bye,
Chris
Am 02.06.2012 04:38, schrieb Ravi:
I am trying to build an android app that connects to tomcat web
sockets.
I need a few java classes that can interact with tomcat
websockets. I
have tried 3 different implementations
(strumsoft, jwebsockets and something else also) but neither one can
talk to tomcat correctly.
The issue seems to be protocol incompatibility between tomcat as
server and any existing java websockets client.
I even compiled jwebsockets swing based test client and that also
cannot talk to tomcat. Surprisingly all javascript based clients can
talk to tomcat, only java based cannot.
So having done all that research, I wonder if somebody can help me
identify java classes that will work with tomcat. Does tomcat have a
client jar I can use?
Help!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
