March 5, 2008

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の思想がだんだん離れてきた感もあります。

March 4, 2008

mixiの規約が改訂されます

mixi、4月1日より利用規約を改定--日記などについて著作者人格権の行使を禁止
http://japan.cnet.com/news/media/story/0,2000056023,20368643,00.htm

(トラックバック)
http://japan.cnet.com/news/media/trackback/0,2000056567,20368643,00.htm

mixiのお知らせ欄にも改訂することが告知されています。

mixiの新規約より


第18条 日記等の情報の使用許諾等
1 本サービスを利用してユーザーが日記等の情報を投稿する場合には、ユーザーは弊社に対して、当該日記等の情報を日本の国内外において無償かつ非独占的に使用する権利(複製、上映、公衆送信、展示、頒布、翻訳、改変等を行うこと)を許諾するものとします。
2 ユーザーは、弊社に対して著作者人格権を行使しないものとします。



この改訂が実施されたら、mixiの日記に書いた文章は書いた本人が著作権を主張できなくなります。またmixiは自身が出版する書籍やWebサイトで参加者の日記の文章を作者に許可なく、mixi自身の著作物として自由に使えることになります。

これでは、mixiに日記は書けなくなりますね。

「日記等」は、下記のように定義されています。

mixiの新規約より

第2条 定義
(7) 日記等の情報 日記、プロフィール、コメント、レビュー、画像、動画等本サービスを利用して投稿できる情報をいいます。



画像、コメント、レビュー、プロフィール等に関しても同様です。
非公開日記や他ユーザ宛のメッセージも対象となります。
自分が非公開設定していても、mixiが自身の著作物として公開することができます。

mixiの新規約より

附則
1 本利用規約は平成20年4月1日から施行します。
2 本利用規約の施行前にユーザーによって行われた行為についても本利用規約が適用されます。



過去の「日記等」にもすべて適用されるということです。


さらに、現在のmixiの規約では改定に際して利用者の同意を得る必要なく、告知する義務もなく自由に改訂できるようになっています。しかもmixi利用者は将来の規約改訂にも自動的に同意することにもなっています。


私は自分の文章や写真等を勝手に使われたくないので、4/1までにmixiからはすべて削除することにします。日記のコメントも削除されるので、コメントいただいた方には申し訳ありませんが・・・


日記は外部ブログにしておいて良かった。


・・・というよりも、何となくこういうことを見越して外部ブログにしていたというのが正直なところです。


以前からmixiの社長って、つくづくバカだなぁって思っていましたから。

TVのニュースやWebでのインタビューを見ていて、お世辞にも頭の切れる人間とは思えません。

mixiだって、元社員のB氏が作って会社に事業化を提案し軌道に乗せたもので、社長である笠原氏が作って育てたものではありません。B氏はIT業界の尊敬を集める素晴らしいエンジニアでしたが、そのB氏も既に笠原氏を見限って退社しています。

かなり無茶な基準でmixiに批判的な日記を削除したり、批判的な言動のユーザやそのユーザを招待したユーザのアカウントを削除したりも以前から行われていました。

mixi株価下落について書いたら日記を削除された、なんてことも。
そういえば、今日付で三菱UFJ証券がmixiの格付けを2段階引き下げた、なんてニュースもありました。

アカウントが削除されると突然mixiにログインできなくなり、問い合わせてもほぼ無視されます。

このような事例はネットを検索すると枚挙にいとまがありません。

Googleの検索結果


そして、今回の規約改定。

バカ社長の横暴もここまできたか・・・という印象です。

仮に司法の場で争うことになったらmixiが敗訴する可能性の高い規約だとは思いますが・・・


※・・・と思ったら今日の夕方になって補足説明が追加されていました。
非難・批判が集中してあわてて取り繕ったのは見え見えです。まるでどこかのテレビ局のようですね・・・(笑)
第18条の条文は修正なしのままですし、規約そのものが変わるまで私は信用できません。

今回の件で、「mixiはよく考えずに行動する企業」という私の印象はますます強くなりました。


※※・・・さらに3/5の夕方に、規約第18条を修正しますという発表がありました。

この後手後手の対応。

以前のユーザアカウント大量削除事件といい、今回の件といい、この会社はどういう行動をしたらユーザーや社会がどう感じるのか?どう思うのか?mixiはどう思われるのか?を考えられない、想像力や熟慮・配慮に欠けている企業、つまりリスク管理ができない企業と言わざるを得ませんね。。。


