WebSphere MQ/ jar の在り処

/usr/lpp/mqm/V7R0M1/java/lib とかに
com.ibm.mq.jar
com.ibm.mq.jmqi.jar
com.ibm.mqjms.jar
とかがある

tag:
WebSphere MQ mq jmqi mqjms jar

tag : WebSphere MQ mq jmqi mqjms jar

2012-08-22 06:45 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

WMQ/ NoClassDefFoundError: JmqiOptionAdapter

■現象
java.lang.NoClassDefFoundError: com/ibm/mq/jmqi/system/JmqiConnectOptions$JmqiOptionAdapter

■原因
jar が古かった

■経緯
classpath には com.ibm.mq.jmqi.jar をきちんと通してる。
jar を zip にして解凍してみたところ JmqiConnectOptions もきちんと存在している
インナークラスはコンパイルされると「CCDT$CCDTRecord.class」みたくダラーマーク連結のクラスファイルになる
なので JmqiConnectOptions$JmqiOptionAdapter.class なるファイルがあるはずが ない!
結論
jar が古い

■ちなみに
役立たなかったけど
com.ibm.mq.jmqi.jar
 Java のための MQ
 JMS のための MW
を実装して=それら IF に依存していてそれぞれ
 com.ibm.mq.jar
 com.ibm.mqjms.jar
にある。
つまり これらもきちんとパスに通っていないとダメ
# 環境変数に食わせてることもあったり
ただし
環境が古い場合は
 jms.jar
 com.ibm.mq.jmqi.jar
でいいとか

ref:
http://www-01.ibm.com/support/docview.wss?uid=swg21316673
http://8318.blog100.fc2.com/blog-entry-577.html

tag:
NoClassDefFoundError JmqiConnectOptions JmqiOptionAdapter WebSphere MQ JMS jar

tag : NoClassDefFoundError JmqiConnectOptions JmqiOptionAdapter WebSphere MQ JMS jar

2012-08-18 01:01 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ EJB3.0

■構成
EJB3.0 Siplified API
|―SessionBean
|  |―Stateful Session Bean
|  |―Stateless Session Bean
|―Message-driven Bean
Java Persistence API
|―Entity
//

■Stateless Session Bean (Bean実装クラス)
--------------------------------------------------
package sample.ejb;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Stateless;
import sample.entity.Account;
@Stateless
public class AccountServiceBean implements AccountService {
 public boolean register(Account account) {
  return true;
 }
 public List find(String loginname) {
  return new ArrayList();
 }
}
/-------------------------------------------------
@Stateless
 →そのBeanがStateless Session Beanであることを示す。
 →name属性:Beanの名前
  ejb-jar内で一意であること。
 →mappedName属性:このBeanをマッピングする製品固有の名前を指定する。
 →description属性:このBeanの説明
@PostConstruct
 EJB作成後に呼ばれる。
@preDestory
 EJB破棄前に呼ばれる。
@PostActivate
 EJB活性化後に呼ばれる。(Statefulのみ)
@PrePassivate
 EJB非活性化前に呼ばれる。(Statefulのみ)

■Session Bean (リモートIFクラス)
--------------------------------------------------
package sample.ejb;
import java.util.List;
import javax.ejb.Remote;
import sample.entity.Account;
@Remote
public interface AccountService {
 public boolean register(Account account);
 public List find(String loginname);
}
/-------------------------------------------------

■Session Bean (ローカルIFクラス)
--------------------------------------------------
package sample.ejb;
import java.util.List;
import javax.ejb.Local;
import sample.entity.Account;
@Local
public interface AccountLocalService {
 public boolean register(Account account);
 public List find(String loginname);
}
/-------------------------------------------------

■Stateful Session Bean
--------------------------------------------------
package sample.ejb;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Stateful;
import sample.entity.Account;
@Stateful
public class SearchServiceBean implements SearchService {
private List searchResult;
………
}
/-------------------------------------------------
@Stateful
 →そのBeanがStateless Session Beanであることを示す。
 →name属性:Beanの名前
  ejb-jar内で一意であること。
 →mappedName属性:このBeanをマッピングする製品固有の名前を指定する。
 →description属性:このBeanの説明。
