著作一覧 |
1.1rcのまま突っ込んじゃおうかと一瞬考えたが、まあ、リリース版にしとけってことでやってみたら、いきなり、GenericDataSourceのClassNotFoundExceptionを喰らってActionServlet#initでこけてしまう。
<dataSource type="oracle.jdbc.bpool.忘れたCacheImpl">で、typeの上書きしてるし、DataSourceConfig.java見ても、Genericなやつは単なる文字列定数としてしか定義してないし、なぜ返るかはわからない(ことは本来ないんだが、調べる前にログを消しちゃったし、再現させるのは簡単だが、それほど閑でもない)。いちいちlegacyなんて名前のjarをWEB-INF/libに入れるのもイヤンな感じだし、面倒なんでlegacy.jarをshared/libに突っ込んでこの件は2週間ほど忘れることにする。
これなんか、名前付けの勝利だろうな。ClassLoaderってそのものズバリ過ぎて、多分、AppDomainと比べるとイメージが湧かないと思うのは、こっちの想像力の不足かも知れないが。
文章力があり、分析能力(自己に対しても)がある人間が、会社をやめた理由を書いて公開する。だから、本来、非常に個人的な視点からしか書かれないような内容が、強い普遍性を持つ。しかも、それを読むことができる。どう考えても世界は前進しているなぁ。
if (ds instanceof GenericDataSource) { ((GenericDataSource) ds).open(); }ここで指定していえるGenericDataSourceは、org.apache.struts.util.GenericDataSourceで、このクラス自体は、struts.jarに入っているので一見問題なさそうに見える。 が、しかし、
public class GenericDataSource extends org.apache.struts.legacy.GenericDataSource {お〜い、実装継承しているよ〜。 これじゃあ、何のため、legacyパッケージに切り分けたのか訳ワカメちゃん。 では、どうすれば良いか考えてみる。 やりたいことは、GenericDataSourceというクラスをlegacyとして、排除したいが、そのクラスを利用しても良いし、利用した場合には、GenericDataSource#openを呼び出す必要が(多分、そこまで調べない)あるということだ。 この場合は、
pakcage org.apache.struts.util; public interface GenericDataSource { public void open(); }として、legacyのほうで、
public class GenericDataSource implements org.apache.struts.util.GenericDataSource {とすればいいんじゃないか? これなら、実際にlegacy GenericDataSourceを使う必要がなければ、クラスローダの手をわずらわ必要もないし。 と、ここに書いてもしょうがないが、Googleしても話題になってないとこ見ると、こんなとこに引っかかるのは、僕だけなのかな。というわけで、特にBugtrackとかに報告しなかったりして。
ジェズイットを見習え |