イージーネット Tech Blog » Java http://blog.eni.co.jp/tech 株式会社イージーネットのスタッフによる技術系ブログです Tue, 12 Jan 2010 01:46:58 +0000 http://wordpress.org/?v=2.8.6 ja hourly 1 Wicket小話その3. Wicketで確認メッセージを出すにはどうすればよいのか？(その2) http://blog.eni.co.jp/tech/2009/09/wicket_03_confirm02.html http://blog.eni.co.jp/tech/2009/09/wicket_03_confirm02.html#comments Tue, 29 Sep 2009 08:20:46 +0000 武輪 恭代 http://blog.eni.co.jp/tech/?p=1812 ども、武輪です。

前回のWicket小話で、Confirmメッセージを出すにはどうすればよいのか？と言った話をしたのですが、今回も引き続きConfirmメッセージの話をしたいと思います。

前回、AjaxボタンでConfirmメッセージを表示する方法として、Wicket-extensionのコンポーネントであるModalWindowを使い、独自のポップアップメッセージを表示する方法をとりました。
しかしながら、これってぶっちゃけConfirmメッセージじゃないよね…！

というわけで今回はAjaxボタンで正真正銘(?)のConfirmメッセージを表示する方法をご紹介します。

AjaxボタンでConfirmメッセージ

>Ajaxで中身を入れ替える以上、onclickアトリビュートをいじるのはややこしそうなので…

と前回書いたのですが、
「confirmで確認後、OKだったら既存AjaxのJavaScriptを実行してあげて、キャンセルだったらfalseを返す」
ようなJavaScriptを書けば問題ないんじゃ…？と思いまして。

そんなわけでさらっとサンプルを書いてみました。
サンプルは前回同様、ボタンを押した時に確認メッセージを表示し、OKだったらカウントする、キャンセルだったら何もしない、といった仕様です。

Confirm2.java

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
32
33
34
35
36
37
38

public class Confirm2 extends WebPage{
 
	private int count = 0;
	private Label result;
 
	/**
	 * コンストラクタ
	 */
	public Confirm2() {
		add(result = new Label("result", new PropertyModel<Integer>(this, "count")));
		result.setOutputMarkupId(true);
		Form<?> form = new Form<Confirm2>("form");
 
		form.add(new AjaxButton("count", new Model<String>("カウントしますか？")){
 
			private static final long serialVersionUID = 1L;
 
			@Override
			protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
				count++;
				target.addComponent(result);
			}
 
			@Override
			protected IAjaxCallDecorator getAjaxCallDecorator() {
				return new AjaxPreprocessingCallDecorator(super.getAjaxCallDecorator()) {
					private static final long serialVersionUID = 1L;
 
					@Override
					public CharSequence preDecorateScript(CharSequence script) {
						return "if(!confirm('" + getModelObject() + "')) return false;" + script;
					}
				};
			}
		});
		add(form);
	}
}

【メモ】
25～34行目付近:
AjaxButtonのgetAjaxCallDecoratorをオーバライドしてあげることで、出力されるAjax用JavaScriptに手を加えています。

実際に出力されるhtmlは以下のようになります。

onclick="if(!confirm('カウントしますか？')) return false;var wcall=wicketSubmitFormById('form2', ';[長いので略]"

まとめ

というわけで、AjaxButtonでも前回みたいな似非確認ダイアログではなくちゃんとした(?)Confirmメッセージを出すことができました。
AjaxButtonを記述する度にgetAjaxCallDecorator()をオーバライドするのも面倒なので、AjaxButtonを継承したサブクラスを作っておくのが便利そうです。

動作環境

今回のサンプルソースは以下の環境で動作させています。

バージョン
JDK 1.6.0_13
Apache Tomcat 6.0.16
Apache Wicket 1.4.0

あわせて読みたい

]]> http://blog.eni.co.jp/tech/2009/09/wicket_03_confirm02.html/feed 1 Wicket小話その2. Wicketで確認メッセージを出すにはどうすればよいのか？ http://blog.eni.co.jp/tech/2009/09/wicket_02_confirm.html http://blog.eni.co.jp/tech/2009/09/wicket_02_confirm.html#comments Fri, 04 Sep 2009 02:35:23 +0000 武輪 恭代 http://blog.eni.co.jp/tech/?p=1365 ども、武輪です。

Webアプリケーションでは、データを登録したり編集したり削除したりといった操作が日常茶飯事です。
そして「削除ボタンを押した時にいきなり削除するのではなく、confirmメッセージを出す」というのはよくあるパターンですね。

さてWicket小話その2では、「Wicketで確認メッセージを出すにはどうすればよいのか？」について、実際のコードを踏まえて試してみようと思います。

非Ajaxボタンの場合

例えばこんなボタンがあるとします。
confirmサンプル

これはcountボタンを押すと画面上に何回クリックしたのかを表示する簡単なサンプルです。

Confirm.html

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Wicket Examples - confirm</title>
</head>
<body>
	<span wicket:id="result" /> 回目
	<form wicket:id="form">
		<input wicket:id="count" type="submit" value="count" />
	</form>
</body>
</html>

Confirm.java(非AjaxButton編)

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
32

public class Confirm extends WebPage {
 
	private int count = 0;
 
	/**
	 * コンストラクタ
	 */
	public Confirm() {
		add(new Label("result", new PropertyModel<Integer>(this, "count")));
		Form<?> form = new Form<Confirm>("form");
		Button countButton;
		form.add(countButton = new Button("count") {
			private static final long serialVersionUID = 1L;
 
			@Override
			public void onSubmit() {
				super.onSubmit();
				count++;
			}
 
		});
		add(form);
	}
 
	/**
	 * countを取得します。
	 * @return count
	 */
	public int getCount() {
		return count;
	}
}

html側で対応

html側に直接JavaScriptを埋め込むことで対応。
Javaのコードには一切変更点はありません。

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Wicket Examples - confirm</title>
</head>
<body>
	<span wicket:id="result" /> 回目
	<form wicket:id="form">
		<input wicket:id="count" type="submit" value="count" onclick="return confirm('カウントしますか？')" />
	</form>
</body>
</html>

【メモ】
9行目:
onclickイベントを追加しただけです。

Java側で対応

SimpleAttributeModifierを使うことで、任意のアトリビュートを付加することができます。
htmlには一切変更点はありません。

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
32
33

public class Confirm extends WebPage {
 
	private int count = 0;
 
	/**
	 * コンストラクタ
	 */
	public Confirm() {
		add(new Label("result", new PropertyModel<Integer>(this, "count")));
		Form<?> form = new Form<Confirm>("form");
		Button countButton;
		form.add(countButton = new Button("count") {
			private static final long serialVersionUID = 1L;
 
			@Override
			public void onSubmit() {
				super.onSubmit();
				count++;
			}
 
		});
		countButton.add(new SimpleAttributeModifier("onclick", "return confirm('カウントしますか？')"));
		add(form);
	}
 
	/**
	 * countを取得します。
	 * @return count
	 */
	public int getCount() {
		return count;
	}
}

【メモ】
22行目:
countButtonにSimpleAttributeModifierをadd。

html側で対応した場合も、Java側で対応した場合も、動作的には下図のように、countボタンをクリックすると確認ダイアログが表示されます。
確認ダイアログのOKをクリックすれば、数字がインクリメントされ、キャンセルをクリックすれば数字は元のままです。
Confirmサンプル


Ajaxボタンの場合

続きましてAjaxボタンの場合。
動作的には変わらないのですが、先ほどのサンプルコードを下記のように、ButtonではなくAjaxButtonを使用するように変更します。
html側には変更はありません。(Wicketってこういうとこ便利ですよね)

Confirm.java(AjaxButton編)

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
32
33
34

public class Confirm extends WebPage {
 
	private int count = 0;
 
	/**
	 * コンストラクタ
	 */
	public Confirm() {
		final Label result;
		add(result = new Label("result", new PropertyModel<Integer>(this, "count")));
		result.setOutputMarkupId(true);
		Form<?> form = new Form<Confirm>("form");
		AjaxButton countButton;
		form.add(countButton = new AjaxButton("count") {
			private static final long serialVersionUID = 1L;
 
			@Override
			protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
				count++;
				target.addComponent(result);
			}
 
		});
		add(form);
	}
 
	/**
	 * countを取得します。
	 * @return count
	 */
	public int getCount() {
		return count;
	}
}

【メモ】
11行目:
Ajaxを用いてコンポーネントを更新する場合は、setOutputMarkupIdをtrueにすることを忘れずに！

こんな失敗

非Ajaxボタンの時と同じように、onclickアトリビュート追加してやればいいんじゃないの？
　↓
html側に「onclick=”return confirm(’カウントしますか？’)”」をつけたしてみる。
　↓
カウントはされるが、確認ダイアログは出てこない。あれ？
　↓
生成されたhtmlソースを見てみる
　↓

<input type="submit" value="count" onclick="var wcall=wicketSubmitFormById('ida', '?wicket:interface=:5:form:count::IActivePageBehaviorListener:0:&amp;wicket:ignoreIfNotActive=true', 'count' ,null,null, function() {return Wicket.$$(this)&amp;&amp;Wicket.$$('ida')}.bind(this));;; return false;" name="count" id="idb"/>

　↓
Ajax用のonclickになってるよーorz
　↓
じゃあ、SimpleAttributeModifierを使うパターンは？
　↓
確認ダイアログは出るけど、OKクリックしてもカウントアップされない
　↓
生成されたhtmlソースを見てみる
　↓

<input type="submit" value="count" name="count" id="id3" onclick="return confirm('カウントしますか？')"/>

　↓
見事Ajax用のonclickイベントはconfirmに置き換わってる
　↓
そりゃそうだorz

力技で解決

Ajaxで中身を入れ替える以上、onclickアトリビュートをいじるのはややこしそうなので、とっても強引に解決してみました。

もう独自にConfirmウィンドウ実装しちゃえばいいんじゃね？
というわけで、できたのがこんな画面。

Confirmサンプル

Wicket-extensionにはいくつかの便利なAjaxコンポーネントが備わっています。
そのうちの一つであるModalWindowを使って、強引に確認ダイアログのようなものを表示させてみました。

