Java Archive

Cubby 1.0.0-RC1がリリースされました。詳細はid:agtさんのCubby 1.0.0-RC1 リリース案内をどうぞ。今回のバージョンから@Urlアノテーションが@Pathと@Acceptに変更・分割されたので、既に使っていた方は書き換える必要があります。@AcceptはPOSTやGETなどのリクエストメソッドを限定する新しい仕様なので、今までと同じPOSTもGETも区別しない挙動で良ければ、@Urlを@Pathに置換でサクっと書き換えるだけでOK。

ってのを長々書いてたものの、Mailmanの対応してる時に書いてたやつ誤って消してしまった。。短く書くと、今までAbstractActionとかCommonAction、Dto、Dxo、Service、Logicとかいろいろ冗長に書いてたけど、僕みたいに一人で作るならここまでがっちり組まなくても良かったんだなーっと思ったという内容。もちろん複数人だったり作るアプリによってはそっちの方が適してる場合も有り。1個づつ良いと思ったことも書いてたけどもう1回書くの面倒なので以下省略。

あと12/30日にCubbyに入門して、上記の組み合わせ – S2JDBC + S2Directory使った小さなアプリが1/2に完成して昨日の夜から配備したよってのもあった。

CubbyのRESTっぽいURIが個人的に激しく良いです。でも、Actionの単体テストがどうしたら良いかよくわからないです。org.seasar.cubby.examples.todo.action.LoginActionに対して次のようなテストを書くと。

public class LoginActionTest extends S2TigerTestCase {
    private LoginAction loginAction;

    protected void setUp() throws Exception {
        include("app.dicon");
    }

    public void testLogin() {
        loginAction.sessionScope = new HashMap<String, Object>();
        loginAction.userId = "test";
        loginAction.password = "test";
        loginAction.process();
        assertEquals(1, loginAction.sessionScope.size());
    }
}

次のぬるぽが出ちゃってテスト出来ません。

java.lang.NullPointerException
    at org.seasar.cubby.controller.impl.ActionContextImpl.getAction(ActionContextImpl.java:63)
    at org.seasar.cubby.controller.impl.ActionContextImpl.getFormBean(ActionContextImpl.java:92)
    at org.seasar.cubby.interceptor.InitializeInterceptor.setupForm(InitializeInterceptor.java:68)
    at org.seasar.cubby.interceptor.InitializeInterceptor.invoke(InitializeInterceptor.java:43)
    at org.seasar.framework.aop.impl.NestedMethodInvocation.proceed(NestedMethodInvocation.java:53)
    at org.seasar.framework.container.customizer.AspectCustomizer$LookupAdaptorInterceptor.invoke
      (AspectCustomizer.java:195)
    at org.seasar.cubby.examples.todo.action.LoginAction$$EnhancedByS2AOP$$787d6a$$MethodInvocation$$process2.proceed
      (MethodInvocationClassGenerator.java)
    at org.seasar.extension.tx.RequiredInterceptor.invoke(RequiredInterceptor.java:48)
    at org.seasar.cubby.examples.todo.action.LoginAction$$EnhancedByS2AOP$$787d6a$$MethodInvocation$$process2.proceed
      (MethodInvocationClassGenerator.java)
    at org.seasar.cubby.examples.todo.action.LoginAction$$EnhancedByS2AOP$$787d6a.process
      (LoginAction$$EnhancedByS2AOP$$787d6a.java)
    at org.seasar.cubby.examples.todo.action.LoginActionTest.testLogin(LoginActionTest.java:25)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at junit.framework.TestCase.runTest(TestCase.java:168)
    at org.seasar.framework.unit.S2FrameworkTestCase.doRunTest(S2FrameworkTestCase.java:519)
    at org.seasar.extension.unit.S2TestCase.doRunTest(S2TestCase.java:103)
    at org.seasar.framework.unit.S2TigerTestCase.doRunTest(S2TigerTestCase.java:82)
    at org.seasar.framework.unit.S2FrameworkTestCase.runBare(S2FrameworkTestCase.java:308)
    at org.seasar.framework.unit.S2TigerTestCase.runBare(S2TigerTestCase.java:66)
    at junit.framework.TestResult$1.protect(TestResult.java:110)
    at junit.framework.TestResult.runProtected(TestResult.java:128)
    at junit.framework.TestResult.run(TestResult.java:113)
    at junit.framework.TestCase.run(TestCase.java:124)
    at junit.framework.TestSuite.runTest(TestSuite.java:232)
    at junit.framework.TestSuite.run(TestSuite.java:227)
    at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