@Remove
 →このStateful Session Beanを破棄する際に呼ばれるメソッドを指定する。
 →@PreDestoryを指定したメソッドが存在する場合、
  先にPreDestoryが呼ばれ、次いでRemoveを付与したメソッドが呼ばれる。
 →retainIfException属性:
  メソッドがアプリケーション例外を発した時、
  SFSBを削除しないことを指定する。
  デフォルトはfalse。

■Message-driven Bean
--------------------------------------------------
package sample.ejb;
import javax.ejb.MessageDriven;
import javax.jms.Message;
import javax.jms.MessageListener;
@MessageDriven
public class MyMDB implements MessageListener {
 public void onMessage(Message message) {
  ………
 }
}
/-------------------------------------------------
@MessageDriven
 →そのBeanがMessage-Driven Beanであることを示す。
 →name属性:Beanの名前
  ejb-jar内で一意であること。
 →mappedName属性:このBeanをマッピングする製品固有の名前を指定する。
 →messageListenerInterface属性:
  BeanがIFを実装していない場合や複数のIFを実装している場合に、
  MessageListenerIFを指定する。

■DeploymentDescriptor

■Dependency Injection
□Simplified API Dependency Injection
EJB
 →EJBへの参照
 →変数の名前と型から注入するBeanをコンテナが判別する。
 →このルールに合わない場合は、
  name属性でJNDI名、beanInterface属性でそのBeanのIFを指定する。
@PersistenceContext
 →PUへの参照
 →name属性で特定のPUを指定する。
@Resource
 →リソースへの参照。
  データソース、トランザクション、オブジェクト等。
 →JNDIにバインドされているオブジェクトを注入する。
 →変数の名前と型から注入するオブジェクトをコンテナが判別する。
 →このルールに合わない場合は、
  name/mappedName属性でJNDI名、type属性でそのオブジェクトの型を指定する。

--------------------------------------------------
package sample.ejb;
@Stateless
public class AccountServiceBean implements AccountService {
 @PersistenceContext
 private EntityManager em;
 ......
}
/-------------------------------------------------

■Persistence Unit
→以下を含む論理的なグループ。
 *Entity Manager FactoryとEntity Manager及びその設定情報
 *Entity Managerで管理されるクラス
 *クラスとDBをマッピングするメタデータ
→JavaEE環境では、EJB-Jar,War,Ear、application client Jarで
 PUを0個以上定義できる。
→PUは名前を持つこと。
 PU名は、アプリで一意であること。
→persistence.xmlに定義する。
→persistence.xmlは、
 クラスパス上のMETA-INFディレクトリに配置する。


XXX

ref:
http://www.java-users.jp/contents/events/basicseminar/200803annotation/AnnotationEE5.pdf

tag : EJB

2009-06-07 17:45 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ トランザクション

■トランザクション属性
トランザクションがEJBアプリでどのように管理されるかを指定。
-WebLogicServerEJBコンテナによるトランザクションの境界の設定(コンテナ管理のトランザクション)
EJB自身によるトランザクションの境界の設定(Bean管理のトランザクション)
EJBがコンテナ管理とBean管理のどっちかは、
デプロイメント記述子のtransaction-type要素次第。


XXX

ref:
EJB アプリケーションのトランザクション, WebLogic JTA プログラマーズ ガイド
http://otndnld.oracle.co.jp/document/products/wls/docs70/jta/trxejb.html

tag : EJB

2009-05-19 23:18 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

LINKS/ J2EE/ EJB

EJB3.0(Early Draft) 入門記
http://www.wikiroom.com/koichik/index.php?EJB3.0%28Early%20Draft%29%20%C6%FE%CC%E7%B5%AD

EJB入門記
http://d.hatena.ne.jp/taedium/20050001

tag : EJB LINKS

2009-05-19 23:17 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ Transaction

EJB2.0時代の話ぽい。

■トランザクション属性
deployment descriptorに記録される。

トランザクション属性の指定対象レベル
-Bean全体
-個々のメソッド毎
※Bean全体にある属性を指定しても、
 そのBean内のメソッドに、
 異なる属性を指定した場合は、
 メソッドの属性が優先される

トランザクション属性の指定対象
-SessionBean
-EntityBean

■Rollback of Container Managerd Transaction


XXX


ref:
第8回 J2EEのトランザクション処理
http://www.atmarkit.co.jp/fjava/rensai/j2ee08/j2ee08_5.html

tag : EJB

