JettyでロードしたXMLがロックされる問題

紆余曲折しましたが、
URLLoaderでロードしたXMLがロックされる現象について、
色々分かって来ました。

以前のブログでも書きましたが、
開発環境で、run-jetty-runのAddtional jetty.xmlに
単体Jettyのjetty.xmlを指定すると、URLLoaderでロードしたXMLがロックされる問題が発生してました。
その時は、Addtional jetty.xmlのjetty.xmlを拡張する分だけの記述にすることで、
開発環境(run-jetty-run)場では、ロックされる問題が解消されました。

しかし、単体Jettyで起動した場合に、やはりロックされる問題が発生してしまいました。
この事から、
単体Jettyの起動が、run-jetty-runと何かしら異なるのが原因
と推測し、アプリケーション(AIR)は、原因ではないと仮定して、原因調べたいと思います。

補足として、URLLoaderを使用した場合、
useCache=falseにすると、最初のロードでロックされます。
useCache=true(default)の場合、2回目のロードでロックされます。

run-jetty-runと単体jettyでは、起動オプションが違うと思うので、
単体Jettyのjetty.xmlを調べていきます。

まず、関係なさそうなのを外します。
start.iniに、
etc/jetty-testrealm.xml
が付いているので、コレを外してみます。→ダメ。2回目のロードで、ロックが発生します。
次、
etc/jetty-webapps.xml
これは外しても大丈夫。→ダメ。2回目のロードで、ロックが発生します。
次、
etc/jetty-deploy.xml
これは外せません。DeploymentManagerを作成する箇所だと思います。
次、
etc/jetty-contexts.xml
これらも外せません。ContextProviderを作成し、contextsからのロードを設定しています。

とやってた所で、
何気なく、webdefault.xmlを見てたら、
useFileMappedBuffer
なんてパラメータを発見。ググる。
http://wiki.eclipse.org/Jetty/Howto/Deal_with_Locked_Windows_Files
おーいえー。これだまさしく。
設定方法としては、
・デフォルトのJARの中身を変更するか
・自前のカスタムwebdefault.xmlを作って、コンテキストに設定する
・web.xmlに記述する
ぐらいのパターンがありそうです。
私は、web.xmlを選択しました。
web.xml

    <servlet>
		<servlet-name>default</servlet-name>
		<servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
		<init-param>
			<param-name>useFileMappedBuffer</param-name>
			<param-value>false</param-value>
		</init-param>
		<load-on-startup>0</load-on-startup>
   </servlet>

試してみる・・・。ロックしなーい。長かった・・・。
途中、
AIRのせいにしたり、
キャッシュのせいにしたり、
run-jetty-runのせいにしたり、
色々ありましたが、解決出来てなにより。
本番環境がLinuxで、この現象が出ないのもきつかったなー。
まぁ、こういう問題が解決出来た時が
エンジニアとしてやりがいを感じる部分ですね。

さて、あとは、BASIC認証戻して、SSLやろー。