Google App EngineのJava版「Stax」を触ってみました

Amazon EC2上で提供されるJava版PaaSサービス「Stax」をちょっと触ってみました。今のところはβサービスで、まだ実装されていない機能もあったりしますが無料で試すことができます。
「Google App EngineのJava版」としてニュース記事等でも紹介されています。

Java対応のGoogle App Engineとも言うべき「Stax Networks」ローンチ
http://jp.techcrunch.com/archives/20081216stax-networks-launches-google-app-engine-for-java/


用意されている環境

• Apache Tomcat/6.0.16
• MySQL/5.0.51

要するにServlet2.5/JSP2.1環境を使えるってことですね。JVMはJavaSE5相当のようです。
GoogleもSalesforce.comも、Servletコンテナにはより軽いResineを採用していますが、ここはTomcatですね。


サポートするフレームワーク

• Apache Struts（ただし、1.xではなく2.0.11）
• Apache Wicket
• Adobe Flex/BlazeDS
• Google Web Tool Kit
• Adobe ColdFusion 8
• JRuby on Rails

とかドキュメントには書いてありますが、アプリケーションの初期作成時のテンプレートとして、デフォルトで必要なライブラリを入れてくれて、最低限の設定済みのxmlファイル類を入れてくれるってだけです。
逆に、WEB-INF/libにライブラリをつっこんで、web.xmlを編集して、WEB-INFに必要な設定ファイルを追加すれば他のフレームワークも使えます。DI/AOPコンテナもORマッピングフレームワークも使えます。
Struts1.3.8/Spring2.5.6/iBATIS2.3.4とか、JSF1.2RI/Spring2.5.6/Hibernate3.3.1とか、試してみたら動きました。この分ならSeasar2を使ったアプリも問題なく動作するでしょう。


アカウントの作成
StaxのWebサイト http://www.stax.net/ へ行きます。



「Apply for the Beta」をクリックしてサインアップ画面へ行き、メールアドレスを入力して送信すると認証メールが送られてくるので、そこに書いてあるURLにアクセスするとサインアップ終了です。簡単です。



改めてStaxのWebサイトからログインするとアプリケーション管理画面に入れます。



管理画面では、TomcatのログやApacheのアクセスログ等の参照、アプリケーションの作成・DBの作成・設定・パフォーマンスやアクセス監視モニタの参照等を利用できます。




アプリケーションの作成
管理画面左側メニューの「Create App」をクリックすると、アプリケーションを作成できます。ユニークな名前を付けましょう。Application Core Runtimeからフレームワークを選べますが、前述の通り、Servlet2.5/JSP2.1環境で動作するものなら好きなモノを使えます。用意されているもの以外のフレームワークを使うのなら「Basic Servlet and JSP」を選択してもかまいません。



Stax SDK http://stax-downloads.s3.amazonaws.com/sdk/stax-sdk-0.2.12-dist.zip をダウンロードして解凍しておきます。
http://www.stax.net/appconsole/createapp から、任意の名前のアプリケーションを作成します。
解凍したディレクトリ中の「Stax Console」ショートカットを起動します。
コマンドラインコンソールが起動するので、そこから
stax getapp -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
を実行すると、アプリケーションのひな形がダウンロードされます。このひな形はEclipseプロジェクトになっているので、そのままEclipseへインポート可能です。でもこのプロジェクトはWTP互換じゃないのが残念です。


アプリケーションの構造

• webapp: JavaEE Webアプリケーションディレクトリ
• src: Java ソースファイルディレクトリ
• conf/stax-application.xml: Stax デプロイメントディスクリプタ

webappディレクトリの中は通常のServletアプリと同じなので、WEB-INF/libに好きなライブラリを入れたり、WEB-INF/web.xmlを編集したり、設定ファイルやTLDを追加したり、自由にできます。


DBの作成
管理画面左側メニューの「Create DB」をクリックすると、アプリケーションを作成できます。任意のDB名、ユーザー名、パスワードを設定します。