2009-05-12 06:41 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ DB TRANSACTION

■アクセス・インテント(DBアクセスに対する最適化)
WASが提供するエンティティBeanのDBアクセスに対する最適化の仕組み。
アクセス・インテント ポリシーの設定で、
CMP(Container Managed Persistence) BeanのDBアクセスの分離レベルを指定する。
※WASは、7つのアクセス・インテント・ポリシーをサポートする。
アクセス・インテント・ポリシーは、以下3要素から成る。
-ConcurrencyControl(DBロック解決案)
-トランザクション分離レベル
-アクセス・タイプ(Read処理かUpdate処理の2つ)

ref:
第6回 EJBはトランザクションのやり方次第で速くなるのに…
http://www.atmarkit.co.jp/fjava/rensai4/websphere06/websphere06_1.html
2009-05-10 23:25 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ Bean Types

■Overview
+Entity Bean
  +CMP Entity Bean
  +BMP Entity Bean
+Session Bean
  +Stateless Session Bean
  +Stateful Session Bean
+Message Driven Bean

□EntityBean
永続化されたデータそのものを表すBean。
複数のクライアントから共有可能で、一意のキーで探索できる。
テーブルの1レコード=1EntityBeanインスタンス
な感じで、プライマリーキーを持てる。
EntityBeanの内容が変更されると、
対象となるデータベースのレコードも内部で自動的に更新(永続化)されるため、
EJBサーバを終了しても、データは消滅しない。

□CMP Entity Bean
Container Managed Persistence Entity Bean。
永続化の為のデータベースアクセスをEJBコンテナが管理する、ゆうもの。
永続化の指定は、配備記述子(DD, Deployment Descriptor)に記述する。
開発者は、リソース(DB等)へのアクセスのためにコードを書かんでも済む。

□BMP Entity Bean
Bean Managed Persistence Entity Bean。
永続化に関する処理を、Bean自身がやる、ゆうもの。
永続化のためのSQLをbeanのコードとして記述する。
開発者が、リソースへのアクセスをコーディングせんといけん。

□Session Bean
ビジネスロジックを実行するためのBean。
「セッション」単位で処理を記述する。
Bean自身の情報が、永続化されることはなく、
EJBサーバの終了で、Beanの状態も破棄される。

□Stateless Session Bean
状態を保持しないBean。
動作が高速で、複数のクライアント要求を同時に処理できる。
Beanのインスタンスの生成・消滅は、全てEJBコンテナが独自管理。
同じBeanのメソッドを続けて呼び出しても、
同じインスタンスである保証はない。
1メソッドで完結するような処理の記述に適す。

□Stateful Session Bean
内部情報を保持できるBean。
クライアントとのconversational状態をコンテナで維持し、
クライアントがセッションを終了すると、データを破棄する。
一般的なクラスのインスタンスと同じ感じ。
Home Interfaceからの生成によってインスタンス化された後は、
メソッドの呼び出し毎に生成、消滅しない。
セッション単位で連続した処理の実装に適す。

□Message Driven Bean
メッセージキューによる非同期トランザクション処理のためのEJB.
オンライントランザクション処理(OLTP)のためのSession BeanとEntity Beanと異なり、
MDBにはEJBクライアントからアクセス出来ず、メッセージの到着をトリガーとして実行される。
メッセージの待ちキューを実装する仕組みをJMSと呼び、
実装する機能はMOM(Message Oriented Middleware)と呼ぶ。



ref:
http://www.atmarkit.co.jp/fjava/javafaq/j2ee/j2e13.html
# ↓なんかトリッキーで信頼性が疑わしい。。
http://72.14.235.132/search?q=cache:9MxQxRub__QJ:www.nextindex.net/java/J2EE/EJB.html

tag : EJB

2009-04-20 23:24 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

Best practicies in EJB exception handling

■before all
あれこれ始める前に ↓をクリアにしといて
・エンティティBeanとセッションBeanの違い
・bean-managed persistence (BMP) と container-managed persistence (CMP)の違い


■例外ハンドリングの一般的な決まりごと
1. ハンドリング出来んのならcatchせんこと.
2. catchした例外は揉み消さないこと.
3. なるたけ例外発生箇所に近いとこでcatchすること
4. catchしたとこでログること 出なければ再throwすること
5. structure your methods according to how fine-grained your exception handling must be.
6. use as many typed exceptions as you need, particularly for application exceptions.

