TopLink EssentialsをTomcatで動かす その３

http://d.hatena.ne.jp/da-yoshi/20060717/1153151493の続きです。
前回作った構成の中で、ClassLoaderをTomcat依存で作るのではなくて、汎用的に作成してContextClassLoaderに登録する形に出来ないかと思って試してみたのですが・・・結果は失敗。どうやらTomcat側がJSP表示の際、ContextClassLoaderをURLClassLoaderにキャストし、そこからClasspathを取得してるみたいです。
・・・ということは、TomcatにセットするClassLoaderはURLClassLoaderの子クラスで、更にClasspath情報をURL配列で保持していなければならないということになり・・・結局コンテナ側のClassLoaderに依存しないと作成できそうにありません。親クラスローダがURLClassLoaderであると決めうちして作成することも可能ですが、その時点で既にTomcatに依存することになってしまいますし・・・だったらはじめからAPサーバに依存した形で作った方がスッキリする気がします。
うーむ・・・どうみても、ここら辺のAPIってAPIとして破綻してる気がする（苦笑）やっぱり、汎用性ではHibernateの方が数段上のようで・・・マッピング機能ではTopLinkの方が強力なんですけど。
一応N:1のLAZYロード対応が出来たとして、後TopLink Essentialsとしての機能で弱いのは、やはりSQL実行環境でしょうか。HibernateならgetDelegateでSessionを取得できるので、Hibernate独自のAPIが利用可能です・・・が、TopLinkの場合、getDelegateの中身は「return this;」となってます（苦笑）・・・
JPAのAPIしか使えないとなると・・・やはりXMLファイルを利用するしか無さそう。ここら辺の定義でも、TopLinkはどうやら引数のMapをあまり有効活用してくれてないみたいで・・・ただ、PersistenceUnitInfo.getMappingFileNamesが有効利用出来るかも？