（補足） クラスローダ
1. クラスローダ 「クラスローダ」とは、クラスのロードやリソース（ファイル）の検索を担当するオブジェクトで、「java.lang.ClassLoader」を継承したクラスのインスタンスです。全てのクラスはクラスローダによってアプリケーションにロードされる事になっており、各クラスは自身をロードしたクラスローダへの参照を保持しています。そのクラスローダは「java.lang.Class」の「getClassLoader」メソッドで取得することができます。 クラスローダはツリー構造をしており、関連する親クラスローダを１つ所有しています。ツリー構造の大元に位置するクラスローダを「ブートストラップ・クラスローダ」と呼びます。これはJava仮想マシンに組み込まれており、Javaアプリケーションの起動時に、最初に読み込まれるものです。ブートストラップ・クラスローダはJava標準のライブラリや、Java
ClassLoaderを使って実行時にクラスを更新する方法（リロード処理）
JavaのClassLoaderの話をちょっとだけ。意外にClassLoaderを知らない人が居るようです。 ざっくりと説明をしますと、 クラスローダーにはBootstrapクラスローダーやシステムクラスローダー、コンテキストクラスローダーがあります。（あと拡張クラスローダーですかね）。そんでもって、クラスローダーは親子関係を持っています。委譲モデルと言って、あるクラスローダーにクラスをロードする依頼があると、親に依頼を委譲します。最初に発見されたクラスが実際にロードされるわけです。 1. Bootstrap (rt.jar) 2. 親クラスローダーA 3. 子クラスローダーB こんなクラスローダーがあるとしてまだロードされていないクラスXをロードしようとした場合は次のように動作します。 B.loadClass(X) Aに委譲 Bootstrapに委譲 BoostrapにXは存在しない A
Javassistメモ(Hishidama's Javassist Memo)
上で作ったconvert()には、クラス名を文字列で指定する必要がある。 しかしこれだと、複数のクラスを変更したい時はいちいち指定してやらないといけないので大変だし、間違った名前にしていても実行するまで分からないし、Eclipseの（クラス名変更の）リファクタリング機能の対象にもなってくれない。 （名前に関して）だからと言ってこういう工夫をすると… convert(Sample1.class.getName()); 実行時例外が発生する。 Exception in thread "main" javassist.CannotCompileException: by java.lang.LinkageError: loader (instance of sun/misc/Launcher$AppClassLoader): attempted duplicate class definitio
Seasar2のHotDeployの流れを追ってみた - SEの行き着くところ…
どうやって実現しているのかな、他に転用できないのかな、と以前から気になっていたので、好きな事ができる時間のある今、Eclipseのデバッグ機能を使いながら処理を追ってみた。なお、Seasar2は情報は(去年冬のSeasarConにも出たし)チェックしてたけど、実際に使ったのは初めて。 【追った処理】Sessionスコープでインスタンス管理したDTOを自前サーブレットから取得する。初めてのアクセスではなく、一度セッションに保持された状態でのアクセス。 【注意事項】・シーケンス図としての正しい書き方には全くなっていない。自分が一番理解しやすい形で書いた。・かなり端折って書いてる。分岐処理とかも抜かしてる。・Seasar2のバージョンは2.4.25。S2Tigerを組み合わせて使用。・ツールを使って出力すればよかったんやろうけど、完全手作業で作ったので細かな間違いはあると思う。 大きな流れは間違
HOT reloadingとClassLoaderを理解しよう - ひがやすを技術ブログ
JavaではClassはClassLoaderに読み込まれます。これはほとんどの人が知っていると思います。AOPを使うときのエンハンスされたクラスも同様にClassLoaderに読み込まれます。 これらの情報は、パーマネント領域に格納されますが、ClassLoaderがGCされると解放されます。 Seasar2のHOT reloadingでは、リクエストの度にClassLoaderを作って、そこにClassをロードし、そのClassLoaderは、リクエストが終わったら破棄しているので、Classの情報は、リクエストごとに破棄されています。 HOT relodingによって、パーマネント領域が使いつくされることはありません。 さらっと書きましたが、きちんとClassLoaderを破棄するのは、かなり大変です。リフレクションの情報がキャッシュされているとそれだけで破棄されなくなってしまうから
Java のクラスアンロード (Class Unloading)
作成日：2004.05.18 更新日：2005.06.21 今後、随時書き足して行きます。多分。 はじめに Java は動的にクラスのロードとアンロードが行われる仕組みになっている。 クラスはクラスファイルの形でディスク上やネットワークに配置され、プログラム中でそれらが本当に必要になった段階で JavaVM 上に読み込まれる。 またクラスはその使用が終わった段階でガーベージコレクターによって動的に回収され JavaVM からアンロードされる。 Servlet / J2EE サーバーなどはこの性質を利用して運用中にプログラムの一部を入れ替えるホットスワップ (Hot Swap) を実現している。 だがこの仕組みを実装するには少し工夫がいる。 この文書ではクラスのアンロードを実現するやり方について述べる。 1. クラスのロードとアンロードの基本的な仕組み クラスローダー Java VM がクラ
責任転嫁 | Tomcatのクラスローダ
Bootstrap | System | Common / \ Catalina Shared / \ Webapp1 Webapp2 ... Webappのクラスローダ以外は基本的な動作と同じ動きをする。 Webappのクラスローダはまずローカルのクラスを検索し、なかった場合、親のクラスローダに処理を委譲する。 ただし、以下のパッケージについては基本的な動作(親から検索)を行う。 java javax // Java extensions org.xml.sax // SAX 1 & 2 org.w3c.dom // DOM 1 & 2 org.apache.xerces // Xerces 1 & 2 org.apache.xalan // Xalan WebappClassLoaderを見ると、SystemClassLoaderに存在する場合はそっちが優先する模様(4.xのtomca
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「自作ClassLoader」（1） Java Solution － ＠IT
http://japan.internet.com/developer/20060808/27.html
トップページ
Java/ClassLoaderを自作 - ゆるゆるWiki
IBM Developer