追加したのは下記3ファイル(ConfirmModalWindowPage.html、ConfirmModalWindowPage.java、IConfirmPage.java)。

ConfirmModalWondowPage.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<meta http-equiv="content-type" content="application/xhtml+xml;charset=UTF-8" />
	<title>ModalWindow</title>
</head>
<body>
	<div wicket:id="info">メッセージ</div>
	<form wicket:id="confirmForm">
		<div style="padding:1em; text-align:center">
			<input type="submit" wicket:id="ok" value="OK" />
			<input type="submit" wicket:id="cancel" value="キャンセル" />
		</div>
	</form>
</body>
</html>

ConfirmModalWondowPage.java

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

public class ConfirmModalWindowPage extends WebPage {
 
	@SuppressWarnings("unchecked")
	public ConfirmModalWindowPage(final IConfirmPage page, final ModalWindow confirmModalWindow, String info) {
		add(new Label("info", new Model<String>(info)));
 
		Form confirmForm;
		add(confirmForm = new Form("confirmForm"));
 
		// OKボタン
		confirmForm.add(new AjaxButton("ok") {
			private static final long serialVersionUID = 1L;
			@Override
			public void onSubmit(AjaxRequestTarget target, Form<?> form) {
				boolean result = page.ok(target);
				if(result){
					// 処理に成功した時の動作
					confirmModalWindow.close(target);
				} else {
					// 処理に失敗した時の動作
				}
			}
		});
 
		// キャンセルボタン
		confirmForm.add(new AjaxButton("cancel") {
			private static final long serialVersionUID = 1L;
			@Override
			public void onSubmit(AjaxRequestTarget target, Form<?> form) {
				// キャンセルボタンが押されたときの処理
				confirmModalWindow.close(target);
			}
		});
	}
 
 
	/**
	 * 確認用ModalWindowを取得する.
	 * @param id
	 * @param page
	 * @return
	 */
	public static ModalWindow getConfirmModalWindow(String id, final IConfirmPage page, final String info){
		final ModalWindow modal = new ModalWindow(id);
		modal.setCssClassName(ModalWindow.CSS_CLASS_GRAY);
		modal.setInitialHeight(150);
		modal.setInitialWidth(350);
		modal.setResizable(false);
		modal.setTitle("確認メッセージ");
		modal.setCookieName("confirm_window");
		modal.setPageCreator(new ModalWindow.PageCreator() {
			private static final long serialVersionUID = 1L;
			public Page createPage() {
				return new ConfirmModalWindowPage(page, modal, info);
			}
		});
 
		modal.setWindowClosedCallback(new ModalWindow.WindowClosedCallback() {
			private static final long serialVersionUID = 1L;
			public void onClose(AjaxRequestTarget target) {
				page.refleshComponent(target);
			}
		});
 
		modal.setCloseButtonCallback(new ModalWindow.CloseButtonCallback() {
			private static final long serialVersionUID = 1L;
			public boolean onCloseButtonClicked(AjaxRequestTarget target) {
				return true;
			}
		});
 
		return modal;
	}
}

【メモ】
11～23行目:
ConfirmウィンドウのOKボタンの定義です。実際の処理は、元のPageのokメソッドに記述しています。
処理の成功/失敗を返すようにしておくと、処理に失敗した場合はConfirmウィンドウ内にエラーメッセージを表示するなんて使い方もできそうです。

26～33行目:
Confirmウィンドウのキャンセルボタンの定義です。Confirmウィンドウを閉じているだけです。

43～73行目:
Confirmウィンドウ用のModalWindowを取得するメソッドです。元のPageから取得するためstaticメソッドにしています。

45～51行目:
ModalWindowの設定です。
　setCssClassName　→　CSS_CLASS_GRAYかCSS_CLASS_BLUEを選択。デフォルトでは青色。
　setInitialHeight、setInitialWidth　→　ModalWindowのサイズ指定。確認ダイアログなので小さめにしておきます。
　setResizable　→　ModalWindowのリサイズを可能にするかしないか。
　setTitle　→　ModalWindowのタイトル文字列。
　setCookieName　→　クッキーの名前。このクッキーはModalWindowの位置などを記憶しています。

58～63行目:
ModalWindowが閉じられたときの処理を記述します。
ここでは元画面のコンポーネントの更新を行っています。

65～70行目:
ModalWindowの×ボタンで閉じられたときの処理を記述します。
ここでは特に何も行っていません。

IConfirmPage.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public interface IConfirmPage {
	/**
	 * 画面の更新
	 * @param target
	 */
	public void refleshComponent(AjaxRequestTarget target);
 
	/**
	 * OKボタンを押した時の処理
	 * @param target
	 * @return 処理が成功したかどうか true:成功 false:失敗
	 */
	public boolean ok(AjaxRequestTarget target);
 
	/**
	 * キャンセルボタンを押した時の処理
	 * @param target
	 */
	public void cancel(AjaxRequestTarget target);
}

【メモ】
Confirmウィンドウを表示するPageでこのインターフェースを実装します。

このインターフェースを実装するようにConfirm.javaを以下のように修正しました。
Confirm.java(修正後)

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

public class Confirm extends WebPage implements IConfirmPage{
 
	private int count = 0;
	private Label result;
 
	/**
	 * コンストラクタ
	 */
	public Confirm() {
		add(result = new Label("result", new PropertyModel<Integer>(this, "count")));
		result.setOutputMarkupId(true);
		Form<?> form = new Form<Confirm>("form");
 
		final ModalWindow confirmModalWindow = ConfirmModalWindowPage.getConfirmModalWindow("confirmModalWindow",
				Confirm.this, "カウントしますか？");
		form.add(confirmModalWindow);
 
		AjaxButton countButton;
		form.add(countButton = new AjaxButton("count") {
			private static final long serialVersionUID = 1L;
 
			@Override
			protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
				confirmModalWindow.show(target);
			}
 
		});
 
		add(form);
	}
 
	/**
	 * countを取得します。
	 * @return count
	 */
	public int getCount() {
		return count;
	}
 
	/**
	 * Confirmウィンドウでキャンセルが押されたときの処理
	 */
	public void cancel(AjaxRequestTarget target) {
		// キャンセル時の処理
	}
 
	/**
	 * ConfirmウィンドウでOKが押されたときの処理
	 */
	public boolean ok(AjaxRequestTarget target) {
		count++;
		return true;
	}
 
	/**
	 * 画面上のコンポーネントの更新
	 */
	public void refleshComponent(AjaxRequestTarget target) {
		target.addComponent(result);
	}
}

【メモ】
14～16行目:
Confirmウィンドウ用のModalWindowを取得します。

23～25行目:
countボタンがクリックされたときの処理。ModalWindowを表示します。

40～45行目:
Confirmウィンドウでキャンセルボタンを押されたときの実処理を記述します。ここでは特に何もしていません。

50～53行目:
ConfirmウィンドでOKボタンが押されたときの実処理を記述します。ここではcountをインクリメントしています。

58～60行目:
Ajaxで画面の更新を行います。ここではresultラベルの表示を更新しています。

Confirm.html(変更後)

1
2
3
4
5
6
7
8
9
10
11
12
13

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Wicket Examples - confirm</title>
</head>
<body>
	<span wicket:id="result" /> 回目
	<form wicket:id="form">
		<input wicket:id="count" type="submit" value="count"/>
		<div wicket:id="confirmModalWindow">削除ConfirmModalWindow</div>
	</form>
</body>
</html>

【メモ】
10行目:
Confirmウィンドウ表示領域の確保。

まとめ

とりあえずこんな感じの実装で、AjaxButtonの場合でも確認ダイアログっぽいものは出すことができました。

もっともこのままだと、1つの画面でOK、キャンセルが押されたときの処理が1つしか記述できないので、実際汎用的に使おうと思えば、さらなる改造が必要ですけどね:）

動作環境

今回のサンプルソースは以下の環境で動作させています。

バージョン
JDK 1.6.0_13
Apache Tomcat 6.0.16
Apache Wicket 1.4.0

あわせて読みたい

]]> http://blog.eni.co.jp/tech/2009/09/wicket_02_confirm.html/feed 2 Wicket小話その1. とりあえずWicketを始めよう http://blog.eni.co.jp/tech/2009/08/wicket_01_start.html http://blog.eni.co.jp/tech/2009/08/wicket_01_start.html#comments Mon, 31 Aug 2009 08:35:02 +0000 武輪 恭代 http://blog.eni.co.jp/tech/?p=1108 mvn --version Apache Maven 2.1.0 (r755702; 2009-03-19 04:10:27+0900) Java version: 1.6.0_06 Java home: C:javajdk1.6.0_06jre Default locale: ja_JP, platform encoding: MS932 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" 早速Wicketを始めよう Moven2のインストールが完了したら、早速Wicketを開始してみましょう。 サンプルアプリケーションを動かしてみよう！ 1. ダウンロード http://wicket.apache.org/ から1.4系のアーカイブをダウンロードしてきます。 適当なディレクトリでアーカイブを展開します。 libディレクトリにはwicketの各種ライブラリーの他に、サンプルアプリケーションのwar(wicket-examples-1.4.x.war)も入っています。 このwarファイルをローカルのTomcatのwebappディレクトリに放り込んでTomcatを再起動してあげれば、とりあえずサンプルを動かすことができるんですが、このwarにはソースが含まれていないので動作を見るだけになってしまいます。 折角なのでEclipseで作業できるようにしましょう。 2. Eclipseにインポート コマンドプロンプト上で、srcディレクトリ以下のwicket-examplesに移動します。 mvn eclipse:eclipse -DdownloadSources=true を実行することでEclipse用の設定ファイルが生成されます。 %展開先のディレクトリ%apache-wicket-1.4.xsrcwicket-examples>mvn eclipse:eclipse -DdownloadSources=true あとはEclipseで「インポート」→「既存プロジェクトをワークスペースへ」からインポートすればOK。 3. サンプルを動かしてみよう wicket-examplesパッケージにはJettyというJAVAのWebサーバが同梱されているので、簡単にサンプルを動作させることができます。 org.apache.wicket.examples.StartExamplesクラスを実行すればJettyサーバが起動します。 そしたらあとは http://localhost:8080/wicket-examples/ にアクセスするだけでWicketのサンプルの数々を試すことができます。 勿論Tomcatで動かしても全然問題ありません。 新規プロジェクトのスタート サンプルアプリケーションは、既に1つの完成されたアプリケーションです。 新規プロジェクトをスタートさせる時には、ブランクのプロジェクトがあれば便利だなーって思いませんか？ というわけでブランクプロジェクトの作り方です。 Maven2の使い方なんかわかんないよーって人にも簡単！ WicketのQuickStartのページからコマンドラインを作成することができます。 上記サイトにアクセスすると、こんな入力欄があります。 各入力欄の意味は、 　GroupId:　パッケージとして使用される 　ArtifactId:　プロジェクト名として使用される 　Version:　Wicketのバージョン こんな感じです。 これらを入力していくと、勝手にCommand Line欄にコマンドが組み立てられていくって寸法です。なんて便利！ 次にコマンドプロンプト上でプロジェクトを作成したいディレクトリに移動し、先ほど生成したコマンドラインをコピペして実行します。 (※Proxyの設定などはこちらを参考に。→Maven2のTipsを集めるwiki#固有の環境設定) C:test>mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4.1 -DgroupId=jp.co.eni.wicket -DartifactId=sample [INFO] Scanning [...]]]> ども、武輪です。

