JSF2.0のエラーハンドリングについて調べてみたのでまとめる。 ここで言う『エラーハンドリング』とは、Struts1.xの<globa-exceptions>や、org.apache.struts.action.ExceptionHandlerを継承してユーザが作成するカスタム例外ハンドラを想定しており、Struts1.xと同じようなことがJSF2.0でも可能か確かめることが目的だ。 今回は、以下のようなバッキングBeanからランタイム例外が投げられた場合に、スタックトレースが表示されないようにしたい。 @Model public class BookController { @EJB private BookService service; @Inject private Book book; public String createBook() { service.persist(b
JBossAS7でEJBのコンテナ管理トランザクションが動かないことではまっていたが、WebコンソールとCLIでJTAを有効にするかどうかのデフォルトが違ったのが原因だったようだ。 Webコンソールの場合 Webコンソールから作成すると、デフォルトでUse JTA?はfalseになっている。この属性がfalseになっていると、データソースから取得したコネクションはautocommit=trueになっていた。このため、EJBのコンテナ管理トランザクションがうまく動かず、insert/update/deleteするとEJBのトランザクション管理を待たずして即時にコミットされていた。 standalone.xmlからもjta属性がfalseになっていることが確認できる。 <datasource jta="false" jndi-name="java:/test" pool-name="test"
Spring3 入門を読んでいて、トランザクションの開始・終了がEJBを使ったJavaEEアプリケーションでも出力できないか考えてみた。 CDIのTransactionnal Observerで試行錯誤 : 失敗 CDIでは、トランザクションの成功・失敗・開始などの合わせてイベントを起動するTransactional Observerと呼ばれる仕様がある。 しかし、下記のように明示的にfire()でイベント発火する必要があり、ちょっとトランザクションの挙動をロギングする用途にはアプリケーションには余分なコードに見えてしまう。あくまでWeld Referenceの例のように、トランザクションの成功・失敗をフックに、何かListの状態を変更したり、なんらかのビジネスロジックを実行するために使いそうだ。 @Inject @Any Event<Book> bookEvent; public voi
FaceletsのXHTMLにコメントを書く時に少しはまったのでメモ。(以下のコードはJBossAS7.1で確認) うまくいかない例 (HTMLコメントをそのまま使う) コマンドボタンを以下のようにコメントアウトすると、Submitしたときではなく、ボタンを含むページを開いたときの『RENDER_RESPONSE』フェーズでaction属性に設定したアクションが実行されてしまう。 <!-- うまくいかないコメント例 --> <!-- <h:commandButton styleClass="btn" action="#{userManageController.changePassword()}" value="コメント"/> --> 上記の例では、action属性に設定されたuserManageController.changePassword()が呼ばれてしまう。 生成されたHTMLを
BeanValidationはJSF2.xと統合した場合に、JSFから自動的に呼び出されるのはプロパティ単位のバリデーションのみである。クラス単位のバリデーションは呼び出されない。 (参考 http://stackoverflow.com/questions/11972419/cross-field-bean-validation-why-you-no-work ) この仕様上、BeanValidationの自作ルールでフィールド間チェック(cross-field valudation)を実装してJSFに適用するのは難しい。そんなときの使えるのがApache MyFacesが提供している拡張バリデータ「extVal」である。 MyFacesと関連がありそうだが、JSFの仕様を満たしているソフトウェア上ではなんでも動くようだ。手元ではJBossAS7にバンドルされたmojjaraで動かしてい
ネイティブクエリのみをシンプルに実行したい場合は、まだまだiBATIS(MyBATIS)を使う機会もあると思います。ここではiBATIS2.3とJava EE6のContest and Dependency Injection(CDI)を組み合わせて、JPAのEntityManagerのように、iBATISのSqlMapClientをインジェクションする方法を考えます。 まず、iBATISの設定ファイル(SqlMapConfig.xml)を読み込んで、初期化する部分のコードです。 // import文はポイントなる部分だけ抜粋 import javax.annotation.PostConstruct; import javax.ejb.Singleton; import javax.ejb.Startup; import javax.enterprise.inject.Produces;
BeanValidation1.0では、@NotNullなどの各検証アノテーションにgroup属性を設定することができます。これは、同じドメインオブジェクトに対して、検証のルールのパターンが複数ある場合に有効です。 例えば、以下のような画面を想定してみます。 本の登録では、ISBNコードとタイトルの両方の入力を必須とします。検索の場合は、どちらか一方が指定されていれば良いこととします。この入力値がバインドされるドメインオブジェクトは両方とも本を示すBookクラスです。 /** 検索の場合にも両方とも必須入力となるケース */ public class Book { @NotNull private String isbn; @NotNull private String title; // getterとsetterは省略 } 上記のように、何もグループを指定せずに@NotNullをフィー
BeanValidation1.0の参照実装であるHibernate Validatorのデフォルトメッセージは英語です。 例えば@NotNullでは「may not be null」、@AssertTrueでは「must be true」といったメッセージが出力されます。通常、JSF2.0を組み合わせて使うときには『"名前"が入力されていません』のように、日本語でかつ入力箇所をメッセージとして出力したいかと思います。 具体例を紹介すると、以下のようなコードを書いた場合のメッセージ表示についてです。 こんな入力フォーム(facelets/XHTML)を作って <h:inputText id="isbn" label="ISBNコード" value="#{controller.book.isbn}" /> <br/> <h:message for="isbn" errorStyle="col
JavaEE6から新しい仕様BeanValidation(JSR303)が導入されています。 BeanValidationではアノテーションでユーザ入力チェックを定義することができます。Struts1.xではvalidation.xmlの記述量が多く、度重なるタイプミスとランタイムエラーに苦しめられてきましたが、アノテーションのタイプミスはコンパイル時にチェックされるので、苦しみが軽減されています。 JSF2.0と組み合わせて使用するとき、「必須入力チェック」について同じような意味を持つアノテーションがいくつかあったので、違いを以下にまとめておきます。 以下のようなPersonクラスを定義し、各アノテーションの挙動の違いを確認します。 import javax.validation.constraints.NotNull; import org.hibernate.validator.co
この記事は Java EE Advent Calendar 2012*1 の12/18分の記事です。 昨日は@yumix_hさんの JAX-RSでファイルアップロード! です。 明日は@den2snさんです。 今回は、ボタンの2度押しチェックについて考えてみたいと思います。 1. ボタンの2度押しとは 2度押しと書くと、直感的にSubmitボタンを連打されることが思い浮かびますが、Webアプリケーションでよくある問題として、画面遷移後にF5(更新)された場合も意図しない多重POSTが発生します。以下の図をみてください。 JSF2.0を使う場合に、それぞれの2度押しにどう対処するかを以下に示します。特に2つ目に紹介するトークンの実装は手間がかかったので、もっとシンプルな方法があれば大歓迎です。 2. Post-Redirect-Getによって、ブラウザ更新による再POSTを防ぐ Post-R
iBATIS2.xの後継ソフトウェアである、MyBatis3.xとJavaEE環境をどう組み合わせるか考える。 MyBatis3.xは、iBATISの開発グループがApache Software FoundationからGoogleCodeに場所を移して開発が続けられているSQLベースのO/Rマッパである。2010年5月にバージョン3.0がリリースされ、2013年1月現在のバージョンは3.1.1である。 JPA(主にHibernate)のようなSQLコーディングなしでDBアクセスというわけにはいかないが、機能がシンプルであり、マニュアルもポイントが絞られて書かれているので覚えやすいフレームワークだ。マニュアルが日本語に翻訳されているのも嬉しい。 1. iBATISとMyBATISの違い 実際に触ってみて、主に2つの点が便利になっている(と私は思う)。 複数データソースを1ファイルで定義 i
Struts1.xユーザがJSF2.0に移行すると、javax.el.PropertyNotFoundExceptionが500エラーの原因として表示されたり、@ModelでアノテートしたCDI管理Beanのパラメータが#{bean.property}でうまく出力されないことがあると思います。 この原因は主に2つあります。 1. CDI管理Beanにgetter/setterメソッドを忘れている Strutsのように操作(Action)と状態(ActionForm)が分かれたプログラミングモデルに慣れていると、どうしても見落としがちなのがアクセッサです。例えば、以下のような簡単なBeanを想定します。 CDI管理Bean(StrutsのAction相当)のソース @Model public class BookController { /* 画面から入力したデータをインジェクション */
JavaEE6を使い始めて、つまずいたのが"Managed Bean"の考え方。 JavaEE6では、大きく分けて以下のコンテナ管理Beanがある。 JSFのManagedBean CDIのManagedBean EJBのManagedBean Servlet、Filter、JAX-RS、JPAなどのその他コンテナ管理オブジェクト @javax.annotation.ManagedBeanでアノテートされたクラス それぞれどんなコンセプトがあって、JavaEE7に向けてどう整理していくのか。 JavaEE7仕様策定エキスパートグループのメーリングリストでも議論されている。 以下、不正確な点も多いと思うが、JavaEEのSpecLeadの提案を翻訳してみた。 原文と、本文中に出てくるMatrix(表資料)のURLはこちら。 http://java.net/projects/javaee-sp
JavaOne2012でセッションを聞いてから、ずーっとさぼっていたがやっと調べた。 Batch Applications for the Java Platform (JSR352) Javaバッチフレームワークの標準仕様がJava EE 7に向けて策定が進められている。 Spring Batchをベースに策定され、現在のステータスはPublic Reviewが終わった段階。上半期中には最終仕様が出てくると思う。詳細についてはJCPのページから確認できる。 なぜJavaでバッチ? バッチというと、COBOLとか汎用機とかベテランとかそんな言葉が思い浮かぶが、やはり同じ開発プロジェクトでオンラインとバッチを両方開発するとき、プログラミング言語が変わるとメンバも変わってきて、コミュニケーションにも影響してくるからではないだろうか。 『プログラミング言語は適材適所』という考え方ももちろんあると
やっとやっと待ちに待ったJava EE 7のリリースが近づいて来ましたね。 予定では5/13(日本だと14日?)にFinal Releaseのようです。 https://java.net/projects/javaee-spec/pages/Home#Java_EE_7_Schedule リリースに備えて軽く自分の備忘録も兼ねて予習しておきます。 あんまり追っかけているわけではないので間違ってたらすみません。 各テクノロジーのバージョンはこんな感じ。 Java EE 7で新規で追加されるもの テクノロジー バージョン Java API for JSON Processing (JSR-353) 1.0 Java API for WebSocket (JSR-356) 1.0 Batch Application for the Java Platform (JSR-352) 1.0 Conc
Oracle Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します(オリジナルのエントリを投稿することもあります)。厳密性をご所望の方は原文をどうぞ。よい内容でしたら原文に対し、"Good Entry, thanks!"でもいいので、是非コメントお願いします(Typoや誤訳はコメント欄からどうぞ)。なお、このエントリは個人の見解であり、所属する会社の公式見解ではありません。また、エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。 Good entries on Oracle Blogs are put into Japanese. Mainly this blog covers technology products. Opinions expressed in this blog is my personal one and d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く