DB作成後、テーブルやら何やらを作成するには、なんとTCP:3306が開いているのでMySQL Query Browser や mysql コマンドが使えます（＾＾；（←いいのか？）
アプリケーションのconfディレクトリにあるstax-application.xmlに、下記の設定を追記します。

<resource name="jdbc/db01" auth="Container" type="javax.sql.DataSource">
<param name="username" value="[ユーザ名]" />
<param name="password" value="[パスワード]" />
<param name="url" value="jdbc:stax://[DB名]" />
</resource>

Javaアプリケーションからは、JNDI参照名「java:comp/env/jdbc/[DB名]」でLookupできます。


アプリケーションのデプロイと動作確認
コマンドラインから
stax deploy -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
とすると、作成したアプリケーションをアップロードできます。
Antを使ってWARファイルからのデプロイも可能です。WARファイルをそのままアップロードできるUIがあればいいのに。。。

次のURLからアプリケーションの動作を確認できます。
http://[アプリ名].[ユーザ名].staxapps.net/

何度アップロード/デプロイし直しても反映されるので、クラスローダはカスタマイズしていじっているっぽいですね。Tomcatのデフォルトのリロード機能ではヒープメモリがすぐに破綻しますから。

[追記]
サーバのログを見るとTomcatまんま再起動しているっぽいです。

一度デプロイしたアプリケーションは削除できません（＾＾；削除機能はまだ未実装のようです。


ちょっと触った所感
Tomcat/MySQL/Eclipse環境に慣れた人ならすぐに開発できるのが良いですね。フレームワークもお仕着せのものだけでなく好きなものを選べますし、使い慣れたRDBがそのまま使えます。Python/Django/webappsにどうしてもなじめず、Google App Engineを放り出してしまった私には嬉しいポイントです。
懸念としては、サーバの信頼性・可用性・セキュリティと正式サービス開始後の料金体系です。まあ、これはすべてのクラウドサービスに言われていることですが。Amazon E2Cを利用しているのでこのレベルではある程度の信頼性はありますが、その上で動作しているアプリケーションサーバレベルではStaxの技術力・資金力・信頼性が問われるところでしょう。

Amazon EC2上に構築されたってのが、次世代のビジネスモデルを予感させます。自前のデータセンターを持たずにSaaS/PaaS事業を展開するという例はこれからも増える可能性がありますね。

Spring Framework 3.0 M1 のEL式

Spring Framework 3.0 M1 のEL式


    <bean id="beanA" class="com.developpez.hikage.spring3.BeanA" >
        <property name="valueTwo" value="test"/>
    </bean>

    <bean id="beanB" class="com.developpez.hikage.spring3.BeanB" >
        <property name="valueOne" value="#{beanA.valueTwo}">
        </property>
    </bean>


とか書ける実行時評価式のようです。

Spring Framework 3.0M1 リリース

Spring Frameworkの次期バージョン3.0の最初のマイルストーンがリリースされましたね。
http://blog.springsource.com/2008/12/05/spring-framework-30-m1-released/

ドキュメントはまだJavadocしかありません。

BeanFactory#getBean()がGenerics対応してます。
・・・WebアプリではWebApplicationContextを使うからあまり関係ありませんが（笑）

@Configurationや@Beanは入っていませんね・・・
3.0で入ると言われていたSpring Java Config は、今のところは標準でバンドルされていないようです。

Changelogをざっと見たところ、主要なポイントはこんな感じです。

• JavaSE5サポート（Genericsや可変長引数など）
  
• JUnit 4.5 および JRuby 1.1 のサポート
  
• WebLogic 8.1 および WebSphere 5.1 のサポートを削除
  
• ネイティブ TopLink API のサポートを削除（JPA使いましょう）
  
• Commons Attributes のサポートの削除（Java5のアノテーションを使いましょう）
  