Wicket小話と題しまして、Wicket初心者の私がWicketを使ってみて、

  • これちょっと便利な機能だなー
  • こんなコンポーネントを使ってみたよ！
  • こんな実装やってみたよ！

などなど。
そんなちょっとしたメモ書きを徒然と残していこうと思います。

基本的に情報はWebと書籍「オープンソース徹底活用 WicketによるWebアプリケーション開発」(矢野勉さん著)から得ています。
あとはWicketのソースとか。

さてWicket小話その1として、「とりあえずWicketを始めよう」という副題で徒然と書いていきます。

はじめに

そもそもWicketって何よって方に簡単に。
Wicketとは、Webアプリケーションフレームワークの1つです。
HtmlとJavaでWebアプリケーションが作れちゃいます。
設定ファイルはほとんど必要ありません。(そりゃweb.xmlは必須ですけども)

2009年8月現在Wicketは1.4がリリースされています。
Wicket小話では特に注意書きがない限り、この最新リリースのWicket1.4で試したことを書いていこうと思います。

開発環境などは以下の通り。

バージョン
JDK 1.6.0_13
Apache Tomcat 6.0.16
Apache Wicket 1.4.0

さてここまで書いたところで、ショックな出来事が1つ。
ちょ…、Wicket1.4.1もう出てるじゃんorz

ま、まぁいっか。

準備

Apache Maven2 のインストール手順

Maven2を使うことで簡単にWicketプロジェクトを開始することができます。
(事前に1.5以上のJDKがインストールされている前提で話を進めていきます。)

1. ダウンロード
Apache Maven Projectより、アーカイブをダウンロードします。
私は2.1.0を使用していますが、2.2.1が既に出ているようです。

2. 環境変数の設定
適当なディレクトリ(MAVEN_HOME)にダウンロードしてきたアーカイブを展開してください。
環境変数PATHに%MAVEN_HOME%binを追加。
(環境変数はシステムのプロパティ→詳細設定→環境変数から変更できます。既存のPATHの値を消してしまわないように気を付けてください。)

※JAVA_HOMEを設定していないとMaven2は動かないので注意。

3. インストール確認
コマンドプロンプトでmvn –versionを実行することでインストールを確認することができます。

C:>mvn --version
Apache Maven 2.1.0 (r755702; 2009-03-19 04:10:27+0900)
Java version: 1.6.0_06
Java home: C:javajdk1.6.0_06jre
Default locale: ja_JP, platform encoding: MS932
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

早速Wicketを始めよう

Moven2のインストールが完了したら、早速Wicketを開始してみましょう。

サンプルアプリケーションを動かしてみよう！

1. ダウンロード
http://wicket.apache.org/ から1.4系のアーカイブをダウンロードしてきます。

適当なディレクトリでアーカイブを展開します。
libディレクトリにはwicketの各種ライブラリーの他に、サンプルアプリケーションのwar(wicket-examples-1.4.x.war)も入っています。
このwarファイルをローカルのTomcatのwebappディレクトリに放り込んでTomcatを再起動してあげれば、とりあえずサンプルを動かすことができるんですが、このwarにはソースが含まれていないので動作を見るだけになってしまいます。
折角なのでEclipseで作業できるようにしましょう。

2. Eclipseにインポート
コマンドプロンプト上で、srcディレクトリ以下のwicket-examplesに移動します。
mvn eclipse:eclipse -DdownloadSources=true を実行することでEclipse用の設定ファイルが生成されます。

%展開先のディレクトリ%apache-wicket-1.4.xsrcwicket-examples>mvn eclipse:eclipse -DdownloadSources=true

あとはEclipseで「インポート」→「既存プロジェクトをワークスペースへ」からインポートすればOK。

3. サンプルを動かしてみよう
wicket-examplesパッケージにはJettyというJAVAのWebサーバが同梱されているので、簡単にサンプルを動作させることができます。
org.apache.wicket.examples.StartExamplesクラスを実行すればJettyサーバが起動します。
そしたらあとは http://localhost:8080/wicket-examples/ にアクセスするだけでWicketのサンプルの数々を試すことができます。
勿論Tomcatで動かしても全然問題ありません。

新規プロジェクトのスタート

サンプルアプリケーションは、既に1つの完成されたアプリケーションです。
新規プロジェクトをスタートさせる時には、ブランクのプロジェクトがあれば便利だなーって思いませんか？
というわけでブランクプロジェクトの作り方です。

Maven2の使い方なんかわかんないよーって人にも簡単！
WicketのQuickStartのページからコマンドラインを作成することができます。

上記サイトにアクセスすると、こんな入力欄があります。

quickstart

QuickStartページ

各入力欄の意味は、
　GroupId:　パッケージとして使用される
　ArtifactId:　プロジェクト名として使用される
　Version:　Wicketのバージョン
こんな感じです。
これらを入力していくと、勝手にCommand Line欄にコマンドが組み立てられていくって寸法です。なんて便利！

次にコマンドプロンプト上でプロジェクトを作成したいディレクトリに移動し、先ほど生成したコマンドラインをコピペして実行します。
(※Proxyの設定などはこちらを参考に。→Maven2のTipsを集めるwiki#固有の環境設定)

C:test>mvn archetype:create -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.4.1 -DgroupId=jp.co.eni.wicket -DartifactId=sample
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [archetype:create] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:create]
[WARNING] This goal is deprecated. Please use mvn archetype:generate instead
[INFO] Defaulting package to group ID: jp.co.eni.wicket
Downloading: http://repo1.maven.org/maven2/org/apache/wicket/wicket-archetype-quickstart/1.4.1/wicket-archetype-quickstart-1.4.1.jar
13K downloaded  (wicket-archetype-quickstart-1.4.1.jar)
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating OldArchetype: wicket-archetype-quickstart:1.4.1
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: jp.co.eni.wicket
[INFO] Parameter: packageName, Value: jp.co.eni.wicket
[INFO] Parameter: package, Value: jp.co.eni.wicket
[INFO] Parameter: artifactId, Value: sample
[INFO] Parameter: basedir, Value: C:test
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] ********************* End of debug info from resources from generated POM ***********************
[INFO] OldArchetype created in dir: C:testsample
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 seconds
[INFO] Finished at: Wed Aug 26 11:11:43 JST 2009
[INFO] Final Memory: 7M/14M
[INFO] ------------------------------------------------------------------------

最後に「[INFO] BUILD SUCCESSFUL」が出てればOK。

さて、実はもうこれだけで実行可能な状態なんです。
上記例では、C:testにsampleというディレクトリが作成されています。
コマンドプロンプト上でこのsampleディレクトリに移動し、以下のコマンドを実行します。

C:testsample>mvn jetty:run

http://localhost:8080/sample にアクセスしてみてください。

Wicket Quickstart Archetype Homepage 

If you see this message wicket is properly configured and running

と表示されていれば成功です。

さらにEclipseで開発するには、sampleディレクトリ上で

C:testsample>mvn eclipse:eclipse -DdownloadSources=true

を実行してEclipse用の設定ファイルが生成して、Eclipseで既存プロジェクトのインポートをすればOKです。

リンク集

Apache Wicket
Apache Wicketの本家サイト

Wicket-ja
日本Wicketユーザーグループ(wicket-ja)の公式サイト。
過去のメーリングリストの内容などが参照できます。
ちなみに「うぃけっと　じぇーえー」ではなく「うぃけっとじゃ」と読むらしいです。

矢野勉のはてな日記
Wicket-ja創設者のブログ。
著書の「オープンソース徹底活用 WicketによるWebアプリケーション開発」には大変お世話になっております。

Wicket学習帳
最終更新が2008年08月19日で止まっていて、Ｗｉｃｋｅｔ1.3ベースまでの話が多いですが、参考になります。

最後に

さて、「とりあえずWicketを始めよう」という目的は達成できたでしょうか。
次回以降のWicket小話では、具体的なコンポーネントの使い方とかを載せていければ、と思っております。

それでは、また。

あわせて読みたい

]]> http://blog.eni.co.jp/tech/2009/08/wicket_01_start.html/feed 1 コマンドを便利に切り替える update-alternatives 使いこなし講座 http://blog.eni.co.jp/tech/2009/08/update-alternatives.html http://blog.eni.co.jp/tech/2009/08/update-alternatives.html#comments Tue, 04 Aug 2009 04:00:39 +0000 白石 将 http://blog.eni.co.jp/tech/?p=968 こんにちは、プロダクト&サービス事業部の白石です。

唐突ですが、日本はよく豊かな国だと言われることがあります。
それは、ただ単に日本人の所得が高いというわけではなく選択の幅があるからです。

いざ美味しいものを食べたいなと思った時、
日本の料理はもちろんのこと、中華料理、韓国料理、イタリア料理などすぐに見つかります。
さらにちょっと手間を掛けて、大きな街中に足を運んだりするともっと多彩な国のグルメを楽しむことが出来ます。
また、こだわりのあるバーなんかに行くと世界中のお酒が並んでたりしますよね。
こういった選択の幅がある国って他にはなかなか無いそうですよ。

