jini's Java EE 5.0 部落格

Struts Action get Resource by Injection

2006-07-17T09:57:27+02:00

http://www.codecomments.com/archive419-2006-6-954408.html

Craig McClanahan:

A couple of possibilities come to mind ...

* Inject the resource into a container-instantiated object
(like a servlet), and modify your framework to copy values
in when it creates, say, an Action instance in the Struts case.
BIG PROBLEM: thread safety ... the servlet instance is shared
across all threads, so the variable would get stomped on if there
was more than one simultaneous request.

* Modify your framework to scan for the injection annotations itself
when it creates new object instances, and perform the same kinds
of injection that the container can do.

* Use a dependency injection framework that knows how to initialize
properties from JNDI lookups, and configure it to look up the
corresponding resources.

* Use the managed beans portion of JSF (even if you are not using
the rest of it) as a dependency injection framework, and let the
container go ahead and do the injection for you. (If you're using
an additional framework, it would need to be modified to use
managed beans to create object instances, instead of doing
Class.newInstance() things itself).

Craig

換句話說, Application Server 決定了是否可以 inject 相關的 Resource 到你的系統之中,
如果該 Application Server 並沒有支援 Struts Action 或其他 Framework,
就等於即使你的系統也在 Java EE 5.0 的環境中執行 ~~
也得使用 JNDI lookup 去取得相關的 Resource,

假設仍然使用習慣的 Framework, 就不會修改相關原始碼去掃描 Annotations.
應該也不會另外找個 DI Framework 來增加 Framework 的複雜度吧..
難道大家都要被迫學習 JSF ?!

看來.. 在 Web-tier 利用 InjectionFilter or InjectionInitServlet 先取得相關資源
例如 DataSources, EntityManager 放到 SessionScope 或 ApplicationScope ?
應該是比較可行的方案了..

Interceptor 與 inv.proceed() 的關係

2006-07-16T11:30:55+02:00

寫了一個小程式測試了一下, @Interceptors 他的操作方式

@Stateless
@Interceptors({AuditInterceptor.class, SecurityInterceptor.class})


public class AuditInterceptor {
    @AroundInvoke public Object auditOperation(InvocationContext inv) 
        throws Exception {
        try {
            System.out.println("audit "+inv.getMethod().getName());
            Object result = inv.proceed();
            System.out.println("test after proceed");
            return result;
        } catch ( Exception ex ) {
            throw ex;
        } finally {
            System.out.println("finally end message");
        }
        
    }
}


import javax.interceptor.*;
public class SecurityInterceptor {
    @AroundInvoke public Object securitySome(InvocationContext inv) 
        throws Exception {
        try {
            System.out.println("security"+inv.getMethod().getName());
            Object result = inv.proceed();
            System.out.println("test after proceed in security");
            return result;
        } catch ( Exception ex ) {
            throw ex;
        } finally {
             System.out.println("Final in security");
        }
        
    }
    
}

執行的結果是

audit getHello|#]

securitygetHello|#]

Hello in getHello()|#]

test after proceed in security|#]

Final in security|#]

test after proceed|#]

finally end message|#]

換句話說, 當我們透過 InvocationContext proceed 之後,
會將 process 指到下一個 Interceptor
當沒有下一個 Interceptor 的時候

就會到了 Bean Method() 的操作

等到 Bean Method() 結束之後
才會開始處理 proceed 之後的功能
一直等到你執行 reutnr Object ( inv.proceed() ) .

雖然 return 該 Object ( inv.proceed() ) 之後,
我們也可以利用 finally 來處理最後的相關事務

Interceptor 攔截 basic concept

2006-07-10T07:11:16+02:00

