｢なんちゃってAjax｣や｢どことなくJSON｣を卒業したくて、とりあえずDWRを試してみる。
このページを参考にというか、この通りやってみたんだけど、いつも通り動かず。
まずEclipseのサーバ環境自体が立ち上がらないし、自宅サーバに上げてみても実行中がtrueにならないまま。
web.xmlの記述で引っかかってるのまでは突き止めたんだけど、動作見ながら一行ずつ消したり足したりしていくとサーバが起動する状態まで記述を削るとDWRについての記述が無くなっちゃうw
結局、どうしようもなくなって本家のサイトのチュートリアル通り試してみようと思ってやってみたら、一発OK…
設定部分がちょっと違ってて、前者には｢WEB-INF/lib直下にdwr.jarを配置する｣としかないんだけど、本家ではその後｢同じくlib直下にCommons Loggingを配置する｣って手順があって、その通りリンク先のアパッチのページからバイナリzipファイルをダウンロードして解凍、その中の｢commons-logging-1.1.1.jar｣ってファイルだけをlibにコピーするとチュートリアル通り動く。ので、先に作ってた参考サイトのアプリでも同じことしたら動きました。
前者のサイトはDWR2.0の説明サイトだし、やっぱり英語サイトさけてたらだめだと実感した次第。プログラム言語学びたかったら英語必須ですな。まぁ、なんでcommons-loggingが必要なのかわかってないんですけどw たぶんDWRがログ解析して動作してるんじゃないかと予測。
12年9月8日(土)‡21時46分11秒 ‡
未分類
Java専用ドメインのほうのfaviconがデフォルトでTomcatアイコンになってるのに気づいて、メインのドメインのほうはどうなってるのかな？もしかしてApacheアイコン？って思って見てみたら空白になってたので作って入れました。で、気づいたこと。
1) 作業中にFireFoxのアップデートがきてたのでインストールしたらfaviconの表示の挙動が変わった。アップデート内容にも書いてあるけど、｢タブのページ名の頭にfavicon｣+｢URL表示部分の頭にfavicon｣だったのが｢タブのページ名の頭にfavicon｣だけになり、｢URL表示部分の頭にはサイト証明書状態アイコン｣に変わった。Chromeと同じになった。考えたらfaviconでサイト証明書の状態が隠されてたわけだからこの変更は当たり前か。まぁ、ほとんどのサイトは証明書なんてもってないしね。
2) ドメインのトップにfavicon置いたらそれ以下は全部同じアイコンが付くようになった。当たり前だけど便利。今さら過ぎるかw
ついでにTomcatドメインのエラー画面も標準のものと差し替えようかと思ったけどやめた。セキュリティ上問題があるって書いてる人が一杯いたんで代える予定だったんだけどやめました。以下理由。
1) 試しにメインのドメイン=サクラのレン鯖がどうなってるか見たら思いっきりApacheのバージョン出てるw
2) Tomcatの設定代えようとして元の状態を探してたら、managerとかのWEB-INFフォルダにきっちりエラーページデータが置いてあるのを発見。つまり各ページごとにエラーページデータ作らなきゃいけないってことらしい。
1) 見て、2)がわかって、Tomcatの生成するエラーページ見てたら、｢別にいいや｣って思ったw 触られたくないページ(階層)やポートはちゃんとふさいどけば良いんで、Tomcatのバージョンごとの脆弱性は｢バージョンを隠すこと」でふさげるとはとても思えないし。
まぁ、いつダウンしてもかまわない自宅サーバだからこその判断なんですけどね。サクラのレン鯖はどういう考えでApacheバージョン公開してるんだろう？
自宅サーバ立ててる時思ったこと。｢あっちこっちサイト見ながら使い慣れてないvimで細かくパラメータいじって、一つ一つセキュリティ設定しながら各アプリ(httpdとかsshとか)インストールしてるけど、centosのインストール時の選択画面から全部一発で入れちゃ何でいけないんだろう？｣
答えはデフォルトだと攻撃に弱いからだと思う(日本語対応って面もあると思う)。だけどデフォルトから変えちゃってるからメンテも手間がかかるし、不具合も再現性がない。ああいう簡単インストールみたいな画面が用意されてるってことは、デフォルトで色々入れて使うことが想定されてるんだと思うんだけど、個別にパラメータいじって改良？されちゃうとベンダー？では把握できなくなっちゃうよね。上に書いたエラーページの件で言うと、バーション表示が不味かったら、各自でエラーページ用意する、じゃなくてTomcatの仕様自体変わるべきだし(Apacheなら設定で隠せる)。
以上だらだら長くて説明不足の話だけど、気がついたことメモ。いちど全部デフォルトでドメイン立ててみよう。
20150502追記あり。
12年7月19日(木)‡00時00分48秒 ‡
未分類
servletは少しづつ勉強してってるんですけど、ちょっとappletをどんな風に配置するのか知りたくて、試しにapplet一個置いただけのページを作成してみる。大はまり。
1)appletの置き場所がわからない
Tomcat Webアプリケーションマネージャ最高！セキュリティの穴ふさぐのめんどくさいけど、その手間を補って余りある使いやすさw まぁ慣れたら使わなくなるらしいけどね。
で、warファイルはeclipseでそのままシームレスにエクスポートできるのが最高！ってやってるんだけど、appletの置き場がわからない。普通にclassとして新規作成するとWEB-INFディレクトリ配下に置かれてしまう。
試行錯誤したんだけどこれは結局まだわかってない。
2)WEB-INFディレクトリの仕様
これはservlet内部からしかアクセス出来ない。htmlなどからパス指定をしても一切見えないのです。色んなページ漁ってみたけどアクセス方法がない。でも探してるうちに、こういうふうにフォルダアクセスも仕組み自体で完全に制御してるところがTomcatの良い点だと理解できた。
3) 1)2)を踏まえての問題
結局WEB-INFより上=ページのルートはアクセスできるんだから、そこにフォルダ作ってapplet置いてhtml指定でアクセスするのが一番簡単な解決法。でもそれだとwarファイル展開→できた構造の中にapplet放り込む、って手順になってなんかエレガントじゃない。warファイル自体の(再)配備も上手く行かなくなるし。そこはマネージャ使って簡単にできる状態から後退するのは何かイヤ。
4)context.xml
関係ない。ページのルートから外れた場所に置いたフォルダ(ディレクトリ)を認識させるために設定するものなんだけど、いまいちよくわからなくて3時間くらい試行錯誤。でもよく考えたらhtml(=クライアントサイド)から認識できるようにすれば良いだけなんだから、context.xmlの設定は必要無い。おかげでTomcatのディレクトリ構造の勉強にはなったけど。
5)今のところ
webapps直下にフォルダ(openSauce w)作ってそこにぶちこんだ。ページからは階層上ればアクセスできる。appletとか画像とかのデータは隠す必要無いんだし、今後他のページ作った時もここなら同じ手順でアクセスできるし。
以上。何か間違ってるような気がしないでもないので書き残し。しかしjsp良いです。できたのはこのページなんですけど、appletをjsp:pluginタグで埋め込んだら勝手にObjectタグとembedタグに書き分けてくれる。先日の苦労は何だったんだw
追記)
jsp:pluginタグの代替コメント指定<jsp:fallback>タグだとnoembedタグでの表記に変換されちゃうな。objectタグの方に適用してくれないと認識されないんですけど。
12年7月18日(水)‡01時26分28秒 ‡
未分類