Javaってまだいけますか ログ

すごく参考になったのでメモ。

java in the box

struts-config.xmlでアクションのパスを”/xxxx"みたいに定義してて、どっかの処理でそのパスから本当のパス("/コンテキストルート/xxxx.do"）を取得したい場合。

import org.apache.struts.taglib.TagUtils;

TagUtils.getInstance().getActionMappingURL("/xxxx", pageContext);

で実際のパスが取得できました。

プロジェクトの共通基盤を作る時に重宝しました。

照会画面なんかで情報を表示する時に便利かと思って作りました。
bean:writeタグクラスを継承して必要なとこだけいじります。

import javax.servlet.jsp.JspException;

import org.apache.commons.validator.GenericValidator;
import org.apache.struts.taglib.TagUtils;
import org.apache.struts.taglib.bean.WriteTag;

/**
 * 複数行テキストの改行をBRタグに変換して出力します。
 */
public class NlToBr extends WriteTag {

  /*
   * (non-Javadoc)
   * @see org.apache.struts.taglib.bean.WriteTag#formatValue(java.lang.Object)
   */
  protected String formatValue(Object valueToFormat) throws JspException {
    if (!(valueToFormat instanceof String)) {
      throw new IllegalArgumentException("文字列以外の項目には利用できません。");
    }
    
    String s = (String) valueToFormat;
    
    if(GenericValidator.isBlankOrNull(s)) {
      return s;
    }
    
    // 自前でエスケープする為
    super.setFilter(false);
    
    // 先にエスケープしてから改行変換
    return TagUtils.getInstance().filter(s).replaceAll("\\r\\n|\\n", "<br />");
  }

}

TLDファイルもbean:writeからこぴぺしてこんな感じで作成。

<tag>
  <name>NlToBr</name>
  <tagclass>jp.co.xxxxx.NlToBr</tagclass>
  <bodycontent>empty</bodycontent>
  <attribute>
  <name>ignore</name>
  <required>false</required>
  <rtexprvalue>true</rtexprvalue>
  </attribute>
  <attribute>
  <name>name</name>
  <required>true</required>
  <rtexprvalue>true</rtexprvalue>
  </attribute>
  <attribute>
  <name>property</name>
  <required>false</required>
  <rtexprvalue>true</rtexprvalue>
  </attribute>
  <attribute>
  <name>scope</name>
  <required>false</required>
  <rtexprvalue>true</rtexprvalue>
  </attribute>
</tag>

使い方。

<ex:NlToBr name="xxxForm" property="body" />

カスタムタグって一部では評判悪かったりしますが、アーキテクト的な立場で開発者にある程度実装を強制したい場合に便利だと思いました。
１つのシステムの入力形式や表示形式って実はある程度分類して形式化できるので、それぞれ専用のカスタムタグを始めに作ってしまうと、HTMLの出力（スタイルシートの指定とかsize指定とかバリデーション用Javascriptとか）が統一できて良い感じでした。

Windows環境でDB2から取得したデータをファイルに書き出すという処理で、ダッシュ「―」や波ダッシュ「～」や全角マイナス「－」が含まれていたときに文字化けがおきました。

調べてみると、

問題になることが多いのはShift_JISとそのサブセット(Windows-31Jなど)とのUNICODEのコンバータです。これらのコンバータにはSJIS、MS932、 Cp943Cなどの複数のコンバータが存在し、これらのコンバータ間で文字コードマッピングが異なるために一部の文字が文字化けを起こします。
DB2ではCp943Cのコンバータを使用すれば上記の文字について文字化けを回避することできます。

とのこと。

ということで、以下のようにしたら解消しました。

System.out.println(new String(ret.getBytes("Cp943C"), "MS932"));

参考にしたサイト

String target = "㍼"; // 文字コードは0x878f

// Stringからコードへ
char[] buf = new String(target.getBytes("MS932"), "8859_1").toCharArray();
System.out.println(Integer.toHexString(buf[0]) + Integer.toHexString(buf[1]));
// →878f

// コードからStringへ
buf = new char[]{(char)Integer.parseInt("87", 16), (char)Integer.parseInt("8f", 16)};
System.out.println(new String(new String(buf).getBytes("8859_1"), "MS932"));
// →㍼

参考にしたサイト

お恥ずかしながら、今までSerializableについてあまり意識してませんでした。
「ＲＭＩで受け渡すオブジェクトとかでは宣言しとけばいいのかな…」ぐらいの軽い気持ちでした。