+ it is a trade-off b/w how close to the source you catch an exception (point 3) and how far you let it fall before you've completely lost the intent or content of the original exception.


□log4j
log4j has three main components: layout, appender and category.
layout
represents the format of the message to be logged.
appender
is an alias for the physical location at which the message will be logged.
category
is the named entity; you can think of it as a handle for logging.

every category comes with its own layout and appender difinitions.


■exception categories
the ejb spec classifies exceptions into three broad categories:
+ JVM exceptions:
 this type of exception is thrown by the JVM.
 there is nothing you can do about JVM exceptions.
 they indicate a fatal situation.
 the only graceful exit is to stop the application server,
 maybe beef up the hardware resources, and restart the system.
 ex. OutOfMemoryError
+ Application exceptions:
 an application exception is a custom exception thrown by the application or a third-party library.
 these are essentially checked exceptions;
 they denote that some condition in the business logic has not been met.
 under these conditions,
 the caller of the EJB method can gracefully handle the situation and take an alternative path.
+ System exceptions:
 most often system exceptions are thrown as subclasses of RuntimeException by the JVM.
 a NullPointerException, or an ArrayOutOfBoundsException, for ex, will be thrown due to a bug in the code.
 another type of system exception occurs
 when the system encounters an improperly configured resource such as a missplelled JNDI lookup.
 in this case, it will throw a checked exception.
 the rule of thumb is, if there isnt anything you can do about an exception, it's a system exception and it should be thrown as an unchecked exception.
 
 note:
 a checked exception
  is a java class that subclasses java.lang.Exception.
  by subclassing java.lang.Exception, you are forced to catch the exception at compile time.
 unchecked exception
  is one that subclasses java.lang.RuntimeException.
  subclassing java.lang.RuntimeException ensures you will not be forced by the compiler to catch the exception.
 
 
■How the EJB container handles exceptions
EJBコンテナが、EJBコンポーネントの全メソッドを呼ぶ。
つまり、例外も、EJBコンテナが呼ぶ。
EJBが扱う例外は2種類のみ:
application exceptionとsystem exception。

+application exception
any exception declared on the method signatures in the remote interface (other than RemoteException).
基本的に業務のワークフローで生じるもの。
application exceptionは、RuntimeExceptionやそのサブクラスを継承すべきでない。
when an application exception occurs, the EJB container doesnt roll back the transaction unless it is asked to do so explicitly, with a call to the setRollbackOnly() method on the associated EJBContext object.
application exceptionはクライアントに届けられるべきもの。
EJBコンテナは決してapplication exceptionをラップしたりしない。

+system exception
cheched exceptionかunchecked exceptionのどっちかで
EJBメソッドがリカバー出来ないもの。
EJBコンテナがunchecked例外をinterceptすると、
トランザクションをロールバックして必要に応じてクリーンアップする。
それからunchecked例外をRemoteExceptionでラップして
クライアントにthrowする。
つまり、
EJBコンテナがクライアントに投げるunchecked system exceptionは
全部RemoteExceptionか、そのサブクラスゆうこと。

EJBコンテナをinternal housekeepingとして使うんなら
checked例外をunchecked例外としてthrowせんといけんくなるやろう。
どこで発生したsystem exceptionだろうが、
javax.ejb.EJBExceptionかそのサブクラスで、
オリジナル例外をラップして投げる感じ。
なぜなら、
EJBException自身はunchecked例外で、
there is no need to declare it in the throws clause of the method.
EJBコンテナは、EJBExceptionかサブクラスをcatchして、
RemoteExceptionにラップしてクライアントにthrow。

※EJB1.1以降は、EJB実行クラスはRemoteExceptionを投げないこと。

※RemoteException ex ... java.lang.Exception
※EJBException ex java.lang.RuntimeException


■Common exception-handling strategies
複数の開発者が好き勝手に例外ハンドリングしては保守が大変。
同じ例外でも、発生箇所次第で、異なるハンドリングが必要になりうるもの。
その辺をきちんとせんと、ログ出力が散在してまう。
ideally, exception logging should occur in as few places as possible w/o compromising the content.


