Webアプリケーションを作成する場合、データベースのテーブルに対応するエンティティクラスを作るのが一般的である。
エンティティクラスは、データベーステーブルの各属性のsetter/getterを持つクラスである。
データベーステーブルのレコード1件分を格納するために用いる。
例えば次のようなデータベーステーブルがあったとする。
CREATE TABLE SAMPLE(
SAMPLE_ID INT AUTO_INCREMENT,
SAMPLE_STRING VARCHAR(256),
PRIMARY KEY(SAMPLE_ID)
);
このテーブルに対応するエンティティクラスは、次のようになる。
public class Sample implements Entity {
private Integer sampleId;
public Integer getSampleId() {
return sampleId;
}
public void setSampleId(Integer sampleId) {
this.sampleId = sampleId;
}
private String sampleString;
public String getSampleString() {
return sampleString;
}
public void setSampleString(String sampleString) {
this.sampleString = sampleString;
}
}
データベースの型を見ると、SAMPLE_IDがINT、SAMPLE_STRINGがVARCHARとなっている。
Javaの場合、IntegerとStringが対応するクラスとなるため、エンティティはIntegerとStringで作る。
（ただし桁数が多い場合など、個別に対応する型を考慮する必要が出てくる場合もある）
記述は必ずキャメル記法とする。（最初の1単語は全て小文字、次の単語以降は先頭1文字のみ大文字）
これはJSPでEL式を使う場合に、重要となる命名規則である。
規則通りに書いておかないと、EL式で変数を認識できなくなる。
DAOクラスでSELECTを実行する場合、取得したデータはエンティティクラスに格納する。
これによりDBから取得したデータをどこに格納するのかが明確となり、コードのメンテナンス性が上がる。
サンプルでEntityというインターフェースをimplementsしているが、これは別途記述するロウマッパーなどの仕組みを使う際に必要となる。
当該クラスがEntityであることを示すためのマーカーインタフェースが必要な場合は、空のインターフェースを作成して、エンティティクラスでimplementsの記述を行う。
2011年10月19日水曜日
[Servlet][JSP][DAO]JDBCについて（可変引数のあるSELECT）
可変要素のあるSELECTを実行するサンプルは、次の通り。
// 可変要素のあるSELECTの実行
public void executePreparedSelect(int searchId) throws ClassNotFoundException,
SQLException {
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
// JDBCドライバをクラス名で探し、初期化を行う
Class.forName("com.mysql.jdbc.Driver");
// コネクションを取得する
conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/SAMPLE", "sampleuser",
"samplepassword");
// プリペアドステートメントを作成する
String sql = "SELECT ID, STR FROM SAMPLE_TABLE WHERE ID = ?";
ps = conn.prepareStatement(sql);
ps.setInt(1, searchId);
// SQLを実行し、リザルトセットを得る
rs = ps.executeQuery();
// テーブルにintのID、varcharの文字列がある場合、次のように取得できる
while (rs.next()) {
Integer id = rs.getInt(1);
String str = rs.getString(2);
System.out.println("ID : " + id);
System.out.println("STR : " + str);
}
} finally {
// 後始末をする
if (conn != null) {
conn.close();
}
if (ps != null) {
ps.close();
}
if (rs != null) {
rs.close();
}
}
}
SELECTの可変要素とは、次のSQLの?の部分のことを指す。
"SELECT ID, STR FROM SAMPLE_TABLE WHERE ID = ?"
Javaプログラム（例えば画面入力項目）を?の箇所に当てはめてSQLを実行する場合、本サンプルのようなプログラム記述となる。
1番目の?に引数のsearchIdを設定しているコードは、次の箇所である。
ps.setInt(1, searchId);
文字列を設定する場合はsetStringとなる。
?が2つ以上になる場合は、1、2、3とsetXXXの第1引数を増やしていく。
// 可変要素のあるSELECTの実行
public void executePreparedSelect(int searchId) throws ClassNotFoundException,
SQLException {
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
// JDBCドライバをクラス名で探し、初期化を行う
Class.forName("com.mysql.jdbc.Driver");
// コネクションを取得する
conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/SAMPLE", "sampleuser",
"samplepassword");
// プリペアドステートメントを作成する
String sql = "SELECT ID, STR FROM SAMPLE_TABLE WHERE ID = ?";
ps = conn.prepareStatement(sql);
ps.setInt(1, searchId);
// SQLを実行し、リザルトセットを得る
rs = ps.executeQuery();
// テーブルにintのID、varcharの文字列がある場合、次のように取得できる
while (rs.next()) {
Integer id = rs.getInt(1);
String str = rs.getString(2);
System.out.println("ID : " + id);
System.out.println("STR : " + str);
}
} finally {
// 後始末をする
if (conn != null) {
conn.close();
}
if (ps != null) {
ps.close();
}
if (rs != null) {
rs.close();
}
}
}
SELECTの可変要素とは、次のSQLの?の部分のことを指す。
"SELECT ID, STR FROM SAMPLE_TABLE WHERE ID = ?"
Javaプログラム（例えば画面入力項目）を?の箇所に当てはめてSQLを実行する場合、本サンプルのようなプログラム記述となる。
1番目の?に引数のsearchIdを設定しているコードは、次の箇所である。
ps.setInt(1, searchId);
文字列を設定する場合はsetStringとなる。
?が2つ以上になる場合は、1、2、3とsetXXXの第1引数を増やしていく。
[Servlet][JSP][DAO]JDBCについて（可変引数のないSELECT）
DAOクラスでJDBCによるアクセスを行う場合は、まずJDBCドライバをクラスパスに配置する。
MySQLならばWebサイトに行ってjarをダウンロードしてくると、JDBCを使えるようになる。
eclipseで開発しているなら、WEB-INF/lib配下にJDBCのjarを置き、ビルドパスに追加する。
DBにアクセスするコードは、次のようになる。
// SELECTの実行
public void executeSelect() throws ClassNotFoundException, SQLException {
Connection conn = null;
Statement s = null;
ResultSet rs = null;
try {
// JDBCドライバをクラス名で探し、初期化を行う
Class.forName("com.mysql.jdbc.Driver");
// コネクションを取得する
conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/SAMPLE",
"sampleuser", "samplepassword");
// ステートメントを作成する
s = conn.createStatement();
// SQLを実行し、リザルトセットを得る
rs = s.executeQuery("SELECT * FROM SAMPLE_TABLE");
// テーブルにintのID、varcharの文字列がある場合、次のように取得できる
while (rs.next()) {
Integer id = rs.getInt(1);
String str = rs.getString(2);
System.out.println("ID : " + id);
System.out.println("STR : " + str);
}
} finally {
// 後始末をする
if (conn != null) {
conn.close();
}
if (s != null) {
s.close();
}
if (rs != null) {
rs.close();
}
}
}
MySQLならばWebサイトに行ってjarをダウンロードしてくると、JDBCを使えるようになる。
eclipseで開発しているなら、WEB-INF/lib配下にJDBCのjarを置き、ビルドパスに追加する。
DBにアクセスするコードは、次のようになる。
// SELECTの実行
public void executeSelect() throws ClassNotFoundException, SQLException {
Connection conn = null;
Statement s = null;
ResultSet rs = null;
try {
// JDBCドライバをクラス名で探し、初期化を行う
Class.forName("com.mysql.jdbc.Driver");
// コネクションを取得する
conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/SAMPLE",
"sampleuser", "samplepassword");
// ステートメントを作成する
s = conn.createStatement();
// SQLを実行し、リザルトセットを得る
rs = s.executeQuery("SELECT * FROM SAMPLE_TABLE");
// テーブルにintのID、varcharの文字列がある場合、次のように取得できる
while (rs.next()) {
Integer id = rs.getInt(1);
String str = rs.getString(2);
System.out.println("ID : " + id);
System.out.println("STR : " + str);
}
} finally {
// 後始末をする
if (conn != null) {
conn.close();
}
if (s != null) {
s.close();
}
if (rs != null) {
rs.close();
}
}
}
[Servlet][JSP][DAO][Seasar2]DAOクラスについて
サーブレットやフレームワークを使った開発でDAOパターンを採用する場合、DAOは必ずインターフェースとする。
これはモックへの差し替えを行うためである。
DIと組み合わせることによって、設定ファイルのみでモックによるテストを行ったり、本物の実装を動かせるようにする。
<<interface>>XxxDao
△
│
XxxDaoImpl
（↑）実装は上記のようなクラス構成となる。
モックを使う場合は、XxxDaoImplクラスのモックを別パッケージに用意し、DI設定を変える。
例えばSeasar2で、通常のDAO設定が次のようなものだとする。
<component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister">
<initMethod name="addClassPattern">
<arg>"jp.co.sample.dao"</arg>
<arg>".*DaoImpl"</arg>
</initMethod>
</component>
モックの場合は、次のように設定が変わる。（パッケージが"jp.co.sample.dao"から"jp.co.sample.dao.mock"になっている）
<component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister">
<initMethod name="addClassPattern">
<arg>"jp.co.sample.dao.mock"</arg>
<arg>".*DaoImpl"</arg>
</initMethod>
</component>
ドメイン駆動などにおけるサービスも同様で、サービスは必ずインターフェースとする。
これはモックへの差し替えを行うためである。
DIと組み合わせることによって、設定ファイルのみでモックによるテストを行ったり、本物の実装を動かせるようにする。
<<interface>>XxxDao
△
│
XxxDaoImpl
（↑）実装は上記のようなクラス構成となる。
モックを使う場合は、XxxDaoImplクラスのモックを別パッケージに用意し、DI設定を変える。
例えばSeasar2で、通常のDAO設定が次のようなものだとする。
<component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister">
<initMethod name="addClassPattern">
<arg>"jp.co.sample.dao"</arg>
<arg>".*DaoImpl"</arg>
</initMethod>
</component>
モックの場合は、次のように設定が変わる。（パッケージが"jp.co.sample.dao"から"jp.co.sample.dao.mock"になっている）
<component class="org.seasar.framework.container.autoregister.FileSystemComponentAutoRegister">
<initMethod name="addClassPattern">
<arg>"jp.co.sample.dao.mock"</arg>
<arg>".*DaoImpl"</arg>
</initMethod>
</component>
ドメイン駆動などにおけるサービスも同様で、サービスは必ずインターフェースとする。
[MySQL][CSV][読み込み]CSVファイルのデータをテーブルに格納する
MySQLに用意されている次のSQLコマンドで、CSVファイルを読み込むことができる。
LOAD DATA INFILE '[CSVファイルの絶対パス]'
INTO TABLE [テーブル名]
FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n';
CSVファイルに記述されているデータがテーブルにロードされる。
バッチファイルやシェルファイルにして、自動化すると効率的。
LOAD DATA INFILE '[CSVファイルの絶対パス]'
INTO TABLE [テーブル名]
FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\r\n';
CSVファイルに記述されているデータがテーブルにロードされる。
バッチファイルやシェルファイルにして、自動化すると効率的。
[MySQL][コマンドライン]コマンドラインからMySQLにクエリを発行する
最初にSQLファイルを作る。（テキストファイル、拡張子は".sql"）
SQLファイル内には複数のクエリを記述できる。
下記はサンプル。（SAMPLEというデータベースに、SAMPLE_TABLEというテーブルを追加）
CREATE DATABASE SAMPLE;
SHOW DATABASES;
USE SAMPLE;
CREATE TABLE SAMPLE(
SAMPLE_ID INT AUTO_INCREMENT,
SAMPLE_STRING VARCHAR(256),
PRIMARY KEY(SAMPLE_ID)
);
SHOW TABLES;
（以上、サンプル）
次にバッチファイルを作成する。
下記はサンプル。（sample.sqlというファイルに書かれたSQLを実行）
@echo off
set MYSQL_DIR="C:\Program Files\MySQL\bin"
set TEST_USER=testuser
set TEST_PASSWORD=password
set SQL_FILE=sample.sql
%MYSQL_DIR%\mysql -u%TEST_USER% -p%TEST_PASSWORD% < %SQL_FILE%
pause
（以上、サンプル）
バッチファイルを実行すると、SQLファイルの中に書かれたSQLが実行される。
なお、バッチファイルで発行するコマンドを次のように変えると、対話モードとなる。
対話モードで直接SQLを発行する場合は、こちらを利用する。
[MySQLのインストールディレクトリ]\bin\mysql -u[ユーザ名] -p
SQLファイル内には複数のクエリを記述できる。
下記はサンプル。（SAMPLEというデータベースに、SAMPLE_TABLEというテーブルを追加）
CREATE DATABASE SAMPLE;
SHOW DATABASES;
USE SAMPLE;
CREATE TABLE SAMPLE(
SAMPLE_ID INT AUTO_INCREMENT,
SAMPLE_STRING VARCHAR(256),
PRIMARY KEY(SAMPLE_ID)
);
SHOW TABLES;
（以上、サンプル）
次にバッチファイルを作成する。
下記はサンプル。（sample.sqlというファイルに書かれたSQLを実行）
@echo off
set MYSQL_DIR="C:\Program Files\MySQL\bin"
set TEST_USER=testuser
set TEST_PASSWORD=password
set SQL_FILE=sample.sql
%MYSQL_DIR%\mysql -u%TEST_USER% -p%TEST_PASSWORD% < %SQL_FILE%
pause
（以上、サンプル）
バッチファイルを実行すると、SQLファイルの中に書かれたSQLが実行される。
なお、バッチファイルで発行するコマンドを次のように変えると、対話モードとなる。
対話モードで直接SQLを発行する場合は、こちらを利用する。
[MySQLのインストールディレクトリ]\bin\mysql -u[ユーザ名] -p
[バッチファイル][変数の外部ファイル化]
WindowsのバッチファイルはUNIX系のシェルに比べて機能が弱く、文法も独自で使い勝手が悪い。
しかし開発等でWindowsでバッチファイルを作って効率化しなければならない局面は多い。
バッチファイルで問題となるのが絶対パスの指定等が必要な場合である。
パス指定は開発者の環境によって変わりうるため、必然的に可変部分を外部ファイルとして切り出したいニーズが出てくる。
可変となる設定部分を外部ファイル化してバッチファイルで読むサンプルは、次の通り。
まず最初に、可変の設定値を集めたテキストファイルを作成する。（例えばsetup.txt）
設定値は "[設定値の名前]=[設定値]" の形式で記述する規則とする。
以下、設定サンプル。
USER_NAME=user
PASSWORD=password
次に作成した設定値のファイルをバッチから読み込むコードを記述する。
バッチファイルを作成し、次のように記述して設定値が読めることを確認する。
@echo off
for /f "tokens=1,2 delims==" %%a in ('findstr USER_NAME setup.txt') do set USER_NAME=%%b
for /f "tokens=1,2 delims==" %%a in ('findstr PASSWORD setup.txt') do set PASSWORD=%%b
echo %USER_NAME%
echo %PASSWORD%
pause
設定ファイル内の設定を読む場合などに重宝するのはforを使った繰り返し処理である。
（下記箇所が、設定を読み込んでいる記述）
for /f "tokens=1,2 delims==" %%a in ('findstr USER_NAME setup.txt') do set USER_NAME=%%b
for /f [解析文字列]
と記述することで、解析文字列内で指定した方法でトークンを切り出すことができるようになる。
"tokens=1,2 delims==" と書いた場合、文字列中にトークンが2つあり、"=" で区切られていると解釈される。
"USER_NAME=user" という設定が書いてあった場合は、トークン1がUSER_NAME、トークン2がuserと解釈される。
%%aはループ内変数を示し、"token=1,2" と書いてあった場合はトークン1（USER_NAME）を示す。
%%bはトークン2（user）を示す。
in ()の括弧内にシングルクオートで囲んだ文字列を指定した場合、コマンドを実行した結果を示す。
in ('findstr USER_NAME setup.txt') とあった場合は、setup.txtというファイル内にUSER_NAMEという文字列があるかfindstrコマンドで探した結果が入る。
上記例でsetup.txtには "USER_NAME" という文字列を含む "USER_NAME=user" という行データが入る。
do以下は、forループで実行されるコマンドを記述する。
set USER_NAME=%%bでUSER_NAMEというバッチ変数にuserという文字列を代入している。
これにより、ファイルから読み込んだ値をバッチファイル内の変数としている。
しかし開発等でWindowsでバッチファイルを作って効率化しなければならない局面は多い。
バッチファイルで問題となるのが絶対パスの指定等が必要な場合である。
パス指定は開発者の環境によって変わりうるため、必然的に可変部分を外部ファイルとして切り出したいニーズが出てくる。
可変となる設定部分を外部ファイル化してバッチファイルで読むサンプルは、次の通り。
まず最初に、可変の設定値を集めたテキストファイルを作成する。（例えばsetup.txt）
設定値は "[設定値の名前]=[設定値]" の形式で記述する規則とする。
以下、設定サンプル。
USER_NAME=user
PASSWORD=password
次に作成した設定値のファイルをバッチから読み込むコードを記述する。
バッチファイルを作成し、次のように記述して設定値が読めることを確認する。
@echo off
for /f "tokens=1,2 delims==" %%a in ('findstr USER_NAME setup.txt') do set USER_NAME=%%b
for /f "tokens=1,2 delims==" %%a in ('findstr PASSWORD setup.txt') do set PASSWORD=%%b
echo %USER_NAME%
echo %PASSWORD%
pause
設定ファイル内の設定を読む場合などに重宝するのはforを使った繰り返し処理である。
（下記箇所が、設定を読み込んでいる記述）
for /f "tokens=1,2 delims==" %%a in ('findstr USER_NAME setup.txt') do set USER_NAME=%%b
for /f [解析文字列]
と記述することで、解析文字列内で指定した方法でトークンを切り出すことができるようになる。
"tokens=1,2 delims==" と書いた場合、文字列中にトークンが2つあり、"=" で区切られていると解釈される。
"USER_NAME=user" という設定が書いてあった場合は、トークン1がUSER_NAME、トークン2がuserと解釈される。
%%aはループ内変数を示し、"token=1,2" と書いてあった場合はトークン1（USER_NAME）を示す。
%%bはトークン2（user）を示す。
in ()の括弧内にシングルクオートで囲んだ文字列を指定した場合、コマンドを実行した結果を示す。
in ('findstr USER_NAME setup.txt') とあった場合は、setup.txtというファイル内にUSER_NAMEという文字列があるかfindstrコマンドで探した結果が入る。
上記例でsetup.txtには "USER_NAME" という文字列を含む "USER_NAME=user" という行データが入る。
do以下は、forループで実行されるコマンドを記述する。
set USER_NAME=%%bでUSER_NAMEというバッチ変数にuserという文字列を代入している。
これにより、ファイルから読み込んだ値をバッチファイル内の変数としている。
[Servlet][JSP]サーブレット最小アプリケーションの作成
eclipseは日本語All in one環境であるPleiadesがインストールされているものとする。
1. [ファイル]-[新規]-[プロジェクト]を選ぶ。
2. [Tomcatプロジェクト]を選択し[次へ]をクリックする。
3. プロジェクト名を入力し、[完了]をクリックする。（※1）
4. [WEB-INF]ディレクトリ直下に、web.xmlを作成する。
5. eclipse上からTomcatを起動する。
6. ブラウザでhttp://localhost:8080/[プロジェクト名]/index.htmlにアクセスする。（※2）
※1 プロジェクト名は英小文字のみをハイフンで接続するのが通例。
※2 index.htmlを作成している場合の例。web.xmlの設定による。
XMLの記述内容サンプルは、次の通り。
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<servlet>
<servlet-name>Index</servlet-name>
<servlet-class>servlet.IndexServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Index</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>Top</servlet-name>
<servlet-class>servlet.TopServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Top</servlet-name>
<url-pattern>/top.html</url-pattern>
</servlet-mapping>
</web-app>
（以上、サンプル）
<web-app>タグにあるごちゃごちゃした記述は、JSPのEL式を使うために必須。（xmlns等）
EL式がないとJSP上にJavaのコードを書くことになるので、おまじないだと思って書くこと。
<servlet>タグ内の<servlet-name>タグは、サーブレットに付ける名前で任意。
プログラム上の名称と合わせたりする必要はない。
<servlet-mapping>との関連付けのために必要。
<servlet-mapping>内の<servlet-name>と同じものを書くこと。
<servlet>タグ内の<servlet-class>は、実際に動かすサーブレットプログラムクラスの完全修飾名を記述する。
"servlet.IndexServlet" と書いたら、プロジェクト配下のservletパッケージにあるIndexServletクラスを指す。
本格的なWebアプリならパッケージ名は "jp.co.xxx.sys.servlet.XxxClass" のように長くなるはずである。
<servlet-mapping>タグ内の<servlet-name>タグは、<servlet>タグと同じものを記述する。
<servlet-mapping>タグ内の<url-pattern>タグは、ブラウザで入力するURLを指定する。
"/index.html"と書いたら、"http://localhost:8080/[プロジェクト名]/index.html" と書くことで、対応するサーブレットが動く。
外部の人から見て、あたかもhtmlを読んでいるかのように見せることができる。
【重要！】Tomcatを起動しても、サーブレットが動かない場合
TOMCAT_HOME配下の設定ファイルにコンテキスト設定がないことが考えられる。
TOMCAT_HOMEはTomcatのインストールディレクトリを指す。
"TOMCAT_HOME/conf/Catalina/localhost" ディレクトリ配下にコンテキスト設定を記述した[プロジェクト名].xmlファイルを置くか、"TOMCAT_HOME/conf/server.xml" にコンテキスト設定を追加することで、アプリケーションが動作するようになる。
後者のserver.xml直接編集はTomcatの設定を変えることになるので、最近は前者がほとんどである。
eclipseの[ウインドウ]-[設定]を選んで、[Tomcat]-[コンテキスト宣言モード]を見るとどちらを使っているか分かる。
後者のXMLファイルに記述する設定内容は、次の通り。
<Context path="/web-app-sample"
reloadable="true"
docBase="C:\eclipse\workspace\web-app-sample"
workDir="C:\eclipse\workspace\web-app-sample\work" />
docBaseで指定したディレクトリ配下のWEB-INFディレクトリを、サーブレットのディレクトリとしてTomcatが認識する。
上記設定サンプルでいうと、docBaseで指定したディレクトリ配下にservletというパッケージがあり、その中にIndexServletクラスがあれば、"http://localhost:8080/web-app-sample/index.html" と記述することでアクセスできるようになる。
この他、「TOMCAT_HOMEがない」というエラーが出る場合は、プロジェクトの右クリックメニューから[ビルドパスの構成]を選択して、TOMCAT_HOMEのディレクトリ設定を行う必要もある。
サーブレットはサンプルを動かすまでが大変。
eclipseとTomcatがあれば動くはずなので、設定をよく見直してまずは動かそう。
サーブレットプログラムは、動作確認だけなら次のコードで十分。
public class IndexServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
RequestDispatcher rd = req.getRequestDispatcher("/jsp/index.jsp");
rd.forward(req, res);
}
}
JSPファイルはeclipseのプロジェクト直下にjspフォルダを作ってそこに置いておく。
（場所を変えても問題ない）
JSPの内容は、次の通り。（ここではUTF-8を使用している）
<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>web-app-sample</title>
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
1. [ファイル]-[新規]-[プロジェクト]を選ぶ。
2. [Tomcatプロジェクト]を選択し[次へ]をクリックする。
3. プロジェクト名を入力し、[完了]をクリックする。（※1）
4. [WEB-INF]ディレクトリ直下に、web.xmlを作成する。
5. eclipse上からTomcatを起動する。
6. ブラウザでhttp://localhost:8080/[プロジェクト名]/index.htmlにアクセスする。（※2）
※1 プロジェクト名は英小文字のみをハイフンで接続するのが通例。
※2 index.htmlを作成している場合の例。web.xmlの設定による。
XMLの記述内容サンプルは、次の通り。
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<servlet>
<servlet-name>Index</servlet-name>
<servlet-class>servlet.IndexServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Index</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>Top</servlet-name>
<servlet-class>servlet.TopServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Top</servlet-name>
<url-pattern>/top.html</url-pattern>
</servlet-mapping>
</web-app>
（以上、サンプル）
<web-app>タグにあるごちゃごちゃした記述は、JSPのEL式を使うために必須。（xmlns等）
EL式がないとJSP上にJavaのコードを書くことになるので、おまじないだと思って書くこと。
<servlet>タグ内の<servlet-name>タグは、サーブレットに付ける名前で任意。
プログラム上の名称と合わせたりする必要はない。
<servlet-mapping>との関連付けのために必要。
<servlet-mapping>内の<servlet-name>と同じものを書くこと。
<servlet>タグ内の<servlet-class>は、実際に動かすサーブレットプログラムクラスの完全修飾名を記述する。
"servlet.IndexServlet" と書いたら、プロジェクト配下のservletパッケージにあるIndexServletクラスを指す。
本格的なWebアプリならパッケージ名は "jp.co.xxx.sys.servlet.XxxClass" のように長くなるはずである。
<servlet-mapping>タグ内の<servlet-name>タグは、<servlet>タグと同じものを記述する。
<servlet-mapping>タグ内の<url-pattern>タグは、ブラウザで入力するURLを指定する。
"/index.html"と書いたら、"http://localhost:8080/[プロジェクト名]/index.html" と書くことで、対応するサーブレットが動く。
外部の人から見て、あたかもhtmlを読んでいるかのように見せることができる。
【重要！】Tomcatを起動しても、サーブレットが動かない場合
TOMCAT_HOME配下の設定ファイルにコンテキスト設定がないことが考えられる。
TOMCAT_HOMEはTomcatのインストールディレクトリを指す。
"TOMCAT_HOME/conf/Catalina/localhost" ディレクトリ配下にコンテキスト設定を記述した[プロジェクト名].xmlファイルを置くか、"TOMCAT_HOME/conf/server.xml" にコンテキスト設定を追加することで、アプリケーションが動作するようになる。
後者のserver.xml直接編集はTomcatの設定を変えることになるので、最近は前者がほとんどである。
eclipseの[ウインドウ]-[設定]を選んで、[Tomcat]-[コンテキスト宣言モード]を見るとどちらを使っているか分かる。
後者のXMLファイルに記述する設定内容は、次の通り。
<Context path="/web-app-sample"
reloadable="true"
docBase="C:\eclipse\workspace\web-app-sample"
workDir="C:\eclipse\workspace\web-app-sample\work" />
docBaseで指定したディレクトリ配下のWEB-INFディレクトリを、サーブレットのディレクトリとしてTomcatが認識する。
上記設定サンプルでいうと、docBaseで指定したディレクトリ配下にservletというパッケージがあり、その中にIndexServletクラスがあれば、"http://localhost:8080/web-app-sample/index.html" と記述することでアクセスできるようになる。
この他、「TOMCAT_HOMEがない」というエラーが出る場合は、プロジェクトの右クリックメニューから[ビルドパスの構成]を選択して、TOMCAT_HOMEのディレクトリ設定を行う必要もある。
サーブレットはサンプルを動かすまでが大変。
eclipseとTomcatがあれば動くはずなので、設定をよく見直してまずは動かそう。
サーブレットプログラムは、動作確認だけなら次のコードで十分。
public class IndexServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
RequestDispatcher rd = req.getRequestDispatcher("/jsp/index.jsp");
rd.forward(req, res);
}
}
JSPファイルはeclipseのプロジェクト直下にjspフォルダを作ってそこに置いておく。
（場所を変えても問題ない）
JSPの内容は、次の通り。（ここではUTF-8を使用している）
<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>web-app-sample</title>
</head>
<body>
<h1>Hello world!</h1>
</body>
</html>
[Java][コマンドライン]Javaプログラムコマンドライン起動
eclipseの便利さに慣れてしまうと、コマンドラインでJavaプログラムをコンパイルすることはないが、現場レベルでは往々にしてコマンドライン起動がありうる。
例えばサーバ上でJavaプログラムを動かしている場合、サーバ機には開発ツール等の余計なものは入っていないはずだ。
サーバ運用に必要な最小限の構成を組み、セキュリティアップデートなども記録して行っているはずである。
開発用サーバならまだしも、本番機にはまずeclipseは入っていない。
こうしたときに、サーバにアップデートした検証用プログラムや新しいプログラムを起動するためには、コマンドライン起動ができなくてはならない。
そのようなケースのために、手順を記述する。
例えばプロジェクトルートSampleProject、パッケージ名sample、クラスファイル名SampleProgram.classという構成でプログラムを動かす場合を考えてみる。
ディレクトリ構成は、下記を想定する。
[dir]SampleProject
[dir]bin
[dir]sample
SampleProgram.class
[dir]src
[dir]sample
SampleProgram.java
ディレクトリには[dir]と記述している。
eclipseでプログラムを作った場合、通常は上記の構成となるだろう。
起動のためには、SampleProjectディレクトリで次のコマンドを打つ。
java -classpath .:./bin sample.SampleProgram
クラスパスオプション（"-classpath [クラスパス]"）には".:./bin"を指定している。
ドット（.）はカレントディレクトリ、./binはカレントディレクトリ配下のbinディレクトリを示している。
複数のディレクトリをつなぐ場合は、コロン（:）を用いる。（Linuxの場合、Windowsならセミコロン（;））
つまり「クラスパスとしてカレントディレクトリ及びbinディレクトリを指定する」という意味になる。
（複数ディレクトリ指定のためにカレントディレクトリも入れたが、本当は./binだけでよい）
続く"sample.SampleProgam"は「sampleパッケージのSampleProgram.class」を意味している。
Javaではプログラムをひとまとまりとするためにパッケージを用いる。
パッケージ名のディレクトリ配下に、そのパッケージに含めるクラスファイルを格納する。
コマンドライン起動の場合は、クラスパスでbinディレクトリを指定したら、その配下にあるクラスファイルの名前を".class"抜きで記述する。
ちなみに、"sample.SampleProgram"を"SampleProgram"とだけ書くのはNG。
プログラムは起動しない。
[パッケージ名].[クラスファイル名（".class"を抜いた名称）]
という記述が決まりとなっている。（完全修飾名）
次に、コンパイルコマンドについて記述する。
eclipseを使っている場合、サーバとJavaのバージョンが合っていればWindowsで作ったクラスファイルをLinuxで起動しても問題なく動く。
通常はコンパイルすることはないだろう。
だが、修正したファイルをすぐに試したい場合など、手動コンパイルの出番がないわけではない。
少々長いが、下記のようにコマンドを打つことで、手動コンパイルができる。
コマンドを実行するディレクトリは、先ほどと同じくSampleProjectディレクトリである。
javac -sourcepath ./src/sample -classpath ./bin -d ./bin ./src/sample/SampleProgram.java
"-sourcepath [ソースパス]"でソースファイルがあるパス名を指定する。
"-classpath [クラスパス名]"でクラスパスを指定するのは、実行コマンドと同じである。
"-d [出力先ディレクトリ]"はクラスファイルの出力先ディレクトリを示す。
クラスパス、出力先ディレクトリともに、パッケージディレクトリまでは指定してはいけない。
sampleパッケージだからbin/sample配下にクラスファイルを出力しようとして、下記のように書くのはNG。
-d ./bin/sample
（↑）こう書くと、bin/sample/sample/SampleProgram.classが出来てしまう。
（sampleの下にsampleが出てくる）
Javaコンパイラはpackage宣言を参照して、自動的にパッケージディレクトリを作るため、"./bin"までの指定が正しい。
なお、依存関係にあるクラスは依存先を最初にコンパイルし、クラスパスを通しておかないと、依存元のコンパイルでエラーとなるので注意が必要である。
上記のコマンドライン起動がうまくいったら、シェルスクリプトやバッチファイルにコマンドを記述し、次回以降は面倒なコマンドをフルに打たなくても起動できるようにするのがオススメである。
例えばサーバ上でJavaプログラムを動かしている場合、サーバ機には開発ツール等の余計なものは入っていないはずだ。
サーバ運用に必要な最小限の構成を組み、セキュリティアップデートなども記録して行っているはずである。
開発用サーバならまだしも、本番機にはまずeclipseは入っていない。
こうしたときに、サーバにアップデートした検証用プログラムや新しいプログラムを起動するためには、コマンドライン起動ができなくてはならない。
そのようなケースのために、手順を記述する。
例えばプロジェクトルートSampleProject、パッケージ名sample、クラスファイル名SampleProgram.classという構成でプログラムを動かす場合を考えてみる。
ディレクトリ構成は、下記を想定する。
[dir]SampleProject
[dir]bin
[dir]sample
SampleProgram.class
[dir]src
[dir]sample
SampleProgram.java
ディレクトリには[dir]と記述している。
eclipseでプログラムを作った場合、通常は上記の構成となるだろう。
起動のためには、SampleProjectディレクトリで次のコマンドを打つ。
java -classpath .:./bin sample.SampleProgram
クラスパスオプション（"-classpath [クラスパス]"）には".:./bin"を指定している。
ドット（.）はカレントディレクトリ、./binはカレントディレクトリ配下のbinディレクトリを示している。
複数のディレクトリをつなぐ場合は、コロン（:）を用いる。（Linuxの場合、Windowsならセミコロン（;））
つまり「クラスパスとしてカレントディレクトリ及びbinディレクトリを指定する」という意味になる。
（複数ディレクトリ指定のためにカレントディレクトリも入れたが、本当は./binだけでよい）
続く"sample.SampleProgam"は「sampleパッケージのSampleProgram.class」を意味している。
Javaではプログラムをひとまとまりとするためにパッケージを用いる。
パッケージ名のディレクトリ配下に、そのパッケージに含めるクラスファイルを格納する。
コマンドライン起動の場合は、クラスパスでbinディレクトリを指定したら、その配下にあるクラスファイルの名前を".class"抜きで記述する。
ちなみに、"sample.SampleProgram"を"SampleProgram"とだけ書くのはNG。
プログラムは起動しない。
[パッケージ名].[クラスファイル名（".class"を抜いた名称）]
という記述が決まりとなっている。（完全修飾名）
次に、コンパイルコマンドについて記述する。
eclipseを使っている場合、サーバとJavaのバージョンが合っていればWindowsで作ったクラスファイルをLinuxで起動しても問題なく動く。
通常はコンパイルすることはないだろう。
だが、修正したファイルをすぐに試したい場合など、手動コンパイルの出番がないわけではない。
少々長いが、下記のようにコマンドを打つことで、手動コンパイルができる。
コマンドを実行するディレクトリは、先ほどと同じくSampleProjectディレクトリである。
javac -sourcepath ./src/sample -classpath ./bin -d ./bin ./src/sample/SampleProgram.java
"-sourcepath [ソースパス]"でソースファイルがあるパス名を指定する。
"-classpath [クラスパス名]"でクラスパスを指定するのは、実行コマンドと同じである。
"-d [出力先ディレクトリ]"はクラスファイルの出力先ディレクトリを示す。
クラスパス、出力先ディレクトリともに、パッケージディレクトリまでは指定してはいけない。
sampleパッケージだからbin/sample配下にクラスファイルを出力しようとして、下記のように書くのはNG。
-d ./bin/sample
（↑）こう書くと、bin/sample/sample/SampleProgram.classが出来てしまう。
（sampleの下にsampleが出てくる）
Javaコンパイラはpackage宣言を参照して、自動的にパッケージディレクトリを作るため、"./bin"までの指定が正しい。
なお、依存関係にあるクラスは依存先を最初にコンパイルし、クラスパスを通しておかないと、依存元のコンパイルでエラーとなるので注意が必要である。
上記のコマンドライン起動がうまくいったら、シェルスクリプトやバッチファイルにコマンドを記述し、次回以降は面倒なコマンドをフルに打たなくても起動できるようにするのがオススメである。
[Subversion][Tomcat]SubversionでTomcatプロジェクトを扱う際の注意点
Windows上で管理者がSubversionにTomcatプロジェクトをインポートし、開発者がチェックアウトすると、コンパイルエラーとなる現象が発生したので、その原因と対処について記述する。
原因はチェックアウト時にTOMCAT_HOMEを認識しないためである。
（環境変数にCATALINA_HOMEやTOMCAT_HOMEを定義していれば出ないかも？）
Tomcatプロジェクトではeclipseがサーバサイドプログラムのための各種設定を行ってくれる。
TOMCAT_HOME/common/libなどへパスを通しておかないと、サーブレット等が使えないため、こうしたディレクトリへのパスもeclipseで自動的に定義される。
ただしSubversionで単純にプロジェクトをチェックアウトしただけだとTOMCAT_HOMEが認識されないため、管理者側ではきちんとコンパイルが通っているコードでもコンパイルが通らなくなってしまう。
この問題を解消するには、プロジェクトを右クリックして出てくるビルドパスの構成で、TOMCAT_HOME配下のディレクトリへの参照をきちんと設定しれやればよい。
（TOMCAT_HOME/common/libなどへの参照が空になっているので、編集ボタンを押してTomcatのインストールディレクトリ配下の該当ディレクトリを指定する）
原因はチェックアウト時にTOMCAT_HOMEを認識しないためである。
（環境変数にCATALINA_HOMEやTOMCAT_HOMEを定義していれば出ないかも？）
Tomcatプロジェクトではeclipseがサーバサイドプログラムのための各種設定を行ってくれる。
TOMCAT_HOME/common/libなどへパスを通しておかないと、サーブレット等が使えないため、こうしたディレクトリへのパスもeclipseで自動的に定義される。
ただしSubversionで単純にプロジェクトをチェックアウトしただけだとTOMCAT_HOMEが認識されないため、管理者側ではきちんとコンパイルが通っているコードでもコンパイルが通らなくなってしまう。
この問題を解消するには、プロジェクトを右クリックして出てくるビルドパスの構成で、TOMCAT_HOME配下のディレクトリへの参照をきちんと設定しれやればよい。
（TOMCAT_HOME/common/libなどへの参照が空になっているので、編集ボタンを押してTomcatのインストールディレクトリ配下の該当ディレクトリを指定する）
[eclipse][環境変数]eclipseを使う場合の環境変数設定について
eclipse、特にpleiadesを使った場合、環境変数の設定は必要ない。
Java入門サイトを見ると、Windowsの場合、よく環境変数のPATH変数にJAVA_HOMEやJAVA_HOME/binへの参照を追加する、という記述が見られる。
かつてMS-DOS時代ならば、configでこうしたパス設定を行うことは珍しくなかったかも知れない。
しかし、シェル変数による環境変数設定が一般的なLinuxでも、むやみに環境変数を書き換えることは推奨されていない。
少なくとも、特定ユーザのログインシェル（.profileや.bashXXなど）を変更し、他のユーザに影響を与えないことが基本である。
Windowsの場合、環境変数はそこまで柔軟なものではなく、下手に書き換えるとPCが正しく立ち上がらなくなったりする。
できれば環境変数設定を操作してはいけないのである。
（その点Linuxならばシェルスクリプトに、当該スクリプト内だけのシェル変数を定義できるので、シェルごとにパス設定が簡単にできる。色々な意味で、WindowsとLinuxの作法は違うのである）
eclipseはそうした点のかなりの部分を解消してくれる。
日本語環境であるpleiadesを使った場合、[ウインドウ]-[設定]で表示されるダイアログから[Java]-[コンパイラー]の順に選んでいくと、最初からpleiadesに入っている複数バージョンのコンパイラを選ぶことができる。
重要なのは1.4から1.5への移行だろう。
1.5以降はVector<String>といったコンテナの型指定が必須となっており、こう書かないと警告になる。
ところが1.4だとGenerics（型指定等を含む新しい文法）がまだ含まれていないため、Vector<String>と書くとコンパイルエラーになってしまう。
1.4ではJUnit4が使えないという点も不利である。
JUnit4はそれまでのJUnitよりも更に簡単な記述で、自動テストができるようになっている。
メソッド名に制約があったり、テストの実行順序などを細かく記述しないとテストスイートが動かなかったJUnit3と比べると便利であり、一度慣れてしまうとなかなか戻れない。
こうしたコンパイラのバージョンはeclipse上で変えられるため、環境変数の設定は必要ない。
同様にTOMCAT_HOMEやMySQLのディレクトリ設定も必要ない。
TOMCATはTOMCATプロジェクトを作った場合、pleiades（eclipse）がTOMCAT_HOME以下WEB-INFまでのパス設定をプロジェクトの設定ファイルで作ってくれる。
MySQLは多少面倒でもバッチファイルにフルパス名でコマンドを記述するか、インストーラでインストールした場合に付属するツールを使えば、パスが通っていなくても動作させることができる。
初心者のときに随分色々と環境変数を追加して「アナログなことをするんだなぁ」と思っていたのは少し前の話。
洗練された統合環境には、必ず洗練されたパス解決の仕組みが備わっているのだ、と思う。
最近になってようやくそのことを理解し、JAVA_HOMEなどの余計な環境変数設定を全て削除して、環境変数をきれいな状態に戻すことができた。
Java入門サイトを見ると、Windowsの場合、よく環境変数のPATH変数にJAVA_HOMEやJAVA_HOME/binへの参照を追加する、という記述が見られる。
かつてMS-DOS時代ならば、configでこうしたパス設定を行うことは珍しくなかったかも知れない。
しかし、シェル変数による環境変数設定が一般的なLinuxでも、むやみに環境変数を書き換えることは推奨されていない。
少なくとも、特定ユーザのログインシェル（.profileや.bashXXなど）を変更し、他のユーザに影響を与えないことが基本である。
Windowsの場合、環境変数はそこまで柔軟なものではなく、下手に書き換えるとPCが正しく立ち上がらなくなったりする。
できれば環境変数設定を操作してはいけないのである。
（その点Linuxならばシェルスクリプトに、当該スクリプト内だけのシェル変数を定義できるので、シェルごとにパス設定が簡単にできる。色々な意味で、WindowsとLinuxの作法は違うのである）
eclipseはそうした点のかなりの部分を解消してくれる。
日本語環境であるpleiadesを使った場合、[ウインドウ]-[設定]で表示されるダイアログから[Java]-[コンパイラー]の順に選んでいくと、最初からpleiadesに入っている複数バージョンのコンパイラを選ぶことができる。
重要なのは1.4から1.5への移行だろう。
1.5以降はVector<String>といったコンテナの型指定が必須となっており、こう書かないと警告になる。
ところが1.4だとGenerics（型指定等を含む新しい文法）がまだ含まれていないため、Vector<String>と書くとコンパイルエラーになってしまう。
1.4ではJUnit4が使えないという点も不利である。
JUnit4はそれまでのJUnitよりも更に簡単な記述で、自動テストができるようになっている。
メソッド名に制約があったり、テストの実行順序などを細かく記述しないとテストスイートが動かなかったJUnit3と比べると便利であり、一度慣れてしまうとなかなか戻れない。
こうしたコンパイラのバージョンはeclipse上で変えられるため、環境変数の設定は必要ない。
同様にTOMCAT_HOMEやMySQLのディレクトリ設定も必要ない。
TOMCATはTOMCATプロジェクトを作った場合、pleiades（eclipse）がTOMCAT_HOME以下WEB-INFまでのパス設定をプロジェクトの設定ファイルで作ってくれる。
MySQLは多少面倒でもバッチファイルにフルパス名でコマンドを記述するか、インストーラでインストールした場合に付属するツールを使えば、パスが通っていなくても動作させることができる。
初心者のときに随分色々と環境変数を追加して「アナログなことをするんだなぁ」と思っていたのは少し前の話。
洗練された統合環境には、必ず洗練されたパス解決の仕組みが備わっているのだ、と思う。
最近になってようやくそのことを理解し、JAVA_HOMEなどの余計な環境変数設定を全て削除して、環境変数をきれいな状態に戻すことができた。
[Subversion][Subclipse][チェックアウト]Subclipseによるチェックアウト手順
eclipse上から、Subversionで管理しているファイルをチェックアウトする手順について記述する。
この手順を実行する際の前提事項は以下の通り。
・svnserve.exeが起動していること
・レポジトリにマスタファイルがインポートされていること
Subclipseを使ったチェックアウト手順は以下の通り。
(1) eclipseを起動する。
Pleiadesを使っている場合、SVNプラグインは最初から入っているので、特別なインストール手順は必要ない。
eclipseを起動するだけでSubclipseが使える状態になっている。
(2) SVNパースペクティブを開く。
メニューから[ウインドウ]-[パースペクティブを開く]-[その他]を選択し、ダイアログから[SVNレポジトリー・エクスプローラ]を選択して[OK]ボタンを押下する。
(3) SVNレポジトリー・エクスプローラのウインドウで右クリックから[新規]-[レポジトリー・ロケーション]を選択する。
(4) URLに"svn://localhost"と入力し、[完了]ボタンを押下する。
(5) SVNレポジトリー・エクスプローラにインポート済みのプロジェクトが表示されれば成功。
本サイトの記事で前述したインポート手順を実行している場合、続けて上記手順を実行できる。
（前の記事を参照のこと）
余談だが、インポート手順について気を付けたい点について記述する。
インポート手順を間違えると変なバージョンが付いたり、ゴミファイルが残ったりする危険がある。
よって、前述したインポート手順が成功したなら、実行したコマンドをバッチファイルにまとめておき、必ず成功する手順を固めておくことが望ましい。（それまでに作ったものは一度全部消して、バッチファイルから再構成するときれいに仕上がる）
バージョン管理ではこうした初期設定の面倒をきちんとクリアしておくことで、管理体制の見通しがよくなる。
最初がうまくいけば、後は追加や更新の手順を整備するだけとなる。
（これもできればバッチ処理や手順をまとめる。こうすることでマスタ管理の混乱を未然に防げる）
この手順を実行する際の前提事項は以下の通り。
・svnserve.exeが起動していること
・レポジトリにマスタファイルがインポートされていること
Subclipseを使ったチェックアウト手順は以下の通り。
(1) eclipseを起動する。
Pleiadesを使っている場合、SVNプラグインは最初から入っているので、特別なインストール手順は必要ない。
eclipseを起動するだけでSubclipseが使える状態になっている。
(2) SVNパースペクティブを開く。
メニューから[ウインドウ]-[パースペクティブを開く]-[その他]を選択し、ダイアログから[SVNレポジトリー・エクスプローラ]を選択して[OK]ボタンを押下する。
(3) SVNレポジトリー・エクスプローラのウインドウで右クリックから[新規]-[レポジトリー・ロケーション]を選択する。
(4) URLに"svn://localhost"と入力し、[完了]ボタンを押下する。
(5) SVNレポジトリー・エクスプローラにインポート済みのプロジェクトが表示されれば成功。
本サイトの記事で前述したインポート手順を実行している場合、続けて上記手順を実行できる。
（前の記事を参照のこと）
余談だが、インポート手順について気を付けたい点について記述する。
インポート手順を間違えると変なバージョンが付いたり、ゴミファイルが残ったりする危険がある。
よって、前述したインポート手順が成功したなら、実行したコマンドをバッチファイルにまとめておき、必ず成功する手順を固めておくことが望ましい。（それまでに作ったものは一度全部消して、バッチファイルから再構成するときれいに仕上がる）
バージョン管理ではこうした初期設定の面倒をきちんとクリアしておくことで、管理体制の見通しがよくなる。
最初がうまくいけば、後は追加や更新の手順を整備するだけとなる。
（これもできればバッチ処理や手順をまとめる。こうすることでマスタ管理の混乱を未然に防げる）
[Subversion][Subclipse][インポート]Subclipseによるインポート手順
Subversionで作成したレポジトリに、eclipseからアクセスする方法について覚書を記述する。
eclipse上からSubversionにアクセスするためには、以下の手順で操作を行う。
（ここではSubversionをc:\svnにインストールしたものとして記述を行う）
1. c:\svn\bin\svnadmin.exeを使って、レポジトリを作成しておく。
例えばWindowsでSubversionを"c:\svn"にインストールし、"c:\svn\repos"にレポジトリを作る場合、以下のコマンドを打つ。
cd c:\svn\bin
svnadmin create c:\svn\repos
2. レポジトリのconf/svnserve.confの設定を行う。
デフォルトで用意される設定ファイルのコメントを外していく。（行頭の"# "を取る）
コメントを外して有効にする設定は、以下の通り。
anon-access = read
auth-access = write
password-db = passwd
realm = My First Repository
（ファイルはc:\svn\repos\conf\svnserve.conf）
3. レポジトリのconf/passwdを編集し、ユーザ・パスワードを設定する。
同ファイルに"[ユーザ名] = [パスワード]"の形式で記述。
例えばユーザ名"user1"、パスワード"password1"のユーザを作る場合、次の行をファイルに追加する。
user1 = password1
（ファイルはc:\svn\repos\conf\passwd）
4. コマンドラインから以下のコマンドを入力し、svnserve.exeを起動する。
eclipseからレポジトリにアクセスするためには、レポジトリを監視している常駐プロセスにTCP/IPで接続できなくてはならない。
（Subclipseでは裏でTCP/IP接続を行っている）
cd c:\svn\bin
svnserve -d -r c:\svn\repos
-dオプションは"svnserve.exeをデーモンモードで起動する"という意味であり、これによってsvnserve.exeがTCP/IP接続を受けられる状態になる。
-rオプションはレポジトリのルートを示すものでレポジトリのディレクトリを指定する。（この場合c:\svn\reposとなる）
5. eclipseを起動し、レポジトリにプロジェクトを追加する。
例えばTargetというJavaプロジェクトがeclipseに存在し、そのプロジェクトをレポジトリに追加したい場合、以下の操作を行う。
(1) Targetプロジェクトを右クリックして出るメニューから[チーム]-[プロジェクトの共用]を選択する。
(2) SVNを選択し、[次へ]をクリックする。
(3) レポジトリのロケーション（URL）に"svn://localhost"と入力する。
(4) ユーザ名とパスワードに上記3.で設定したデータを入力する。
(5) URLの横にある参照ボタンを押し、エラー表示が出ないことを確認する。
(6) 上記(5)が確認できたら[完了]ボタンを押す。
(7) 続く画面では[全て選択]、[OK]を押下する。（プロジェクトのファイル全てを管理対象として追加できる）
(8) eclipseのメニューから[ウインドウ]-[パースペクティブを開く]-[その他]を選択する。
(9) [SVNレポジトリ・エクスプローラ]を開き、Targetがインポートされていれば成功。
なお、テストした環境では1回目の接続でエラーになった。
その場合は手順をもう一度繰り返せば成功する。
（何度か繰り返したが現象変わらず。2つ目以降のプロジェクト登録は成功するので1度目だけ）
eclipse上からSubversionにアクセスするためには、以下の手順で操作を行う。
（ここではSubversionをc:\svnにインストールしたものとして記述を行う）
1. c:\svn\bin\svnadmin.exeを使って、レポジトリを作成しておく。
例えばWindowsでSubversionを"c:\svn"にインストールし、"c:\svn\repos"にレポジトリを作る場合、以下のコマンドを打つ。
cd c:\svn\bin
svnadmin create c:\svn\repos
2. レポジトリのconf/svnserve.confの設定を行う。
デフォルトで用意される設定ファイルのコメントを外していく。（行頭の"# "を取る）
コメントを外して有効にする設定は、以下の通り。
anon-access = read
auth-access = write
password-db = passwd
realm = My First Repository
（ファイルはc:\svn\repos\conf\svnserve.conf）
3. レポジトリのconf/passwdを編集し、ユーザ・パスワードを設定する。
同ファイルに"[ユーザ名] = [パスワード]"の形式で記述。
例えばユーザ名"user1"、パスワード"password1"のユーザを作る場合、次の行をファイルに追加する。
user1 = password1
（ファイルはc:\svn\repos\conf\passwd）
4. コマンドラインから以下のコマンドを入力し、svnserve.exeを起動する。
eclipseからレポジトリにアクセスするためには、レポジトリを監視している常駐プロセスにTCP/IPで接続できなくてはならない。
（Subclipseでは裏でTCP/IP接続を行っている）
cd c:\svn\bin
svnserve -d -r c:\svn\repos
-dオプションは"svnserve.exeをデーモンモードで起動する"という意味であり、これによってsvnserve.exeがTCP/IP接続を受けられる状態になる。
-rオプションはレポジトリのルートを示すものでレポジトリのディレクトリを指定する。（この場合c:\svn\reposとなる）
5. eclipseを起動し、レポジトリにプロジェクトを追加する。
例えばTargetというJavaプロジェクトがeclipseに存在し、そのプロジェクトをレポジトリに追加したい場合、以下の操作を行う。
(1) Targetプロジェクトを右クリックして出るメニューから[チーム]-[プロジェクトの共用]を選択する。
(2) SVNを選択し、[次へ]をクリックする。
(3) レポジトリのロケーション（URL）に"svn://localhost"と入力する。
(4) ユーザ名とパスワードに上記3.で設定したデータを入力する。
(5) URLの横にある参照ボタンを押し、エラー表示が出ないことを確認する。
(6) 上記(5)が確認できたら[完了]ボタンを押す。
(7) 続く画面では[全て選択]、[OK]を押下する。（プロジェクトのファイル全てを管理対象として追加できる）
(8) eclipseのメニューから[ウインドウ]-[パースペクティブを開く]-[その他]を選択する。
(9) [SVNレポジトリ・エクスプローラ]を開き、Targetがインポートされていれば成功。
なお、テストした環境では1回目の接続でエラーになった。
その場合は手順をもう一度繰り返せば成功する。
（何度か繰り返したが現象変わらず。2つ目以降のプロジェクト登録は成功するので1度目だけ）
[Subversion][Subclipse][使い方]Subclipse概要調査
Subversionで作成したレポジトリにeclipseからアクセスするツールについて、調査内容をまとめる。
eclipseからSubversionに接続するためのツールは複数があるが、Subclipseの使い方について調査した。
Pleiadesというeclipse環境をインストールしていれば、SubclipseというSubversionアクセスツールが最初から入っている。
Pleiadesはアマテラスプロジェクトで公開している日本語eclipse環境のことで、SubclipseやStruts、Tomcatなど、eclipseでよく使うツールが最初から全部入っている。
通常はeclipseにプラグインを次々に付け足していかなければならないが、これは英語サイトなどで説明を読みながら自力で行う必要があり、初心者にはハードルが高い。
Pleiadesはオススメのeclipse開発環境である。
以下、Subversionで使う概念について、簡単に記述する。
レポジトリとはバージョン管理対象となるファイルを格納する場所のこと。
レポジトリにはマスタファイルを登録（インポート）する。
各開発者はレポジトリからマスタファイルを取得（チェックアウト）する。
開発者がマスタファイルを更新した場合、更新の登録（コミット）を行う。
他の開発者が再度チェックアウトを行うと、コミットした内容が適用された最新ファイルが取得できる。
Subclipseでは、svnのレポジトリにeclipseからアクセスし、マスタファイルをインポートすることができる。
また、インポートしたマスタファイルをeclipse上からチェックアウトすることができる。
よって、開発環境管理者はマスタファイルをインポートし、各開発者はそのマスタファイルをチェックアウトして編集作業を行うという手順を、eclipse上からできることになる。
この次以降の記事では、実際の手順について記述する。
eclipseからSubversionに接続するためのツールは複数があるが、Subclipseの使い方について調査した。
Pleiadesというeclipse環境をインストールしていれば、SubclipseというSubversionアクセスツールが最初から入っている。
Pleiadesはアマテラスプロジェクトで公開している日本語eclipse環境のことで、SubclipseやStruts、Tomcatなど、eclipseでよく使うツールが最初から全部入っている。
通常はeclipseにプラグインを次々に付け足していかなければならないが、これは英語サイトなどで説明を読みながら自力で行う必要があり、初心者にはハードルが高い。
Pleiadesはオススメのeclipse開発環境である。
以下、Subversionで使う概念について、簡単に記述する。
レポジトリとはバージョン管理対象となるファイルを格納する場所のこと。
レポジトリにはマスタファイルを登録（インポート）する。
各開発者はレポジトリからマスタファイルを取得（チェックアウト）する。
開発者がマスタファイルを更新した場合、更新の登録（コミット）を行う。
他の開発者が再度チェックアウトを行うと、コミットした内容が適用された最新ファイルが取得できる。
Subclipseでは、svnのレポジトリにeclipseからアクセスし、マスタファイルをインポートすることができる。
また、インポートしたマスタファイルをeclipse上からチェックアウトすることができる。
よって、開発環境管理者はマスタファイルをインポートし、各開発者はそのマスタファイルをチェックアウトして編集作業を行うという手順を、eclipse上からできることになる。
この次以降の記事では、実際の手順について記述する。
[Javadoc][生成]Javadoc生成
eclipse上からJavadocを生成する手順。
Javadocは/** ～ */までのコメント内に特定のシグネチャ（@で始まるキーワード）を埋め込むことによって、従来でいう関数仕様書のようなものを自動で生成するツール。
出来上がったJavadocはHTMLとなっており、見やすい上に詳細な記述ができるレイアウトである。おそらくこれを自分で1から作ったら何日もかかる。こうした自動生成により、ドキュメント作成にかける時間を短縮し、プロジェクトの効率化を図ることができる。
生成手順は下記の通り。
ソースファイル上のメソッド名をクリックし、行が選択された状態になったら右クリック。
メニューから[ソース]-[要素コメントの生成]でJavadoc形式のコメントを作成できる。
生成した要素コメントがJavadocにどう反映されるかは、次の操作でビューを表示することによって確認できる。
パッケージエクスプローラ上でソースファイルを選択する。
[ウインドウ]メニューから[ビューの表示]-[Javadoc]を選択すると、当該ソースファイルのJavaDocが見れる。
また、最終的にプロジェクトが完成した場合、次の手順によりプロジェクト全体のJavadocを生成することができる。
パッケージエクスプローラ上でプロジェクトを選択する。
[プロジェクト]メニューから[Javadocの生成]を選択すると、Javadocのドキュメントが生成される。
[Javadocの生成]は、プロジェクトが完成した時点で行うのが妥当。
途中でメソッドを追加すると、生成されたドキュメントがエラーとなり、パッケージエクスプローラ上で×印が付く。
生成されたドキュメントはプロジェクト配下のdocディレクトリに格納される。
これを全て削除してもう一度手順を実行すると、最新のソースファイルからJavadocが再度生成される。
docディレクトリのindex.htmlを見ると、プロジェクト全体のJavadocを概観できる。
Javadocは/** ～ */までのコメント内に特定のシグネチャ（@で始まるキーワード）を埋め込むことによって、従来でいう関数仕様書のようなものを自動で生成するツール。
出来上がったJavadocはHTMLとなっており、見やすい上に詳細な記述ができるレイアウトである。おそらくこれを自分で1から作ったら何日もかかる。こうした自動生成により、ドキュメント作成にかける時間を短縮し、プロジェクトの効率化を図ることができる。
生成手順は下記の通り。
ソースファイル上のメソッド名をクリックし、行が選択された状態になったら右クリック。
メニューから[ソース]-[要素コメントの生成]でJavadoc形式のコメントを作成できる。
生成した要素コメントがJavadocにどう反映されるかは、次の操作でビューを表示することによって確認できる。
パッケージエクスプローラ上でソースファイルを選択する。
[ウインドウ]メニューから[ビューの表示]-[Javadoc]を選択すると、当該ソースファイルのJavaDocが見れる。
また、最終的にプロジェクトが完成した場合、次の手順によりプロジェクト全体のJavadocを生成することができる。
パッケージエクスプローラ上でプロジェクトを選択する。
[プロジェクト]メニューから[Javadocの生成]を選択すると、Javadocのドキュメントが生成される。
[Javadocの生成]は、プロジェクトが完成した時点で行うのが妥当。
途中でメソッドを追加すると、生成されたドキュメントがエラーとなり、パッケージエクスプローラ上で×印が付く。
生成されたドキュメントはプロジェクト配下のdocディレクトリに格納される。
これを全て削除してもう一度手順を実行すると、最新のソースファイルからJavadocが再度生成される。
docディレクトリのindex.htmlを見ると、プロジェクト全体のJavadocを概観できる。
[JUnit][動作確認]JUnit4動作確認テスト
eclipseを起動し、Javaプロジェクトを作成する。
ここでは動作確認のためのプロジェクト名をTarget、テスト対象のクラスをTargetClassとした。
なお、TargetClassはmodelパッケージの配下とした。（パッケージは作らなくてもよい、便宜上のもの）
テスト用のプロジェクトを、Javaプロジェクトとして作成する。
ここではプロジェクト名をTargetTestとした。
TargetTestプロジェクトにmodel.junit.testパッケージを追加し、その配下にTargetClassTestクラスを追加する。
（ここでもパッケージは作らなくてもよい、便宜上のもの）
パッケージエクスプローラ上でTargetTestプロジェクトを右クリックするとメニューが出る。
ここで出るメニューから、[ビルドパス]-[ビルドパスの構成]を選択する。
[ライブラリ]タグを選択し、[ライブラリの追加]ボタンを押下する。
JUnitを選択し[次へ]。
次の画面では[JUnit4]を選択する。
同じく[ビルドパスの構成]を選んで出てくる画面で、[プロジェクト]タグを選択し、[追加]ボタンを押下する。
[Target]にチェックを入れ、[OK]ボタンを押下する。（このTargetは先に作ったプロジェクトのこと）
TargetClassのソースファイルを開き、以下のメソッドを追加。
public void exec(String[] args) {
// ひとまず中身は空でよい
}
TargetClassTestクラスのソースファイルを開き、次のimportステートメントを追加。
import static org.junit.Assert.*;
import org.junit.Test;
import model.TargetClass;
さらに、次のテストメソッドを追加。
@Test
public void testExec() {
try {
TargetClass tc = new TargetClass();
tc.exec(null);
}
catch (Exception e) {
fail();
}
}
パッケージエクスプローラ上でTargetClassTestを右クリックするとメニューが出る。
このメニューから[実行]-[JUnitテスト]を実行し、1/1成功の表示が出れば動作確認完了。
ひとまずこれで、JUnitを動作させる環境が整ったことになる。
迅速なテストを行うため、JUnitのテストはオブジェクト指向分析でいうところのモデル部分のみを対象とすることが望ましい。
たとえば作成したモデル部分のロジックが、リッチクライアントアプリケーション上から使われても、Webアプリケーションから使われても、結果は同じはずである。（モデルとしての動作は、ビューに影響を受けない）
自動テスト対象はモデル部分に限定する、というのが私の個人的な意見である。
ツールが発達してWebアプリなども自動でテストできるようだが、原則は「不変」であるはずのモデルのロジックのみとしたいところ。
標準出力へのprintといった動作も原則NG。
代わりにlog4jなどを使ったロギングで動作状況を把握する、というJUnit以外のトレース手段も本番環境としては用意すべきだと思う。
とはいえ、これは頭が固い人間の意見で、却って効率を落とすことがあるかもしれない。
プロジェクトごとに最善の方法を探っていくべきである。
ここでは動作確認のためのプロジェクト名をTarget、テスト対象のクラスをTargetClassとした。
なお、TargetClassはmodelパッケージの配下とした。（パッケージは作らなくてもよい、便宜上のもの）
テスト用のプロジェクトを、Javaプロジェクトとして作成する。
ここではプロジェクト名をTargetTestとした。
TargetTestプロジェクトにmodel.junit.testパッケージを追加し、その配下にTargetClassTestクラスを追加する。
（ここでもパッケージは作らなくてもよい、便宜上のもの）
パッケージエクスプローラ上でTargetTestプロジェクトを右クリックするとメニューが出る。
ここで出るメニューから、[ビルドパス]-[ビルドパスの構成]を選択する。
[ライブラリ]タグを選択し、[ライブラリの追加]ボタンを押下する。
JUnitを選択し[次へ]。
次の画面では[JUnit4]を選択する。
同じく[ビルドパスの構成]を選んで出てくる画面で、[プロジェクト]タグを選択し、[追加]ボタンを押下する。
[Target]にチェックを入れ、[OK]ボタンを押下する。（このTargetは先に作ったプロジェクトのこと）
TargetClassのソースファイルを開き、以下のメソッドを追加。
public void exec(String[] args) {
// ひとまず中身は空でよい
}
TargetClassTestクラスのソースファイルを開き、次のimportステートメントを追加。
import static org.junit.Assert.*;
import org.junit.Test;
import model.TargetClass;
さらに、次のテストメソッドを追加。
@Test
public void testExec() {
try {
TargetClass tc = new TargetClass();
tc.exec(null);
}
catch (Exception e) {
fail();
}
}
パッケージエクスプローラ上でTargetClassTestを右クリックするとメニューが出る。
このメニューから[実行]-[JUnitテスト]を実行し、1/1成功の表示が出れば動作確認完了。
ひとまずこれで、JUnitを動作させる環境が整ったことになる。
迅速なテストを行うため、JUnitのテストはオブジェクト指向分析でいうところのモデル部分のみを対象とすることが望ましい。
たとえば作成したモデル部分のロジックが、リッチクライアントアプリケーション上から使われても、Webアプリケーションから使われても、結果は同じはずである。（モデルとしての動作は、ビューに影響を受けない）
自動テスト対象はモデル部分に限定する、というのが私の個人的な意見である。
ツールが発達してWebアプリなども自動でテストできるようだが、原則は「不変」であるはずのモデルのロジックのみとしたいところ。
標準出力へのprintといった動作も原則NG。
代わりにlog4jなどを使ったロギングで動作状況を把握する、というJUnit以外のトレース手段も本番環境としては用意すべきだと思う。
とはいえ、これは頭が固い人間の意見で、却って効率を落とすことがあるかもしれない。
プロジェクトごとに最善の方法を探っていくべきである。
[Subversion][インストール]Subversion 1.6.1 インストール
eclipseからも使えるバージョン管理ソフトとして、Subversionを試すことに決め、インストールを行った。
SubversionはCVSのいいところを残して進化させたツールであるとのこと。
WinCVSを使った開発を最近になってもやってきた経緯があるので、技術の流れが早いことを痛感する。
インストールは"Subversion インストール"で出てくるサイトからリンクをたどれば、意外とすぐいける。
インストールの紹介サイトではWindows版ならインストーラ提供、となっているが、実際にはzipだった点が予想外。
ただこれはJava関係ならよくある話で、要はインストールするまでもなく、zipを解凍して適当なディレクトリに置けば、そこがインストールディレクトリになる、というものである。
zipを解凍して、コマンドラインからレポジトリを作成する。
（[インストールディレクトリ]\binにパスを通しておく）
コマンドは、以下の通り。
svnadmin create [レポジトリのディレクトリを指定]
コマンドラインで出るメッセージが「成功」を意味する英語ならOK！
指定したディレクトリに、Subversionが管理に使う様々なディレクトリやファイルが自動生成されているはずである。
次にJava開発プロジェクトなど、管理対象をレポジトリにインポートする。
コマンドは、以下の通り。
svn import [管理対象に加えたいディレクトリのパス] [レポジトリのURL] -m ""
レポジトリがc:\sub_version\manage\repositoryディレクトリであり、管理対象の開発プロジェクトがc:\java\projectであるとする。
レポジトリを作成するコマンドは、
snvadmin create c:\sub_version\manage\repository
レポジトリに管理対象のプロジェクトを追加するコマンドは、
svn import c:\java\project file:///c:/sub_version/manage\repository -m ""
となる。
ここで注意すべきは"file:///c:/sub_version/manage/repository"で、ここを書き間違えやすい。
この表記はブラウザからローカル（自分のPC）のファイルを見るときに指定する方法と同じであり、このように書くことで
c:\sub_version\manage\repository
（↑）このディレクトリを指定したのと同じ意味になる。
ディレクトリの区切りもここだけは"\"ではなく"/"でなければならない。
ブラウザで"file:///c:/～"と入力すれば、実際にローカルPCのディレクトリが見えるはず。
納得いかない場合は、試してみると理解が早い。
ちなみに、自分のPCではなくネットワーク上にあるファイルをレポジトリに登録する場合は、"http://～"に変わる。
ブラウザと同じ指定方法で、管理対象のファイルを指定できるようになっている。
ここまでで、バージョン管理を行うレポジトリ（格納庫）にプロジェクトが登録されたことになる。
後は各開発者が、自分の開発用ディレクトリを作り、レポジトリからプロジェクト全体のソースファイルを取得する。
これをチェックアウトと呼ぶ。
自分の開発用ディレクトリで、以下のコマンドを打つ。
svn checkout file:///c:/sub_version/manage/repository
（↑）こうすると、レポジトリで管理しているプロジェクトの全ファイルが自分の開発用ディレクトリにコピーされる。
ここで何らかのファイルを修正した場合、コミットを実行すればそれがレポジトリに登録され、新しいマスタとなる。
コミットした後に、自分の開発用ディレクトリの中身を全部消して、もう1回チェックアウトを実行すれば、自分がコミットしたファイルも含めた最新版が取得できるはずだ。
チェックアウトやコミットをコマンドラインでやっていくのは面倒であるため、eclipseにプラグインを入れてGUIから操作できるようにすることが多い。
それについては、改めて記述する。
以上、確認が取れたところまで記述。
SubversionはCVSのいいところを残して進化させたツールであるとのこと。
WinCVSを使った開発を最近になってもやってきた経緯があるので、技術の流れが早いことを痛感する。
インストールは"Subversion インストール"で出てくるサイトからリンクをたどれば、意外とすぐいける。
インストールの紹介サイトではWindows版ならインストーラ提供、となっているが、実際にはzipだった点が予想外。
ただこれはJava関係ならよくある話で、要はインストールするまでもなく、zipを解凍して適当なディレクトリに置けば、そこがインストールディレクトリになる、というものである。
zipを解凍して、コマンドラインからレポジトリを作成する。
（[インストールディレクトリ]\binにパスを通しておく）
コマンドは、以下の通り。
svnadmin create [レポジトリのディレクトリを指定]
コマンドラインで出るメッセージが「成功」を意味する英語ならOK！
指定したディレクトリに、Subversionが管理に使う様々なディレクトリやファイルが自動生成されているはずである。
次にJava開発プロジェクトなど、管理対象をレポジトリにインポートする。
コマンドは、以下の通り。
svn import [管理対象に加えたいディレクトリのパス] [レポジトリのURL] -m ""
レポジトリがc:\sub_version\manage\repositoryディレクトリであり、管理対象の開発プロジェクトがc:\java\projectであるとする。
レポジトリを作成するコマンドは、
snvadmin create c:\sub_version\manage\repository
レポジトリに管理対象のプロジェクトを追加するコマンドは、
svn import c:\java\project file:///c:/sub_version/manage\repository -m ""
となる。
ここで注意すべきは"file:///c:/sub_version/manage/repository"で、ここを書き間違えやすい。
この表記はブラウザからローカル（自分のPC）のファイルを見るときに指定する方法と同じであり、このように書くことで
c:\sub_version\manage\repository
（↑）このディレクトリを指定したのと同じ意味になる。
ディレクトリの区切りもここだけは"\"ではなく"/"でなければならない。
ブラウザで"file:///c:/～"と入力すれば、実際にローカルPCのディレクトリが見えるはず。
納得いかない場合は、試してみると理解が早い。
ちなみに、自分のPCではなくネットワーク上にあるファイルをレポジトリに登録する場合は、"http://～"に変わる。
ブラウザと同じ指定方法で、管理対象のファイルを指定できるようになっている。
ここまでで、バージョン管理を行うレポジトリ（格納庫）にプロジェクトが登録されたことになる。
後は各開発者が、自分の開発用ディレクトリを作り、レポジトリからプロジェクト全体のソースファイルを取得する。
これをチェックアウトと呼ぶ。
自分の開発用ディレクトリで、以下のコマンドを打つ。
svn checkout file:///c:/sub_version/manage/repository
（↑）こうすると、レポジトリで管理しているプロジェクトの全ファイルが自分の開発用ディレクトリにコピーされる。
ここで何らかのファイルを修正した場合、コミットを実行すればそれがレポジトリに登録され、新しいマスタとなる。
コミットした後に、自分の開発用ディレクトリの中身を全部消して、もう1回チェックアウトを実行すれば、自分がコミットしたファイルも含めた最新版が取得できるはずだ。
チェックアウトやコミットをコマンドラインでやっていくのは面倒であるため、eclipseにプラグインを入れてGUIから操作できるようにすることが多い。
それについては、改めて記述する。
以上、確認が取れたところまで記述。
[Java][開発][セキュリティ]Java開発関連セキュリティ
Javaの各種開発ツールを使う上で気を付けたいのがセキュリティの問題。
開発用のTomcatしかり、正式なWebサーバとするためにApacheを採用する場合にもいえることだが、ポートが開くためにセキュリティ上の問題が生じる。
いわゆるBOF攻撃は、特定のIPアドレスに対し、特定のデータを送信するだけで、コンピュータの制御権を取られてしまう。（サービスがセグメンテーションバイオレーションで異常終了するだけのこともあり）
ポートが開いていれば、自動的に攻撃の対象となる。
一番良いのはスタンドアロンによる開発。
Webと接続していない環境のローカルマシンでTomcatなどのサーバを立ち上げ、開発を行うのがよい。
少なくともネットに対してポートを開いてはいけない。
しかしこの制約はわざわざ開発用にPCを1台スタンドアロンにする余裕がない人には向かない方法だ。
次善の策としては、Acronisといったハードディスクの内容をすべてバックアップできるツールを使い、いざとなったら5分程度で以前の環境に復旧できるようにすることだ。
もうかなり以前から、ハードディスクに個人情報を一切置かないようにしている。
一瞬「無理」と思われるが、やってみると意外にいける。
インストール時に入力する名前は適当な偽名、組織名等は入力せず。
最重要なメールは携帯で受けられるようにする、といった工夫が必要ではあるが・・・
万一ワーム等で情報が流出すると、絶対に消せなくなってしまう。
いつまでも、どこかで誰かがその流出データを見る可能性を消せなくなる。
それは時として致命的なことだ。
特に社会人として長く職に在り、責任が重くなってくればくるほどそうである。
学生時代には自分の住所や電話番号が分かったところで、どうなるものでもないと考えていたが、今では個人情報を入力しなくてはならないサイトも、かなり考えてから登録の有無を決定している。
開発用のTomcatしかり、正式なWebサーバとするためにApacheを採用する場合にもいえることだが、ポートが開くためにセキュリティ上の問題が生じる。
いわゆるBOF攻撃は、特定のIPアドレスに対し、特定のデータを送信するだけで、コンピュータの制御権を取られてしまう。（サービスがセグメンテーションバイオレーションで異常終了するだけのこともあり）
ポートが開いていれば、自動的に攻撃の対象となる。
一番良いのはスタンドアロンによる開発。
Webと接続していない環境のローカルマシンでTomcatなどのサーバを立ち上げ、開発を行うのがよい。
少なくともネットに対してポートを開いてはいけない。
しかしこの制約はわざわざ開発用にPCを1台スタンドアロンにする余裕がない人には向かない方法だ。
次善の策としては、Acronisといったハードディスクの内容をすべてバックアップできるツールを使い、いざとなったら5分程度で以前の環境に復旧できるようにすることだ。
もうかなり以前から、ハードディスクに個人情報を一切置かないようにしている。
一瞬「無理」と思われるが、やってみると意外にいける。
インストール時に入力する名前は適当な偽名、組織名等は入力せず。
最重要なメールは携帯で受けられるようにする、といった工夫が必要ではあるが・・・
万一ワーム等で情報が流出すると、絶対に消せなくなってしまう。
いつまでも、どこかで誰かがその流出データを見る可能性を消せなくなる。
それは時として致命的なことだ。
特に社会人として長く職に在り、責任が重くなってくればくるほどそうである。
学生時代には自分の住所や電話番号が分かったところで、どうなるものでもないと考えていたが、今では個人情報を入力しなくてはならないサイトも、かなり考えてから登録の有無を決定している。
[eclipse][Pleiades][Tomcatプロジェクト]Eclipse 3.4 Ganymede Pleiades Tomcat プロジェクト作成
プレアデス（Pleiades）にTomcatとTomcatプラグインが最初から入っており、eclipseのメニュー上からもTomcatプロジェクトをいきなり作成できる状態だった。
eclipseからTomcatを起動してコンソールの表示を確認。
Pleiadesに3バージョンも入っているTomcatのうち、Tomcat 5.5.27 を動かしていることが判明。
早速Tomcatプロジェクトを作成して、JSPとサーブレットを動かしてみる。
すると、JSPはすんなり動いたのにサーブレットは動かない。
パス設定の問題かと思い、CATALINA_HOMEの設定をしてみたが動かず。
となると、JSPは動くのにサーブレットが動かない理由は、invokerの設定かと考え、%CATALINA_HOME%/conf/web.xmlを編集。
コメントとなっていたinvokerの設定を有効にすると、サーブレットも動くようになった。（ファイルを"invoker"で検索し、コメントになっている部分のコメントを解除する）
そういえばinvokerはセキュリティ上の問題から、使用が推奨されないのだったか。
web.xmlを手書きで編集しないとダメだった点は痛いが、原因が分かったのでひと安心。
手書きサーブレットは、web.xmlも手書きで登録するか、invokerを使わないとダメなようだ。
サーブレットはStrutsなどを使う場合、ActionServlet（自動で動くサーブレット）となり不要になるため、invokerの設定は再度コメントにしておくこととした。
パス設定も不要なので、CATALINA_HOMEは削除。
eclipseからTomcatを起動してコンソールの表示を確認。
Pleiadesに3バージョンも入っているTomcatのうち、Tomcat 5.5.27 を動かしていることが判明。
早速Tomcatプロジェクトを作成して、JSPとサーブレットを動かしてみる。
すると、JSPはすんなり動いたのにサーブレットは動かない。
パス設定の問題かと思い、CATALINA_HOMEの設定をしてみたが動かず。
となると、JSPは動くのにサーブレットが動かない理由は、invokerの設定かと考え、%CATALINA_HOME%/conf/web.xmlを編集。
コメントとなっていたinvokerの設定を有効にすると、サーブレットも動くようになった。（ファイルを"invoker"で検索し、コメントになっている部分のコメントを解除する）
そういえばinvokerはセキュリティ上の問題から、使用が推奨されないのだったか。
web.xmlを手書きで編集しないとダメだった点は痛いが、原因が分かったのでひと安心。
手書きサーブレットは、web.xmlも手書きで登録するか、invokerを使わないとダメなようだ。
サーブレットはStrutsなどを使う場合、ActionServlet（自動で動くサーブレット）となり不要になるため、invokerの設定は再度コメントにしておくこととした。
パス設定も不要なので、CATALINA_HOMEは削除。
[eclipse][Pleiades][インストール]Eclipse 3.4 Ganymede Pleiades All in Oneインストール
検索で"eclipse 日本語化"で出てくるリンクをたどればすぐにたどりつく。
インストールは圧縮ファイルを展開するだけ。
ただし、パス名が長くなりすぎるとエラーになるため、なるべくインストールするドライブのルートに近いディレクトリで展開する必要がある。
展開後は1GB近くになる大容量だが、何とTomcatまで中に入っている。
eclipse.exeをダブルクリックすると、最初から全て日本語表示。
すばらしい！
まさしく開発者のためにあるような環境だ。
アマテラスプロジェクトおそるべしである。
念のため、Javaプロジェクトを作成して、System.out.printlnで"Hello world"系の出力を出すだけのプログラムを作成してみた。
問題なく動く。
あとはTomcatプロジェクトだが、これもTomcatプラグインをインストールしなくても、最初から入っている模様。
Tomcatプロジェクトについて後で試すこととし、とりあえずインストール成功とみなす。
Tomcatプロジェクトが動かなかったら別途考える。
十分に枯れてそうな完成度なので大丈夫だと思うが・・・
この分だと、Strutsも入ってる？
最初にこれをインストールすればよかった、って感じの万能環境だった。
とりあえずこれまでにインストールしたものと、PATH設定とかでのバッティングもないので、今後はこの環境を使っていく。
（英語版の環境も、英語版でないとできないものがあってはいけないので、念のため残しておく）
インストールは圧縮ファイルを展開するだけ。
ただし、パス名が長くなりすぎるとエラーになるため、なるべくインストールするドライブのルートに近いディレクトリで展開する必要がある。
展開後は1GB近くになる大容量だが、何とTomcatまで中に入っている。
eclipse.exeをダブルクリックすると、最初から全て日本語表示。
すばらしい！
まさしく開発者のためにあるような環境だ。
アマテラスプロジェクトおそるべしである。
念のため、Javaプロジェクトを作成して、System.out.printlnで"Hello world"系の出力を出すだけのプログラムを作成してみた。
問題なく動く。
あとはTomcatプロジェクトだが、これもTomcatプラグインをインストールしなくても、最初から入っている模様。
Tomcatプロジェクトについて後で試すこととし、とりあえずインストール成功とみなす。
Tomcatプロジェクトが動かなかったら別途考える。
十分に枯れてそうな完成度なので大丈夫だと思うが・・・
この分だと、Strutsも入ってる？
最初にこれをインストールすればよかった、って感じの万能環境だった。
とりあえずこれまでにインストールしたものと、PATH設定とかでのバッティングもないので、今後はこの環境を使っていく。
（英語版の環境も、英語版でないとできないものがあってはいけないので、念のため残しておく）
[SWT][インストール]SWT 3.5M6 インストール
記述を忘れていたが、ここまでに記載した内容はいずれもWindows環境にJava開発関連のソフトをインストールする手順である。
Linuxの場合、eclipseやTomcat、MySQLなど一部のツールについては、OSのインストールと同時に入ることもある上、環境設定のやり方が違うので注意が必要。
SWTはJavaのウインドウプログラムサンプルを作るためにダウンロードしてきた。
eclipseのFileメニューからImportを選び、アーカイブファイルのインポートを選択、ダウンロードしてきたzipファイル内にあるアーカイブを指定すると、SWTを使ったGUIプログラムが作れるようになる。
eclipseで簡単なウインドウプログラムを作成し、プログラムが動いたことが確認できた。
インストール成功。
Linuxの場合、eclipseやTomcat、MySQLなど一部のツールについては、OSのインストールと同時に入ることもある上、環境設定のやり方が違うので注意が必要。
SWTはJavaのウインドウプログラムサンプルを作るためにダウンロードしてきた。
eclipseのFileメニューからImportを選び、アーカイブファイルのインポートを選択、ダウンロードしてきたzipファイル内にあるアーカイブを指定すると、SWTを使ったGUIプログラムが作れるようになる。
eclipseで簡単なウインドウプログラムを作成し、プログラムが動いたことが確認できた。
インストール成功。
[MySQL][インストール]MySQL 5.1.33 インストール
Javaからアクセスするデータベースとして、MySQLを選択。
"MySQL ダウンロード"などのキーワードで検索し、Windows用のインストーラをダウンロードする。
インストーラから普通にインストールできる。
カスタムを選択しても、英語の内容をよく読めば問題なくインストールできると思う。（実際、カスタムにした）
標準で付いてくるコンソールプログラムでパスワードを入力するとログインできる。
デフォルトではtestというデータベースディレクトリが用意されている。
use test
（↑）このコマンドを打ってtestデータベースを選択したら、適当にテーブルを作成し、
select * from XXX_TBL
などと打ち込んで、データが取得できればインストール完了。
"MySQL ダウンロード"などのキーワードで検索し、Windows用のインストーラをダウンロードする。
インストーラから普通にインストールできる。
カスタムを選択しても、英語の内容をよく読めば問題なくインストールできると思う。（実際、カスタムにした）
標準で付いてくるコンソールプログラムでパスワードを入力するとログインできる。
デフォルトではtestというデータベースディレクトリが用意されている。
use test
（↑）このコマンドを打ってtestデータベースを選択したら、適当にテーブルを作成し、
select * from XXX_TBL
などと打ち込んで、データが取得できればインストール完了。
[Tomcat][インストール]Tomcat 5.5.27 インストール
TomcatはサーブレットやJSPといった、サーバサイドのJavaアプリケーションを開発するために必要となる。
いわゆるWebサーバである。
TomcatはWebサーバとしての機能が弱く、セキュリティにも問題があるので、実際のWebアプリケーションではほとんど採用されないが、イ ンストールしてeclipseにTomcatプラグインを付ければ、開発マシンですぐにデバッグできる環境が整うとあって、開発にはよく利用される。
検索で"Tomcat ダウンロード"などのキーワードを指定し、インストーラをダウンロードする。
eclipseと同じく、インストールパス名に半角スペースやドットが入るといけないので、ドライブ直下のディレクトリを指定してインストール。（デフォルトだと半角スペース入りの"Program Files"配下などにいってしまうため、この点は注意する必要がある）
インストールが完了したら、標準で付いているモニタプログラムかシステム管理 - サービスからapache tomcatサービスを起動する。
ブラウザを開き、
http://
と入力して、tomcatのページが表示されればインストール完了。
なお、Vistaでは標準添付のモニタプログラムでアクセス拒否エラーが出てしまう。
なので面倒だったが、システム管理 - サービスから起動してテストを行った。
いわゆるWebサーバである。
TomcatはWebサーバとしての機能が弱く、セキュリティにも問題があるので、実際のWebアプリケーションではほとんど採用されないが、イ ンストールしてeclipseにTomcatプラグインを付ければ、開発マシンですぐにデバッグできる環境が整うとあって、開発にはよく利用される。
検索で"Tomcat ダウンロード"などのキーワードを指定し、インストーラをダウンロードする。
eclipseと同じく、インストールパス名に半角スペースやドットが入るといけないので、ドライブ直下のディレクトリを指定してインストール。（デフォルトだと半角スペース入りの"Program Files"配下などにいってしまうため、この点は注意する必要がある）
インストールが完了したら、標準で付いているモニタプログラムかシステム管理 - サービスからapache tomcatサービスを起動する。
ブラウザを開き、
http://
と入力して、tomcatのページが表示されればインストール完了。
なお、Vistaでは標準添付のモニタプログラムでアクセス拒否エラーが出てしまう。
なので面倒だったが、システム管理 - サービスから起動してテストを行った。
[JDK][インストール]JDK 1.6.0_13 インストール
JDKのバージョンは1.6.0_13。
JDKはJava Development Kitの略称。
ダウンロードしたファイルをダブルクリックするとインストーラが起動する。
問題はダウンロードにあり。
"jdk ダウンロード"などで検索し、リンクをたどっていかないと場所が分からない。
サンマイクロシステムズは経営危機にあるというが、管理がずさんになってきている？
ともかく、素人にはリンクをたどってたどりつくのが難しい位置にあると思う。
少なくともページを見てすぐにたどりつけるようにはなっていない。
（JREなら簡単に入手できるが・・・）
インストール後、環境変数にJAVA_HOMEを追加し、jdkをインストールしたディレクトリを設定する。
さらに環境変数PATHに%JAVA_HOME%\binを追加すると、コマンドプロンプトでJavaソースファイルがコンパイルできるようになる。
サーブレットやJSP、その他のJavaプログラムを手書きすることはもちろん可能である。
よって、JDKのみでも開発を行っていくことは不可能ではない。
しかしこのままでは余りに環境が貧弱なため、通常は統合開発環境であるeclipseをインストールし、Java開発を支援するいくつかのプラグインを追加して使うことになる。
JDKはJava Development Kitの略称。
ダウンロードしたファイルをダブルクリックするとインストーラが起動する。
問題はダウンロードにあり。
"jdk ダウンロード"などで検索し、リンクをたどっていかないと場所が分からない。
サンマイクロシステムズは経営危機にあるというが、管理がずさんになってきている？
ともかく、素人にはリンクをたどってたどりつくのが難しい位置にあると思う。
少なくともページを見てすぐにたどりつけるようにはなっていない。
（JREなら簡単に入手できるが・・・）
インストール後、環境変数にJAVA_HOMEを追加し、jdkをインストールしたディレクトリを設定する。
さらに環境変数PATHに%JAVA_HOME%\binを追加すると、コマンドプロンプトでJavaソースファイルがコンパイルできるようになる。
サーブレットやJSP、その他のJavaプログラムを手書きすることはもちろん可能である。
よって、JDKのみでも開発を行っていくことは不可能ではない。
しかしこのままでは余りに環境が貧弱なため、通常は統合開発環境であるeclipseをインストールし、Java開発を支援するいくつかのプラグインを追加して使うことになる。
[eclipse][インストール]eclipse 3.4.2 インストール
eclipseのバージョンは3.4.2。
ganymedeと呼ばれる版。
サイトからダウンロードしてきたzipファイルを解凍すると、eclipseのexeも含めたインストールディレクトリが形成される。
インストールパスに半角スペースやドットがあると、開発時に問題を起こしていたらしいので、慣習的に空いているドライブの直下に置くことが多いようだ。
最も多いのが当然ながらCドライブ直下。
念のため、ドライブ直下のパスにインストールすることに。
解凍したファイルをコピーするのみとなっており、一般的なインストーラを使った手順ではない。
別途JDK（Java Development Kit）をインストールしており、環境変数にJAVA_HOMEが設定されていること、PATHに%JAVA_HOME%\binが追加されていることが起動の条件。
exeをダブルクリックして、無事に起動すれば成功。
メニューからJavaプロジェクトを作成し、System.out.printlnで"Hello world!"でも出力すれば、動作確認も完璧。
ひとまずJava開発のプラットフォームを手に入れたことになる。
ganymedeと呼ばれる版。
サイトからダウンロードしてきたzipファイルを解凍すると、eclipseのexeも含めたインストールディレクトリが形成される。
インストールパスに半角スペースやドットがあると、開発時に問題を起こしていたらしいので、慣習的に空いているドライブの直下に置くことが多いようだ。
最も多いのが当然ながらCドライブ直下。
念のため、ドライブ直下のパスにインストールすることに。
解凍したファイルをコピーするのみとなっており、一般的なインストーラを使った手順ではない。
別途JDK（Java Development Kit）をインストールしており、環境変数にJAVA_HOMEが設定されていること、PATHに%JAVA_HOME%\binが追加されていることが起動の条件。
exeをダブルクリックして、無事に起動すれば成功。
メニューからJavaプロジェクトを作成し、System.out.printlnで"Hello world!"でも出力すれば、動作確認も完璧。
ひとまずJava開発のプラットフォームを手に入れたことになる。
登録:
投稿 (Atom)