このように何かしようと思った時に、
色々あるものの中から好きなものを選べるのことはとても恵まれていることだと思いませんか?

そんな選択肢を文字通りLinuxに与えてくれるのが update-alternatives というコマンドです。

今回はCentOSでの検証を基に話をしますが、
CentOSの他に、Debian、RedHat系(RHEL、Fedora)にも
この update-alternatives という

シンボリックリンクを管理してデフォルトのコマンドを決定(man参照)するコマンド

があります。
簡単に言うと、複数のバージョン(または似たような機能)を持つプログラムを切り替える(管理する)コマンドです。

CentOSにSUNの Java を入れたことがある方は、一度は使ったことがあるのではないかと思います。

今回はこの update-alternatives コマンドについて解説したいと思います。

目次

  1. update-alternatives とは
  2. update-alternatives の使い方
  3. スレーブとは
  4. update-alternatives の簡単なファイル構成
  5. 共通オプション
  6. まとめ
  7. 参考ドキュメント
  8. おまけ – SUNのJDKをCentOS 5.3にインストールする

使用したソフトウェアのバージョン

今回、使用したソフトウェアのバージョンは下記のようになります。

バージョン
CentOS 5.3 x86_64(インストール直後のもの)
update-alternatives 1.3.30.1

update-alternatives とは

長いので使い方のみを知りたい方はこの節は飛ばして、update-alternatives の使い方へどうぞ。

update-alternatives コマンドとは冒頭の通り、

複数のバージョン(または似たような機能)を持つプログラムを切り替える(管理する)コマンド

です。

# which update-alternatives
/usr/sbin/update-alternatives
# ls -l /usr/sbin/update-alternatives
lrwxrwxrwx 1 root root 12  4月 25 02:02 /usr/sbin/update-alternatives -> alternatives

どうやら、update-alternatives は /usr/sbin/alternatives へのシンボリックリンクのようです。
では、/usr/sbin/alternatives を見てみましょう。

# ls -l /usr/sbin/alternatives
-rwxr-xr-x 1 root root 26384  5月 24  2008 /usr/sbin/alternatives

/usr/sbin/alternatives が本体みたいですね。
ということは、

# update-alternatives

とコマンドを実行するよりも、

# alternatives

と実行した方が入力の手間が省けますが、
CentOSの『man alternatives』では”UPDATE-ALTERNATIVES”となっているので、
本エントリでは基本的に update-alternatives として話を進めることにします。

さて、この update-alternatives ですが、
元はDebianの機能だったのが、現在ではRedHat系のディストリビューションにも移植されています。

今回、update-alternatives の機能を説明をするには、
Java が適しているので Java をもとに簡単にどんな機能なのか見ていきたいと思います。

まずは Java の確認

# which java
/usr/bin/java
# java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

このことからCentOS 5.3には標準で OpenJDK が入っていることが分かります。

けれど、実はCentOS 5.3にはデフォルトで Java が2種類入っており、
update-alternatives の機能を利用して管理されています。

# update-alternatives --config java
 
2 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:

本来はステータスを参照する場合には --display オプションを使用するのですが、
見やすさのため --config オプションを指定しました。

上記の結果から、

  1. update-alternatives で管理されている Java グループには OpenJDK と GCJ の2種類がある
  2. プログラムは OpenJDK の方が選択されているっぽい

ということが何となく分かると思います。

それでは update-alternatives の機能を使って Java グループのプログラムを切り替えてみましょう。

# update-alternatives --config java
 
2 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します: 2    <---- 入力!!

では、もう一度 Java の確認を行ってみましょう。

# which java
/usr/bin/java
# java -version
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20080704 (Red Hat 4.1.2-44)
 
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

同じ /usr/bin/java を実行しているはずなのにさっきと結果が変わりました!!

これは操作上では同じプログラムを実行しているようでも、
実は update-alternatives が裏で頑張ってプログラムを切り替えてくれているからなんです。

このように

  • 複数のバージョンの同一のプログラム
  • 同じジャンルに分類される複数のプログラム

などを手軽に切り替えて使えるようにするのが update-alternatives の機能となります。

update-alternatives の使い方

update-alternatives の機能が何となく分かったところで使い方を見ていきましょう。

その前に動作モードと用語の説明をしておきます。

動作モード
解説
自動 update-alternatives が優先度で判断して選択肢を変更する状態。
手動 rootが行った設定を保持している状態
用語
説明 記述例
グループ名 update-alternatives で管理されるプログラムのグループ名 java
実行リンク update-alternatives の機能を使ってプログラムを実行するためのパス /usr/bin/java
プログラムパス update-alternatives で管理するプログラム(ファイル)のパス /usr/java/jdk1.6.0_14/bin/java
優先度 “自動モード”の場合、優先度が高いものが選択される 16014

グループのプログラムを切り替える

update-alternatives のグループで管理されているプログラムを切り替えます。

update-alternatives --config グループ名
update-alternatives --auto グループ名
update-alternatives --set グループ名 プログラムパス

update-alternatives とはでの Java グループのプログラム切り替えと同様の手順となります。

では、 Java グループの選択プログラムを OpenJDK から GCJ に切り替えてみましょう。

# update-alternatives --config java
 
2 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します: 2    <---- 入力!!

もしくは、

# update-alternatives --set java /usr/lib/jvm/jre-1.4.2-gcj/bin/java

とすることでも切り替わります。
こちらは非対話形式なので、
シェルスクリプトの中でグループの選択プログラムを切り替える際に重宝しそうです。

ちなみに上記の2通りの方法で選択プログラムを切り替えた場合、
グループの動作モードは“手動”に変更されます。

逆に次の方法では、
自動モードに変更することで“優先度が最も高いプログラムを選択”します。

# update-alternatives --auto java

“自動”モードに設定されることにより、
選択されるプログラムが自動で update-alternatives によって決められることになり優先度の最も高いものが選択されます。

グループにプログラムを追加する

指定したプログラムを update-alternatives のグループに追加します。

update-alternatives --install 実行リンク グループ名 プログラムパス 優先度

SUNの JDK1.6.0_update14(以下jdk1.6.0_14) が /usr/java にインストール済みである状態とします。　

おまけ – SUNのJDKをCentOS 5.3にインストールする

# update-alternatives --install /usr/bin/java java /usr/java/jdk1.6.0_14/bin/java 16014

何も表示されなかった場合にはグループにプログラムが追加されているはずです。

では早速、update-alternatives で管理されている Java グループのリストを見てみましょう。

# update-alternatives --config java
 
3 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
 + 2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*  3           /usr/java/jdk1.6.0_14/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:

Java グループの中に jdk1.6.0_14 が追加されているのが確認出来ました。

グループの状態を表示する

update-alternatives で管理されているプログラムの状態を表示します。

update-alternatives --display グループ名

Java グループの詳細を見てみましょう。

# update-alternatives --display java
java - ステータスは手動です。
リンクは現在 /usr/lib/jvm/jre-1.4.2-gcj/bin/java を指しています。
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java - 優先項目 16000
 スレーブ keytool: /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/keytool
    ～中略～
/usr/lib/jvm/jre-1.4.2-gcj/bin/java - 優先項目 1420
 スレーブ keytool: /usr/lib/jvm/jre-1.4.2-gcj/bin/keytool
    ～中略～
/usr/java/jdk1.6.0_14/bin/java - 優先項目 16014
 スレーブ keytool: (null)
    ～中略～
現在の「最適」バージョンは /usr/java/jdk1.6.0_14/bin/java です。

以上のような詳細な状態の確認をすることができます。

--display オプションで確認できる内容は、

  • 現在の動作モード
  • 現在グループで選択されているプログラム
  • グループに登録されているプログラムとその優先度
  • プログラムに関連付けられているスレーブ(後述)
  • 自動モード時に選択されるプログラム

となります。

上記の実行結果から、

  • OpenJDK と GCJ と jdk1.6.0_14 の計3種類の Java が update-alternatives で管理されている
  • OpenJDK の優先度は”16000″
  • GCJ の優先度は”1420″
  • jdk1.6.0_14 の優先度は”16014″
  • 現在の動作モードは”手動”
  • 現在、jdk1.6.0_14が選択されている
  • 各スレーブの状態
  • 自動モードにした場合、jdk1.6.0_14 が選択される(最適バージョン)

ということが読み取れます。

グループからプログラムを削除する

グループに追加済みのプログラムをグループから削除します。

update-alternatives --remove グループ名 プログラムパス

それでは、jdk1.6.0_14 を削除してみましょう。

# update-alternatives --remove java /usr/java/jdk1.6.0_14/bin/java

きちんと削除されたか確認してみます。

# update-alternatives --config java
 
2 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
*  1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
 + 2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:

きちんとプログラムパスで指定したものが消えていますね。

グループからプログラムを削除する際に、
“自動”モードの場合、選択中のプログラムを削除した場合には、update-alternatives が優先度の大きいものに自動で変更します。
“手動”モードの場合には、プログラム情報を削除するだけで選択情報は変更されないみたいです。
また削除後に選択すべきプログラムが無い場合にはグループが削除されます。

ちなみに、プログラムパスを間違えると次のように怒られちゃいます。

# update-alternatives --remove java /usr/java/jdk1.6.0_14/
/usr/java/jdk1.6.0_14/ は java の為の互換用として設定されていません。

RedHat系ディストリビューションでは使えないオプション

Debianにはあっても、
残念ながらRedHat系ディストリビューションでは使えないオプションがあるようです。

RedHat系ディストリビューションでは使えないオプション
--list グループ内の管理プログラムを一覧表示する
--remove-all グループごと削除する
--all すべてのグループにたいして --config オプションを呼び出す

使い道の思い浮かばない --all オプションはともかく、
個人的に --list オプションは欲しかったように思います。
--display オプションがありますが、
グループ内のプログラムを参照するだけであれば --config オプションで見た方が視認性が高いかと思います。

スレーブとは

簡単に言ってしまうと、

グループの選択プログラムが変更されると、スレーブとして登録されたプログラムも同時に変更する

機能です。

update-alternatives --install 実行リンク グループ名 プログラムパス --slave 実行リンク グループ名 プログラムパス