• Jakarta JSTL for JSP1.2 のサポートを削除（JSP2.0を使いましょう）
  
• Struts 1.x Action delegation をサポート（DelegatingRequestProcessorを使いましょうってことかな？）
  
• ContextLoaderServlet および Log4jConfigServlet を削除（もう要らないよね？ってことかな？）
  
• JUnit 3.8は非推奨に
  
• Bean定義で#{...}式をサポート
  
• Atom/RSS Feed View を追加
  
• "spring:url" および "spring:param" JSP タグを追加
  

Atom/RSS Feed View というのはAtom/RSSフィードの生成・パブリッシング機能で、Project ROMEの機能を利用しています。

あとは、Spring ELというのが導入され、Bean定義で#{…}が使えるとのことですが・・・Javadocだけで、マニュアルもサンプルアプリケーションも無い状況ではいまいちピンと来ません・・・

明記されている箇所を見つけられなかったのですが、J2SE1
4.2以前のサポートは削除され、JavaSE5以降が前提となっている可能性も高そうです。

※追記：思いっきり「Note that Spring Framework 3.0 requires Java 5 or above and J2EE 1.4 or above. We are building on Java 6 and Java EE 5 as the primary platform levels - but rest assured, we will retain compatibility with Java 5 enabled J2EE 1.4 servers such as WebLogic 9 and WebSphere 6.1.」とありました・・・（汗；

SpringFramework 2.5.6 リリース

されました。

主な変更点は

• AspectJ 1.6.2 対応（1.5.x、1.6.x との互換背は保持）
  
• EHCache 1.5.0 対応（1.2 以上との互換背は保持）
  
• TestNG 5.8 対応（5.5 以上との互換背は保持）
  
• OpenJPA 1.1.0 対応（1.2.0 と同様、1.0 との互換性は保持）
  
• EclipseLink 1.0.1 対応
  

など。

changelogはこちら。


来週木曜日に、次期バージョン Spring3.0 について何か発表があるようですね。

BEA 買収後の Oracle のミドルウェア戦略

少し前に某 ML で得た情報ですが・・・

今月初めに、BEA 買収後の Oracle のミドルウェアの統合方針が発表されています。

http://www.oracle.com/products/middleware/docs/oracle-middleware-strategy-briefing-072008.pdf

JavaEE アプリケーションサーバは、OC4J を捨てて WebLogic Server へ統合される模様です。
しかし（というか、もちろん）ORM フレームワークは Toplink です。

WebLogic Server は、Pitchfork という Spring Framework ベースの DI/AOP コンテナを内包しており、事実上 Oracle のアプリケーションサーバは Oracle ADF + Spring + Toplink という構成になりそうです。

商用 JavaEE アプリケーションサーバ製品は、IBM と Oracle の2強時代になりそうですね。

統合開発環境は、従来通り Eclipse Pack と JDeveloper の2本立て。BEA Workshop の機能は Eclipse Pack の一部として取り込まれていくようです。

Beehive は消えゆく運命に・・・

Spring Framework 2.5.5 リリース

一ヶ月も前に出ていました。
2.5.4の時も、今回もアナウンスがないのでダウンロードページを直接見ないとアップデートがわかりません。

主な変更点

• Hibernate 3.3.0対応
• iBATIS SQL Maps 2.3.2対応
• IBM JDK1.6対応
• DriverManagerDataSourceが削除され、代わりにSimpleDriverDataSourceが追加。クラスローディングとシンクロナイぜーションの都合らしい。
• MS SQL Server用のエラーコード対応
• HibernateTransactionManagerに"hibernateManagedSession"フラグが追加
• Hibernate/OpenJpa/TopLink/EclipseLink利用時にDerbyとH2をサポート
• Hibernate/TopLink/JDO/JPAのプロキシクラスはORMプロバイダのクラスローダが生成するように変更（OSGi対応）
• iBATIS SqlMapで複数のSqlMapConfigファイルに対応

