since2OO7 j2ee

パッケージング

□J2EEパッケージング
J2EE仕様に準拠した
「どんなアプリケーション・サーバでも通用するポータブルEAR」
を作成すること。

□J2EEパッケージング 3大原則
ルール①
　EARは、独立・自己完結させること。
　※EAR以外のライブラリ参照や要APサーバ特有のクラスパス修正はご法度。
　※[他のシステムのリモートメソッドを呼び出す]系の依存関係の残留はOK。

ルール②
　クラスローダ・デリゲーションモードは、APクラスローダと各WARクラスローダ、
　共に[PARENT_LAT]にすること。

ルール③
　クラスローダ・ポリシー(アイソレーション・モード)はデフォルトのままにすること。
　※[単数(シングル)][アプリケーション]等に変更しないこと。
　※アイソレーション・モードは、
　　パッケージングが出来ていないEARへの一時的な救済策に使うもの。
　※デフォルト設定
　　アプリケーションごとにアプリケーション・クラスローダが１つで、
　　さらに下位クラスローダとして、WAR毎の専用WARクラスローダが１つずつ割り当てられる。
　　

□パッケージング策①/重複戦略
ターゲットアプリ：
　WebアプリとしてWARが3つ、EJBモジュールとしてejb-jarが2つ、さらに複数のライブラリを使用。
　各Webアプリは、さらにStrutsを使用。

―例①―
luv-app.ear
　|― META-INF/application.xml
　|― ejb1.jar
　|― ejb2.jar
　|― utility.jar
　|― commons-xxx.jar
　|― luv1.war
　|　　|― WEB-INF/lib
　|　　　　|- utility.jar
　|　　　　|- commons-xxx.jar
　|　　　　|- struts.jar
　|― luv2.war
　|　　|― WEB-INF/lib
　|　　　　|- utility.jar
　|　　　　|- commons-xxx.jar
　|　　　　|- struts.jar
　|― luv3.war
　|　　|― WEB-INF/lib
　|　　　　|- commons-xxx.jar
　|　　　　|- struts.jar
　|　　　　|- web-util.jar
―/例①―

目標：自己完結したEAR。
使用するライブラリのうち、J2SE/EEに含まれていないものは、
全てEAR内にパッケージング。
EAR・WAR配下にそれぞれが使用するライブラリを配置。

J2EEコンテナは、EAR内に配置した各モジュールやライブラリをどうやって認識してるのか？
・WARやejb-jar系のJ2EEモジュール
　　→EARのDD(DeploymentDescriptor:配置記述子)である[META-INF/application.xml]内に明記されてる。
・各WAR内の[WEB-INF/lib]以下のライブラリ
　　→コンテナの担当、ってゆう仕様。
・EAR直下のJ2EEモジュールでないライブラリ
　　→ただ置くだけでは、認識されない！！

上記のパッケージ構成のEARをアプリケーション・サーバにデプロイすると
各クラスローダの担当モジュールは以下の通り。

―例①：デプロイ後―
luv-app.ear
　|
　|―ejb1.jar / Application ClassLoader
　|―ejb2.jar / Application ClassLoader
　|―commons-xxx.jar
　|―utility.jar
　|
　|―luv1.war / WAR ClassLoader
　|　　|
　|　　|―utility.jar
　|　　|―commons-xxx.jar
　|　　|―struts.jar
　|
　|―luv2.war / WAR ClassLoader
　|　　|
　|　　|―utility.jar
　|　　|―commons-xxx.jar
　|　　|―struts.jar
―/例①：デプロイ後―
EJBモジュールはutility.jar等に依存する。
しかし、
utility.jarは、EJBモジュールのクラス検索対象外の
下位クラスローダ(WARクラスローダ)にロードされているため
EJBモジュールには、utility.jarを見つけられない。
結果、正常に動作しない。

□パッケージング策①/重複戦略/Bundled Optional Package
Bundled Optional Package:
　EAR内に同梱され、J2EEモジュールから使用されるライブラリ

使用する依存ライブラリーをJ2EEコンテナに教える必要がある。
→マニフェストファイルのClass-Pathエントリに必要なライブラリを定義する
　※Class-Pathエントリに記述するパスは、EARのトップからの相対位置で指定すること。

例
ejb1.jar(EJBモジュール)が、utility.jar等に依存している場合
↓
EJBモジュール内部のマニフェスト･ファイル[META-INFO/MANIFEST.MF]に使用するライブラリを宣言する
―例：ejb1.jar内のMETA-INF/MANIFEST.MF―
Manifest-Version: 1.0
Class-Path:
utility.jar
commons-xxx.jar
commons-yyy.jar
commons-zzz.jar
―/例：ejb1.jar内のMETA-INF/MANIFEST.MF―
J2EEコンテナは、J2EEモジュールである、WARとejb-jar内のマニフェストファイルをチェック。
Class-Pathエントリがあった場合、
そこに宣言されているライブラリをアプリケーション･クラスローダ配下に配置する。
※EARトップ直下に依存ライブラリがある場合、
　Class-Pathエントリには、Jarファイル名のみで指定。

※依存ライブラリの発見の仕組みは連鎖する。
　依存先ライブラリ内のマニフェストファイルに更にClass-Pathエントリがあった場合、
　依存先ライブラリの依存先ライブラリをも、アプリケーションクラスローダ下に同様に配置する。
　