では今までの流れから、
既に jdk1.6.0_14 が入ってる状態に、
更に JDK1.5.0_update19(以下jdk1.5.0_19) を入れてスレーブ機能を使ってみましょう。

jdk1.5.0_19 をインストールする際に、
既に jdk1.6.0_14 をRPMパッケージでインストールしている場合、
古いバージョンをRPMパッケージでインストール出来ないので、
RPMパッケージを使わずに jdk-1_5_0_19-linux-amd64.bin を展開し /usr/java に配置します。

配置出来たら、jdk1.5.0_19 も update-alternatives で管理させます。

# alternatives --install /usr/bin/java java /usr/java/jdk1.5.0_19/bin/java 15019

では、早速 jdk1.5.0_19 に切り替えてみましょう。

# alternatives --config java
 
4 プログラムがあり 'java' を提供します。
 
  選択       コマンド
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*+ 3           /usr/java/jdk1.6.0_14/bin/java
   4           /usr/java/jdk1.5.0_19/bin/java
 
Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:4

早速 Java のバージョンを確認。

# java -version
java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_19-b02, mixed mode)

うまく切り替わっているのが確認出来ますね。

しかし、

# javac -version
javac 1.6.0_14

Java はうまく切り替わっていても、
javac は jdk1.6.0_14 のものを使ってしまっています。

javac をはじめ、jar や javadoc など Java の変更に伴って同時に変更したいプログラムがいくつかあります。
一つ一つを丁寧に update-alternatives に登録 –> 変更と繰り返すことで解決はしますが、
Java を切り替える度にいくつものその他プログラムを切り替えるのは少々骨が折れる作業となります。

そんな時に活用したいのがスレーブ機能です。

スレーブ機能とは最初に紹介した通り、

グループの選択プログラムが変更されると、スレーブとして登録されたプログラムを同時に変更する

です。

なんだか今回の事例にピッタリな機能ですよね。

では、早速スレーブ機能を使ってみましょう。

# alternatives --install /usr/bin/java java /usr/java/jdk1.5.0_19/bin/java 15019\
      --slave /usr/bin/javac javac /usr/java/jdk1.5.0_19/bin/javac

--install オプションでの追加時に --slave オプションを設定するだけです。
(既にグループにプログラムが登録済みでも上書き出来ます。)

これでスレーブを保持する jdk1.5.0_19 の追加が出来ました。

では、早速 update-alternatives で jdk1.5.0_19 に切り替えて、
javac がどうなっているか確認してみましょう。
(既に jdk1.5.0_19 の場合は、他に変更後、再度 jdk1.5.0_19 に変更してください)

# javac -version
javac 1.5.0_19

javac も Java と一緒に更新されていることが確認できました。

このスレーブは --install オプションの設定時に何個でも登録することが出来ます。
複数個の登録の場合には、

# alternatives --install /usr/bin/java java /usr/java/jdk1.5.0_19/bin/java 15019\
      --slave /usr/bin/jar jar /usr/java/jdk1.5.0_19/bin/jar\
      --slave /usr/bin/javac javac /usr/java/jdk1.5.0_19/bin/javac\
      --slave /usr/bin/javadoc javadoc /usr/java/jdk1.5.0_19/bin/javadoc

のように実行してください。

自分で必要なだけスレーブを追加出来るので、
記述は冗長になってしまいますが毎回1つ1つを変更していくよりもはるかに効率的ですね。

ちなみに、
上記の javac の設定だけだと jdk1.6.0_14 に戻した際に、
javac は変更されないので、
jdk1.6.0_14 にも同様に javac などスレーブを設定する必要があります。

update-alternatives の簡単なファイル構成

ここでは簡単な update-alternatives のファイル構成を解説したいと思います。

alternatives ディレクトリ ( /etc/alternatives )

update-alternatives の Java グループでどのJavaが選択されていても、
一様に /usr/bin/java を操作すれば問題無く任意の Java を実行することが出来ました。

# ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22  4月 25 02:04 /usr/bin/java -> /etc/alternatives/java

この /usr/bin/java が /etc/alternatives/java のシンボリックリンクであることが分かります。

では /etc/alternatives/java も見てみましょう。

# ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 30  8月  3 00:41 /etc/alternatives/java -> /usr/java/jdk1.5.0_19/bin/java

この /etc/alternatives/java が、
グループで選択されたプログラムの実体のシンボリックリンクになっていることが分かります。

つまり、update-alternatives は、
選択したプログラムのシンボリックリンクを作り替えてプログラムを切り替えているみたいですね。

プログラムを実行すると、

実行リンク —-> /etc/alternatives/グループ名 —-> プログラムパス

のようにプログラム本体を参照しているということになります。

ちなみに /etc/alternatives 以下を参照してみると、

# ls -l /etc/alternatives/
合計 80
lrwxrwxrwx 1 root root 19  4月 25 02:06 antlr -> /usr/bin/antlr-java
lrwxrwxrwx 1 root root 30  8月  3 00:41 java -> /usr/java/jdk1.5.0_19/bin/java
lrwxrwxrwx 1 root root 31  8月  3 00:41 javac -> /usr/java/jdk1.5.0_19/bin/javac
    ～後略～

スレーブで設定した javac もこちらで切り替えるためにシンボリックリンクになっているのが分かります。

この alternatives ディレクトリは、
--altdir オプションにより /etc/alternatives から別のディレクトリに変更することが出来ます。

管理ディレクトリ ( /var/lib/alternatives )

プログラムを切り替える仕組みは alternatives ディレクトリで確認出来ますが、
グループのモードやスレーブの関係などの情報は管理ディレクトリを見ることで確認することが出来ます。

例えば、Java グループの各情報は /var/lib/alternatives/java にテキストで格納されています。

この管理ファイルの細かいフォーマット形式はよく分かりませんが、
中身はテキストでそのままのことが書いてあるので何となくの情報は読み取れます。

この管理ディレクトリをよく見ると、
スレーブで設定されたグループ(本エントリでは javac)の情報ファイルは作成されていないようですね。

ちなみにこの 管理ディレクトリは、
--admindir オプションにより /var/lib/alternatives から別のディレクトリに変更することが出来ます。

共通オプション

管理プログラムの操作(アクション)について一通り説明しましたが、
ここでは全アクションに対応する共通オプションについて解説します。

--verbose 詳細な情報を表示します。
--quiet エラー以外の情報を表示しません。未実装
--test 指定した操作をテストします。実際には何も更新されません。未実装
--help update-alternatives に関する簡単な使用方法を表示します。
--altdir directory alternativesディレクトリ(デフォルト : /etc/alternatives(alternatives)を指定したディレクトリに変更します。
--admindir directory 管理ディレクトリ(デフォルト : /var/lib/alternatives)を指定したディレクトリに変更します。

まとめ

さて、ひたすら update-alternatives について説明してみましたがいかがだったでしょうか?

意外と簡単だけど案外知らない人も多い update-alternatives コマンド。
上手に使いこなせれば良い武器になると思います。

ここで、僕のもっぱらの使い方を紹介しましょう。

# update-alternatives --config 彼女
 
致命的なエラー : 何も登録されていません!!!

･･･････････orz

参考文献

おまけ – SUNのJDKをCentOS 5.3にインストールする

簡単に僕がSUNのJDKをインストールする手順を紹介します。

jdk1.6.0_14 のファイルのURIをSUNのサイトから拾ってきます。

# cd /usr/local/src
# wget http://cds.sun.com/ ～中略～ /FileName=/jdk-6u14-linux-x64-rpm.bin
名前が長いのでリネーム
# mv jdk-6u14-linux-x64-rpm.bin\ ～中略～ \jdk-6u14-linux-x64-rpm.bin jdk-6u14-linux-x64-rpm.bin
# chmod u+x jdk-6u14-linux-x64-rpm.bin
# ./jdk-6u14-linux-x64-rpm.bin

これで /usr/java に jdk1.6.0_14 がインストールされます。

環境変数を設定する場合は ~/.bash_profile に

export JAVA_HOME=/usr/java/default
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=.:$JAVA_HOME/jre/lib:$JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar

とでも記述しておくと良い感じです。

]]> http://blog.eni.co.jp/tech/2009/08/update-alternatives.html/feed 0 SeleniumRCで自己署名証明書使用のWEBアプリケーションをテストする際、セキュリティ警告を表示させない方法 http://blog.eni.co.jp/tech/2009/07/selenium_firefox_self_signed_ssl.html http://blog.eni.co.jp/tech/2009/07/selenium_firefox_self_signed_ssl.html#comments Thu, 23 Jul 2009 01:33:58 +0000 笹山 昭秀 http://blog.eni.co.jp/tech/?p=901 こんにちは。プロダクト&サービス事業部の笹山です。

前回のブログ(Seleniumの自動テストを止めることなく、Flexを手動操作する方法)で「FlashSeleniumについて調査をして、このブログに公開できたら・・・」などと書きましたが、全く調査できておりません。お詫び申し上げます。

前回のブログ執筆時後、SeleniumRCのバージョンも1.0.1に上がっていますし、FlashSeleniumもSeleniumRC1.0互換のものが出ているようです。
ですから、現時点では「あっさり動いてしまう？」のかもしれません。

今回もSeleniumRCネタではありますが「SeleniumRCで自己署名証明書使用のWEBアプリケーションをテストする際、Firefoxからのセキュリティ警告を表示させない方法」について書きたいと思います。

自己署名証明書使用のWEBアプリケーションをテストする際の問題

SSL対応のWEBアプリケーションのテストを行う際に、自己署名証明書を作成してテストすることは多いと思います。

SeleniumRCで自己署名証明書使用のWEBアプリケーションのテストを行うことはもちろん可能です。
しかし、面倒くさい操作が発生してしまうのです。

サーバに接続する際に、「信頼できない接続 – 接続の安全性を確認できません」と警告が出ます。

警告 - 信頼できない接続

警告 - 信頼できない接続

例外として追加しても毎回警告が表示され、そのたびに例外に追加する操作を行わなければいけません。
これでは、SeleniumRCを用いての自動テストの意味がありません。

問題の解決方法

これを解決する方法が分かりました。ただしFirefoxでのみです。
FirefoxでSeleniumServer用のProfileを作成し、SeleniumServer起動時にそのProfileを指定させれば良いのです。