その他詳細はChangeLogを参照。
http://static.springframework.org/spring/docs/2.5.x/changelog.txt

今度のSpringユーザー会勉強会はSlim3！

http://springframework.jp/index.php?%CA%D9%B6%AF%B2%F1#swy35rsc

なんと、Seasar のひがさんがSpringユーザー会の勉強会にて Slim3 を紹介してくださいます！！！

Spring な人も、Seasar な人も、あらゆる意味で注目です。

Spring Framework 2.5.4 リリース

4月28日付けで、Spring Framework 2.5.4 がリリースされていました。
オフィシャルサイトのトップページにも、RSS 配信にも無かったので今日まで気づきませんでした・・・

http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=173644&release_id=595476

2.5.3 からの主な変更点は下記の通り。

• AspectJ が 1.6 になった（1.5.x との互換性あり）
• JdbcTemplate で CallableStatement から null の ResultSets が返るのを検出してスキップするようになった
• BeanPropertySqlParameterSource は MySQL との互換性のために JDBC 3.0 の Types.BOOLEAN をデフォルトで使わないようになった
• Hibernate3.2 + ピュア Spring 管理 JTA トランザクションで、クエリ発行前にフラッシュ実行をサポート

詳細は下記を参照してください。
http://static.springframework.org/spring/docs/2.5.x/changelog.txt


あまり大きな変更点はありませんね。
ニュースにするまでもないってコトでしょうか。

SpringSource Application Suite Enterprise Edition

L.A.にお住まいの方から日本Springユーザ会のMLに情報提供の投稿がありました。
SpringSource主催のトレーニングコースに参加した際に得た情報だそうです。

http://groups.google.co.jp/group/jsug/browse_thread/thread/98e78742e3bffdb6?hl=ja

この中で私の興味を引いたのは、SpringSource Application Suite Enterprise Edition に関する情報です。

• 今月末頃に Tomcat + Spring をベースにしたアプリケーションサーバをリリース。クローズドなコードが含まれている。
• 商用と GPL のデュアルライセンス
• 商用ライセンスはサブクリプションベースのサポート付き

・・・クローズドなコードを含んだものって GPL で公開できましたっけ？

SpringSource社がCovalent社を買収したときに、こういう展開になるのではないかという声はありました。

Hibernate.org のブログエントリを読むと、JBoss 対 Spring という構図がより明確になっています。
http://blog.hibernate.org/Bloggers/SpringSourcesStrategy
ここでは Tomcat + Spring には機能が足りないことに言及していますが、Rod Johnson は、そういう観点で勝負する気は無いでしょう。

このMLの投稿でも「JBossの対抗馬」とされていますが、真っ向対立したいのであればJavaEE完全準拠のアプリケーションサーバを作ると思います。

Tomcat + Spring は今でも十分に支持されています。Rod Johnsonが考えているのは、今までの Tomcat + Spring というアプローチの延長線上のアーキテクチャでしょう。今の SpringSource社は VC から資金調達しているので利益を出さなければならないという事情があるようですが、この Tomcat + Spring スタイルでオフィシャルにサポート提供するのなら顧客は獲得できるのではないでしょうか。

今まで、Glassfish でもなく JBoss でもなく、Tomcat + Spring を選択してきたユーザには大歓迎ですね。

Spring Framework 2.5.3 リリースされました

Spring Framework 2.5.3 がリリースされました。

http://www.springframework.org/node/622

すべての2.5.xユーザにアップグレードが推奨されています。

主な変更点はこんな感じです。