■EJB exception-handling heuristics
in good EJB design,
clients never invoke methods on entity EJB components.
基本的にエンティティEJBは、セッションEJBが呼ぶもの。
きちんとセッションEJBが呼んでる場合は、例外ログもセッションBeanで。
クライアントが直接エンティティEJBを呼んでしまってる場合は、
クライアントだけやなく、エンティティEJBでもログ出力すべし。

クライアントに呼ばれたエンティティEJBはセッションEJBからも呼ばれうる。
つまり、ログの重複が生じうる。

解決法↓
・the extent of planned code reuse:
 複数ヶ所でのログ出力が問題。ログ出力箇所を減らすデザインに直す。
・the type of clients you want to serve:
 it is important to consider whether you will be serving a J2EE Web tier, stand-alone java applications, PDAs, or other clients.
・the type of exception (app or sys) youll be dealing with:
 handling application exception is significantly different from handling system exceptions.
 it's best to handle an original exception by wrapping it.
 on the other hand,
 application exception are explicitly thrown by the EJB developer, often by wrapping a message. because the intent of an application exception is clear, there is no reason to preserve its context. this type pf exception need not be logged in the EJB tier or the client tier.


■handling application exceptions
nth special discovery...


■handling system exceptions
entity EJB components encounter
- RemoteExceptions when they refer to other EJB remote interfaces
-NamingExceptions while looking up other EJB components
-SQLException if they use bean-managed persistence (BMP).
上記のような例外らは、EJBExceptionにラップされてcatchなりthrowなりされるべき。


■avoiding duplicate logging
一般的に、例外ログは、セッションBeanで出力されるもの。
だが、エンティティBeanが直接他の層のBeanにアクセスしたりすると、エンティティBeanでも例外をログったり投げたりせんといけんくなる。
the problem here is that the caller has no way of knowing that the exception has been logged and will likely log it again, which will result in duplicate logging.
more importantly, the caller has now way of accessing the unique ID generated during the initial logging. any logging w/o the mechanism to cross-reference is no good.

solution:
fortunately, addressing there problems is fairly easy to do in a generic way. all you need is a mechanism for the caller to:
-access the unique ID
-find out if the exception has already been logged
ex:
public class LoggableEJBException extends EJBException {
 //flg to check if the exception has been logged.
 protected boolean isLooged = false;
 protected String uniqueID = null;
 public LoggableEJBException (Exception e) {
  super(e);
  // generate a ID using the current time and host name of the machine.
  uniqueID = ExceptionIDGenerator.getExceptionID();
 }...
}

note code:
} catch (RemoteException re) {
 Throwable t = re.detail;
 if ( t != null && t instanceof Exception) {
  throw new LoggableEJBException ( (Exception) re.detail );
 } else {
  throw ne LoggableEJBException(re);
 }
}


■System exception in session EJB components
there is one way that session EJB components might handle exceptions differently from entity EJB components:
because
most EJB systems are accessible only from the Web tier and session EJB can serve as a facade to the EJB tier.
it's different because in a RemoteException, the actual exception will be stored in a public attribute called detail (which is of type Throwable). most of the time, this public attribute holds an esception. if you call a printStackTrace on a RemoteException, it prints the stack trace of exception itself, in addition to the stack trace of the detail. you dont need the stack trace of the RemoteException as such!!


■[TIPS] StackTraceUtil
a StachTraceUtil can help you to lconvert stack traces into Strings and log the Strings.
(log4j can only log the String messages.)

public class StrackTraceUtil {
 public static String getStackTrace(Exception e) {
  StringWriter sw = new StringWriter();
  PrintWriter pw = new PrintWriter(sw);
 }
 ...
}

note:
デフォルトのjava.lang.Throwable#printStachTrace()は、
system.err.throwableにログ出力するのと、
オーバーロードされたprintStackTrace()を持つ。
printStackTrace()は、PrintWriter か PrintStreamにログる。
上のStackStraceUtilのメソッドは、StringWriterをPrintWriterでラップしてるから、
PrintWriterが呼ばれた時、PrintWriterはスタックトレースを保持してる、ゆうわけ。
つまり、
StringWriterのtoString呼ぶだけで、stack trace情報が取得できちゃうのだ。


ref:
Best practicies in EJB exception handling
Srikanth Shenoy, 01 May 2001
http://www.ibm.com/developerworks/library/j-ejbexcept.html

tag : EJB TIPS

