Wicket 1.5ではSecondLevelCacheSessionStoreクラスが分解されている

はじめに

　SecondLevelCacheSessionStoreクラスといえば、「Wicketはページの履歴を保存しているのに、なぜメモリ使用量が現実的な範囲に収まるのか？」を調べていくと必ず遭遇するクラスだったわけですが、Wicket1.5では、このクラス名が見あたらず。
　私は内心相当慌てたのですが、単に内部構造が変わっただけで、同等の役割をするクラスは存在していました。

環境

• Wicket 1.5

どういった内部構造の変更が行われたのか

　どうやら、Wicket1.4までに存在したSecondLevelCacheSessionStoreは、IPageStore系とIDataStore系に分解されたようです。
　もうちょっと言うと、「メモリにストアしようが、ディスクにストアしようが、ストアすることには変わりないよね？」といった趣旨の元に再構成が行われたっぽいです(想像ですが)。

　以下にWicket1.5におけるクラス図を示します(クリックで拡大)。

データをストアする処理について、IPageStoreを実装するクラスが、IDataStoreを実装するクラスに委譲する構成です。

これを踏まえて

　解析の結果、「ディスクにページをシリアライズしたくない」と言う場合は、HttpSessionDataStoreを使えばよいことがわかりました。
　HttpSessionDataStoreを使いたければ、Application#init()内(正確には派生クラスにてオーバーライドしたメソッド)で、Application#setPageManagerProvider(final IPageManagerProvider)を使って、そういうIPageManagerProviderを設定してやればOKです。

　細かいことを言うと、Application#init()の前に、Application#internalInit()が呼び出され、そこで「setPageManagerProvider(new DefaultPageManagerProvider(this));」という文が実行されるので、内心気持ち悪いです。
(すなわち、結果的にDefaultPageManagerProviderのインスタンス生成が無駄になる)
　しかし、他にそれっぽい拡張ポイントは見あたらないので、前述した方法で良いはず。

さいごに

　AsynchronousDataStoreといういかにも「ページの返却が速くなりまっせ！」なオーラを出しているクラスがあるのですが、実験できておらず。
　誰か実験してくれないかなー。