• @Autowiredアノテーション、@Requiredアノテーションの動作の変更。
• @Autowiredアノテーションが付けられたメソッドがサブクラスでオーバーライドされているとき、@Autowiredアノテーションの動作はオーバーライドされたメソッドには継承されないように変更になった。（2.5.2までは、@Autowiredアノテーションがついたメソッドがサブクラスでオーバーライドされた場合は、サブクラスのオーバーライドされたメソッドにも暗黙的に@Autowiredアノテーションがついていることになっていた）
• @Requiredアノテーションは、XMLでのBean定義をしなくても@Autowiredアノテーションと組み合わせて利用できるようになった。
• @Controllerアノテーションが付いたBeanがデフォルトで検索されるようになった
• <jee:...要素を使ったjndiルックアップはresource-ref="true"がデフォルトになった
• JMSセッションとプロデューサプーリング用の新しいCachingConnectionFactoryクラス
• DB2/390とDB2/400のための新しいDB2MainframeSequenceMaxValueIncrementerクラス
• リファレンスドキュメントがJSF1.2、Struts2.0対応になった
• PropertyPlaceholderConfigurerで、${db.${environment}}のようにネストしたプレイスホルダーキーをサポート
• その他

詳細はChangelogを参照してください。
http://static.springframework.org/spring/docs/2.5.x/changelog.txt


すべての2.5.xユーザにアップグレードを推奨すると言ってますが・・・。メソッドがオーバーライドされたときの@Autowiredアノテーションの振る舞いの変更は、ソースコードの修正が発生しそうですね。setterをオーバーライドすることはあまり無さそうですが、コンストラクタインジェクションを使っている場合はオーバーライドしているケースが結構多いのではないでしょうか？

@Requiredアノテーションについては、2.5.2 までは@Requiredアノテーションを使う場合はXMLでのBean定義が必須でしたが、2.5.3 では@Autowiredアノテーションと組み合わせて利用できるようになったのが便利ですね。
・・・まぁ、@Autowired(required=true) とあまり変わりませんが・・・

Spring2.5はどのぐらいパフォーマンスが向上したのか？

仕事で、あるお客様に「Spring2.5は2.0からどのぐらい変わったのか？」と聞かれました。Spring2.5は2.0よりパフォーマンスが大幅にアップしたと言われていますが、私自身いったいどのぐらい向上したのかを具体的に知らなかったので、簡単なサンプルを使って検証してみました。

• 検証したマシン： Lenovo Tinkpad X60
• CPU: Core2 DUO T7200 2.00GHz
• RAM: 2GB
• Windows XP Professional SP2
• Sun JavaSE JDK 1.6.0_05
• Eclipse 3.3 Europa

まず用意したのは、あまりにも簡単なこんなサンプル。

[ParentBeanImpl.java]

package springtest.bean;

public class ParentBeanImpl {
}

[applicationContext.xml]

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
         http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

    <bean id="parentBean" class="springtest.bean.ParentBeanImpl" />

</beans>

これで、ひたすら getBean("parentBean") を、100万回 * 100セットして、100万回の実行にかかった時間の平均値を求めてみました。

[SampleMain.java]

package springtest;

import springtest.bean.ParentBean;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SampleMain {

    private static final int count = 1000000;
    private static final int set = 10;

    public static void main(String[] args) {

        ApplicationContext ctx = new ClassPathXmlApplicationContext(
                "applicationContext.xml");

        for (int i = 0; i < set; i++) {
            for (int j = 0; j < count; j++) {
                ctx.getBean("parentBean");
            }
        }
    }
}

Spring2.0.8 442ミリ秒
Spring2.5.2 234ミリ秒

Spring2.5は、2.0に比べて2倍近くパフォーマンス向上していることがわかります。


次に、DIありで。

[ParentBeanImpl.java]

package springtest.bean;

public class ParentBeanImpl {

    private ChildBean childBean;

    public void setChildBean(ChildBean childBean) {
        this.childBean = childBean;
    }
}

[ChildBean.java]

package springtest.bean;

public interface ChildBean {
}

[ChildBeanImpl.java]

package springtest.bean;

public class ChildBeanImpl implements ChildBean {
}

[applicationContext.xml]

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
         http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

    <bean id="parentBean"
        class="springtest.bean.ParentBeanImpl">
        <property name="childBean">
            <ref bean="childBean" />
        </property>

    </bean>
    <bean id="childBean"
        class="springtest.bean.ChildBeanImpl" />