それでは、まず最初にFirefoxでSeleniumServer用のProfileを作成する手順について説明します。

SeleniumServer用のProfile作成手順

  1. アクセサリ-ファイル名を指定して実行でFirefoxのProfileManagerを起動します
    ファイル名を指定して実行 - ProfileManager

    ファイル名を指定して実行 - ProfileManager

    firefox.exe -ProfileManager
  2. 「新しいプロファイルを作成」でSelenium用のプロファイルを作成します
    新しいプロファイルを作成

    新しいプロファイルを作成

  3. プロファイル作成ウィザードで順番に作成していきます
    ※安全のため保存先は、Selenium用のフォルダを作成し、そのフォルダを指定することをお勧めします
    プロファイル作成ウィザード

    プロファイル作成ウィザード

  4. Selenium用のプロファイル作成後、作成したプロファイルを指定して自己署名証明書使用のサイトにアクセスします
    「信頼できない接続 – 接続の安全性を確認できません」と警告が出ます
    警告 - 信頼できない接続

    警告 - 信頼できない接続

  5. 自己署名証明書使用のサイトを例外として追加し、セキュリティ例外を承認します
    例外として追加

    例外として追加

    セキュリティ例外を承認

    セキュリティ例外を承認

後にも先にも、Firefoxで自己署名証明書使用のサイトを例外として追加する操作はこの1回だけです。

次に、SeleniumServerへProfileを指定する方法を説明します。

JUnitテストソースでSeleniumServer起動時にProfileを指定させるコード

使用するProfileを指定して、SeleniumServerを起動するコードです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 自己署名証明書使用のURL
testUrl = "https://localhost:8443";
 
// テストを行うブラウザ
testBrowser = "*firefox";
 
// SeleniumServerのインスタンス化
seleniumServer = new SeleniumServer();
 
// Selenium用プロファイルの指定 --------- ここから -------------
RemoteControlConfiguration config = seleniumServer.getConfiguration();
config.setFirefoxProfileTemplate(new File("D:\\firefox_selenium"));
// Selenium用プロファイルの指定 --------- ここまで -------------
 
// SeleniumServerの起動
seleniumServer.start();
 
// seleniumClientを起動
selenium = new DefaultSelenium("localhost", 4444, testBrowser, testUrl);
selenium.start();

selenium-server.jarファイル実行時にProfileを指定させる方法

上記のJUnitのテストケースではなく、別途SeleniumServerを起動してテストを行う場合は、以下のコマンドを実行してください。

java -jar selenium-server.jar -firefoxProfileTemplate d:\\selenium-firefox

最後に

これで通常通りSeleniumRCで自動テストを実行すると、わずらわしい警告は出なくなるはずです。

Firefoxのみの対処方法でしたが、IEやその他ブラウザでの解決方法はまだ分かっていません。
調査を続行していこうと思っています。（FlashSeleniumの調査も忘れずに！）

あわせて読みたい

Seleniumの自動テストを止めることなく、Flexを手動操作する方法

]]> http://blog.eni.co.jp/tech/2009/07/selenium_firefox_self_signed_ssl.html/feed 2 Solr/SolrJ1.3のCoreAdmin(マルチコア)機能を用いて動的にCoreを追加する方法(SolrJのバグの対処方法) http://blog.eni.co.jp/tech/2009/07/apache_solr_13_coreadmin_multicore_solved.html http://blog.eni.co.jp/tech/2009/07/apache_solr_13_coreadmin_multicore_solved.html#comments Wed, 15 Jul 2009 06:38:05 +0000 kubo@eni.co.jp http://blog.eni.co.jp/tech/?p=863 こんにちは。
株式会社イージーネット プロダクト&サービス事業部 の久保です。

前回書いたSolrの記事 全文検索サーバ: これからSolrを始める人のためのApache Solr概要と便利なリンク集 はおかげさまで沢山のアクセス/ブックマークをいただきました。
来週火曜日の7/21には、Lucene/Solrで有名なロンウイットの関口さん(参考: 関口宏司のLuceneブログ)などが参加されるSolr勉強会も開催されるようですので、Solr人気は高まっているのかもしれません。

今回は前回から変わって小さなネタになりますが、
Solr/SolrJ1.3のCoreAdmin(マルチコア)機能を用いて動的にCoreを追加する際にはまるSolrJのバグと、その対処方法について書きます。

Solr1.3のマルチコア機能とは

単純に言うと、1つのSolrアプリケーション(サーブレットアプリケーション)の上で、論理的に複数のSolrアプリケーションを動かすことができる機能です。
詳しくは前回の記事の「マルチコア構成」をご覧ください。

Coreを追加するためのURL(Query String)

Coreを追加するのに必要なURL(Query String)は次のようになります。
(参考URL: Solr Wiki – CoreAdmin)

http://server/solr/admin/cores?action=CREATE&name=[name]&instanceDir=[dir]&config=[solrconfig]&schema=[schema]

(例)

http://testserver:8080/solr/admin/cores?action=CREATE&name=test&instanceDir=test&config=/solr/conf/solrconfig.xml&schema=/solr/conf/schema.xml
[name] coreに付ける名前(例: test)
[dir] coreのディレクトリ名(例: test)
[solrconfig] solrconfig.xmlファイルのパス(例: /solr/conf/solrconfig.xml)
[schema] schema.xmlファイル(例: /solr/conf/schema.xml)

SolrJを使った場合の問題

SolrJのver1.3において、SolrCoreAdminRequestのcreateCoreメソッドを使った以下のコードは失敗します。

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
32
33
34

package jp.co.eni.solr.test;
 
import java.io.IOException;
import java.net.MalformedURLException;
 
import org.apache.solr.client.solrj.SolrServer;
import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.impl.CommonsHttpSolrServer;
import org.apache.solr.client.solrj.request.CoreAdminRequest;
import org.apache.solr.client.solrj.response.CoreAdminResponse;
 
//失敗する
public class FailedCoreCreateTest {
	public static void main(String[] args) {
		try {
			// SolrのURL
			String url = "http://server/solr/";
			// coreの名前
			String coreName = "failed";
			// coreのディレクトリ名
			String instanceDir = "failed";
 
			SolrServer server = new CommonsHttpSolrServer(url);
			CoreAdminResponse response = CoreAdminRequest.createCore(coreName, instanceDir, server);
			System.out.println("qtime: " + response.getQTime());
		} catch (MalformedURLException e) {
			e.printStackTrace();
		} catch (SolrServerException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

失敗の原因は、上記コードにより生成されるHTTP RequestのQuery Stringにあります。
エラーのログを見ると、

Exception in thread "main" org.apache.solr.common.SolrException: Internal Server Error
 
Internal Server Error
 
request: http://server/solr/admin/cores?action=CREATE&core=failed&instanceDir=failed&wt=javabin&version=2.2
	at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:343)
	at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183)
	at org.apache.solr.client.solrj.request.CoreAdminRequest.process(CoreAdminRequest.java:170)
	at org.apache.solr.client.solrj.request.CoreAdminRequest.createCore(CoreAdminRequest.java:226)
	at jp.co.eni.solr.test.FailedCoreCreateTest.main(FailedCoreCreateTest.java:23)

とあるように、 

name=failed

ではなく 

core=failed

となっていることが分かります。
これは、SolrJ1.3のorg.apache.solr.client.solrj.request.CoreAdminRequest.Create#getParames(rev:688188)が以下のような実装になっているためです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

    @Override
    public SolrParams getParams() {
      if( action == null ) {
        throw new RuntimeException( "no action specified!" );
      }
      ModifiableSolrParams params = new ModifiableSolrParams();
      params.set( CoreAdminParams.ACTION, action.toString() );
      params.set( CoreAdminParams.CORE, core );                      //←※ここがおかしい
      params.set( CoreAdminParams.INSTANCE_DIR, instanceDir);
      if (configName != null) {
        params.set( CoreAdminParams.CONFIG, configName);
      }
      if (schemaName != null) {
        params.set( CoreAdminParams.SCHEMA, schemaName);
      }
      return params;
    }

簡単な解決策

以下のようなCoreAdminRequest.Createの拡張クラスを用意することで、上記の問題を解決することができます。

用意するクラス

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
32
33
34
35
36
37
38

package jp.co.eni.solr.test;
 
import org.apache.solr.client.solrj.request.CoreAdminRequest.Create;
import org.apache.solr.common.params.CoreAdminParams;
import org.apache.solr.common.params.ModifiableSolrParams;
import org.apache.solr.common.params.SolrParams;
 
public class SolvedCreate extends Create {
	/**
	 * コンストラクタ
	 *
	 * @param coreName
	 * @param instanceDir
	 * @param configName
	 * @param schemaName
	 */
	public SolvedCreate(String coreName, String instanceDir, String configName, String schemaName) {
		super();
		// coreの名前
		setCoreName(coreName);
		// coreのディレクトリ名
		setInstanceDir(instanceDir);
		// solrconfig.xmlのパス
		setConfigName(configName);
		// schema.xmlのパス
		setSchemaName(schemaName);
	}
 
	@Override
	public SolrParams getParams() {
		ModifiableSolrParams params = (ModifiableSolrParams) super.getParams();
		// coreではなくnameを使う
		params.set(CoreAdminParams.CORE, (String) null);
		params.set(CoreAdminParams.NAME, core);
 
		return params;
	}
}

getParamsメソッドは、org.apache.solr.client.solrj.impl.CommonsHttpSolrServer#requestの中で呼ばれます。

CoreAdminParams.COREやCoreAdminParams.NAMEを持つorg.apache.solr.common.params.CoreAdminParamsというのは以下のようなインタフェースになっており、
COREではなくNAMEを用いるのが正しそうだということになります。

1
2
3
4
5
6
7
8
9
10
11
12

public interface CoreAdminParams 
{
  /** What Core are we talking about **/
  public final static String CORE = "core";
 
  /** Persistent -- should it save the cores state? **/
  public final static String PERSISTENT = "persistent";
 
  /** If you rename something, what is the new name **/
  public final static String NAME = "name";
 