2009-04-20 22:29 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ JPA

Java Persistence API

【*】登場人物
+エンティティ
 Javaクラスをアノテーションが設定ファイルで定義
+エンティティ・マネージャ
 JPA提供のIF
 エンティティの取得や永続化を担当
+永続コンテキスト
 メモリ上のエンティティの集合
 JPAの実装で管理される
EJB QL
 エンティティを取得する為の問い合わせ言語

【*】さんぷる
--------------------
pkg hoge;
impt javax.persistence.Entity;
impt javax.persistence.GeneratedValue;
impt javax.persistence.Id;

@Entity
public class Employee {//final指定しないこと

 public Employee() {}//引数なしコンストラクタの用意
 public Employee(Str name, long salary) {
  this.name = name;
  this.saraly = salary;
 }

 @Id//means primaryKey
 @GeneratedValue//means generating primaryKey automatically
 private Long id;
 private String name;
 private long salary;//dont def field as final

 public Long getId() {return id;}//doesnt need setter cuz its generated automatically.

 public String setName() {return name;}
 public void setName(String name) {this.name = name;}

 public String toString() {
  return getId() + ", " + getname() + ", " + getSalary();
 }
}
--------------------

【*】EntityManager
エンティティの取得や永続化等エンティティのライフサイクルの制御を担当

【+】エンティティのライフサイクル
*new
 プログラム上で新規に生成されたエンティティの状態
 プライマリキーなし
 永続コンテキストとの関連付けなし
*managed
 プライマリキーあり
 永続コンテキストと関連付け済み
 managedEntityに対する変更は自動的に検出され
 トランザクションのコミット時にDBに反映される
*detacked
 プライマリキーあり
 永続コンテキストとの関連付けなし
 managedEntityは永続コンテキストが終了で分離された状態になる
 永続コンテキストはデフォルトでは
 トランザクションの終了で自身も終了する
*removed
 プライマリキーあり
 永続コンテキストと関連付け済み
 DBからの削除が予定された状態
 実際の削除はトランザクションのコミット時

【*】さんぷる
--------------------
pkg hoge;
impt java.util.List;
impt javax.ejb.Stateless;
impt javax.persistence.EntityManager;
impt javax.persistence.PersistenceContext;

@Stateless
public class EmplyeeDaoBean impl EmployeeDao {

 @PersistenceContext
 private EntityManager entityManager;

 public void setEntityManager(EntityManagerr em) {
  this.entityManager = em;
 }

 public List getAllEmployees() {
  return entityManager.createQuery("select e from Employee e").getResultList();
 }

 public Employee create(String name, Long salary) {
  Employee e = new Employee(name, salary);
  //persist-method
  //making the new entity managerdEntity.
  entityManager.persist(e);//the timing to insert into DB.
  return e;
 }

 public void updateSalary(Loing id, Long newSalary) {
  //find-method
  //searching with primaryKey.
  //it returns a managedEntity.
  Employee e = entityManager.find(Employee.class, id);
  e.setSalary(newSalary);
 }

 public void update(Employee employee) {
  //merge-method
  //merging the detachedEntity with persistenceContext,
  //and making it managedEntity.
  Employee managed = entityManager.merge(employee);
 }

 public void remove(Long id) {
  Employee e = entityManager.find(Enployee.class, id);
  //remove-method
  //deleting the entity.
  entityManager.remove(e);
 }
}
--------------------
pkg hoge;
impt java.util.List;
impt javax.ejb.Local;

@Local
public interface EmployeeDao {
 List getAllEmployees();
 Employee create(String name, long salary);
 void update(Employee employee);
 void updateSalary(Long id, long newSalary);
 void remove(Long id);
}
--------------------
pkg hoge;
impt java.util.List;
impt javax.naming.InitialContext;
impt org.jboss.ejb3.embedded.EJB3StandaloneBootstrap;

public class Main {
 public static void main(String[] args) throws Exception {
  EJB3StandaloneBootstrap.boot(null);
  EJB3StandaloneBootstrap.scanClasspath();

  InitialContext ctx = new initialContext();
  EmployeeDao empDao = (EmployeeDao) ctx.lookup("EmployeeDaoBean/local");

  syso("### 1.追加 ###");
  empDao.updateSalary(emp.getId(), 100000);
  display(empDao.getAllEmployees());

  syso("### 2.更新 ###");
  empDao.updateSalary(emp.getId(), 200000);
  display(empDao.getAllEmployees());

  syso("### 3.更新(マージ) ###");
  emp.setSalary(300000);
  empDao.update(emp);
  display(empDao.getAllEmployees());

  syso("### 4.削除 ###");
  empDao.remove(emp.getId());
  display(empDao.getAllEmployees())+

  EJB3StandaloneBootstrap.shutdown();
 }