</beans>

Spring2.0.8 450ミリ秒
Spring2.5.2 235ミリ秒

Spring2.0はDIのオーバーヘッドが2～3%ほどかかっていますが、Spring2.5ではそれほどかかっていないことがわかります。
でもまあ、DIのコストは気にする程度のものではないでしょう。



次は、scope="prototype"で。
100万回 * 100セットでは時間がかかりすぎたので、1万回 * 100セットで検証。


[applicationContext.xml]

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
         http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

    <bean id="parentBean" scope="prototype"
        class="springtest.bean.ParentBeanImpl">
        <property name="childBean">
            <ref bean="childBean" />
        </property>

    </bean>
    <bean id="childBean" scope="prototype"
        class="springtest.bean.ChildBeanImpl" />

</beans>

Spring2.0.8 122ミリ秒
Spring2.5.2 162ミリ秒

なんと、Prototypeではわずかですが2.5の方が遅いという結果に。




ところで、お客様に聞かれたのはSpring2.0と2.5の比較ですが、興味本位でSeasar2もほぼ同一プログラムで検証してみました。

結果は、Seasar圧倒的。これほどまでに差が出るとは・・・

	Singleton、DIなし(ミリ秒) 100万回 * 100セット平均	Singleton、DIあり(ミリ秒) 100万回 * 100セット平均	Prototype、DIあり(ミリ秒) 1万回 * 100セット平均
Spring 2.0.8	442	450	122
Spring 2.5.2	234	235	162
Seasar 2.4.23	84	87	67

　ところで余談になりますが・・・

　最近Seasar界隈を中心に「スーツ or Geek論」が再燃していますが・・・
　ひがさんだって十分に「スーツなGeek」じゃない？と思うのは私だけでしょうか・・・

　大手SIerがSeasarをなかなか採用しない理由は、周辺プロダクトと開発環境のロックオンという理由も大きいと思います。私はSpringの方が柔軟性や他プロダクトとの親和性が高いと思います。

iBatisのBLOB・CLOBおよびOracle固有SQL型サポート(メモ)

iBatis2.3.0では、次のOracle固有のSQL <-> Java型マッピングをデフォルトでサポート。
iBatis2.0.9以降ではBLOBとCLOBをデフォルトでサポートするようになった。
http://wiki.apache.org/ibatis/How_do_I_use_a_Custom_Type_Handler_with_a_BLOB_or_CLOB

• CLOB → java.lang.String
• BLOB → byte[]
• RAW → byte[]
• LONG → java.lang.String
• LONG RAW → byte[]

BLOB型は、Springのorg.springframework.orm.ibatis.support.BlobSerializableTypeHandler
を使うとSerializable Objectでマッピングすることも可。
org.springframework.orm.ibatis.support.BlobByteArrayTypeHandler とか org.springframework.orm.ibatis.support.ClobStringTypeHandler とかあるけど、少し古いバージョンのiBatisサポートのために残されているだけ。

Spring Framework 2.5.2 リリース

昨日、Spring Framework 2.5.2 がリリースされています。

http://www.springframework.org/node/601

主な変更点は以下の通りです。

• Spring2.0拡張ポイントの完全互換
• MS SQL、MySQL、PostgreSQL、Oracleの拡張SQLエラーコード対応
• TaskExecutorバックエンドとしてのGlassFish/JBoss JCA WorkManagerのサポート
• Eclipse Persistence Services （EclipseLink JPA実装）1.0 M4のサポート
• WebSphere JPA実装（OpenJPA）のサポート
• @RequestMappingアノテーションでの"!myParam"式のサポート
• @RequestMappingアノテーションでの"params"属性の型宣言部でのサポート
• JSP CheckboxesTagとRadioButtonsTagの修正

さらにいくつかのプロダクトをサポートが追加されました。