EJB3 為了可以支援 AOP ( swanky : AOP Presentation - http://www.ice.ntnu.edu.tw/~swanky/presentation/PL_AOP.pdf )
所以建立了Interceptors 的觀念.

不過, 雖然是放在 ejb3 api 的製作之中, 但是他的 package 為 javax.interceptor.*, 換句話說, 未來有機會可能會移出 ejb-api .

其實, 熟稔 AOP 概念的人 ( AspectJ, AspectWerkz ) 通常會對於 EJB3 目前僅提供 Interceptor 實作的方法, 覺得比較陽春.
但是, 也可以這麼思考, 利用 Interceptor 應該就可以達到一般人的需求 !

在 Interceptor, 只有 InvocationContext Interface, 以及四個 Annotation Types.
* AroundInvoke
* ExcludeClassInterceptors
* ExcludeDefaultInterceptors
* Interceptors

我們在呼叫任何一個 EJB Bean Class 的時候, 可以利用 @Interceptors 來設定

@Interceptors(MyCallbackHandler.class)
public class MyEJB {
....
}

或是利用 deployment descriptor ( ejb-jar.xml ) 來定義 interceptors


<ejb-jar>
  <sessions>
    ...
  </sessions>
  <interceptors>
     <interceptor>
       <interceptor-class>com.softleader.interceptors.MyCallbackHandler</interceptor-class>
       <pre-destroy>
         <lifecycle-callback-method>someInteceptorMethod</lifecycle-callback-method>
       </pre-destroy>  
     </interceptor>
  </interceptors>
  <assembly-descriptor>
      <interceptor-binding>
         <ejb-name>*</ejb-name>
         <interceptor-class>com.softleader.interceptors.MyCallbackHandler</interceptor-class>
      </interceptor-binding>  
      <interceptor-binding>
         <ejb-name>SlessEJB</ejb-name> 
         <exclude-default-interceptors>true</exclude-default-interceptors> 
      </interceptor-binding>
      <interceptor-binding>
         <ejb-name>SlessEJB2</ejb-name> 
         <exclude-default-interceptors>true</exclude-default-interceptors> 
      </interceptor-binding>
  </assembly-descriptor>
</ejb-jar>

非常明顯的, 我們可以看到, 我們需要利用 interceptor-binding 將 interceptor-class 指向到所有(*) 或單一(EJBName) 的結合.
以及是否去除 ( exclude-default-interceptors ) 預設的 binding 原則.

一個簡單的 Interceptor 的撰寫方式


import javax.interceptor.InvocationContext;
public class MyCallbackHandler {
    public void someInteceptorMethod(InvocationContext invCtx) {
        System.out.println("Hello Inteceptor in pre-destroy callback methods ");
        try {
            invCtx.proceed();
        } catch(Exception e) {
            e.printStackTrace();
        }
    }
}

當呼叫 InvocationContext.proceed() 之後, 將會進行下一個 interceptor 的作業.

所以我們必須利用 InvocationContext 來取得我們攔截下來取得相關的資訊, 進行相關的處理.

Map getContextData()
Method getMethod()
Object[] getParameters()
Object getTarget()
Object proceed()
void setParameters()

除了控制生命週期的攔截之外, 我們可以利用 ArroundInvoke() 進行相關的攔截


@AroundInvoke

Object aroundInvoke(InvocationContext ctx) throws Exception {

  Common.aroundInvokeCalled(ctx, "testArroundInvoke");

  Object instance = ctx.getTarget();

  if( instance instanceof SomeEJB) {

      ((SomeEJB) instance).aroundInvokeCalled = true;

   }

   return ctx.proceed();

}

這樣就可以建立基本的 AOP 實作了

@Resource 資源取得 JNDI 的相關資源

2006-04-09T17:20:07+02:00

在 TheServerside 看到這篇文章
http://www.theserverside.com/news/thread.tss?thread_id=39828

我利用簡單的資料庫連結做說明, Java EE 5.0 如何使用 @Resource 來取得相關資源

1. JDBC direct connect the Database
這是簡單的範例, 我們可以直接利用 DriverManager 去取得 connection, 這種寫法是由 Application 直接驅動連結, 沒有透過 Container, 我認為不是很好的方法 !


// JDBC Driver 的主要 class 名稱
Class.forName("com.mysql.jdbc.Driver"); 
// 每個 Driver都有標準的連結位置撰寫方式
String url = "jdbc:mysql://host:port/database"; 
// 將 URL 與登入帳號密碼連結
Connection con = DriverManager.getConnection( url ,"username","password"); 
//....
con.close();

2. DataSource Connection
透過 JNDI 以及 Context lookup 取得 DataSource, 再用 DataSource.getConnection() 取得 Connection.


Context initCtx = new InitialContext();
DataSource ds = (DataSource) initCtx.lookup("jdbc/mysql");
Connection conn = ds.getConnection();
//... use this connection to access the database ...
conn.close();

3. @Resource mapped global JNDI
當開發工程師知道, application server 之中, 已經具備了 jdbc/mysql 這個 JNDI Name, 這樣算是取代了 JNDI context lookup 的方法.


@Resource(name="jdbc/mysql")
private DataSource ds;

Connection conn = ds.getConnection();
//... use this connection to access the database ...
conn.close();

4. @Resource dependency injection
當開發工程師不知道, application server 之中, 到底具備了哪些資源可以利用, 可以利用 Java EE 5.0 Annotation Resource Injection 的特性, 讓組裝部署人員做相關的設定.


@Resource
private DataSource ds;

Connection conn = ds.getConnection();
//... use this connection to access the database ...
conn.close();

web.xml


    
        packageName.ClassName/ds
        javax.sql.DataSource
        Container
        Shareable

sun-web.xml


  
    DSResourceInjectionServlet/ds
    jdbc/__default

所以, 組裝人員可以在 web.xml , sun-web.xml ( glassfish ) 設定相關的 injection 環境及對應到 application server 的 global 的 jndi 設定, 這樣, 可以輕易地完成 Injection 的實作.

Java EE 5.0 Resource Injections

2006-03-30T21:05:00+02:00

Java EE 5.0 之中有定義一些可以使用 injection 的 classes

*Servlet
- servlets
- servlet filters
- event listeners
* JSP
- tag handlers
- tag library event listeners
* JSF
- scoped managed beans
* JAX-WS
- service endpoints
- handlers
* EJB
- beans
- interceptors
* Java EE platform
- main class ( static )
- login callback handler

之前沒有看到這個規定, 難怪我嘗試著使用 Struts Action 透過 @Resource, @EJB 取得相關的 Resources, 都是回傳 NULL, 看來 action 之中目前僅能透過 JNDI context.lookup 的方式取得 ejb3 及其他的環境變數.

另外, 曾經當面和 saijones 提到 Deployment Descriptor 與 Annotations 的互補性, 在 spec 中也有定義, 當你在撰寫程式的時候, 使用 @Annotations 可以簡化開發的流程, 基本上, 你就少寫了一個 XML 檔案, 更可以直接設定預設值. 但是當部署人員或應用系統組合人員, 發現你的一些數值需要重新設定, 是不必重新打開原始碼, 修改 @annotations 的部分, 僅僅需要丟一個 xml 檔案放在 /META-INF/ 之中.

不過, 這種方法, 會不會造成 debug 更為艱鉅呢, 如果工程師被告知有 bugs, 可能永遠不知道是 deployer 將初始值修改成另外一個數值 !! 看來, 簡化開發是否能夠簡化 Debug !! 將會是新的 UnitTest 設計考驗 !!

另外, 使用 java EE platform 之中的 annotation 大多是 @Retention 為 RUNTIME 的, 所以並非僅用於 compile-time, annotation 的資料是會封裝在 classes 之中.. 所以使用上要格外留意 :)

