JBoss5.0のコアはおそらくMicroContainer2.0。
JBoss EJB3.0 Ｅｍｂｅｄｄableのコアも最終的にはMicroContainer2.0になるのでは？
#MicroContainer2.0がどんなモノか調べてみました。
MicroContainer2.0ではシンプルさは同じで主にDeployerまわりが実装されます。
デプロイメント仮想化フレームワークが用意され、各Deployerがこれを利用します。
JAR Deployer、Main Deploer、Classloading Deployerだけでなく他のDIコンテナを
プラグインするDIコンテナDeployerの実装も予定されています。Spring Deployerだけでなく
Seasar2 Deployerも実装されるかもしれません。
(JBoss4.x用にSpring Deployerがリリースされているので、それを見ればイメージし易いかも。)
これは他のDIコンテナで管理されているPOJOを容易にMicroContainerから利用できる
ようにするということだと思います。他のDIコンテナの管理するPOJOをそのままハイジャック
できるので"MicroContainer"にはシンプルな機能しかいらないと。
#力(勢い)のあるミドルウェア・ベンダはすごい...。
今まで単純なテキストファイルの読込にInputStreamReaderを使ってたけど、1.4からNewIOが
導入されていることだし、遅まきながらFileChannelを試してみる。
一括してバイト配列に読み込めるし、小規模ファイルの一括読込では問題なさそう。
あとはパフォーマンス、ファイルの一括読込で差はでる？
テキストファイルを一行ずつ処理したい場合はInputStreamReader -> BufferdReaderが簡単、
ファイル全体を読み込んでグリグリいじりたいような場合はFileChannel -> ByteBuffer、
というふうにIOと用途によって使いわける感じ。
#Channel APIはFileとSocketを同じAPIで透過的に扱えるのがミソなんだろうな、やっぱり。
#Socket周りには縁がないけど、そのうちいじってみよう。
A.InputStreamReaderでの読み込み
(BufferdReaderをかます必要は実はない...readLineメソッドでないのは改行コードがいるため)
StringBuffer sb = new StringBuffer();(1.5の場合、StringBuilder = new StringBuilder();)
//ファイルのオープン
FileInputStream fis = new FileInputStream(filePath);
InputStreamReader isr = new InputStreamReader(fis, encoding);
BufferedReader br = new BufferedReader(isr);
//読込及び格納
while ((s = br.read()) != -1) {
sb.append((char) s);
}
//ファイルのクローズ
br.close();
fis.close()
String str = sb.toString();
//ファイルのオープン
FileInputStream fis = new FileInputStream(filePath);
FileChannel channel = fis.getChannel();
ByteBuffer bbuf = ByteBuffer.allocate((int)channel.size());
//読込及び格納
channel.read(bbuf);
bbuf.clear();
byte[] bytes = new byte[bbuf.capacity()];
bbuf.get(bytes);
channel.close();
//ファイルのクローズ
fis.close();
String str = new String(bytes,encoding);
使ってみた感じ、StAXはSAXより柔軟性があり、SAX的な記述も可能。
SAXを齧ったことのある人なら、おそらく、すぐに習得可能。
SAXより癖がない気がするので、XMLパースの初学者にもStAXはおすすめ。
ハンドラを継承する等、煩雑な手順がいらないのも魅力。
サンプルはこちら(on off)。
JAX-WS(旧名JAX-RPC)も内部で全面的にStAXを使っているとのことなので
やっぱり時代はSAXよりStAXかも。
JAXB2、XFire、ActiveSOAP等最近のXML周りのフレームワークはStAXを採用する
のが多い。
現在、両者の処理速度に差はないように感じる。
Jakarta OROはPerl互換の正規表現書式を採用しているので、Ruby等のLLでもそのまま
通用する。Java標準正規表現APIとJakarta OROの採用する正規表現のサポート範囲に
ほとんど差はない。
但し、Jakarta OROは現在、メンテもされず放置中、安定しているからなのかは謎。
Java標準正規表現API はJava言語仕様の一部なのでメンテは期待できる。
#CometをJava標準正規表現API、 Jakarta OROを用いて開発している経験に基づく。
#正規表現は便利、文字列操作には必須。覚えておいて損はない。
#このブログの設定をいじっているときにこんな正規表現もありと気づいたりする。
メモメモφ。/* from Kohsuke Kawaguchi's Blog(on off) */
XMLStreamReaderでのバイナリデータの読込を可能にする等、StAXを小粋に拡張する
プロジェクト。Sunの人間が取り組んでいるので、StAXの次期仕様に反映されやすいかも。
メモメモφ。