2013年4月4日木曜日

jettyサーバーでwebsocket動作を組んでみました。

会社でやろうとおもったので、mavenとjettyについていろいろと学習しています。
でいろいろとハマりました。
今回はそのはまった話。

https://github.com/taktod/websocketJetty/commits/master

例によってgithubにあげています。
今回はmaven2をつかってつくっていますので、動作確認したければ、websocketJettyのディレクトリでmvn jetty:run
を実行してもらえればjettyサーバーが勝手に起動して、確認できるかと思います。

mvn経由でjettyを実行する場合、webアプリケーションのrootは/になります。
よって、昨日の時点では、web.xmlの記述で設定しているpathをsocket/にしてあります。

で、jettyのtarballをダウンロードしてきて展開した場合の動作ですが、
warファイルの名前がrootになります。
コンパイル時には、websocketという名前で実行しているので、rootがwebsocket/になります。
実験はしていませんが、元のプログラムのままだと、pathにsocketをいれてあるので
websocket/socket/でアクセスしないとservletのクラスにコネクトしないことになります。

ところが、web.xmlに設定した値でいけると思い込んでしまったため、socket/でずっとアクセステストをしていました。
で、うごかなかったというわけです。

さて、ハマっていた状態だったわけでそこから脱出できた理由について書いておきます。
jettyサーバー8.1.10を利用しているのですが、通常モードでつかっているとログがなにもでてきませんが、ログレベルをDEBUGに変更すると、詳細動作ログがでてきます。
普通にjettyを起動する場合は
$ java -jar start.jar
というコマンドになりますが、ログの詳細を出したい場合は
$ java -Dorg.eclipse.jetty.LEVEL=DEBUG -jar start.jar
という形で出すことができます。
この状態でログを出したところ


2013-04-04 21:29:37.650:DBUG:oeji.nio:created SCEP@5d295c59{l(/0:0:0:0:0:0:0:1:50573)<->r(/0:0:0:0:0:0:0:1:8080),d=false,open=true,ishut=false,oshut=false,rb=false,wb=false,w=true,i=0}-{AsyncHttpConnection@466e06d7,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-14,l=0,c=0},r=0}
2013-04-04 21:29:37.653:DBUG:oejh.HttpParser:filled 303/303
2013-04-04 21:29:37.659:DBUG:oejs.Server:REQUEST /socket/ on AsyncHttpConnection@466e06d7,g=HttpGenerator{s=0,h=-1,b=-1,c=-1},p=HttpParser{s=-5,l=22,c=0},r=1
2013-04-04 21:29:37.659:DBUG:oejsh.ContextHandler:scope null||/sockettt/ @ o.e.j.w.WebAppContext{/,null},/Users/todatakahiko/Downloads/jetty-distribution-8.1.10.v20130312/webapps/test.war

こんなログがでてきました。
追加しているwarファイルがwebsocket.warなのに、参照しているのがtest.warになっています。
このおかげで、見ているservletプログラムが自作したものと違う状態になっているというのに気づけました。

ちなみに、http://www.websocket.org/echo.htmlこちらのwebsocketのechoアクセステストのページで実行テストをするとエラーだった場合に以下のようなログがでてきます。

あーそれにしてもなんとかなってよかった・・・
mvn jetty:runのときとアクセスパスがかわるのは、musicTubeM4aのyoutubeのmp4のコンバートプロキシ書いたときにわかっていたのにハマるとは・・・

0 件のコメント:

コメントを投稿