該怎麼面對 JSF !

2006-03-15T16:31:04+01:00

21 世紀初期就是一個很有趣的時代..
如果就拿 Java 來說, 則是一個詭譎多變的時代

無論是 Servlet, JSP, 甚至 JSTL, 幾乎每年都在反對著之前的 java 架構

當大家在嚷嚷著不使用 struts 的時候,
Webwork 的團隊卻和 struts 合作 ?!

當大家放棄 EJB 準備使用 SpringFramework 的時候,
EJB3.0 卻浩浩蕩蕩要統一 Business + Persistence Layer ?!
不過我相信
已經使用 SpringFramework 的人們 ~ 一定不會想要轉換跑道 ..

無論結果如何, MVC Framework 應用在 web 之中,
一定得去面對和實作, 無法逃避的選擇..
除非你是自己寫的 Framework或是直接用 jsp 來玩 ...

當我面對著 JSF 預設在 Java EE 5.0 之中
真的覺得很無力...
畢竟我到目前為止, 還是認為 JSF 不是成熟的規格..
又面對著 Tapestry, Wicket 的侵略與威脅
我實在不知道 JSF 的市場在哪裡 ...

我只能幻想著未來會有越來越多的 JSF components
讓我可以靠著拖拉工作

簡單說.
如果 ( if )
你要挑選一個 component-based mvc framework.學習
並且 ( && )
而且沒有任何根深蒂固的觀念的話 ( 沒有其他 framework 的經驗 )

你再去看 JSF 吧

use action/servlet to call EJB3

2006-02-19T17:25:00+01:00

現在我們撰寫 WebApplication, 現在應該都是採用 MVC 的架構,
就算不是利用 Opensource 如 Struts, Webwork, Tapestry 等等,
也可能是利用 JSF, 甚至自己撰寫的 Servlet 作為 Model2 的 Controller.

這在學習 ejb3 有一個好處, 因為目前無法在 jsp 撰寫 @annotations,
我們可以透過 controller 的 servlet 呼叫 action 或任何 java class,
如此一來, 在 java source 之中,
只需要撰寫


package com.softleader.web.servlet;

import javax.ejb.EJB;

public class HelloServlet {

   @EJB 
   private MySessionLocal mysession;

   public String doGet( xxxxx ) {

         String name = request.getParameter("name");

         return mysession.getHello(name);
   }

}

透過 @EJB 的 annotation, 我們可以不用在使用複雜的


InitialContext ic = new InitialContext(); 
ic.lookup("ejb/MySession");

再去轉型, 容易發生導致 ClassCastException 的錯誤 :)