Seasarは、何でも自前で用意したり、StrutsやJSF実装等の他のプロダクトを取り込んだ自前のフレームワークを用意したりする傾向が強いプロジェクトですが、Springは他のプロダクトとの疎な連係機能を充実させる方向ですね。
Springのこういうところが好きです。
少し前に日本Springユーザ会のMLでも話題になっていましたが、DI/AOPコンテナフレームワークとして日本国内では何かと比較されることの多いSeasarとSpringですが、あくまで「アプリケーションフレームワーク」として進化するSeasarと、ミドルウェア的な「コンテナ」の方向に進化するSpringの思想がだんだん離れてきた感もあります。

iBatis

最近仕事で使っています。
実際に仕事で使うようになるまで、iBatisを詳しくは知りませんでした。

「SQLを直接指定できるORマッピングフレームワーク」
「Apache iBatis Projectで開発されているOSS」

という程度の認識でした。


調べてみると、O/Rマッピングフレームワークとしての機能はひととおり備えています。


が・・・しかし・・・

こりゃ、O/Rマッピングフレームワークと言うよりは
SQL/Oマッピングフレームワークですね。

「オブジェクトの永続化」という考え方は薄く、
「SQL文をオブジェクトにマッピングする」というイメージ。
iBatisではマッピングの対象は、テーブルやカラムではなく、あくまでSQL文です。

HibernateやJPAでは、エンティティオブジェクトとテーブル、
プロパティとカラムを関連づけていきます。

それに対してiBatisでは、エンティティオブジェクトとSQL文を関連づけます。
テーブルありきの、完全にデータベースドリブンなボトムアップアプローチ。
「オブジェクトを永続化する」というアプローチではありません。
関連やカスケード処理、Lazy Loading機能は弱く、SQLで何とかする感じですね。

SQL/Oマッピングフレームワークというアプローチは
オブジェクト指向としては美しくないかもしれませんが、
とても現実的だと捉えるのもありかと思います。



で、このiBatisですがO/Rマッピング（というかSQL/Oマッピング）フレームワークと
DAOフレームワークが用意されていますが、最新バージョン（2.3.0）では
DAOフレームワークは非推奨となり、
SpringのiBatis連係機能を利用することが推奨されています。


ところが・・・
Apache iBatis Projectからは、DBスキーマ情報からエンティティオブジェクトとDAOを
自動生成するツール「Abator」がリリースされていますが、
このDAOは非推奨なDAOフレームワークにしか対応していません。


ということで、DBスキーマ情報からエンティティオブジェクトと
DAOと設定ファイル類を自動生成するツールを自作しています。
テンプレートエンジンには FreeMarker を使いました。
Antタスクとして作成したので、
コマンドラインからでもEclipseからでもNetBeansからでも利用できます。

シンプルなCRUDは全部自動生成しました。
どんな単純なCRUDでも全部SQL文を書かなくてはならないという
iBatisの欠点というか面倒くさい点を克服できます。
Genericsを利用した、よいDAOができたと自画自賛です（＾＾；


内部的にはインスタンス管理とDB接続管理がラクなのでSpringを使いました。
Webアプリケーションではないところで使うのは初めてでしたが、
改めて依存オブジェクトの外部注入の素晴らしさを実感しています。
他のファイルを生成するような機能を追加するときも、
既存のコードを修正せずに機能追加できます。


ただ、個人的には実装クラスとインタフェースを分離する必要が無いと感じる
オブジェクトも多いのですが、「Springで管理するクラスはインタフェースが分離されている」
というお作法というか、暗黙の了解みたいなものがあるので
個人的には疑問を感じつつ渋々インタフェースと実装クラスに分けたクラスが多いです。
実装クラスとインタフェースが分かれていないと何か特別な理由があるのか？
と勘ぐられそうなほど常識化している勢いですからね・・・・

この常識は何とかしたいものです。
必要以上に作成・管理しなければいけないファイルを増やす必要など無いはずですから。