TheServerSide.com's 4th annual Java Symposium --Schedule
Schedule At a Glance
|
posted @ 2005-12-24 10:45 beyondduke 閱讀(572) | 評論 (0) | 編輯 收藏
Schedule At a Glance
|
posted @ 2005-12-24 10:45 beyondduke 閱讀(572) | 評論 (0) | 編輯 收藏
一、TSS(http://www.theserverside.com):全球最多的J2EE用戶站點,里邊經常會有大牛辯論。象咱們這種蝦米就在旁邊偷著樂吧,高手往往在沖動的時候才會把壓箱底的真功夫搬出來施展。
二、javaeye(http://www.javaeye.com):起初robbin在jdon中跟斑竹沖突后自己創辦的一個論壇,帖子不多,但是仔細觀看很值得玩味。喜歡這個地方里邊自由的氣氛。
三、matrix(http://www.matrix.org.cn):開始是被這里的免費下載書籍吸引,后來matrix論壇里邊山頭建多了后才逛一逛,多數只看不回,有點慚愧了。
四、blogjava(http://www.aygfsteel.com):現在有點專業java blog的氛圍了,希望繼續努力,創辦中國java之家。
五、spring英文論壇(http://forum.springframework.org):這個里邊帖子很多,而且很容易得到解決的方案。我每天必逛之地,有N多好玩的東東。
六、hibernate論壇(http://www.hibernate.org):hibernate的官方論壇
七、IBM developerworks中國(http://www-128.ibm.com/developerworks/cn/):學院味太濃,不太喜歡
八、BEA dev2dev在線(http://dev2dev.bea.com.cn/):比IBM的好一點,還是學院派
源代碼下載:
一、sourceforge(http://sourceforge.net):全球最大的開源基地,里邊有好多java的開源代碼。
二、java開源大全(http://www.open-open.com):中文的簡單介紹,偶爾上去看看。
目前的四大山頭,還處于互不競爭的形態,而且大家都有當年國共合作時期的精神,互相加入對方的組織。
2006年12月19日更新:
1,http://www.bewww.net/index.html?? IT公司速查手冊,能基本了解所查IT公司的缺點。
2,http://www.cec-ceda.org.cn/channel/dlk/? 管理大師德魯克,一個朋友介紹給我的老師。
3,http://www.linuxvirtualserver.org/zh/lvs1.html? Linux集群項目。
posted @ 2005-12-24 10:39 beyondduke 閱讀(367) | 評論 (0) | 編輯 收藏
Java設計模式之策略模式篇 |
作者:馮睿 本文選自:賽迪網 2003年02月27日 |
策略模式(Strategy Pattern)中體現了兩個非常基本的面向對象設計的基本原則:封裝變化的概念;編程中使用接口,而不是對接口實現。策略模式的定義如下: 定義一組算法,將每個算法都封裝起來,并且使它們之間可以互換。策略模式使這些算法在客戶端調用它們的時候能夠互不影響地變化。 策略模式使開發人員能夠開發出由許多可替換的部分組成的軟件,并且各個部分之間是弱連接的關系。弱連接的特性使軟件具有更強的可擴展性,易于維護;更重要的是,它大大提高了軟件的可重用性。 為了說明策略模式,我們將首先討論一下在Swing中是如何利用策略模式來繪制組件邊界的,然后討論在Swing中使用策略模式帶來的好處,最后討論如何在軟件中實現策略模式。 對所有的Swing組件,例如按鈕、列表單等,都還可以繪制邊框。在Swing中提供了各種邊框類型,例如bevel、etched、line、titled等。Swing組件的邊框是通過JComponent類來繪制的,該類是所有Swing組件的基類,實現了所有Swing組件公共的功能。在JComponent中有一個paintBorder()方法,該方法為組件繪制邊框。Swing的開發人員可以象下面的例子中所示那樣來繪制邊框:
請注意上面的代碼只是一種假設,事實上Swing的開發人員并沒有這樣實現paintBorder()方法。在上面的代碼中,在JComponent中繪制邊框的代碼被直接寫入了paintBorder()方法中,這意味著JComponent和繪制邊框的功能被緊密地結合在了一起。很自然地大家會聯想到如果需要實現一種新的邊框類型,開發人員必須修改至少三處代碼:首先增加一個常量,該常量代表新添加的邊框的類型值;其次需要在Switch語句中增加一個case語句;最后開發人員需要實現paintXXXBorder()方法,其中XXX代表新邊框的名稱。 很顯然要擴展上面paintBorder()方法的功能是一件很困難的事情,不僅僅是因為開發人員需要增加一種新的邊框類型,更麻煩的是開發人員很難修改JComponent類。JComponent類已經被編譯到了Swing的開發工具中,如果開發人員想修改它的話,必須獲得Swing的源代碼,修改后重新編譯Swing。同時在用戶的計算機上與需要使用新編譯的Swing API。另外所有的Swing組件都可以使用開發人員新添加的邊框類型。有可能開發人員只希望新的邊框被某些組件使用,但是現在開發人員無法對使用該邊框的組件進行限制。 開發人員有更好的實現方法嗎?答案就是策略模式。通過策略模式,可以將JComponent和實現繪制邊框的代碼分離開來,這樣開發人員在增加或修改繪制邊框的代碼使就不需要修改JComponent的代碼。通過應用策略模式,開發人員將變化的概念(在這個例子中是繪制邊框)封裝起來,然后通過一個Border接口,使程序能夠重用繪制邊框的功能。下面讓我們來看JComponent是如何利用策略模式來實現繪制邊框的功能的:
上面的paintBorder()方法通過一個border對象繪制了組件的邊框。這樣border對象替代了前一個例子中的JComponent封裝了邊框繪制的功能。我們還應該注意到JComponent將一個對自己的引用傳遞給了Border.paintBorder()方法,這是因為Border的實例必須知道它對應的組件的信息,這種方式通常被稱為委托。通過這種方式,一個對象可以將功能委托給另一個對象來實現。 在JComponent類中引用了一個Border對象,通過JComponent.getBorder()方法可以獲得該Border對象。下面的代碼演示了如何設定和獲得Border對象:
當開發人員通過JComponent.setBorder()方法設定了一個組件的邊框后,JComponent類發出一個屬性更新事件。如果新的邊框和以前的邊框不同的話,setBorder()方法就重新繪制邊框。getBorder()方法僅僅返回對Border對象的引用。圖1顯示了Border的類結構圖: ![]() 通過類結構圖我們可以看到,JComponent類中保存了一個對Border對象的引用。由于Border是一個接口,Swing組件可以使用任何一個實現了Border接口的類。 現在我們已經知道了JComponent是如何利用策略模式來繪制組件的邊框的。下面讓我們通過實現一個新的邊框類型來測試一下它的可擴展性。 圖2中是一個有三個JPanel對象的小程序,每個JPanel對象有各自不同的邊框,每個邊框對應一個HandleBorder實例。 ![]()
HandleBorder類繼承了javax.swing.border.AbstractBorder類并重寫了paintBorder()和getBorderInsets()。HandleBorder是如何實現的其實并不重要,重要的是由于Swing使用了策略模型,開發人員能夠很方便地增加新的邊框類型。下面的代碼顯示了如何使用HandleBorder類。在這個例子中創建了三個JPanel對象,并對每個JPanel對象設定一個HandleBorder實例作為邊框。
還記得在上面的例子中曾提到在有些情況下,對組件的引用會作為參數傳遞給Border.paintBorder()方法。雖然上面的HandleBorder類沒有保存對組件的引用,但是有些情況下Border接口的實現類會使用到對組件的引用并從中獲得關于組件的信息。例如在EtchedBorder中,paintBorder()方法通過對組件的引用獲得它對應的組件的陰影和高光色:
通過以下步驟,開發人員可以很容易地在軟件中實現策略模型: 1.對策略對象定義一個公共接口。 2.編寫策略類,該類實現了上面的公共接口。 3.在使用策略對象的類中保存一個對策略對象的引用。 4.在使用策略對象的類中,實現對策略對象的set和get方法。 在Swing邊框的例子中,公共接口是javax.swing.Border。策略類是LineBorder、EtchedBorder、HandleBorder等。而使用策略對象的類是JComponent。 |
posted @ 2005-12-24 10:09 beyondduke 閱讀(581) | 評論 (0) | 編輯 收藏
posted @ 2005-12-21 18:54 beyondduke 閱讀(1841) | 評論 (0) | 編輯 收藏
今天對書生是一個不平凡的日子,對中國軟件業也是一個不平凡的日子,我們在這里歡聚一堂,共同見證這樣一個歷史性時刻:中國軟件業第一次在軟件技術核心領域達到全球領先。書生SEP文檔庫技術在軟件業歷史上第一次為文檔互操作提供了可行之路。SEP文檔庫技術是我們十年心血的成果,我難以在這短短的時間內做詳細闡述。我只能簡單介紹幾點,歡迎各位專家和業界同行在今后跟我們做進一步的交流。
我的匯報分四個部分,首先介紹我們取得的突破,然后說明文檔不能互操作形成對信息產業發展的重要障礙,然后介紹解決文檔互操作的文檔庫技術,接下來是UOML聯盟相關情況的介紹。
大家都知道,中國軟件業長期以來核心技術掌握在他人手中,產業發展受制于人,處于一種被動局面。在制約我們發展的核心技術中就包含了數據庫技術。數據庫是比結構化數據更為重要的領域,領域目前存在一個重大問題就是文檔的互操作問題,如果能夠解決這個問題,就能夠在這個領域里取得重大突破,我們將能夠獲得比數據庫更大的。歷經十年的發展,SEP文檔庫技術第一次為文檔互操作提供了可行之路。事實證明,我們雖然起步比較晚,但是只要我們敢于創新、堅持創新、善于創新,我們還是能夠有所作為的。SEP技術第一代技術是1995年發表的,SEP數字紙張技術,當時僅比國外落后兩年。應該算是中國軟件業在核心技術領域差距最小的技術。在2000年我們取得了局部的突破,在數字全縣管理方面達到了國際領先水平。我們是在全球第一家推出在線的DRM技術,而且這個技術到現在也是安全可靠程度最高的。2004年我們基本上與國外同步推出了第二代SEP(智能文檔技術),我們在開發第二代技術的同時發現,文檔互操作并不能被第二代技術解決。我們認為這個技術還會往上發展,經過市場的分析技術研究文檔未來十年的需求,就產生了這樣的想法,同步開發第三代技術,就是今天發表的SEP文檔庫技術,這個技術比國外技術整整領先了一代。
信息產業就是對信息進行處理的技術,信息可以分為結構化數據、書面文檔和流媒體,結構化數據大約占20%左右的比例,剩下的80%是非結構化信息,其中書面文檔占了主要的份額,如果能夠在這個領域取得成績的話,它的意義和價值應該不亞于在結構化領域取得的成績。但是現在正在被一個問題困擾著,這就是文檔的互操作。目前不同軟件不能對同一文檔進行操作。不管是封閉格式,還是開放格式,最后的結果都是被電腦軟件所壟斷。但是一種軟件是不可能包含所有功能的,就算是微軟的Word、Excel等等。更重要的是不可能涵蓋信息信息處理的所有環節,這樣造成的結果是信息流難以貫穿各個環節,形成了信息孤島。文檔 世界杯分割得四分五裂。而且由于被個別大公司壟斷,中小企業缺乏生存空間。我們也發現,到現在為止紙張還是一個最好的互操作平臺,可以在紙上用不同的筆寫寫畫畫,可以用圓珠筆、彩筆、毛筆等等。于是我們投入巨資做無紙化改造,結果紙張沒有減少,反而劇增。
為了解決這個問題,這么多年來國內國外無數的業界精英,大家小小的組織都為這個目標進行了很多努力。但是到現在為止解決方案基本上都局限在制定文檔存儲格式標準的技術路線上。經過十幾年的產業實踐可以證明這條路線是有局限性的,是不可行的。時間的關系,我不能在這里做詳細論述,只簡單說一點,如果最簡單的文檔格式(如TXT)不能滿足各類軟件的需求。全球只有幾家專業廠商具備足夠的專業水平、研發經費能夠完整準確地處理,而其他數十萬家軟件企業做不到,這樣同一軟件會出現不同的結果。還存在著阻礙創新、影響性能等無法克服的困難。
我們可以看一下在結構化數字領域,數據流往往是貫穿各個環節的,比如說數據的采集、報送、統計等等。但是在這個領域里目前不同軟件之間沒有出現這個問題。很久以前數據庫也存在著格式標準,大家都知道當年有一個標準很流行,后來改成SQL標準準。只要符合這個標準就能夠對同一個數據庫進行操作,這樣就實現了數據的互操作。我們借鑒這種思路,在文檔領域如果也改變存儲格式標準的思路,而改為以操作為標準是不是就能夠解決互操作問題呢?文檔庫技術就這樣誕生了。文檔庫技術是以操作為標準,是對書面文檔進行描述、存儲、處理、管理的基礎技術平臺,為應用軟件提供數文檔的通用操作功能。通過非結構化操作標記語言(UOML)統一面向書面文檔處理的操作標準。不同的文章只要按照同一個標準就能夠對同一文檔進行操作。
我們看一下在發明了這個技術后產業格局是什么樣的。在這個書面文檔領域里也是跟數據庫相似的產業結構。有幾家專業廠商來提供通用的技術平臺,各個軟件只需要通過UOML,相當于數據庫的SQL就能夠實現互操作。
它的意義和價值是非常多的,簡單總結幾點。首先最重要的是不同軟件可以對同一文檔進行操作,可以使信息流暢通無阻。實現產業分工,避免重復開發。由于可以把各個軟件的編輯功能合并到一起來,所以可以編輯、使用復雜文檔。而且文檔庫提供了多文檔的組織管理。通過開放的UOML標準,可以打破壟斷,使中小企業有更大的生存空間。最后文檔庫有可能會形成一個比數據庫還規模龐大的新興產業,成為新興產業一個新的增長點。
在使用文檔庫技術之前,每個公司都有各自的模式,相互之間都是隔絕的。使用文檔庫技術后,不同軟件通過同一個操作標準就可以實現對同一文檔的互操作,信息流就能夠暢通了。
這是另外一個例子,這是一個比較復雜的文檔,包括文字、圖像、五線譜、電子表格、條形碼,可以用不同的軟件對它進行編輯、處理,而不再要求有一個軟件具備所有的復雜功能。這是數據庫產業的規模,而且僅僅只包括了數據庫本身直接的效益,沒有包含間接帶來的效益。到現在已經發展為一年超過一百多億美元的龐大隊伍。可以想象一下,如果占信息總量20%的結構化數據能夠孕育出原產值一百多億美元的產業,那么占空間更大的書面文檔領域又能夠孕育出多大的產業規模呢?
為了推廣應用文檔庫技術,為了早日實現這個夢想,我們成立了UOML聯盟。UOML聯盟是由遵守UOML標準的企業、機構、組織、個人自愿組成的聯合體,旨在通過共同的標準實現文檔的互操作。UOML聯盟為聯盟成員之間提供了免費授權技術支持,使聯盟成員開發的軟件相互之間可以實現文檔可交換、互操作,讓信息流能夠暢通無阻,優化非結構化文檔領域的產業分工,能夠保證UOML標準被廣泛地使用。
總結一下今天的發言。首先文檔互操作對IT產業的發展是至關重要的,而SEP文檔庫技術第一次為文檔互操作提供了可行之路。文檔庫技術有望成為一個比數據庫技術更為重要的產業核心技術。UOML聯盟為文檔庫技術的推廣、普及將提供強有力的支持。
信息產業是全球化程度很高的行業,誰率先掌握的未來的IT核心技術,誰就能掌握全球信息產業的未來。SEP文檔庫技術和UOML標準的出現給我們帶來了這樣的機會,只要大家共同努力,就完全有可能在非結構化文檔領域打破國外軟件巨頭的壟斷,改變我們受制于人的被動局面,并成為我國軟件產業騰飛的一個契機。
過去十多年間,數據庫技術培育了一批美國軟件巨頭,我們期待,未來十年時間,文檔庫技術也將會培育一批世界級的中國軟件企業。
最后我在這里代表書生公司感謝中國軟件行業協會和北京軟件行業協會,感謝信息產業部、科技部、北京市科委、北京市信息辦、北京市高企協等長期以來對書生的幫助和支持。正是因為你們的鼓勵和支持給了書生極大的信心和勇氣,使書生能夠一直專注于開發核心技術。十年來堅守理想、堅持自主創新、堅定開發自主 知識產權的核心技術,終于在今天取得了這樣的成績。當然我們最重要的支持來自于我們的用戶。另外也要特別感謝業界同行的緊密合作和媒體界朋友的幫助、支持,使的我們取得的成果能夠得到廣泛的宣傳和應用。我們無法預言,但我們相信文檔庫產業的形成和發展將為人類帶來無法估量的價值!謝謝大家!
主持人:
我想代表大家提幾個小問題。SEP文檔庫誕生從某種意義上說是民族產業、軟件產業在核心技術領域一個罕見的重大突破。我想您現在一定很激動,因為畢竟奮斗了十年的時間。中國人的智慧確實是全世界公認的,但是軟件產業做了這么多年,一直沒有形成比較有規模的像國際上的微軟公司的企業,說一下你的體會。
王東臨:
中國軟件業雖然起步比較晚,這是一個原因,但是更重要的原因是因為我們缺乏核心技術。中國軟件企業里大多數都是做的應用開展軟件開發的,做產品開發的比較少,做核心技術的應該講是鳳毛麟角。因為我們缺乏核心技術所以產業發展就受制于人,未來要想改變這個局面就應該加強核心技術的開發,而且應該加強對未來核心技術的開發,使我們在信息產業,因為這是一個創新的行業,如果我們能夠率先創新,今天可能我們已經是被動了,但是明天我們還有未來。
主持人:
很多朋友還不是很了解這個復雜的技術,這個核心技術能夠對行業有多大影響呢?
王東臨:
我想它的影響會分幾個方面,首先通過實現信息的互聯互通,通過這種互操作,能夠擴大 信息化的應用面,能夠增大產業規模,能夠優化產業結構。我們以后可能不會再有從用戶界面到存儲是同一個軟件包打天下,會形成更好的產業分工。第三點通過開放標準、打破壟斷,可以給更多企業帶來生存空間。
主持人:
最后一個問題,在這么多巨頭的占領下怎么開拓市場?
王東臨:
我想新的產業形成肯定是需要一定的時間,當是我相信這么一個開放標準能夠得到業界和用戶認可的,如果我們有更的多軟件廠商能夠支持這樣的標準,如果更多用戶能夠選擇這樣一個標準,開放將會成為一個主流,壟斷就會退居后面。我想我們的核心技術能夠得到更廣泛的應用,業界的其他同行、我們的用戶將會得到一個更大的收益。書生在這個領域里已經做了十年了,我相信會等到這一天。
posted @ 2005-12-17 14:18 beyondduke 閱讀(294) | 評論 (0) | 編輯 收藏
posted @ 2005-12-17 13:40 beyondduke 閱讀(332) | 評論 (0) | 編輯 收藏
posted @ 2005-12-17 13:11 beyondduke 閱讀(1020) | 評論 (0) | 編輯 收藏
近期為完成一個簡單的報表模塊,需求很簡單,從數據庫中取出數據導出到已寫好的Excel模版中。
一開始準備用jfreeReport實現,偶然調試spring的demo時發現,countries的例子很好,既有web分頁,又有excel,pdf的輸出,經分析例子,spring封裝了poi實現excel導出,itext實現pdf輸出。
1,先來分析一下poi的一些背景。POI的主頁:http://jakarta.apache.org/poi。POI HSSF是當今市面上最強大的處理EXCEL表格的java工具,比韓國人寫的那個JExcelApi或其它幾種工具都要好。而且它是Apache的開源項目。當然POI HSSF也有缺點:不能直接支持EXCEL圖表,API文檔粗糙簡略,有些類和方法需要引用Apache項目中的其它一些包,包與包之間依賴關系比較復雜等等。
Apache的Jakata項目的POI子項目,目標是處理ole2對象。目前比較成熟的是HSSF接口,處理MS Excel(97-2002)對象。它不象我們僅僅是用csv生成的沒有格式的可以由Excel轉換的東西,而是真正的Excel對象,你可以控制一些屬性如sheet,cell等等。這是一個年輕的項目,所以象HDF這樣直接支持Word對象的好東西仍然在設計中。其它支持word格式的純java方案還有itext,不過也是仍在奮斗中。但是HSSF已經成熟到能夠和足夠我們使用了。另外,無錫永中Office的實現方案也是純java的解決方案,不過那也是完全商業的產品,并不是公開代碼項目。其實,從開發歷史的角度講,在80年代中期starOffice的原作者在德國成立了StarOffice suite公司,然后到1999年夏天starOffice被sun收購,再到2000年6月starOffice5.2的發布;并且從starOffice6.0開始,starOffice建立在OpenOffice的api的基礎上,這個公開代碼的office項目已經進行了很長的時間。雖然那是由C++寫的,但是POI的代碼部分也是由openOffice改過來的。所以,應該對POI充滿足夠的信心。國內已經有部分公司在他們的辦公自動化等Web項目中使用poi了,如日恒的ioffice,海泰的HTOffice等。java當初把核心處理設成Unicode,帶來的好處是另代碼適應了多語言環境。然而由于老外的英語只有26個字母,有些情況下,一些程序員用8位的byte處理,一不小心就去掉了CJK的高位。或者是由于習慣在程序中采用硬編碼,還有多種原因,使得許多java應用在CJK的處理上很煩惱。還好在POI HSSF中考慮到這個問題,可以設置encoding為雙字節。編譯好的jar主要有這樣4個:poi包,poi Browser包,poi hdf包,poi hssf例程包。實際運行時,需要有poi包就可以了。如果用Jakarta ant編譯和運行,下載apache Jakarta POI的release中的src包,它里面已經為你生成好了build文件了。只要運行ant就可以了(ant 的安裝和使用在此不說了)。如果是用Jbuilder 運行,請在新建的項目中加入poi包。以Jbuilder6為例,選擇Tools菜單項的config libraries...選項,新建一個lib。在彈出的菜單中選擇poi包,如這個jakarta-poi-1.5.1-final-20020820.jar,把poi添加到jbuilder中。然后,右鍵點擊你的項目,在project的properties菜單中path的required Libraries中,點add,添加剛才加入到jbuilder中的poi到你現在的項目中。如果你僅僅是為了熟悉POI hssf的使用,可以直接看POI的samples包中的源代碼,并且運行它。hssf的各種對象都有例程的介紹。hssf提供的例程在org.apache.poi.hssf.usermodel.examples包中,共有14個,生成的目標xls都是workbook.xls。如果你想看更多的例程,可以參考hssf的Junit test cases,在poi的包的源代碼中有。hssf都有測試代碼。
2 ,poi提供了一個不錯的tutor,教初學者如何快速上手使用POI HSSF:http://jakarta.apache.org/poi/hssf/quick-guide.html
建一個poiDemo的工程,然后把tutor首頁的例子運行一遍,入門級別就夠了。其中包括:新建excel文件(WorkBook);新建sheet;開辟cell;設置cell數據類型和格式;設置輸出的樣式如對齊方式,顏色,字體,邊框等;合并單元格;讀取已有excel文件;設置打印區域;設置頁碼和頁腳;調用公式;選中sheet;屏幕縮放;繪圖;插入圖像等等。
3, spring的對poi的封裝。在spring-framework-1.2-rc2\src\org\springframework\web\servlet\view\document下有兩個類AbstractExcelView.java和AbstractPdfView.java,其中前者是處理excel的抽象類,繼承它的時候,需要實現抽象方法buildExcelDocument,實例代碼如下:
posted @ 2005-12-15 10:05 beyondduke 閱讀(7399) | 評論 (7) | 編輯 收藏
Attribute | Description |
---|---|
clientAuth |
Set this value to true if you want Tomcat to require all SSL clients to present a client Certificate in order to use this socket. Set this value to want if you want Tomcat to request a client Certificate, but not fail if one isn't presented. |
keystoreFile |
Add this attribute if the keystore file you created is not in the default place that Tomcat expects (a file named .keystore in the user home directory under which Tomcat is running). You can specify an absolute pathname, or a relative pathname that is resolved against the $CATALINA_BASE environment variable. |
keystorePass |
Add this element if you used a different keystore (and Certificate) password than the one Tomcat expects (changeit ). |
keystoreType |
Add this element if using a PKCS12 keystore. The valid values are JKS and PKCS12 . |
sslProtocol |
The encryption/decryption protocol to be used on this socket. It is not recommended to change this value if you are using Sun's JVM. It is reported that IBM's 1.4.1 implementation of the TLS protocol is not compatible with some popular browsers. In this case, use the value SSL . |
ciphers |
The comma separated list of encryption ciphers that this socket is allowed to use. By default, any available cipher is allowed. |
algorithm |
The X509 algorithm to use. This defaults to the Sun implementation (SunX509 ). For IBM JVMs you should use the value IbmX509 . For other vendors, consult the JVM documentation for the correct value. |
truststoreFile |
The TrustStore file to use to validate client certificates. |
truststorePass |
The password to access the TrustStore. This defaults to the value of keystorePass . |
truststoreType |
Add this element if your are using a different format for the TrustStore then you are using for the KeyStore. The valid values are JKS and PKCS12 . |
posted @ 2005-11-04 09:21 beyondduke 閱讀(831) | 評論 (0) | 編輯 收藏