とりあえずValidationだけをテストするか、Helper MethodもしくはServiceとして実装してそっちでテストかな？。SAStrutsだと返り値がパスを表したStringなので単体テストしやすいです。

と、RESTっぽいURIを持つCubbyとSAStruts の良いとこどりがあれば良いのかも？

なんだかんだで予定より3週間も遅れてしまいましたが無事リリースできました。

この日記を見られているか判りませんが、今回のリリースまでに多くのバグ・要望を出していただいた鈴木さん(MLより)、海野さん(MLより)ありがとうございました。さらに、S2DirectoryTigerのベースとなったソースコードをご提供いただいたid:shot6さんありがとうございました。

• 今回のリリースに関して

S2Directory 0.5 以前はコネクションの解放に問題があるため、今回リリースした 0.6 を利用することをお奨めします。

今回のリリースによる大きな機能追加として、SSL/TLS接続とATTRIBUTE/COLUMNアノテーションが利用できるようになりました。また、実験的にコネクションプーリング機能を追加しました。

• 設定参考: http://s2directory.sandbox.seasar.org/ja/documentation/configuration.html
  • directory.dicon に設定が必須ではない設定項目が追加されました。
    • 新しい機能を利用しない場合、今までと同じ設定で問題ありません。
  • directorydao.dicon に設定項目が増えました。
    • 独自に directorydao.dicon をカスタマイズしている場合、修正が必要です。多くの場合、directorydao.dicon は独自に用意する必要はありません。

また、S2DirectoryTigerを併用することで、Tigerアノテーションを利用できるようになりました。

• それぞれのダウンロードはこちらからどうぞ。

http://s2directory.sandbox.seasar.org/ja/downloads.html

• Maven2からのご利用はこちらを参照ください。

http://www.seasar.org/wiki/index.php?Maven2RepoRemote

• S2Directoryプロジェクトサイト

http://s2directory.sandbox.seasar.org/

バグや不具合などあれば、この日記かMLまでご連絡よろしくお願いします。

準備中にちょっとバグっぽいのがあって時間が無くなりました。結局バグではなく現状で問題なかったので、家に帰ってご飯とお風呂入ってまったりして、日が変わった頃にリリースします。Mavenリポジトリにはもうあったりします。

あと、リリース手順忘れてちょっと悩んだ。

うわーー。

• https://www.seasar.org/svn/s2dao/trunk/s2dao/

じゃなくて

• https://www.seasar.org/svn/s2dao/branches/s2dao-1.0.x/

こっちだったのか・・・。

ここ3日間で前者に併せてS2Directoryのソース直してしまった。。そして、いろいろ直したのは直す前の方が新しいかったっぽい。。

DaoMetaDataFactoryImplにHotDeploy用のinitializedが無くなってておかしいなと思いつつ、S2Container側でなんか対応したのが入ったのかなと思いS2Directory修正してたのがやっぱしHot deployでエラー吐くから気付いた。。

うーん、以前の状態に戻したいけど、その間にSSL/TLS対応とかいろいろ入れたからぐちゃぐちゃになっちゃいそうだ。1からまた直そう。

[16:12追記] 元に近い形に戻ってとりあえずHot deployで動くようになった。0.6-SNAPSHOTでMavenにSNAPSHOTをdeploy済み。

DevLoader改変で作ったパッチをSysdeoのサポート宛に送ってたんだけど、中の人から返事が来て次のリリースに入れてくれるそうです。調子に乗って、devloaderはjar形式で、Sysdeo/SQLI Eclipse Tomcat Launcher pluginはupdate site形式でリリースして欲しいってお願いしてみました。こっちも取り入れてくれると嬉しいな。

日付超える前にコードは出来てたのになぜかMavenが言うこと聞かなかった。