  // 後略

SolvedCreate利用コード

上記のSolvedCreateクラスを利用したコードは次のようになります。

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
32
33
34
35
36
37
38
39

package jp.co.eni.solr.test;
 
import java.io.IOException;
import java.net.MalformedURLException;
 
import org.apache.solr.client.solrj.SolrServer;
import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.impl.CommonsHttpSolrServer;
import org.apache.solr.client.solrj.response.CoreAdminResponse;
 
// 成功する
public class SuccessCoreCreateTest {
	public static void main(String[] args) {
		try {
			// SolrのURL
			String url = "http://server/solr/";
			// coreの名前
			String coreName = "name2";
			// coreのディレクトリ名
			String instanceDir = "dir2";
			// solrconfig.xmlのパス
			String configName = "/solr/conf/solrconfig.xml";
			// schema.xmlのパス
			String schemaName = "/solr/conf/schema.xml";
 
			// Createクラスのバグ対応のため、SolvedCreateクラスを作成して使っている
			SolvedCreate createRequest = new SolvedCreate(coreName, instanceDir, configName, schemaName);
			SolrServer server = new CommonsHttpSolrServer(url);
			CoreAdminResponse response = createRequest.process(server);
			System.out.println("qtime: " + response.getQTime());
		} catch (MalformedURLException e) {
			e.printStackTrace();
		} catch (SolrServerException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

1.4では修正される模様

この問題は、Apacheプロジェクトのバグトラックにも登録されています。
SOLR-803: CoreAdminRequest.createCore fails because name parameter isn’t setを見ると、StatusはResolveとなっています。
Solrのレポジトリを直接確認してみたところ、上記の問題はrev.708266の修正で解決されているようです。

SOLR-803: fix CoreAdminRequest.createCore error

コードは確認していませんが、ちゃんとした？修正がされていそうです。

またpache Solr Version 1.4-dev Release Notesを見ると、SOLR-803も含まれていますので、1.4のリリース時にはこのエントリで取り上げた問題は発生しなくなるはずです。

参考URL

使用したソフトウェア

ソフトウェア バージョン
Solr 1.3
SolrJ 1.3

あわせて読みたい

]]> http://blog.eni.co.jp/tech/2009/07/apache_solr_13_coreadmin_multicore_solved.html/feed 1 CentOS5.2でWEBアプリケーション開発環境を作るまでの注意点 http://blog.eni.co.jp/tech/2009/06/centos_webapplication_using.html http://blog.eni.co.jp/tech/2009/06/centos_webapplication_using.html#comments Mon, 15 Jun 2009 12:00:27 +0000 中村 浩也 http://blog.eni.co.jp/tech/?p=634 初めまして。プロダクト＆サービス事業部新人の中村です。

私はイージーネットに入社して半年程でまだまだ新人なのですが、
そのせいもありLinux上でWEBアプリケーションを開発する環境を整えるまでに意外と時間がかかりました。
私の場合OSはCentOS5.2を使用していたのですが、CentOS5.2は特にEclipseを起動し動的WEBプロジェクトを動作させるまでで、注意すべき点が多いような気がします。

そこで今回は同じように悩んでる方がいるのではないのかと思い、
CentOS5.2上でEclipseを用いてWEBアプリケーション開発環境を構築するまでの手順についてお伝えしたいと思います。

使用したimageは”CentOS-5.2-i386-bin-DVD.iso”で、デスクトップはGNOMEを採択しています。
なお今回の記事ではOS自体のインストール方法は割愛させて頂きます。

手順

手順一覧

手順は大きく以下の流れになります。

  1. Firefoxパッケージをアップデートする
  2. java1.5以上を導入する
  3. Eclipseをインストールする
  4. tomcatをインストールする
  5. 動作を確認する

1. Firefoxパッケージをアップデートする

package

CentOSではpackage updaterというものがあり、アップデートが可能なパッケージについて知らせてくれます。
あまり知られていない問題かも知れませんが、Firefoxのバージョンが原因でEclipseが正しく起動しない場合があります。
package updaterからFirefoxのアップデートを行うことで正しく起動するようになることを確認していますので、まずはFirefoxのアップデートを行いましょう。

以下、詳細解説を行います。
“CentOS-5.2-i386-bin-DVD.iso”のイメージには”firefox-3.0-0.beta5.6.el5.centos.i386.rpm”が含まれているのですが、
そのバージョンでEclipseを起動しようとした際以下のようなメッセージが出力されました。
(使用したEclipseは、eclipse-jee-ganymede-SR2-linux-gtk.tar.gzになります。)

  org.eclipse.swt.SWTError: XPCOM error -2147467262
          at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1638)
          (以下略)

“XPCOM error”といったキーワードで検索してみると、3.0b5以外のFirefoxのバージョンによっても同じエラーが起きている人がいることがわかります。

（Eclipse bugレポート記事）
https://bugs.eclipse.org/bugs/show_bug.cgi?id=103620

2. java1.5以上を導入する

Eclipseの動作条件はjavaのバージョンが1.5以上です。
CentOS5.2ではデフォルトでインストールされているjavaの種類とバージョンはそれぞれgij(GNU libgcj) の1.4.2でした。
従って、CentOS5.2を使用する際は、1.5以上のjavaをインストールすることを忘れないようにしなければなりません。

javaのバージョンを確かめる方法は以下になります。

[root@hiroyapc /]# java -version
java version "1.4.2"
gij (GNU libgcj) version 4.1.2 20080704 (Red Hat 4.1.2-44)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1.5以上のjavaのインストール方法ですが、yumでインストールする方法と、sunのダウンロードページからダウンロードしてくる方法があります。
yumでインストールする場合ですが、2009/06/15現在Openjdkがインストールされることになります。

[root@hiroyapc /]# yum install java-1.6.0 java-1.6.0-devel

OpenJDKは、少し前までは目にすることはなかったのですが、最近多くのディストリビューションで標準で取りいれられているらしく目にすることが多くなってきました。
何でもSunがリリースしている純正のJDK6が派生したものだそうです。
それぞれの違いについて詳しく言及している記事が以下にありますので、参考にして下さい。

http://www.infoq.com/jp/news/2009/01/jdk-openjdk-icedtea

javaをyumでインストールした際も直接ダウンロードした場合も、”/etc/alternatives/java”が新しいバージョンのjavaを向いていることを確認します。

[root@hiroyapc /]# update-alternatives --config java

2 プログラムがあり 'java' を提供します。

  選択　　　　コマンド
------------------------------------------------
 + 1        /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*  2        /usr/lib/jvm/jre-1.6.0-openjdk/bin/java

Enter を押して現在の選択[+]を保持するか、選択番号を入力します:

上記のように表示されていた場合、1.4.2が選択されています。
2番を選択し、1.6.0が選択されるようにします。

バージョンを確認するコマンドを叩き、上記のようになっていれば1.6.0を向いていることがわかります。

[root@hiroyapc /]# java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK Client VM (build 1.6.0-b09, mixed mode)

3. Eclipseをインストールする

次に、Eclipse本体をダウンロードします。
Eclipseは統合開発環境ツールの1つであり、webアプリケーション等の開発を行うにあたって大変便利なツールです。
Eclipseのサイトのダウンロードページからtar.gzファイルをダウンロードして使用します。

Java向けのEclipseを使用しようとした際、Eclipse IDE for Java EE Developers とEclipse IDE for Java Developersがダウンロード出来ることがわかるかと思いますが、それぞれの違いについてはCompare Packagesに分かりやすい表が記載してあります。

表を見ての通りなのですが、Java EE DevelopersはJava Developersに加えてWeb ToolsやJEE Tools等のパッケージが同梱されています。
パッケージ内容については詳しい内容の説明は省略いたしますが、今回はWebアプリケーション開発環境構築を目的としているのでEclipse IDE for Java EE Developers をダウンロードします。

ちなみに私がダウンロードしたファイルはeclipse-jee-ganymede-SR2-linux-gtk.tar.gzです。
ダウンロードしたらファイルを任意の場所(/usr/local/bin等)に展開します。

4. tomcatをインストールする

tomcatをインストールする方法について、CentOSでは主に2種類があります。

1つはyumを使用してインストールする方法。

[root@hiroyapc /]# yum install tomcat5

もう1つはApache Tomcatのサイトよりtar.gzファイルを直接ダウンロードし、インストールする方法です。
どちらもメリット・デメリットがあるのですが、今回はtar.gzファイルをダウンロードして使用することにします。

tomcat

sourceとbinaryどちらをダウンロードすれば良いのかについて簡単に補足します。プログラムはsourceで書かれ、binaryに変換されて最終的に実行されます。
ここではtomcatを実行することが目的であることから、binaryをダウンロードします。

次にCoreとDeployerについてですが、DeployerはCoreに加えて、
作成したweb アプリケーションの検証、コンパイル、WARファイルへの圧縮、Tomcatサーバに配備をするためのパッケージです。
作成したデータを公開サーバに配備する必要がある場合等はDeployerが必要になりますが、今回はまずは環境を構築するところまでを目的としているのでCoreファイルをダウンロードすることにします。

ダウンロードしたらファイルを任意の場所(/usr/share/等)に展開します。

5. 動作を確認する

正しく起動したならば、Eclipseを立ち上げて動作をすることを確認して下さい。
Tomcatが起動するところまでを確認したいので、動的webページを作成し、JSPまたはServletを作成します。
なお、EclipseでのTomcatの設定や詳しい動的webページ作成方法については既に多くのwebページや書籍で詳しく紹介されていることから割愛します。
Target Runtimeで指定するtomcatのバージョンやtomcatを展開した場所の指定を間違わないこと等に注意して設定して下さい。
tomcatが正しく動作して、実行結果が返ってきたでしょうか。

Eclipse起動エラーが起こってしまったら？

上記の手順を参考にしてもEclipseを起動する際にエラーが起こった際、どうすれば良いのでしょうか。
Eclipseは起動時にログを吐き出してくれています。出力されるログの場所は、例えばプロジェクトを”/root/workspace”に作成しようとした際以下になります。

