Server: Play 1.2.4, WebSocket
Client: jQuery, Boostrap
Tested with: Safari 5.0.5 (on Win XP)
Inspired by a Blog-Post from Lucas Jellema I have done a similar demo with Play!.
The nice thing is that it was really easy to setup and deploy into the cloud. So everyone can test the websocket app - eeehm that was my initial plan (Actually it does not work currently, see why below). Further I took the chance to get in touch with git and published the source code on github. So feel free to test and fork.
Since there are some great cloud services arosed in the past I wanted to give it a try. So here are my experiences:
Prerequisite: install heroku CLI, git client (Please google for it how to set app. I only post the interesting stuff here)
C:\play\apps\play-push-imgsel>heroku login C:\play\apps\play-push-imgsel>heroku create -s cedar play-push-imgsel Creating play-push-imgsel... done, stack is cedar http://play-push-imgsel.herokuapp.com/ | firstname.lastname@example.org:play-push-imgsel.git Git remote heroku added C:\play\apps\play-push-imgsel>git push heroku master Counting objects: 46, done. Delta compression using up to 2 threads. Compressing objects: 100% (40/40), done. Writing objects: 100% (46/46), 110.54 KiB, done. Total 46 (delta 6), reused 0 (delta 0) -----> Heroku receiving push -----> Play! app detected -----> WARNING: Play! version not specified in dependencies.yml. Default version : 1.2.4 being used.... -----> Installing Play! 1.2.4..... -----> done -----> Installing ivysettings.xml..... done -----> Building Play! application... ~ _ _ ~ _ __ | | __ _ _ _| | ~ | '_ \| |/ _' | || |_| ~ | __/|_|\____|\__ (_) ~ |_| |__/ ~ ~ play! 1.2.4, http://www.playframework.org ~ 1.2.4 Building Play! application at directory ./ Resolving dependencies: .play/play dependencies ./ --forceCopy --silent - Duser.home=/tmp/build_jxh1de2j7wc9 2>&1 :: loading settings :: file = /tmp/build_jxh1de2j7wc9/.ivy2/ivysettings.x ml ~ Resolving dependencies using /tmp/build_jxh1de2j7wc9/conf/dependencies. yml, ~ ~ ~ No dependencies to install ~ ~ Done! ~ Precompiling: .play/play precompile ./ --silent 2>&1 Listening for transport dt_socket at address: 8000 10:26:55,430 INFO ~ Starting /tmp/build_jxh1de2j7wc9 10:26:56,387 INFO ~ Precompiling ... 10:27:03,224 INFO ~ Done. -----> No Procfile found. Will use the following default process: play run --http.port=$PORT $PLAY_OPTS -----> Discovering process types Procfile declares types -> (none) Default types for Play! -> web -----> Compiled slug size is 26.6MB -----> Launching... done, v5 http://play-push-imgsel.herokuapp.com deployed to Heroku To email@example.com:play-push-imgsel.git * [new branch] master -> master C:\play\apps\play-push-imgsel>heroku open Opening http://play-push-imgsel.herokuapp.com/ C:\play\apps\play-push-imgsel>
This is an awesome and easy to use stack!!!!! #PGH => Play, Git, Heroku!
Deployed at: http://play-push-imgsel.herokuapp.com/
Application is accessible but WS request are not working (oops).
C:\play\apps\play-push-imgsel>heroku logs ... ... 2012-01-14T10:36:29+00:00 heroku[router]: Error H12 (Request timeout) -> GET pla y-push-imgsel.herokuapp.com/ap... dyno=web.1 queue= wai t= service=30000ms status=503 bytes=0
=> Feature Request has been filed at Heroku. http://support.heroku.com/tickets/40910
Since WebSocket is currently not supported (according to: http://www.jamesward.com/2011/12/11/tutorial-play-framework-jpa-json-jquery-heroku) I decided to give cloudbees a try. Same here
Deployed at: http://play-push-imgsel.multikoop.cloudbees.net/
Same issues here:
... 20:27:42,952 WARN ~ 404 -> GET /application/pushimgsel/process (GET /application/pushimgsel/process) ...
=> Request #2383 "HTTP 404 on WebSocket Reque..." created. https://cloudbees.zendesk.com/tickets/2383
The cloud is not ready for WebSocket applications in early 2012! ;-)
If you want to see the demo live, all you need to do is
-Install Play 1.2.4
-Get push-imgsel Sourcecode: https://github.com/multikoop/play-push-imgsel
-Test with Safari (Other modern browsers currently not working, cause WebSocket Implementation in Play 1.2.4 cannot handle the newest Sec-WebSocket-Version Headers. Hopefully it will be fixed in 1.2.5 at least in 2.0.