 private static void display(List employees) {
  for (Employee emp : employees) {
   syso(emp);
  }
 }
}
--------------------

ref:
http://itpro.nikkeibp.co.jp/article/COLUMN/20060627/241918/

tag : Java Persistence API JPA EJB

2009-02-20 21:12 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :

EJB/ Introduction

Enterprise JavaBeans
Javaのエンタープライズ向けコンポーネントの標準仕様

【*】コンポーネント作成
通常のIFとクラスでEJB3.0のコンポーネント作成
EJB2.1
 コンポーネントが実装するIF=javax.ejbパッケージのIFを実装
 コンポーネントのクラス自身=Beanクラス
EJB3.0
 コンポーネントが実装するIF=ビジネス・インタフェース
 コンポーネントのクラス自身=Beanクラス

設定(実行時情報の定義)は XML か アノテーション
EJB2.1
 XML(デプロイメント記述子)
EJB3.0
 アノテーション
 ex
 @Stateless
 public class HogeBean impl HogeIF {...}
 →ステートレス・セッションBeanゆう種類のEJBクラスを表す

【*】コンポーネント呼び出し
@EJB2.1
 ホーム・インタフェースゆうIF使ってコンポーネントを取得
@EJB3.0
 呼び出し元のソースコードに@EJBのアノテーションを記述して取得
 →要はDI。

【*】Javaオブジェクト-DB間のデータ変換
@EJB2.1
 エンティティBeanでO/Rマッピングと永続化を実現
 →あれこれ機能が絡まってて めんどう
@EJB3.0
 Java Persistence APIゆう仕様で O/Rマッピングと永続化系機能をEJBから独立

【+】Java Persistence API
サーバ再度環境とスタンドアロン環境に共通したJava標準のAPI
JDBCよりも上位のAPI
直接JDBCのAPIを使うのに比べ シンプルなコードで
DBのデータとJavaオブジェクトとの相互変換が出来る
開発者は
DBのテーブルに対応するJavaクラスを作成し
そのクラスにアノテーションを付けるだけでマッピング終了

【+】EJB3.0の動作環境
Embeddable EJB3.0が有効
APサーバなしでも動かせる

Embeddable EJB3.0で足らんかったら
JBoss Application Serverが有効

IDEはエクリプスで

【*】@Stateless/ ステートレス・セッションBean
メソッド呼び出しにまたがって状態を保持しないEJBのコンポーネント
パフォーマンスに優れていて設計しやすいんが特徴
要IFの実装

【*】@EJB/ DI
フィールドに付けることで
そのフィールドがIFへの参照が要ることを示す
--------------------
pkg hoge;
public interface Hoge {
 String getName();
}
--------------------
pkg hoge;
impt javax.ejb.Stateless;
@Stateless
public class HogeImpl impl Hoge {
 public String getName() {
  return "hoge";
 }
}
--------------------
pkg hoge;
public interface Piyo {
 void sayHello();
}
--------------------
pkg hoge;
impt javax.annotation.EJB;
impt javax.ejb.Stateless;
@Stateless
public class PiyoImpl impl Piyo {
 @EJB
 private Hoge hoge;
 public void sayHello() {
  syso("Hello " + hoge.getName() + "!");
 }
}
--------------------

【*】EJB3.0のオブジェクト
全部で3種類
①セッションBean
②メッセージ・ドリブンBean
③エンティティ

【*】セッションBean
呼び出し元のプログラムに呼び出されると同期的に実行される
全部で2種類
①ステートフルセッションBean
 メソッド跨ぎのステートを維持するセッションBean
②ステートレスセッションBean
 メソッド跨ぎのステートを維持しないセッションBean
ステートレスセッションBeanはWebサービスとして実行できる

【*】メッセージ・ドリブンBean
メッセージ受信で起動し 非同期的に実行されるため
呼び出し元のプログラムは
送信したメッセージドリブンBeanの実行完了を待たずして次処理へ

