JettyにSecurityを。DIGEST認証(続きの続き)

例のJavaがファイルを掴む問題、わかりました。

URLRequestDefaults全然悪くありませんでした。
そうですよね。
「URLRequestに個別にヘッダーを設定してみたら、結果変わりました」
と、ほざきましたが、結果同じでした。すいません。

原因は、run-jetty-runのデバッグの構成で、
「additional jetty.xml」の項目に単体Jettyのjetty.xmlを割り当てていたのが原因でした。
run-jetty-runとしては、この「additional jetty.xml」は、
プロジェクトの設定以外に追加したい設定があれば、使いなさいよという事なのでしょう。

前に
「Additional Jetty.xmlに設定すると、その上にあるプロジェクトの設定無視しますね」
と、ほざきましたが、無視するのではなく、上書きするイメージだと思います。
もともとrun-jetty-runでプロジェクトの設定があるにもかかわらず、
Additional Jetty.xmlで、割り当てたたjetty.xmlにcontextの設定が無いと、
そちらで上書きされるのだと思います。
さらに、Javaがファイルを掴む問題としては、
run-jetty-runでのコンテキストの設定
プラス
Additional Jetty.xmlでのコンテキストの設定
が重複した場合に発生するようです。

ですので、Additional Jetty.xmlには最低限デバッグに必要な設定、
今回の私のケースでは、LoginServiceの設定です。
これだけを別のxmlに定義して、Additional Jetty.xmlに設定するのがよさそうです。
同じ設定を単体Jettyのjetty.xmlにも設定しておく(本番環境用)

整理すると、
run-jetty-runのデバッグ設定は、
・プロジェクトは、デバッグするプロジェクト。
・ポートは、本番環境が80番で待つので、80。
・コンテキストは、本番環境のjetty.xmlに設定するコンテキスト。
・Additional Jetty.xmlには、LoginServiceのみの設定を抜き出したxml
・作業ディレクトリは、単体Jettyのパス

これで正常に動きました。
コンテキストの設定は、色々回り道してしまいましたが、
単一のアプリケーションなら、jetty.xmlに設定するほうが、シンプルに済みます。
複数のアプリケーションが必要ならば、contextsにそれぞれ設定するしかないと思います。

一つ、イヤなのは、このAdditional Jetty.xmlに設定した内容を
本番環境では、jetty.xmlに含む必要があり、
同一の記述を2ヶ所にしてるので、開発環境では動くけど、本番環境で動かねーみたいな事にならないように
注意する必要がありますね。
たぶん、起動オプションで、そのxmlを読み込むみたいなオプションがあったと思うので、
一箇所で済むように出来るとは思うのですが。

ひとまずこれで、認証はオシマイ。
DIGEST認証で行く予定でしたが、SSLも設定するので、
ポピュラーな、SSL＋BASICで今後進めて行きたいと思ってます。

追記)
罠がまってました。
解決はこちらhttp://d.hatena.ne.jp/nosa1/20120214/1329182933