  /root/workspace/.metadata/.log

焦らずエラーメッセージの内容を検索サイトで検索してみることで、対処法が見つかるかもしれません。

最後に

2009年06月15日現在ではCentOS5.3が既にリリースされており、本記事で取り上げた問題は既に解決されています。
ですのでCentOS5.3でWEBアプリケーションを開発する環境を整えるまでに手間はあまりかからないかと思います。

CentOS5.2を今から使用しようとする方は少ないかもしれませんが、この記事の内容が読んで下さった皆さんの参考になれば幸いです。

それではまた！

リンク集

OpenJDK

・サン、Javaをオープンソース化–Java SE向けJDKをOpenJDKで公開
http://japan.cnet.com/news/ent/story/0,2000056022,20348500,00.htm
・Sun社のJDK7、OpenJDK、そしてIcedTea：曖昧さの回避
http://www.infoq.com/jp/news/2009/01/jdk-openjdk-icedtea

Apache Tomcat

・Apache Tomcat 本家サイト
http://tomcat.apache.org/

Eclipse

・Eclipse.org 本家サイト
http://www.eclipse.org/
・エクリプス
http://eclipsewiki.net/eclipse/index.php?FrontPage
・Eclipse XPCOM errorについて
https://bugs.eclipse.org/bugs/show_bug.cgi?id=103620

CentOS

・CentOS 本家サイト
http://www.centos.org/

]]> http://blog.eni.co.jp/tech/2009/06/centos_webapplication_using.html/feed 0 JSFでAjaxを使いたい – OpenFacesの紹介 - http://blog.eni.co.jp/tech/2009/06/jsf_ajax_openfaces.html http://blog.eni.co.jp/tech/2009/06/jsf_ajax_openfaces.html#comments Wed, 10 Jun 2009 06:41:50 +0000 武輪 恭代 http://blog.eni.co.jp/tech/?p=631 はじめまして。
プロダクト&サービス事業部の武輪です。

Ajaxと言えば、JavaScriptをごりごり書かないと！ってイメージがあるのですが、JavaScriptを少し書くだけ、もしくはまったく書かずに、コンポーネント側で勝手にやってくれれば簡単ですよね。
Ajaxを用いたJSFコンポーネントやフレームワークって他にも、RichFacesやらajax4jsfやらICEfacesやらがあるのですけども、今回私は、OpenFacesというJSFコンポーネントを紹介したいと思います。

OpenFacesは2009年5月末に出てきたばかりのAjaxを用いたJSFコンポーネントです。
サイトからはfaceletsで実装されたサンプルとJSPで実装されたサンプルをダウンロードすることができます。

早速、faceletsで実装されたサンプルを動かしてみました。

どんな機能があるの？

サンプルにはたくさんの魅力的なデモが含まれていたのですが、そのうちのいくつかを紹介したいと思います。

カレンダー

デフォルトのカレンダー

よくこんなカレンダーありますよね。

1

<o:calendar/>

xhtmlファイルにはたったこれだけで画面にカレンダーがぽんと表示されちゃいます。
また、下のようにスタイルを細かく指定することもできます。

1
2
3
4
5
6
7
8
9
10
11

<o:calendar style="border: 1px solid white;"
            headerStyle="background: #fff;"
            rolloverDayStyle="background: #fff; border: 1px solid #8eb5d4; color: black;"
            rolloverWeekendDayStyle="background: #f9f6f1; border: 1px solid #f3922b; color: black;"
            selectedDayStyle="background: #8eb5d4;"
            todayStyle="color: #ff8a01; font-weight: bold; background: #fff;"
            footerStyle="border-top: 1px solid #505050; background: #fff;"
            daysHeaderStyle="background: #505050; color: white;"
            inactiveMonthDayStyle="color: #b4b4b4; background: #fff;"
            dayStyle="color: #505050;  background: #fff; border: 1px solid #f9f9f9;"
            weekendDayStyle="color: #000000;  background: #fff;"/>

これが画面に表示されるとこんな感じ。
カレンダー

ちなみにデモではすべて～～Styleでcssを直接指定していましたが、～～Classというアトリビュートでcssのクラスを指定することもできます。
JAVA側の実装もシンプルな感じ。
CalendarBean.javaとLocaleItem.javaの2クラスだけでした。

グラフ

グラフ
OpenFacesでは、JFreeChartというライブラリーを利用してグラフを生成できます。
円グラフ、横棒グラフ、縦棒グラフ、折れ線グラフの4種類が用意されています。

円グラフの記述例は↓こんな感じ。

1
2
3
4
5
6
7
8
9

<o:chart id="yearPrecipitationChart"
        model="#{CityPrecipitation}"
        width="320"
        height="275"
        legendVisible="false">
<o:pieChartView colors="#5a87be, #94c237, #fff555, #da6a28" labelsVisible="true"/>
<o:chartTitle text="Amount of Precipitation During the Year"
                style="font-size: 14px;"/>
</o:chart>

BackingBeanは、それぞれのグラフ用にChartModelというインターフェースを実装したmodelをもっています。
そのmodelを元にグラフが描画されるみたい。

データテーブル

Data Table
データリストの一覧表示には以下の機能が備わっています。

  • 検索
  • ソート
  • ページング
  • 選択・・・1行選択したり複数行選択したり。
  • カラムのリサイズ
  • キーボード操作・・・方向キーで選択行を変更したり、Shiftキー＋方向キーで複数行選択したり。

他にもいろいろ面白そうな機能があります

ウィンドウの表示とか。
ポップアップメニュー(右クリックでメニュー表示)とか。
ツリー状メニューの表示とか。
カレンダーからの日付選択とか。

たくさんの面白そうな機能がついているので、ぜひ実際に動く様子を見てみてください。(→OpenFaces Live Demo)

ところでライセンスは？

OpenFacesが採用しているライセンスは、dual license modelです。

dual licenseって何よ？って話なんですけども、簡単に言うと、開発したアプリケーションのライセンスをLGPLにするなら無償、そうでないならOpenFacesの商用ライセンスを購入してねってことみたいです。

]]> http://blog.eni.co.jp/tech/2009/06/jsf_ajax_openfaces.html/feed 0 Seleniumの自動テストを止めることなく、Flexを手動操作する方法 http://blog.eni.co.jp/tech/2009/05/selenium_wait.html http://blog.eni.co.jp/tech/2009/05/selenium_wait.html#comments Fri, 29 May 2009 08:17:50 +0000 笹山 昭秀 http://blog.eni.co.jp/tech/?p=478 バリデーションエラーが画面上に表示されている間は、指定時間待機させます。（以下コード参照） 待機中にFlex操作を手動で行い、バリデーションエラーが画面上から消えると、再び自動テストが始まります。 Selenium実行途中でWaitをかけるコード 1 2 3 4 5 6 7 8 9 new Wait() { public boolean until() { if(!selenium.isTextPresent("送信先が選択されていません。1つ以上選択してください。")) { return true; } else { [...]]]> はじめまして。

プロダクト&サービス事業部の笹山です。

今回は、SeleniumRCを用いてWebアプリケーションのテスト中に、Flex部分のみを手動操作し、
その後再び自動テストを継続させる方法について書きたいと思います。

有名なツールなのでみなさんご存知と思いますが、まずSeleniumRCとは、
「Webブラウザの操作を自動化させ、Webアプリケーションの画面表示や画面遷移のテストを行うツール」で
Webアプリケーションのテストには欠かせないツールです。

今回弊社では、easyFiLEXのテストをSeleniumRCを用いて行うことになりました。

easyFiLEXテストでSeleniumRCを使用する際の問題

弊社Tech Blog(05/18)記事にもあるように、easyFiLEXではFlexを採用しています。
easyFiLEXには、Wizard形式の画面があり、その一部画面にFlexが採用されています。

しかし、SeleniumRCは一般的なWebアプリケーションのテストを行うツールで、Flexには対応していません。
そのため、Flexが採用されているWizard形式の１画面がクリアできず、次の画面のテストができないのです。

ここをどう解決するか非常に悩みました。

FlashSelenium発見と挫折

まずは、Google先生に聞いてみました。

すると以下のサイトが検索に引っ掛かりました。

FlashSeleniumというSeleniumRCとFlexを連携させるツールです。

「これで解決！（Flex部分のテストも自動化できる！）」と思いました。
意気揚揚と公開されているサンプルを動かしはじめましたが、サンプルすら動きませんでした。（動いた方は教えてください。）

解決方法の発見

途方に暮れselenium-client-driverのJavaDocを眺めていた時、ふと目に入った文字が・・・。

com.thoughtworks.selenium.Wait

便利なクラスがselenium-client-driverに用意されていました。

「条件がtrueになるまで、指定時間待つ」というものです。
easyFiLEXのテストでは以下の手順で使用しました。

手順内の画面は、

Flexが採用されているWizard形式の１画面で、「ファイルのアップロード後、送信先を指定する画面」です。
送信先を指定しない限り、次の画面へ進むことができないようになっています。
  1. Flexが採用されている画面までは、SeleniumRCを用いてWizard形式画面の自動テストを行います。
  2. Flexが採用されている画面に遷移後、SeleniumRCで送信先を指定せずに「次へ」ボタンを押下させ、バリデーションエラーを発生させます。
    バリデーションエラー：「送信先が選択されていません。1つ以上選択してください。」

    easyFiLEX送信先設定画面におけるバリデーションエラー

    easyFiLEX送信先設定画面におけるバリデーションエラー発生時の画面

  3. バリデーションエラーが画面上に表示されている間は、指定時間待機させます。（以下コード参照）
  4. 待機中にFlex操作を手動で行い、バリデーションエラーが画面上から消えると、再び自動テストが始まります。

Selenium実行途中でWaitをかけるコード

1
2
3
4
5
6
7
8
9

new Wait() {
    public boolean until() {
        if(!selenium.isTextPresent("送信先が選択されていません。1つ以上選択してください。")) {
            return true;
        } else {
            return false;
        }
    }
}.wait("タイムアウト", 60000);

最後に

Flex部分だけは手動操作になってしまいますが、それ以降はスムーズに自動テストできるので現時点ではこの方法でテストを行っています。

時間の都合上、FlashSeleniumについて深く調査はしていませんが、調査をして「このブログに公開できたら・・・」と思っています。

公式サイト

Quick Lookup:

あわせて読みたい

SeleniumRCで自己署名証明書使用のWEBアプリケーションをテストする際、セキュリティ警告を表示させない方法

]]> http://blog.eni.co.jp/tech/2009/05/selenium_wait.html/feed 2