【*】エンティティ
DBのデータをオブジェクトして表したもの
典型的なケースは 1レコード1エンティティインスタンスになる
Java Persistence APIでのデータアクセスで使用するもの

【+】StatelessSessionBean > StatefulSessionBean @利便性
①cuz of high performance
 StatefulSessionBean keeps its conversation.
 if there are many StatefulSessionBean, it affect the resources.
 this gonna be a reason for a bad performance.
②easy design and test
 StatelessSessionBean has simple lifecycle than Stateful.
 its operation result only depends on its self.
 this make designing and test easy.
you can use StatelessSessionBean and keep the state by using HttpSession via a webContainer.
acutally it depends on the case, but better to use Stateless.

【*】さんぷる
--------------------
pkg hoge;
impt javax.ejb.AroundInvoke;
impt javax.ejb.InvacationContext;

public class TraceInterceptor {

 @AroundInvoke
 public object trace(InvationContext ctx)
   throws Exception {//AroundInvokeの規約

  String className = ctx.getBean().getClass().getName();
  String methodName = ctx.getMethod().getName();

  String dspName = className + "#" + methodName;
  syso("START " + dspName);

  try {
   return ctx.proceed();//インタセプトしたメソッドの実行
  } finally { syso("END " + dspName);}
 }
}
--------------------
pkg hoge;
//impt javax.ejb.Remote;
impt javax.ejb.Local;

//@Remote//リモート呼び出しで実行可能
@Local//ローカル呼び出し(呼び出し元とセッションBeanが同一JVMにいること)で実行のみ実行
public interface Hello {
 void sayHello();
}
--------------------
pkg hoge;
impt javax.ejb.Interceptors;
impt javax.ejb.Stateless;

@Stateless //means this is a StatelessSessionBeanClass
@Interceptors({TraceInterceptor.class})//means this is the target class to intercept.
public class HelloBean impl Hello {//must be a class. no final or abstract.

 public void sayHello() {//must have a constructor with noargs for container to create a instance.
  syso("Hello!");
 }
}
--------------------
pkg hoge;
impt javax.naming.InitialContext;
impt org.jboss.ejb3.embedded.EJB3StandaloneBootstrap;

public class Main {
 public static void main(String[] args) throws Exception {
  EJB3standaloneBootstrap.boot(null);
  EJB3standaloneBootstrap.scanClasspath();

  InitialContext ctx = new InitialContext();
  Hello hello = (Hello) ctx.lookup(Hello.class.getName());

  hello.sayHello();

  EJB3standaloneBootstrap.shutdown();
 }
}
--------------------
[RESULT]
START hoge.HelloBean#sayHello
Hello!
END hoge.HogeBean.sayHello
--------------------

【*】宣言的トランザクション
--------------------
@Stateless
@TransactionManagement(CONTAINER)//デフォルト指定なら引数省略可
@TransactionAttribute(REQUIRED)//デフォルト指定なら引数省略可
public class MyLogic {

 public void myLogicMethod() {
  dao.MyDaoMethod1();
  dao.MyDaoMethod2();
 }
}
--------------------
@Stateless
@TransactionMnagement(CONTAINER)//コンテナがトランザクション管理を担当
@TransactionAttribute(REQUIRED)//既存トランザクションの流用+なければ新規作成
public class MyDao {

 public void MyDaoMethod1() {
 //gonna executed with the same transaction as where calling.
  //DB ACCESS
 }

 public void MyDaoMethod2() {
  //DB ACCESS
 }
}
--------------------
[FLOW]
SOME CLASS calls BusinessInterface@EJBContainer.
BussinessInterface calls EJBInstance@EJBContainer.
EJBContainer intercepts the TransactionInterceptor@EJBContainer before returning the EJBInstance to BusinessInterface.
TransactionInterceptor uses Java EE API to transact.

【*】HOW TO ROLLBACK
方法① javax.ejb.SessionContext#setRollbackOnlyを利用する
方法② 例外を利用する


ref:
http://itpro.nikkeibp.co.jp/article/COLUMN/20060615/241006/

tag : EJB

2009-02-19 00:24 : __j2ee__ejb : コメント : 0 : トラックバック : 0 :
ホーム

search

ad



counter


tag cloud

category cloud