※※※・・・規約修正案が発表されました。

まあ妥当な線でしょう。「弊社は、ユーザーが投稿する日記等の情報を、本サービスの円滑な提供、弊社システムの構築、改良、メンテナンスに必要な範囲内で、使用することができるものとします。」は、将来コンテンツマッチ広告の配信等も視野に入れているのでしょうか?


今回の件で、約80万人がmixiを退会したそうです。
また、私の周辺では外部ブログを持っている方はほぼ全員mixi日記から外部ブログへ移行しました。

ユーザ不在で物事を進めるとこうなるという、良い教訓になったのではないでしょうか。

February 28, 2008

mixiがOpenIDプロバイダに

先日、こんなニュースが流れてきました。

OpenIDファウンデーション・ジャパン設立へ--ミクシィやヤフーも参加
http://japan.cnet.com/news/media/story/0,2000056023,20368347,00.htm

mixiやYahoo!JapanがOpenIDプロバイダになります。
(Yahoo!Japanは既に対応済み)

mixiも、以前からOpeinIDのAPIを利用しているフシがあったので
そのうち正式にサービスとして公開するのかな・・・?とは思っていました。

楽天は完全に出遅れ感が・・・(^^;


OpenIDってなに?・・・という人のために。

mixiやYaoo!や楽天など、いろいろなネットサービスを使うようになる
とユーザーIDやパスワードの管理がだんだん難しくなりませんか?

このサイトのIDとパスワードって何だっけ・・・?って。

そこで、インターネットサービスをもっと利用しやすくしよう!
ということでいろんなWebサイトでID/パスワードを共通化しよう
という仕組みが考えられました。

この仕組み業界用語ではSSO(Single Sign On)と言います。
OpenIDはそのSSOという仕組みのうちの一つです。


OpenIDでは、単純にOpenIDに対応しているだけのサイト(コンシューマ)と
OpenIDのID/パスワードを発行するサイト(OpenIDプロバイダ)の2種類があり、
mixiやYahoo!JapanはOpenIDプロバイダになることを表明しました。

OpenIDに対応しているサイトなら
OpenIDプロバイダが発行するID/パスワードでログインできるようになります。

具体的には、OpenIDに対応しているサイトならどこでも
mixiやYahoo!のID/パスワードでログインできるようになるんです。


いろんなサイトにID/パスワードをばらまくのは不安・・・
という声もあるかと思いますが、OpenIDなら認証を行うのはOpenIDプロバイダなので、
他のサイトにIDやパスワードが漏れることはありません。
ログインするサイトは、OpenIDプロバイダから「このユーザは正しく認証されました」
という情報をもらうだけです。


OpenIDが広まれば、一つのID/パスワードで
いろんなサイトにログインできるようになるんです。

OpenIDが普及したら便利になると思いませんか?


今のところ、ネット「OpenID」を調べても
IT業界の人向けの情報ばかりというのが現状です。

OpenIDが普及するには、一般ユーザにも直感的にわかりやすく
受け入れられるマーケティング・プロモーション戦略が重要なのではないかと思います。
その辺のところをmixiやYahoo!には頑張ってもらいたいですね。

February 27, 2008

EJB3でのホームインタフェースの作成

どのWebサイトや雑誌記事を見ても「EJB3ではホームインタフェース不要」と、書いてありますが・・・

Stateful SessionBeanのセッション管理をアプリケーションで制御したい場合にはホームインタフェースが必要になる場面も多いと思います。

具体的な例のひとつは、アプリケーションで一旦セッションを破棄して新規にセッションを開始したい場合です。

@EJBアノテーションはコンテナがフィールドを初期化する時にしか動作しないため、EJBのビジネスインタフェース型のフィールドを定義して、@EJBアノテーションを付与する方法では、このようなシチュエーションに対応できません。


EJB3でホームインタフェースを利用する場合は、次のように実装します。

ホームインタフェースを作成する。

  • javax.ejb.EJBLocalHome(リモート呼び出しを行う場合は javax.ejb.EJBHome)インタフェースを継承して作成する。
  • 1つ以上のcreate()メソッドを定義する。戻り値の型は次の手順で作成するビジネスインタフェースの型、引数は任意(と言ってもSerializableな型)、javax.ejb.CreateException をthrowするように実装する。
  • create()メソッドは引数の数と型が異なるものをいくつでもオーバーロード可。

package study.ejb3.model.service;

import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;

/**
 * ホームインタフェース。
 * javax.ejb.EJBLocalHome または javax.ejb.EJBHome を継承して作成する。
 * 1つ以上の create() メソッドを定義する。戻り値の型は ビジネスインタフェースの型。
 * create() メソッドは javax.ejb.CreateException をthrowするように定義する。
 * create() メソッドは引数の数と型が異なるものをいくつでもオーバーロード可。
 */
public interface HogeServiceHome extends EJBLocalHome {

    /**
     * create() メソッド
     */
    public HogeService create() throws CreateException;

}


ビジネスインタフェースを作成する。
  • 通常のEJB3ビジネスインタフェースとは違い、ホームインタフェースを併用する場合は javax.ejb.EJBLocalObject(リモート呼び出しを行う場合は javax.ejb.EJBObject)インタフェースを継承して作成する。
  • 任意のビジネスメソッドを定義する。ただし、引数と戻り値は Serializableな型であること。これは通常のEJB3スタイルと同様。
  • また、後述するBean実装クラスで@Removeアノテーションを付けたメソッドをクライアントから呼び出せるようにするため、同メソッドを定義する。


package study.ejb3.model.service;

import java.rmi.RemoteException;

import javax.ejb.EJBLocalObject;

/**
 * ビジネスインタフェース.
 * javax.ejb.EJBLocalObjectまたはjavax.ejb.EJBObjectを継承して作成する。
 * 任意のビジネスメソッドを定義する。戻り値と引数はSerializableな型であること。
 *
 */
public interface HogeService extends EJBLocalObject {

    /**
     * ビジネスメソッド
     */
    public String businessMethod() throws RemoteException;

    /**
     * Bean実装クラスで@Removeアノテーションを付けるメソッド
     */
    public void destroy() throws RemoteException;

}


Bean実装クラスを作成する。
  • 通常のEJB3スタイルとは異なり、ビジネスインタフェースをimplementsしない。
  • create() メソッドの引数の数と型に対応したメソッドを実装し、@Initアノテーションを付ける。メソッド名は任意。アクセス修飾子は public、戻り値の型は void 。
  • 任意の名前のメソッドを実装し、@Remove アノテーションを付ける。アクセス修飾子は public、戻り値の型は void。
  • ビジネスインタフェースに定義したビジネスメソッドを実装する。javax.ejb.EJBException をthrowするように実装する。
  • クラス宣言部に @Stateful アノテーションを付ける。これは通常の EJB3スタイルと同様。
  • クラス宣言部に@LocalHome(リモート呼び出しを行う場合は@RemoteHome)アノテーションを付ける。引数に、ホームインタフェースのクラスオブジェクトを指定する。
  • クラス宣言部に@Local(リモート呼び出しを行う場合は@Remote)アノテーションを付ける。引数に、ビジネスインタフェースのクラスオブジェクトを指定する。
  • 上記2つの設定により、ホームインタフェース、ビジネスインタフェース、Bean実装クラスの3つが関連付けられる。従来のEJB2.xではデプロイメントディスクリプタ(配備記述子)ejb-jar.xmlで設定した内容。


package study.ejb3.model.service;

import javax.ejb.EJBException;
import javax.ejb.Init;
import javax.ejb.Local;
import javax.ejb.LocalHome;
import javax.ejb.Remove;
import javax.ejb.Stateful;

/**
 * Bean実装クラス。
 * 通常のEJB3スタイルとは異なり、ビジネスインタフェースをimplementsしない。
 * @Local(または@Remove)アノテーションで
 *                          関連づくビジネスインタフェースを指定する。
 * @LocalHome(または@RemoveHome)アノテーションで
 *                          関連づくホームインタフェースを指定する。
 */
@Stateful(name = "HogeService")
@Local(HogeService.class)          // ビジネスインタフェースのクラスオブジェクトを指定
@LocalHome(HogeServiceHome.class) // ホームインタフェースのクラスオブジェクトを指定
public class HogeServiceBean {

    /**
     * ビジネスメソッド
     */
    public String businessMethod() throws EJBException {
        return "Hello! Business Method!";
    }

    /**
     * ホームオブジェクトのcreate()メソッドが呼ばれたとき
     * (新規セッション開始時)に呼ばれる
     */
    @Init
    public void init() {
        System.out.println("init() が呼ばれた");
    }

    /**
     * クライアントからこのメソッドが呼ばれるとセッションが破棄される
     */
    @Remove
    public void destroy() {
        System.out.println("destroy() が呼ばれた");
    }

}


EJBクライアント(EJB呼び出し側)の実装。
  • EJBビジネスインタフェース型ではなく、ホームインタフェース型のフィールドを定義し、@EJBアノテーションを付ける。EJBオブジェクトと同様、ホームオブジェクトも@EJBでインジェクション可能。


@EJB
private HogeServiceHome home;


  • ホームオブジェクトの create() メソッドを呼び出すと、EJBオブジェクトを取得可能。同時に新規にセッションが開始される。


// セッションを開始。
HogeService service = home.create();


  • EJBオブジェクトの、@Remove が付いたメソッドを呼び出すとセッション破棄。


// セッションを破棄
service.destroy();


  • 新規にセッションを開始したい場合(EJBオブジェクトを新規に取得したい)は、再度ホームオブジェクトの create() メソッドを呼び出せばOK。


// セッションを改めて新規に開始。
service = home.create();


@EJBアノテーションはフィールド初期化時にしか動作しないため、ホームインタフェースを使わないと新規にセッションを開始したい場合(EJBオブジェクトを新規に取得したい)は、JNDIルックアップするコードを書かないといけないことになります。



・・・なんだか、EJB2.xとEJB3のスタイルが混在した、えらく中途半端なコードになってしまいますね(^^;

February 23, 2008

JBoss4.2.xにおける@EJBアノテーション

JBoss4.2はServlet2.5/EJB3にデフォルトで対応しているので、Webコンテナ上で動作するコンポーネントで @EJB アノテーションが当然使えると思っていました。

JNDIルックアップのコードを書かなくても、EJBのビジネスインタフェース型のフィールドに「@EJB」とアノテーションをつけておけば、フィールド初期化時にコンテナが裏でコッソリEJBオブジェクトのインスタンスを取得してフィールドにセットしてくれるという機能です。アノテーションによるDI(Dependency Injection)ってやつですね。

@EJB
private HogeService;

こう書いておけば、コンテナがこのフィールドを初期化する際に、HogeServiceインタフェースを実装したEJBオブジェクトをJNDIサービスより取得してフィールドにセットしてくれます。

しかし、結論から言うとJBoss4.2ではWebコンテナ上でのこの動作はサポートされていません。
JBossの公式文書に下記のような記述がありました。

Java EE 5 allows you to inject EJB3 bean instances directly into the web application via annotations without explicit JNDI lookup. This behavior is not yet supported in JBoss AS 4.2.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/docs/trunk/Server_Configuration_Guide/ja-JP/EJB3.po?revision=65669&pathrev=68449

JBoss4.2.xはEJB3 (JSR-220) 対応のEJBコンテナを実装し、Servlet2.5 (JSR-154) 対応のWebコンテナを実装していますが、Common Annotations (JSR-250) は完全に実装されていないようです。

結局、ServletコンテナからEJBを利用するには従来のEJB2.x時代のようにJNDIルックアップするコードを書かなくてはいけません。


・・・道理で、Web上にもWebコンテナから@EJBでEJBオブジェクトをインジェクションするサンプルが見つからないわけです。

これで1日ぐらいハマりました。

今度のセミナーではCommon Annotations (JSR-250) が動作する JBoss5.0.0Beta4を使うことにします・・・


それにしても、JBossの情報って少ないですね。利用者が減っているのでしょうか?少なくともネット上の情報を探す限りでは、積極的にブログ等へ情報をアップするエッジの効いたエンジニアの利用が減っている感じがします。
JavaEE5完全対応のアプリケーションサーバを正式リリースできていないのはJBossだけですしね。OSSのJavaEEアプリサーバでは、最近はGlassfishの勢いが目立ちます。GlassfishはNetBeansにも標準でバンドルされるようになったし。

※ところが、JBoss5.0.0Beta4はJMSがうまく動かなかったり、セキュリティロールがうまく動かなかったりでした。具体的には、QueueのJNDIサービスへの登録時に例外が発生してデプロイできません。セキュリティロールは、@RollsAllowedで指定していないロールでもメソッドの実行が許可されてしまいました。まあ、βなのでこんなもんですね・・・