• 症例1: 同じソースが違うマシンでmvn testが失敗する
  • 例外: There are some test failure.っと普通にテストに失敗
  • 解決方法: ローカルにキャッシュされてる$M2_REPO\org\apache\maven 以下をすべて削除

• 症例2: 同じソースが違うマシンでmvn deployが失敗する
  • 例外: Connection timed out: connect
    • [INFO] Repository ‘maven.seasar.org’ will be blacklisted
  • 解決方法: ローカルリポジトリ全部削除しても未だ解決せず…

症例1と症例2が2台のマシンで別々に問題だったため、どっちからもmvn deployが出来ないという罠にはまりました。結局症例1が解決したのでそっちのマシンでdeployしました。症例2はまだ未解決。

[12/10 16:16追記] ファイアウォールのせいだった。リモートデスクトップで作業してた時はポップアップが表示されないらしい。

前回Windows Vista 64-bit版でEclipseで調べたものに、32-bit版JDKとAptena、Flex Builderについても動作確認してみました。結論は、開発環境やクライアント環境なら32-bit版を使えばXP 32-bit時代と何も変わらず、問題ないっぽいです。Eclipseベースのソフトウェアもすべて同じです。以下、一覧。

[Tips] Vista 64-bit版であっても32-bit版のJDKやEclipseは動きます。Vista 64-bit版だから32-bit版アプリケーションは動かないなんてことはJDKやEclipseに限らず多くの場合ありません。

• Eclipse本体
  • JDK 32-bit版を使えば3.4系じゃなくても動く
  • JDK 64-bit版は今のところ3.4以降の64-bit版のみ動く
  • Eclipse WPF版はベースとなる32-bit/64-bit版と同じ結果
  • Eclipse 3.3.1.1 32-bit版とJDKの組み合わせ一覧 (3.3系の64-bit版は今のとこない)
    • OK: JDK 1.4.2_16 32-bit版
    • OK: JDK 1.5.0_13 32-bit版
    • OK: JDK 1.6.0_03 32-bit版
    • NG: JDK 1.5.0_13 64-bit版
    • NG: JDK 1.6.0_03 64-bit版
  • Eclipse 3.4M3 32-bit版とJDKの組み合わせ一覧
    • OK: JDK 1.4.2_16 32-bit版
    • OK: JDK 1.5.0_13 32-bit版
    • OK: JDK 1.6.0_03 32-bit版
    • NG: JDK 1.5.0_13 64-bit版
    • NG: JDK 1.6.0_03 64-bit版
  • Eclipse 3.4M3 64-bit版とJDKの組み合わせ一覧
    • NG: JDK 1.4.2_16 32-bit版
    • NG: JDK 1.5.0_13 32-bit版
    • NG: JDK 1.6.0_03 32-bit版
    • OK: JDK 1.5.0_13 64-bit版
    • OK: JDK 1.6.0_03 64-bit版

• Aptana Studio 1.0
  • ベースとなるEclipseのバージョンと一緒
  • Aptana Studio 1.0 (32-bit版のみ) とJDKの組み合わせ一覧
    • OK: JDK 1.4.2_16 32-bit版
    • OK: JDK 1.5.0_13 32-bit版
    • OK: JDK 1.6.0_03 32-bit版
    • NG: JDK 1.5.0_13 64-bit版
    • NG: JDK 1.6.0_03 64-bit版

• Flex Builder 2
  • %FLEX_BUILDER_HOME%\jre\ 以下に JRE 1.4.2_12 32-bit版を持っているので、環境変数に指定したJAVA_HOMEはデフォルトでは影響しない
    • なので、Vista 64-bitでも問題なく利用可

さらに今回32-bit版を入れて気付いたのですが、64-bit版JDKには、IEとFirefoxのJava Plug-Inが入っていませんでした。というわけで、この点からも現時点で開発環境やクライアント環境なら32-bit版を使った方が良いようです。

よく考えたらJDKとそれに関連するものの32-bit/64-bit版は揃えましょうという普通な結果だったけど、これで今後無駄に迷ったり、ハマったりしなくなるのでまぁ良かったかな。

昨日のDevLoader、JDK1.5でコンパイルしてたのをJDK1.4でコンパイルし直してアップし直しました。