しかし、従事していたプロジェクトでこれが原因の不具合が発生してしまいました。
要はクラスタ環境で稼動しているアプリケーションで、Serializableを実装していない属性がセッション情報に格納されており、セッションレプリケーションが行なわれないという現象でした。
ローカルや検証環境ではクラスタ構成を組むことが無いので気づきづらいですよね…。

開発規約として「Serializableを実装しましょう」では弱いので、こんな感じで専用クラスを作って利用を強制する方がよいでしょうか。
（EclipseでHttpSession.setAttributeを検索すればチェックできますし。）

public class SessionManager {
	
	/**
	 * セッションにSerializableを実装したオブジェクトを格納します。
	 * 
	 * @param request
	 * @param name 
	 * @param value 
	 */
	public static void setAttribute(HttpServletRequest request, String name, Serializable value) {
		request.getSession().setAttribute(name, value);
	}
	
	/**
	 * セッションからSerializableを実装したオブジェクトを取り出します。
	 * @param request
	 * @param name
	 * @return
	 */
	public static Serializable getAttribute(HttpServletRequest request, String name) {
		return (Serializable) request.getSession().getAttribute(name);
	}
}

テストフェーズにクラスタ環境を意識したテストをしておくことも重要ですよね。
反省。

SerializableなクラスのメンバもSerializableな必要があるようですがjava.lang.Stringやプリミティブ型のほか、Java標準のコレクションなどであれば問題ないようです。（ArrayList.subList()の戻り値など、一部例外有り）

その他参考にしたサイト

Serializableについて
Serializableについて(java API)

Tomcat5でのクラスタリングについて

ググってみるといろんな方がブログで取り上げてるので、結構みんな一回は通る道っぽいですねｗ

maven-war-pluginを利用したWARプロジェクトで、pom.xmlで不要なファイルやフォルダを除外したり、リリース用のweb.xmlを指定したりする場合のメモ。

・<warSourceExcludes>タグ
　除外するリソースをカンマ区切りで指定する。ex. **/logs/**,**/.*

・<webXml>タグ
warファイルに含めるweb.xmlをpom.xmlからの相対パスで指定する。

参考にしたサイト１

参考にしたサイト２

つづきはこちら

Maven2でマルチプロジェクト構成にする場合、以下のような構成だと、Eclipseでバージョン管理システムに登録するのに困ります。

親P
├子P1
└子P2

全部同じ階層に配置する場合のpom.xmlの記述は以下の通り。

・親Pのpom.xml

  <modules>
    <module>../子P1</module>
    <module>../子P2</module>
  </modules>

・子Pのpom.xml

  <parent>
    <artifactId>子P</artifactId>
    <groupId>・・・</groupId>
    <version>・・・</version>
    <relativePath>../親P/pom.xml</relativePath>
  </parent>

relativePathを使うのがポイント。
これで親子ともどもEclipseでプロジェクトとしてインポートしてバージョン管理システムに登録できます。

以下の構成でEARプロジェクトを作成する際のpom.xmlの記述方法のメモ。

- Sample　（POMプロジェクト）
- Sample-ear　（EARプロジェクト）
- Sample-war　（WARプロジェクト）

つづきはこちら

Google先生を参考に、

<tasks if="パラメータ"> 
  Antの処理 
</tasks> 

とやってみたがうまく動かない。っていうかifとかちゃんと見てんのか。
という感じだったので、別の方法で試してみました。
（いや、もちろん僕がどっか間違ってることは確かですけど…）

---- pom.xml -----

<plugin> 
    <artifactId>maven-antrun-plugin</artifactId> 
    <executions> 
      <execution> 
        <phase>compile</phase> 
        <configuration> 
          <tasks> 
            <echo message="run build.xml" /> 
            <ant antfile="build.xml" target="${ant.target}" inheritRefs="true"/> 
          </tasks> 
        </configuration> 
        <goals> 
          <goal>run</goal> 
        </goals> 
      </execution> 
    </executions> 
  </plugin> 

---- build.xml ----

<?xml version="1.0" encoding="Shift_JIS"?> 
  <project name="sample" basedir="." default="target_it"> 
    <target name="target_ut"> 
      <echo message="process is none" /> 
    </target> 
     
    <target name="target_it"> 
      <echo message="including config_it.properties" /> 
      <copy file="resources/config_it.properties"  
        tofile="target/classes/config.properties" 
        overwrite="true" /> 
    </target> 

    <target name="target_release"> 
      <echo message="including config_release.properties" /> 
      <copy file="resources/config_release.properties"  
        tofile="target/classes/config.properties" 
        overwrite="true" /> 
    </target> 
  </project> 

としてから、

$ mvn -Dant.target=target_it package 

とすることで切り替えができました。