顯示具有 java 標籤的文章。 顯示所有文章
顯示具有 java 標籤的文章。 顯示所有文章

星期二, 1月 29, 2008

Install Pluto 1.1.4 on Geronimo 2.0.2

剛把pluto 1.1.4安裝到geronimo 2.0.2上,花掉一天以上的時間,在這裡作個記錄。

安裝環境
OS: Windows XP sp2 中文版
JDK: Sun jdk 5.0 update 12
Geronimo: 2.0.2
Pluto: 1.1.4

在安裝之前需要由pluto網站上下載pluto-current-bin.zip檔。

安裝share library
將以下檔案安裝為geronimo 的common library:

  • castor-1.1.1.jar

  • commons-logging-1.1.jar

  • pluto-container-1.1.4.jar

  • pluto-descriptor-api-1.1.4.jar

  • pluto-descriptor-impl-1.1.4.jar

  • pluto-taglib-1.1.4.jar



安裝pluto-portal
建立pluto-portal用的deployment plan,dependency中加入上述的common library以及xercesImpl 2.8.1版。正常狀況下,應該就能夠順利的安裝到geronimo中,能夠在http://localhost/pluto中看到pluto的登入畫面。

如果在安裝過程中發生Portlet init NullPointException,log中發現register 0 portlet的訊息,有可能是castor parse portlet.xml時發生問題,只需要把pluto-portal.war解開,將portlet.xml裡 tag的namespace拿掉,應該就能夠順利的部署上去。

安裝pluto-testsuite
pluto testsuite並不需要安裝額外的library,只需要在dependency中以classes的方式import pluto.pluto 的class以及pluto-taglib就行了,如果遇到register 0 portlet,和pluto-portal一樣,修改portlet.xml就能夠解決。

security config
在pluto-portal的deployement plan也需要註記security 的定義,定義如下

/pluto

geronimo-admin


class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>




class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>






pluto-testsuite的deployement plan中需包含下列片段:

/testsuite

geronimo-admin



class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>




class="org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>






如此應該就能夠順利把pluto 1.1.4安裝到geronimo上了。

星期五, 1月 25, 2008

Java 專案環境設定 -- maven 篇 (簡介)

maven 是一個比較新近的java 專案開發工具,能夠簡化開發人員設置專案開發環境的程序與步驟,快速的進入專案的開發階段。透過Convention over Configuration 的概念以及設定檔的繼承機制,maven能夠讓團隊中所進行的各個開發專案有相同的檔案結構,同時也讓個別專案所需要進行的設定減到最低。

檔案結構

maven 預設的檔案結構如下



/src
/main
/java
/resources
/configuration
/webapp
/test
/java
/resources
/configuration
/target


以 main子目錄下放置專案的production code,test下則放置專案的testing code以及configuration,專案建置(build)的結果與過程中的中間產物則會產生在target子目錄之下。/src/main/webapp則是進行網頁專案開發時的特別目錄,放置如web.xml等等的網頁相關資訊。



專案設定檔


maven的設定檔(如同ant的 build.xml)稱作pom.xml(project object model),設定了如建置環境(java 版本,application server),相依性(使用到的其他library及版本)。



設定檔的設定方式都是定義式的,如在相依性的設定中,僅需定義使用的library的名稱與版本,在建置過程中,maven會依據所設定的相依性,由repository中取得所需要的函式。定義式的設定檔另外一個好處就是與系統維持最低的相依性,同樣的設定檔,不過是在 *nix或是Windows系統下,都能夠正常的使用。



專案設定檔的繼承


專案設定檔間的繼承提供了一個能夠設定團隊中跨專案的共通性設定的地方。在一般的團隊中有許多跨專案的共通規範,如coding convention, coding style, test rule等等,團隊能夠建立一個團隊的pom設定檔,而個別的專案,只需要繼承這個團隊設定檔即可擁有相同的設定,不需要在個別的專案設定檔中重複的進行這些共通的設定。

星期五, 6月 01, 2007

在Struts2 中取得JAAS相關資訊

在WebWork/Struts 2的應用框架中,可以讓系統開發者在寫程式時,專注在應用系統的邏輯,透過IoC的注入(injection)方式,程式碼中可以完全看不到與JavaEE相關的程式碼。但是這種美好的世界,在遇到一些需要根據使用者傳回不同的結果的action時,就不是那麼美好,除非你所開發的應用系統自行處理使用者權限與授權相關的功能。如果是使用JAAS,那程式中不免會需要透過HttpRequest來取得remoteUser等資訊。在Struts2/WebWork中,提供了兩個介面可以做到這樣的功能 HttpRequestAwarePrincipalAware。


HttpRequestAware 是第一個會想到的介面,既然remoteUser的資料是從request來的,那就叫struts幫我們注入個request object不就成了?但是一但在action中引入HttpRequest,使用Struts2/Webwork的最大好處,與平台低相依性,易測試的優點就當場被破壞了。當引入HttpRequest之後,為了測試action,必需透過如spring-mock等等的JavaEE mock 套件,無法簡單的透過如jmock, 或是自行打造stub的方式來進行測試,而且,只是需要getRemoteUser, isUserInRole等function,卻把整個HttpRequest 都暴露在action中,怎麼看味道也不對。


PrincipalAware 就是為了解決上述的問題產生的,如果你只是很單存的需要getRemoteUser, isSecured, getPrincipal, isUserInRole等功能,那action只需要實作PrincipalAware,Struts2/WebWork會為action注入一個PrincipalProxy,提供getRemoteUser等需要的方法,又不需要將整個HttpRequest都暴露在action中,造成與平台過度的相依。更好的是,PrincipalProxy是一個interface,可以利用jmock, dynaMock等mock framework簡單的產生測試時需要的替代品,對自動測試可是一大利多。


使用WebWork到現在,也好幾年了,居然到現在才發現有這個interface,該說是後知後覺,還是太不認真了,不過,這個介面可是解決了以往為了測試這些需要principal 的action,而搞了幾乎整套的JavaEE stack的問題,又能夠滿足整個應用系統的味道能夠一致,真該認真點的。

星期三, 4月 04, 2007

WebLogic 10 正式發佈

中心的server才剛啟動由WebLogic 8到WebLogic 9的轉移程序,10居然就發表了,雖然以中心的理境而言,用這麼大的AppServer或是Portal Server真的是很明顯的殺雞用牛刀的狀況,但是,買都買了,預算也編了,暫時也只能維持在目前的平台,再儘可能的以符合標準的方式來作系統開發,減少日後萬一需要轉移時需要的工夫吧。



不過,這次的Workshop 10總算能以個別plugin的方式安裝在原有的Eclipse環境下,這點對我可是有很大的吸引力呢,至少不用在去處理ClearCase plugin 與 Workshop 9之間偶爾會發生的怪異狀況,再加上很多Eclipse的plugin 也都轉移到3.2的版本了,看來,可以認真考慮是不是要跳過9, 一次攻頂上到10版了。