□パッケージング策②

ref:
http://www-06.ibm.com/jp/software/websphere/developer/j2ee/strategy/3.html

クラスローダ/ デリゲーション・モード

■デリゲーション・モード
WARクラスローダそのものを単純標準出力した結果
--------------------
com.ibm.ws.classloader.CompoundClassLoader@1f7010c3
　Local ClassPath: ...(略)...installedAppslemonNode02Cell
　　　　　　　　　　　　　　 luv-app.earluv.warWEB-INFclasses;
　　　　　　　　　 ...(略)...installedAppslemonNode02Cell
　　　　　　　　　　　　　　 luv-app.earluv.war;
　Delegation Mode: PARENT_FIRST
--------------------
該当クラスローダに関する情報が出力されるように、
クラスローダのtoString()がオーバーライドされている。
これで、該当クラスローダのローカルクラスパス(LocalClassPath)が分かる。

[Delegation Mode: PARENT_FIRST]ゆう出力結果は、
クラスローダのデリゲーション・モード(Delegation Mode)が、PARENT_FIRSTであることを示す。

デリゲーション・モードの設定によって、デリゲーションモデルが決まる。
選択できるモードは２つ。
・PARENT_FIRST
・PARENT_LAST

Java基本クラスローダ/ブーストトラップクラスローダ
　(loads /lib/*.jar)
｜
｜―Java基本クラスローダ/エクステンションクラスローダ
　　　(loads /lib/ext/*.jar)
｜
｜―Java基本クラスローダ/システムクラスローダ
　　　(loads CLASSPATH)
　　｜
　　｜―WebSphere/EXTクラスローダ
　　　　　(loads /lib/*.jar)
　　　　｜
　　　　｜―banking.ear/アプリケーションクラスローダ
　　　　　　　(loads banking-ejb.jar, utility.jar)
　　　　｜　｜
　　　　｜　｜―customer.war/WARクラスローダ
　　　　｜　｜
　　　　｜　｜―admin.war/WARクラスローダ
　　　　｜
　　　　｜―trading.ear/アプリケーションクラスローダ
　　　　　　　(loads trading-ejb.jar, utility.jar)
　　　　　　｜
　　　　　　｜―company.war/WARクラスローダ

上記のうち、アプリケーション・クラスローダとWARクラスローダについては、
デリゲーション・モードをカスタマイズできる。

■PARENT_FIRST（デフォルト）
　自クラスローダのローカルクラスパスを探す前に、最初に親クラスローダにデリゲートする。
　親で見つからなかった時に初めて、自分のローカル・クラスパスを探しにく。

■PARENT_LAST
　自クラスローダのローカル・クラスパスを最初に探す。
　見つからなかった時に初めて、親クラスローダにデリゲートする。

■探索順序
デリゲーション・モードの設定次第で、クラスを探す順序が変わる。

ローカル・クラスパス	デリゲーション・モード設定
ローカル・クラスパス	（A） APP-FIRST WAR-FIRST	（B） APP-LAST WAR-FIRST	（C） APP-FIRST WAR-LAST	（D） APP-LAST WAR-LAST
Java基本クラスローダー	1	2	2	3
WebSphere Ext クラスローダー	2	3	3	4
アプリケーションクラスローダー	3	1	4	2
WARクラスローダー	4	4	1	1

※WebSphereApplicationServerの管理コンソール上では、
デリゲーション・モードをクラス・ローダ・モード(Class loader mode)と表記している。

■ケーススタディ
PARENT_LASTはいつ役立つのか？

某月某日
Ａ：jakartaプロジェクトのライブラリのhoge-1.2.jar使うてんねんけど
　　どうも挙動がおかしいねん。
Ｂ：ちゃんとWEB-INF/libに置いとうと？
Ａ：置いとうよ。クラスを見には行ってるようなんやけど…。
　　観てみたら、WebSphereのインストールしたディレクト(WAS_HOME)下の
　　libディレクトリ内にhoge-1.1.jarがあったわ。
　　自分らのAP内に置いたWEB-INF/lib/hoge-1.2.jarやのうて、
　　WAS_HOMEのを先に使うてるようやわ。
Ｂ：あかんやん！WebSphereでhoge-1.2.jarは使えんゆうこと？
Ａ：WAS_HOME/lib/hoge-1.1.jarをhoge-1.2.jarで置き換えちゃばええちゃうん？
Ｂ：いいね。やってみて～
Ａ：あかん。WebSphere自体が立ち上がらんくなってもうた…。

解説
Ａがやるべきやったんは、jarの置き換えやのうて、デリゲーション・モードをPARENT_LASTにすること！
デリゲーション・モードを変更することで、
WebSphereそのものに影響を全く与えずに、
自分のWebアプリケーション内に含まれるライブラリが先に優先されるようになる。

→クラスローダが複数ある利点。

■PARENT_LASTの必要性
WebSphere Application Serverの内部ライブラリに影響されることなく
アプリケーションに最新のライブラリを用いたい場合に[PARENT_LAST]が有効

サーブレットの仕様でも
It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs.
(アプリケーションのクラスをロードするクラスローダーは、アプリケーション・サーバー、Webコンテナ全体で使用するライブラリー内よりも、WAR内部のクラスやリソースを優先してロードすることが推奨される。)
ref: 2.4 Specification SRV.9.7.2

なぜだか
websphereは、PARENT_FIRSTがデフォルトだけど..

注：Java基本クラスローダーが担当するコアクラス（java.lang.*など）に関しては、
　　Javaのセキュリティー・モデルで禁止されているため、
　　たとえ「PARENT LAST」にしても、「上書き」はできない。

□ちなみに WebコンテナTomcat
Tomcatのクラスローダ・ツリー
　Bootstrap
　｜
　｜―System
　　　｜
　　　｜―Common
　　　　　｜
　　　　　｜―Catalina
　　　　　｜
　　　　　｜―Shared
　　　　　　　｜
　　　　　　　｜―Webapp1
　　　　　　　｜
　　　　　　　｜―Webapp2

ref: The Apache Jakarta Tomcat 5.5 Servlet/JSP Container Class Loader HOW-TO

Tomcatの場合、EARがなく、Webアプリケーション(WAR)だけなので若干違いがあるが、
tomcat#common、share配下よりも各webapps内のクラス・リソースが優先される
とドキュメントに明記されている。
つまり、PARENT_LASTの設定。

■シングルトンがシングルトンでなくなる日
PARENT_LASTとすべきだが、
通常のJavaのクラスローダのデリゲーション・モードは、PARENT_FIRST。

―typical singleton pattern class―
package com.example;
public class Singleton {
　　
　　private static Singleton instance = new Singleton();
　　private int counter;
　　private Singleton() {}
　　
　　public static Singleton getInstance() {
　　　　return instance;
　　}
　　
　　public void increment(int i) {
　　　　counter += i;
　　}
　　
　　public int getCounter() {
　　　　return counter;
　　}

}
―/typical singleton pattern class―

１つしかインスタンス生成されない、
というシングルトンクラスのルールでも
以下ルールで破られる。

―クラスの同一性に関するルール―
全く同じパッケージ名・同じクラスでも、
異なるクラスローダからロードされたものは、
同一クラスとして扱われずに、別クラス扱いとなる。
―/クラスの同一性に関するルール―

□実験

―EAR構成―
luv-app.ear
　|― luv-ejb.jar
　| 　　|― com.example.Singleton
　| 　　|― com.example.ejb.InEJB
　|― luv.war
　　　　|― WEB-INF/
　　　　　　　|― classes/
　　　　　　　|― com.example.Singleton
　　　　　　　|― com.example.web.ClassLoaderTestServlet
―/EAR構成―

Singletonクラスを、EJBモジュールとWebモジュールの双方に配置。
アプリケーション・クラスローダとWARクラスローダ
両方のデリゲーション・モードをPARENT_LASTに設定。

―test classes―
package com.example.web;

import com.example.Singleton;
import com.example.ejb.InEJB;
...
public class ClassLoaderTestServlet extends HttpServlet {

　　protected void service(HttpServletRequest req,
　　HttpServletResponse res)
　　　　　　throws ServletException, IOException {
　　　　testSingleton();
　　}

　　private void testSingleton() {
　　　　Singleton singleton = Singleton.getInstance();

　　　　System.out.println("1. InWeb - counter: "
　　　　　　　　　　　　 + singleton.getCounter());
　　　　System.out.println("counter: +1");
　　　　singleton.increment(1);
　　　　System.out.println("2. InWeb - counter: "
　　　　　　　　　　　　 + singleton.getCounter());　　　　
　　　　InEJB.testSingleton();
　　　　System.out.println("5. InWeb - counter: "
　　　　　　　　　　　　 + singleton.getCounter());
　　　　
　　}
}

package com.example.ejb;

import com.example.Singleton
...

public class InEJB {

　　public static void testSingleton() {
　　　　Singleton singleton = Singleton.getInstance();

　　　　System.out.println("3. InEJB - counter: "
　　　　　　　　　　　　 + singleton.getCounter());
　　　　System.out.println("counter: +10");
　　　　singleton.increment(10);
　　　　System.out.println("4. InEJB - counter: "
　　　　　　　　　　　　 + singleton.getCounter());
　　}
　　
　　public static Singleton getSingleton() {
　　　　return Singleton.getInstance();
　　}
}
―/test classes―

Webモジュール内のサーブレットClassLoaderTestServletと、
EJBモジュール内のクラスInEJBの両方から
同一のシングルトン・クラスcom.sample.Singletonを使用。

Singletonクラスが１インスタンスしか生成されていない場合、
実行の結果、最後に出力される[counter]は[11]のはず。

―１インスタンスしか生成されていない場合の実行結果―
1. InWeb - counter: 0
counter: +1
2. InWeb - counter: 1
3. InEJB - counter: 1
counter: +10
4. InEJB - counter: 11
5. InWeb - counter: 11
―１インスタンスしか生成されていない場合の実行結果―

が、実際はPARENT_LASTモードでシングルトンでなくなってる。

―実際の実行結果―
1. InWeb - counter: 0
counter: +1
2. InWeb - counter: 1
3. InEJB - counter: 0
counter: +10
4. InEJB - counter: 10
5. InWeb - counter: 1
―/実際の実行結果―

Webモジュール内のサーブレット、EJBモジュール内のInEJBは
それぞれ異なるシングルトンのインスタンスを参照している。

PARENT_LASTモードとなっているため、
サーブレット(@子クラスローダ)は、
WARクラスローダ(子)内にロードされたシングルトンクラスを先に見つける。
一方、
InEJBクラスは、EJBモジュール(親)内にロードされたシングルトンクラスを最初に見つける。

結果、別々のSingletonクラスを参照。
当然、static変数インスタンスもそれぞれのクラスに存在。
→シングルトンのインスタンスが２つ！

PARENT_FIRSTに設定した場合、
シングルトンインスタンスは１つしか生成されず、
JVM全体でシングルトンの役割を果たす。

１つのJVM内で、クラスを識別するキーとなるのは
[パッケージ名＋クラス名]ではなく、
[パッケージ名＋クラス名＋ロードしたクラスローダ]が識別キーとなる。

http://www-06.ibm.com/jp/software/websphere/developer/j2ee/strategy/2.html

クラスローダ/ デリゲーション・モデル

■クラスローダ
クラスをロードするもの
クラスは使用される前に必ずクラスローダによってJVM（Java Virtual Machine）のメモリ空間上にロードされる。

public class SimpleTest {
public static void main(String[] args) {

SimpleTest test = new SimpleTest();//①
ClassLoader loader = test.getClass().getClassLoader();
syso("SimpleTest.class is loaded by " + loader);
syso("java/lang/String.class is found at " + loader.getResource("java/lang/String.class"));//②

}
}

①クラスローダの取得
　クラスローダはプログラム中からでも取得可能。
　上記は、java.lang.Class#getClassLoaderで取得。
　syso結果は、
　SimpleTest.class is loaded by sun.misc.Launcher$AppClassLoader@3c6d53c4

②クラスローダでリソース検索
　ClassLoader#getResource(String)は、＊.properties等の読み込みでよう利用されるが、＊.classだっけよ見込み可能。
　※getResource(String)は、リソース検索のメソッド
　　引数は、"java.lang.String"ではなく、"java/land/String.class"とすること。
　syso結果は、
　java/lang/String.class is found at jar:file:C:/opt/rad/runtimes/base_v6/java/jre/lib/core.jar!/java/lang/String.class

実際にクラスがファイルシステム上の何処からロードされたを知るのにもクラスローダは有効。

■クラスローダヒエラルキー
１つのJVM内に複数のクラスローダが普通。
J2EEアプリケーション･サーバの世界も同じ。

□WebSphereApplicationServer内のクラスローダ構成
Java基本クラスローダ/ブーストトラップクラスローダ
　(loads /lib/*.jar)
｜
｜―Java基本クラスローダ/エクステンションクラスローダ
　　　(loads /lib/ext/*.jar)
｜
｜―Java基本クラスローダ/システムクラスローダ
　　　(loads CLASSPATH)
　　｜
　　｜―WebSphere/EXTクラスローダ
　　　　　(loads /lib/*.jar)
　　　　｜
　　　　｜―banking.ear/アプリケーションクラスローダ
　　　　　　　(loads banking-ejb.jar, utility.jar)
　　　　｜　｜
　　　　｜　｜―customer.war/WARクラスローダ
　　　　｜　｜
　　　　｜　｜―admin.war/WARクラスローダ
　　　　｜
　　　　｜―trading.ear/アプリケーションクラスローダ
　　　　　　　(loads trading-ejb.jar, utility.jar)
　　　　　　｜
　　　　　　｜―company.war/WARクラスローダ

―ブーストトラップクラスローダ
　一番の親。
　JavaのコアAPIに関するクラス(java.lang.*等)をロード。

―エクステンションクラスローダ
　ブーストトラップクラスローダの子供。
　エクステンション･ディレクトリ(/lib/ext/*.jar)内のクラスをロード。

―EXTクラスローダ
　エクステンションクラスローダの子供。
　WebSphereApplicationServer特有のクラスローダ。
　WebSphereApplicationServer本体のクラスをロード。
　/lib/*.jar等がロード対象。

―アプリケーションクラスローダ
　EXTクラスローダの子供。
　アプリケーション･サーバにインストールされたエンタープライズ･アプリケーション(EAR)ごとに１つずつ専用に割り振られるクラスローダ。
　各EAR内に含まれるejb-jarやユーティリティ-jar内のクラスがロード対象。

―WARクラスローダ
　アプリケーションに含まれるWARモジュール（＝Webアプリケーション）毎に１つずつ割り当てられる。
　各WARモジュール内のWEB-INF/classes以下やWEB-INF/lib/*.jar内のクラスがロード対象。

■クラスローダ･デリゲーション･モデル
　クラスローダは、必要に応じて、自分自身でロードせずに、親クラスローダにクラスのロードを委譲(デリゲート)する。
　例えば、
　システム･クラスローダがあるクラスをロードする必要があったとする。
　この時、
　システム･クラスローダは、自分のローカルクラスパス内、すなわち環境変数CLASSPATH内を探す前に、最初に親であるエクステンション･クラスローダにクラスをロードを依頼する。
　同じように、
　エクステンション･クラスローダも、まず親であるブート･ストラップ･クラスローダにクラスのロードをデリゲートする。
　親クラスローダで見つかった場合は、そこで終了。
　親クラスローダで見つからなかった場合になって、初めて子供は自分のローカルクラスパス内を探しにいき、クラスをロードしようとする。
　
　※注：デリゲートモデルは、子供が親に依頼しても、親が子供に依頼することはない。

■クラスとクラスローダの関係に関するルール

□ルール① クラスロードの際、使用されるクラスローダの決定方法
　クラスAの内部でクラスBを使用するケース。
　クラスAをロードしたクラスローダ[CL-A]が起点となり、クラスBをロードする。
　この時、デリゲーションモデルで、CL-Aの親クラスローダにはデリゲーションするが、
　CL-Aの子供にはデリゲーションしない。
　
　------------------------------
　package com.example.web;
　public class InWeb {//子階層のクラス
　}
　------------------------------
　package com.example.ejb;
　...
　public class InEJB {//親階層のクラス
　　private InWeb inWeb = new InWeb();//子階層のクラスの呼び出し
　}
　------------------------------
　package com.example.web;
　...（略）...
　import com.example.ejb.InEJB;
　
　public class ClassLoaderTestServlet extends HttpServlet {
　
　 protected void service(HttpServletRequest req, HttpServletResponse res)
　　　throws ServletException, IOException {
　
　　System.out.println("inWeb : " + new InWeb()); // (1)
　　System.out.println("inEJB : " + new InEJB()); // (2)
　　}
　}
　------------------------------
　を実行すると
　------------------------------
　inWeb: com.example.web.InWeb@3e25a5
　サーブレット ClassLoaderTestServlet で service() メソッドを呼び出せませんでした。
　スローされた例外: java.lang.NoClassDefFoundError: com/example/web/InWeb
　　　　　　　　　　　　 at com.example.ejb.InEJB.(InEJB.java:10)
　　　　　　　　　　　　 at com.example.web.ClassLoaderTestServlet.service(ClassLoaderTestServlet.java:20)
　　　　　　　　　　　　 ...（略）
　------------------------------
　ClassLoaderTestServletの(2)で落ちている。
　クラスInWebは見れてるが、クラスInEjbは見れてない。
　
　クラスClassLoaderTestServletがクラスInWebを使用するときは、
　クラスClassLoaderTestServletをロードしたクラスローダ、
　すなわちWARクラスローダ(子クラスローダ)が、クラスInWebを探しに行く。
　問題なし。
　
　クラスClassLoaderTestServletがクラスInEjbを使用するときは、
　クラスClassLoaderTestServletをロードしたクラスローダ、
　すなわちWARクラスローダが、クラスInEjbを探しに行く。
　が、実際は、
　デリゲーションモデルで、クラスInEjbをロードするのは
　アプリケーションのクラスローダ(親クラスローダ)。
　※起点クラスローダがWARクラスローダ(子)からAPクラスローダ(親)に変わっている。
　問題なし。
　
　さて、InEjbの中身。
　クラスInEjbがクラスInWebを使用する時は、クラスInEjbをロードした
　クラスローダ(起点クラスローダ)、すなわちアプリケーションのクラスローダ(親)が、
　クラスInWeb(子階層のクラス)を探しに行く。
　が、
　クラスInWebはWARクラスローダ(子)にいるので、親のアプリケーションクラスローダは
　見つけられずに、NoClassDefFoundErrorとなってまう。
　
　あるクラスが、下位クラスローダ配下しか存在しないクラスに依存している構成がＮＧ！
　

ref:
http://www-06.ibm.com/jp/software/websphere/developer/j2ee/strategy/1.html

Velocity

■Velocity
Javaベースのテンプレートエンジン
Web ページや SQL、PostScript といった出力をテンプレートから生成
Javaコードで定義されたメソッドが参照可
JSP、PHPの代替的もの

■VTL
Velocity テンプレート言語(VTL:Velocity Template Language)

□VTL識別子
[英字]から始め [英数字,ハイフン,アンダースコア]で続けること

□VTL指示子認識子[#]
指示子は[#]で始めること

□変数認識子[$]
変数は[$]で始めること

□値識別子[引用符]
値は["]["]で囲むこと

□コメント識別子
・1行コメント
[##]で開始
行末で終了
・複数行コメント
[#*]で開始
[*#]で終了

■[VTL]レファレンス
3種類
・変数
・プロパティ
・メソッド
リファレンスを出入りするものは全て文字列オブジェクト
文字列オブジェクトでない物は toStringで影で強制変換

□変数
正式表記：[$]＋[{]＋VTL識別子＋[}]
簡略表記：[$]＋VTL識別子
値は [set]識別子かjavaコードから取得

□プロパティ
正式表記：[$]＋[{]＋VTL識別子＋ドット[.]＋他のVTL識別子＋[}]
簡略表記：[$]＋VTL識別子＋ドット[.]＋他のVTL識別子
--------------------
$customer.Address
--------------------
customerで識別されるhashtableを見てキーAddressと関連づけられる値
か
$customer.Address()
を得る

□メソッド
正式表記：[$]＋[{]＋VTL 識別子＋VTLメソッドボディ＋[}]
簡略表記：[$]＋VTL 識別子＋VTLメソッドボディ
＊VTLメソッドボディ
表記：VTL 識別子＋左括弧[(]＋パラメータ/パラメータリスト(オプション)＋右括弧[)]
--------------------
$purchase.getTotal()
$page.setTitle( "My Home Page" )
$!person.setAttributes( ["Strange", "Weird", "Excited"] )
--------------------

□エスケープ
VTL特殊文字はバックスラッシュ[\]でエスケープ
--------------------
#set( $hoge = "piyo" )
1.$hoge
2.\$hoge
3.\\$hoge
4.\\\$hoge
1.$hogehoge ##未定義変数
2.\$hogehoge
3.\\$hogehoge
4.\\\$hogehoge
--------------------
1.piyo
2.$hoge
3.\piyo
4.\$hoge
5.$hogehoge
6.\$hogehoge
7.\\$hogehoge
8.\\\$hogehoge

□大小文字置換
Velocityは Javaのイントロスペクション機能とBean機能を利用して
コンテキスト内のオブジェクトとオブジェクトメソッドの両方のリファレンス名を解決できる。
--------------------
$foo.getBar()
same as
$foo.bar

$data.getUser("jon")
same as
$data.user("jon")

$data.getRequest().getServerName()
same as
$data.Request.ServerName
same as
${data.Request.ServerName}
--------------------

□沈黙リファレンス
Velocity が未定義のリファレンスに遭遇したとき、
通常の挙動として、リファレンスの記述をそのまま出力する。
--------------------
$hoge ##未定義の場合 [hoge]と出力される
$!hoge ##未定義の場合 [](ブランク)と出力される
$!{hoge} ##未定義の場合 [](ブランク)と出力される
--------------------

■[VTL]指示子
スクリプト要素

□[set]指示子
リファレンスの値を設定
書式：#set( $ref = [ ", ' ]arg[ ", ' ] )
#set 指示子は、リファレンスの値をセットする。
値は、変数リファレンスかプロパティリファレンスにセットされる。

[[変数が左側で値が右側で[=]が区切]]
左辺(LHS:LeftHandSide)：変数リファレンス/プロパティリファレンス
右辺(RHS:RightHandSide)：変数リファレンス/文字列リテラル/プロパティリファレンス/メソッドリファレンス/数値リテラル/配列リスト(ArrayList)
--------------------
#set( $monkey = $bill ) ## 変数リファレンス
#set( $monkey.Friend = "monica" ) ## 文字列リテラル
#set( $monkey.Blame = $whitehouse.Leak ) ## プロパティリファレンス
#set( $monkey.Plan = $spindoctor.weave($web) ) ## メソッドリファレンス
#set( $monkey.Number = 123 ) ## 数値リテラル
#set( $monkey.Say = ["Not", $my, "fault"] ) ## 配列リスト

$monkey.Say.get(0) ## ＝[Not]
--------------------

※右辺がnullとして評価された場合　 null値は左辺に代入されない。
※[set]指示子には #end 文はない。

□文字列リテラル
["]で文字列リテラルを囲むと中身がパース／処理される。
※[']はバースされない。
※[']のパースは [velocity.properties]#[stringliterals.interpolate=false]で変更可
--------------------
#set( $directoryRoot = "www" )
#set( $templateName = "index.vm" )
#set( $template = "$directoryRoot/$templateName" )
$template

#set( $foo = "bar" )
$foo
#set( $blargh = '$foo' )
$blargh

#set($prefix = "prefix")
#set($suffix = "suffix")
#set($hoge = "$prefix$suffix")
$hoge
--------------------
↓
--------------------
www/index.vm

bar
$foo

prefixsuffix
--------------------

※算術式も記述可
・加算: #set( $value = $foo + 1 )
・減算: #set( $value = $bar - 1 )
・乗算: #set( $value = $foo * $bar )
・除算: #set( $value = $foo / $bar )
・剰余: #set( $value = $foo % $bar )

□if/elseif/else文
条件分岐
書式： #if( [condition] ) [output] [ #elseif( [condition] ) [output] ] * [ #else [output] ] #end
--------------------
#if ($foo == $bar)
AND
#elseif ( $foo || $bar )
OR
#else ( !$foo ) ## NOT SAME AS [$!foo](沈黙リファレンス)
NOT
#end
--------------------

□foreach文
オブジェクトのリストでループ
書式： #foreach( $ref in arg ) statement #end
※Vector、Hashtable、配列の場合のみ使用可
--------------------
<'ul>
#foreach( $product in $allProducts )
<'li>$product<'/li>
#end
<'/ul>
--------------------
※ループカウンタ変数はデフォルト1
([velocity.properties]#[directive.foreach.counter.initial.value]で変更可)

□include
ローカルファイルのインポート
書式：#include( arg[, arg2, ... argn] )
ファイルは、#include指示子が定義される位置に挿入される。
テンプレートエンジンでの中身の処理はしない。
※TEMPLATE_ROOT以下にあるファイルだけインポート可
--------------------
#include( "one.gif","two.txt","three.htm" )
--------------------

□parse
VTLを含むローカルファイルのインポート
書式：#parse( arg )
※TEMPLATE_ROOT以下にあるファイルのみインポート可
--------------------
#parse( "parsefoo.vm" )
--------------------

□#stop
テンプレートエンジンの実行を停止

□#macro
Velocimacro
VTLテンプレートのセグメントの繰り返し
書式： #macro( vmname $arg1[, $arg2, $arg3, ... $argn ] ) [ VM VTL code... ] #end

ref:
http://www.jajakarta.org/velocity/velocity-1.3.1/docs-ja/user-guide.html

正規表現

特殊文字列
. ^ $ [ ] * + ? | ( )
→メタ文字列

メタ文字列を単なる文字として使う場合は[\]を前に足す
\. \^ \$ \[ \] \* \+ \? \|  \\

□とにかく何でもいい1文字[.]
半角の[.]でとにかくなんでもいい１文字を表現
ex. 私は...が..→私は早起きが苦手

□行の先頭と最後[^$]
行の先頭や最後にのみ存在する文字列を検索したい場合に[^$]
ex. ^ありがとう→ありがとうから始まるもの
　　ありがとう$→ありがとうで終わるもの

□同じ文字の繰り返し[* + ?]
同じ文字の繰り返しを表す正規表現は [*]、[+]、[?]の３つ
・[*]:[*]の直前の文字が0個以上連続するか
　ex. おー*い→おい、おーい、おーーーい
・[+]:[+]の直前の文字が1個以上連続するか
　ex. おー+い→おーい、おーーーい
・[?]:[?]の直前の文字が0個か1個だけ存在するか
　ex. Windows?→Window、Windows

□何でもいい文字の連続[.*]
[* + ?]は[.]と併用可
ex. コーヒーが好き.*。→コーヒーが好きです。、コーヒーが好きかもね。
　　[.]が[*]であるもの→何でもいい1文字が0個以上連続するもの

□いずれかの文字列[|]
| で区切られた文字列のいずれかの文字列が存在するもの
ex. hoge|piyo→hoge、piyo

□指定した文字のどれか[[]]
[]中のどれか１つに合致するもの
ex. 今日は[晴曇雨]です→今日は晴です
　　Ａ[A-Z]Ｃ→ＡBＣ
　　１[0-9]８→１0８
　　Ａ[^A-Z0-9]Ｚ→Ａ－Ｚ
　　[]の中で^→ＸＸ以外→2番目の文字はアルファベットと数字以外の文字

□グループ化[()]
まとめて数文字単位で処理
ex. (じゃ)+ーん→じゃーん、じゃじゃーん
　　明日(ぼく|わたし)は帰宅します→明日ぼくは帰宅します、明日わたしは帰宅します

ref:
http://www.mnet.ne.jp/~nakama/

JSP#include

JSPに、外部のJSPページやHTMLページをincludeする手段は２つ

１．includeディレクティブ：<'%@ include file="ファイル名" %>
２．includeアクション：<'jsp:include page="ファイル名" />

□includeディレクティブ
インクルードする側のJSPページ（親ページ）のコンパイル時に、
インクルードされる側のJSPページやHTMLページ（子ページ）が
親ページの一部として挿入される。
⇒静的なインクルード機能

□includeアクション
Webブラウザが親ページをリクエストするたびに
子ページのコンテンツがレスポンスに挿入される。
⇒動的なインクルード機能

□文字化け対処法
pageディレクティブの
・contentType属性
・pageEncoding属性
を記述する。

□contentType属性
JSPページ出力時の文字コード、およびContent-Typeヘッダに指定する文字コード名を指定する

□pageEncoding属性
JSPページ読み込み時の文字コードを指定する

pageEncodingは省略可
省略時はcontentType属性の値が使用される

contentType属性の本来の目的は「HTTPレスポンスに用いる文字コードの指定」
→１回セットすればOK。
→子ページ側には不要。
が、
子ページにcontentTypeを記述せんと
サーブレット・コンテナ
が子ページの文字コードを判別する手立てがなくなり
子ページ部分の文字化けが発生してしまう。
で、
子ページには、
読み込み時の文字コードを伝える手段として
pageEncoding属性だけを記述しておく。

つまり、
・親ページ：contentType属性で文字コードを指定する
・子ページ：pageEncoding属性で文字コードを指定する

ref:
http://www.atmarkit.co.jp/fjava/rensai3/mojibake04/mojibake04.html

Shift-JIS & Windows-31J

□NG:charset=Windows-31J
======
content="text/html; charset=Windows-31J">
======
cuz.
charset=Windows-31Jだと
PHPのDOMDocument::loadHTMLFile()関数で上手く読み込めない

Windows-31JのエンコーディングはShift-JISと同じ
が、
PHPは不明なエンコーディングと見なして変換する

うんぬんぬん…

ref:
http://d.hatena.ne.jp/eggtoothcroc/20060214

□Windows-31JはShift-JISを拡張したもの
CP932=MS932=MS漢字コード=Windows-31J≒Shift JIS

ref:
http://q.hatena.ne.jp/1167447698

Encoding stg

□そもそも
Javaは内部的に文字列（String型）をUnicode（UCS-2）で保持。
そのため、
Javaへの文字列の入出力では必ず Unicodeとの間でコード変換が発生。
特に、
Javaのコード変換では、
対応するコードポイントが存在しない場合“？”に変換される。
⇒文字化け

プラス、
Java以外の部分でも発生する！
ex
ファイル転送時のコード変換
ブラウザのエンコーディング設定

□Weblogic#EncodingStgPoint
ⅰ HTTPリクエスト
　servlet:
　　・ソースコード中のServletRequest#setCharacterEncoding
　　・weblogic.xml の
　　・weblogic.xmlの
　JSP:
　　・weblogic.xml の
　　・weblogic.xmlの
ⅱ HTTPレスポンス
　servlet:
　　・ソースコード中のServletResponse#setContentType
　　・weblogic.xmlの
　JSP:
　　・pageディレクティブのcontentTypeの指定
　　・weblogic.xmlの
ⅲ Servlet／JSP内の文字列(コンパイル時)
　servlet:
　　・ソースコードをコンパイルするときのエンコーディングの指定
　JSP:
　　・JSP中のpageディレクティブのcontentTypeの指定
ⅳ weblogic.log／コンソールへのログ出力
　　・Javaのデフォルトエンコーディング（起動するユーザーのロケール）
ⅴ JDBCによるDBへのアクセス(Oracleの場合)
　　・DBの文字コードセット
　　・WebLogic起動ユーザーのNLS_LANG環境変数
　　・コネクションプールのweblogic.codesetプロパティ

□Shift-JIS
JSPのコード変換に影響を与えうる設定
ⅰ．JSP内のpageディレクティブ
　　<%@ page contentType="text/html; charset=Shift_JIS" %>
ⅱ．weblogic.xmlのcharset-mappingの指定
　　

Shift_JIS

MS932

ⅰ
pageディレクティブ#contentType#charsetは、
HTTPレスポンスのヘッダに利用される。
HTTPはJavaのエンコーディングではなく、
ianaで規定されているエンコーディングを指定すること。
→pageディレクティブの指定は、Javaの Shift_JISではなく、ianaのShift_JIS*2である。

このEncoding指定は、JSPをコンパイルするときにも使用される
が、
Shift_JISをそのままJavaのShift_JISとして扱うのは問題やも。
Java#Shift_JISは
MS932 or SJIS の別名として定義されてる！
※ JDK 1.3ではMS932だが、JDK 1.4ではSJISとなる。

そこで、
ⅱ
WebLogicでは、
weblogic.xml#charset-mappingに、
ianaの charsetをJavaのcharsetにマッピングする指定を設けて、
明示的にJavaのエンコーディングを指定。

□暗黙の文字コード変換
JSPのコンパイルでは、
JSPファイル→Javaソース（by Servlet）→classファイル
⇒２段階のコンパイル
前者のコンパイル＝JSPC
後者のコンパイル＝javac

⇒requestからresponseまで４段階のコンパイル

文字化けした場合、どの段階で文字化けたのかをクリアに！

□javacのencoding
javaでは起動するユーザのLANG設定によって
デフォルトのencodingが決められている。
ex
LANG設定＝ja_JP.PCK→SJISでコンパイル

ref:
http://www.atmarkit.co.jp/fjava/rensai2/webopt08/webopt08.html

mime

■MIME type
in web, there are two main concepts; extension of file and mine type.
MIMEタイプ＝「タイプ名/サブタイプ名」の形式の文字列
WEBサーバーとWEBブラウザの間はこのMIMEタイプを用いてデータの形式を指定。
such as
+ テキスト
→.txt, text/plain
+ HTML文書
→.htm .html, text/html
+ XML文書
→.xml, text/xml
+ JavaScript
→.js, text/javascript
+ VBScript
→.vbs, text/vbscript
+ CSS
→.css, text/css
+ GIF画像
→.gif, image/gif
+ JPEG画像
→.jpg(.jpeg), image/jpeg
+ PNG画像
→.png, image/png
+ CGIスクリプト
→.cgi, application/x-httpd-cgi
+ Word文書
→.doc, application/msword
+ PDF文書
→.pdf, application/pdf
+ any other ref http://www.iana.org/assignments/media-types/index.html
cf.
x-hogehoge means

when a browser ask a webServer a hoge.gif,
server gonna return the hoge.gif telling that this is a data of image/gif-type.
so that,
browser can operate the hoge.gif correctly.

but,
some browser like IE ignore the info of mime-type, and trust the info of extension of the file.
and
some ignore the both info, and checking the content of file, display the file as HTML because the content looks like HTML document. its a unnecessary favors!

so,
mine-type is not perfect.

■how to set MIMEタイプ
it is different depends on the webServer.
if webServer is Apache,
there is a file named hoge.htaccess. using this file to specify the MIME.
so,
create a file with the name "hoge.htaccess" under the directory same as other data like hoge.html.
and
write following in the hoge.htaccess.
"AddType text/html .html"
so that,
webServer gonna send the .html file as a data of text/html mime-type.
the setting is not necessary for .html and .gif files cuz provider-side gonna do that for those file.
but you have to do the setting for something like CGI and RealAudio

■excel file download
for downloading and saving a excel file;
application/octet-stream

for displaying a excel file on a browser;
application/vnd.ms-excel

ref:
とほほのWWW入門
http://www.tohoho-web.com/wwwxx015.htm

web.xml

what in web.xml#web-app

servlet
- servlet-name
- servlet-class
sevlet-mapping
- servlet-name
- url-pattern
welcome-file-list
- welcome-file
error-page
- error-code
- location
taglib
- taglib-uri
- taglib-location

Top|Next »

HOME

日	月	火	水	木	金	土
-	-	-	1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31	-