2006年8月11日
#
摘要: 使用Apache的mod_authn_dbd和PostgreSQL實施HTTP Basic登錄認證,同時做了到Tomcat的轉發。這樣,所有對Apache Http Server的請求都會轉發給Tomcat,而Apache Http Server就作為一個前端認證的服務器使用。另外,在Tomcat的JSP中,使用request.getRemoteUser還可以取到登錄的用戶名。
閱讀全文
摘要: 可以使用C標準庫(Windows-Based & Unix-Based兩方)的time函數取得精度為秒的時間,在Unix-Based系統中,使用gettimeofday函數取得更小精度的時間。
閱讀全文
摘要: 最近嘗試在Windows環境下安裝了Hadoop,遇到一些困難,在此記錄一下以備忘。
閱讀全文
摘要: 美國國家標準及技術研究所信息技術實驗室對云計算(Cloud Computing)的定義。
閱讀全文
摘要: 本文章主要討論了在Java web系統中亂碼產生的內在原理, 是認識和解決亂碼問題的基礎. 如果您對亂碼問題還沒有一個清晰的概念, 請嘗試閱讀本文. 另外, 本文也討論了最近流行的Ajax技術中的亂碼問題, 如果您在使用Ajax技術中遇到了亂碼, 本文對您也有一定的參考價值.
閱讀全文
摘要: 新下載的插件PlugIn一定不要都放在原始的Eclipse目錄下去,一大堆,累死你:(
閱讀全文
摘要: 比較當前幾種流行的開發語言的薪資水平
閱讀全文
摘要: 測試并行程序尤其困難。這是因為并行測試程序本身就是并行程序,這種程序即難寫而且比順序執行程序更容易發生不確定的問題。
在這篇文章中將討論一些關于測試并行類的話題,提供一些構建并行程序的技術,這些技術使并行程序更容易被測試。
閱讀全文
摘要: 本方法適用于Oracle9i, 10g以及XE. 在10.2.0.1.0下測試無錯. 需要注意的是, 使用此方法會破壞數據庫中的原有雙字節字符. 一種辦法是先將數據庫導出, 修改完字符集后再導入; 另一種辦法就是不管他, 就那樣使用. 一般如果是一個測試環境, 像方法二那樣就可以了, 但是可能某些表無法讀取, 需要注意.
閱讀全文
摘要: 最近有一個需要支持unicode的項目在上傳和下載文件時遇到文件名亂碼問題. 項目背景, 這個項目關鍵之處在于需要支持unicode以及支持Micorosoft Internet Explorer和Netscape Navigator兩種瀏覽器. 為了解決這個問題, 我對IE, NC另外加上Firefox進行上傳和下載的文件名編碼的測試.
閱讀全文
摘要: Tom Ball, Sun Microsystems公司的技術主管說如何寫出更好的代碼.
閱讀全文
BEA公司為weblogic server準備了petstore for weblogic供開發者安裝, 因為最近測試Hyperic-HQ, 所以進行了petstore for weblogic的安裝.
首先, 需要下載Sun的petstore和在bea.com下載petstore for weblogic. 對應weblogic 8.1服務器的petstore版本是1.3.2.
下載后, 按照下載包中的readme.txt文件的提示一步一步安裝, 沒有什么問題, readme上說得非常清楚. 但是到Step1的第12步和Step2的第7步卻無法啟動weblogic服務器. 現象為, 啟動后拋出如下異常.
<2006/09/06?9時13分08秒?CST>?<Critical>?<WebLogicServer>?<BEA-000364>?<Server?failed?during?initialization.?Exception:weblogic.security.spi.ProviderInitializationException:?[Security:090314]Entitlement?Engine?unable?to?connect?to?the?embedded?LDAP?server
netscape.ldap.LDAPException:?error?result?(50)
weblogic.security.spi.ProviderInitializationException:?[Security:090314]Entitlement?Engine?unable?to?connect?to?the?embedded?LDAP?server
netscape.ldap.LDAPException:?error?result?(50)
????????at?weblogic.security.providers.authorization.DefaultAuthorizationUtils.getEngine(DefaultAuthorizationUtils.java:130)
????????at?weblogic.security.providers.authorization.DefaultRoleMapperProviderImpl.initialize(DefaultRoleMapperProviderImpl.java:104)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.createSecurityProvider(SecurityServiceManagerDelegateImpl.java:242)
????????at?weblogic.security.service.SecurityServiceManager.createSecurityProvider(SecurityServiceManager.java:957)
????????at?weblogic.security.service.RoleManager.initialize(RoleManager.java:152)
????????at?weblogic.security.service.RoleManager.<init>(RoleManager.java:98)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.doRole(SecurityServiceManagerDelegateImpl.java:513)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.initializeRealm(SecurityServiceManagerDelegateImpl.java:409)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.loadRealm(SecurityServiceManagerDelegateImpl.java:700)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.initializeRealms(SecurityServiceManagerDelegateImpl.java:733)
????????at?weblogic.security.service.SecurityServiceManagerDelegateImpl.initialize(SecurityServiceManagerDelegateImpl.java:876)
????????at?weblogic.security.service.SecurityServiceManager.initialize(SecurityServiceManager.java:734)
????????at?weblogic.t3.srvr.T3Srvr.initializeHere(T3Srvr.java:822)
這個問題的原因是petstore模板中的Critical密鑰已經過期.
解決辦法是找到weblogic的配置文件config.xml.
修改其中的如下這行
<EmbeddedLDAP Name="petstore" Credential="{3DES}78P9aVGmaIE="/>將其中的Credential屬性刪除即可. 再啟動weblogic的時候, 服務器會重新自動生成一個Credential.
這個問題在petstore for weblogic的readme中并沒有提到. 因此不少同志在安裝的時候遇到這個問題. 在此進行一下memo, 以饗后來人.
摘要: 在Weblogic 8.1上, 我們通過JDBC log得到的Connection Pool的信息非常有限, 那么如何能更多的得到數據庫連接的信息呢? 我們在網上發現了一個開源工具Hyperic-HQ協助我們很好地解決了這次問題.
閱讀全文
摘要: 在 Sheryl Calish 撰寫的“Linux 文件命令精通指南”這篇出色的文章中,您學習到了一些對于 Linux 新手尤為重要的常用 Linux 命令。既然您現在已經掌握了基礎知識,下面我們將介紹一些更為復雜但卻非常有用的命令。
閱讀全文
摘要: 為剛接觸 Linux 文件命令的初學者提供的速成教程
閱讀全文
摘要: 一、簡介
MTS(Multi-Threaded Server)是ORACLE SERVER的一個可選的配置選擇,是相對DEDICATE方式而言,它最大的優點是在以不用增加物理資源(內存)的前提下支持更多的并發的連接。換句話說,如果你只有2G的物理內存,而你又想支持2000個連接,在獲取最好性能的前提下,你就應該選擇MTS了。
本文先說一說MTS的工作方式,然后與DEDICATE...
閱讀全文
摘要: 最近有一個項目需要支持SSL的JavaMail收發郵件. 經過一些調查, 把使用SSL的JavaMail方法總結如下.
閱讀全文
摘要: 作者:Andrei Cioroianu
了解如何利用 XML 和 JavaScript Object Notation 在 Ajax 客戶端和 Java 服務器之間傳輸數據。
2006 年 6 月發表
Ajax 核心 API(即所謂的 XMLHttpRequest)的唯一用途就是發送 HTTP 請求,在 Web 瀏覽器與服務器之間進行數據交換。...
閱讀全文
一、范型(generic)的支持
支持generic的tiger屬于較1.4及以前最大的變化之一。由于支持范型,所以以前的諸多集合類(譬如,list和map)的接口都做了比較大的變化。而Java developer們從理論上說則可以擺脫使用括號的強制轉型;使用類型安全(type-safe)的各種集合類,甚至可以寫自己的支持范型的類。
二、枚舉(enumerated)類型的支持新加入了enum關鍵字,使Java developer們可以創建一種新的類型——枚舉類型。并且,枚舉類型支持switch分支以及行內(inline)的創建。和范型配合使用,我們可以創建枚舉類型的map或者set。
三、Autoboxing和Unboxing的支持現在tiger可以自動的把primitive type變成與之對應的object類型。Java developer們再也不用使用諸如intValue()或者new Integer()這樣的方法來把一個整型的變量變來變去了。
四、可變長參數(vararg)的支持
以前函數參數中帶有“...”一直是C++ fans的專利,現在Java developer們也可以享受到其帶來的好處。
五、Annotation的支持
這是tiger帶給我們的又一偉大的功能。Java developer們現在可以撰寫自己的annotation(當然,tiger自身帶有annotation,一些先進的框架framework也用到annotation)來給class、method甚至package添加額外信息,這就昭示著可能單體(unit)試驗會更加輕松并且那些習慣xdoclet的同學終于可以拋棄它了。
六、for/in語句的支持
這個特性使Java developer們的代碼更小以及更酷。并且避免了不必要的類型轉換。
七、靜態import的支持
這個特性最主要的用途我想就是使Java developer們的代碼更酷了。如果搭配枚舉類型,以及printf功能可能讓你寫出類似的C風格的代碼。
八、線程方面的改進在線程方面有各種各樣的改進,最主要的有三個,添加了Excutor對象,從此Java developer們可以把線程作為一個task執行,另外,由此,線程的寫法也有了徹底的改變;第二,添加了高等synchronizing的支持以及locking地加入;最后,就是原子(atomic)類型的加入。
九、其他
除了以上的主要改進以外,還有一些比較重要的修改和增強。譬如說,加入了printf方法,現在Java也擁有了C語言的經典函數;在Array中加入了大量的靜態方法用來操作數組和集合;加入了Queue這種數據類型和Comparator這樣一個排序接口;以及用一個StringBuilder這個類使得可以更好的處理Unicode。
第一節:理解XSL?
有一天晚上我做了一個夢。這個夢真嚇人。但如我告訴我的釋夢師的,如果你沒有讀過寫使用XML和我媽媽的菜譜賺錢的計劃,這個夢就沒什么意義。
不管怎么說,這個夢......
那是在公元2001年,我用我媽媽的菜譜建立了一個網站,而且行得不錯。網站的節讀數很高,得到的反饋也很多。后來就到了電話,是Michael?Ovitz打來的。他告訴我他回來做生意,想把這些菜譜作為事業的起點。他認為其潛力不僅僅在于它一份菜譜,而是Sally?Field領銜出演的一系列關于與恐怖份做斗爭的身懷絕藝的技藝精湛的廚師的電影。他所要的是一250個菜譜的標題和它們組成成分的清單。而且他希望在15分內得到它們。我狂喜,我顫栗,然后我意識到我用的是HTML。
我從尖叫中醒來?-?冷汗順著我的臉往下淌。
為什么是個噩夢呢?夢中的是發生在將來,一個XML和它的同伴XSL(擴展樣式表?-?eXtensible?Stylesheet?Languange)被廣泛使用的時代。即使這樣,我用HTML建立我的整個菜譜網站,不是XML。而且,HTML就是HTML?-?我沒有辦法從中通過拷貝粘貼提取想要的信息。CSS此時也毫無用處。但是如果我在夢用了XSL,我就會很快產生那份清單,然后快樂地從別人的天和努力中榨取利益。
然而現在,XSL的允諾只是一個夢。關鍵在于從W3C的第一份草稿到發布第一份推薦稿至少要八個月(或至少一年)的時間。在完成之前,其規范可能要做根本性的改變。
盡管這樣,微軟還是正在打算在其IE?5的第二個beta版中支持XSL現有草稿的功能。坦率地說,我不知道為什么它會在這上面耗費資源。因為這件事對每個人來說,誰都不愿意花費時間在學習一種在其實現之前就過時的語言。
雖然如此,但理解XSL的要點還是很重要的?-?它會使Web開發者的生活更容易些。如果對XSL一無所知,對被經常吹捧的XML的一些優點的理解就會有困難。
那么就讓我們看看其中的一些基本概念?-?不太可能改變的東西。
第二節:攀登結果樹
你從本文中學到的最重要的一點是XSL不僅僅是應用樣式。當使用XML處理器時,XSL源文檔中的信息將被評價、重新安排,然后重新組裝。我們最終得到的不只是XML數據的可愛的版本?-?而是可以被容易地添加、修改和重新排序的靈活的源信息。這個最終產品叫做結果樹(Result?Tree)。
這通過一系列測試產生。下面是一個簡單的例子:
???<xsl:template?match="recipe_name">
?????<P>
???????<xsl:process-children/>
?????</P>
???</xsl:template>
最先要解釋的是以"/"?結束的標記符是空的。即此種類型的標記符的起始和結束標記符之前什么也不發生。在HTML中類似的例子是<img>標記符。因為一個圖像所需的所有信息都包含在一個標記符中,所以就沒有必要存在結束標記符</img>。組織良好的XML文檔可以接受空標記符,同時XSL樣式表必須是組織良好的XML。
讓我們再回到例子,它告訴XSL處理器如果發現一套<recipe_name>標記符,就應該分離出內容然后用<p>和</p>包圍起來。或者,如果你想炫耀你的XSL的知識,你可以說“添加到結果樹中。”
這是一個相當簡單的測試,而且很典型。XML元素的內容被表現信息所包圍。
現在讓我們看看書寫菜譜的XSL樣式表的完整例子。
在我講述更多的XSL標記之前,我要解釋一個可能被問到的問題。誰都知道在HTML中<p>本身就足夠了,那么我為什么要使用結束的</p>標記符呢?
有人能回答嗎?答案是:沒有對應的結束標記符,那部分就不是組織良好的XML,于是會產生一個致命的錯誤。
第三節:一個XSL樣式表
下面是一個完整的樣式表。
<xsl:stylesheet>
???<xsl:template?match?=?"/">
?????<HTML>
?????<BODY>
?????????<xsl:process-children/>
?????</BODY>
?????</HTML>
???</xsl:template>
???<xsl:template?match?=?"author">
?????????<H1>
?????????<xsl:process-children/>'s?fabulous
?????????</H1>
???</xsl:template>
???<xsl:template?match?=?"recipe_name">
??????<H2>
??????<xsl:process-children/>
??????</H2>
???</xsl:template>
???<xsl:template?match?=?"meal">
??????<TABLE><TR><TD><H3>EAT?FOR:</H3></TD>
??????<TD><H3><xsl:process-children/></H3></TD>
??????</TR></TABLE>
???</xsl:template>
???<xsl:template?match?=?"directions">
??????<H4>DIRECTIONS</H4>
??????<P>
??????<xsl:process-children/>
??????</P>
???</xsl:template>
???<xsl:template?match?=?"ingredients">
???????<B>INGREDIENTS</B><BR></BR>
???????<xsl:process-children/>
???</xsl:template>
???<xsl:template?match?=?"item">
???????<BR>
??????<xsl:process-children/>
??????</BR>
???</xsl:template>
</xsl:stylesheet>
其結果不會使我得到任何設計獎,但是它是一個能起作用的XSL。這里可能只有下面的命令需要解釋:
??<xsl:template?match?=?"/">
????<HTML>
?????<BODY>
?????????<xsl:process-children/>
?????</BODY>
?????</HTML>
?</xsl:template>
第一行的"/"告訴處理器這個節點應用到XML文檔的根上。于是,這部分中的命令是結果樹的基礎。處理器被告之把<HTML>和<BODY>標記符放在文檔的開始和結尾處,然后處理或打印所有的子元素。因為它是根元素,所以意味著“打印所有的東西。”
現在,如果你考慮幾秒鐘,就會覺得有點古怪。如果根層的process-children命令把源代碼傳遞給結果樹,那么所有與模板匹配的節點都可以與已經經過處理的源碼一起工作。
然而,出現的問題是:XSL有一套確定哪些內容被傳遞給結果樹的規則,其中最重要的規則是,最特定的匹配將會贏。顯然,元素名的模板匹配比根層的匹配更特定。因此,所有模板匹配的節點將超越根層的規則。
注意用XML數據添加HTML標記符是多么的容易。當XSL處理器看到那些不在XSL詞匯表中的標記符時,就會把他們傳遞給結果樹。如果你花些時間,就可能發現其中巨大的潛力。XSL可以被用做一種轉換語言。存儲在一個XML文件中的數據可以用完全不同的標記符轉換到另一個文件中。還有,信息可以被修改成與可以對應一套不同的標記符集的XML應用程序一起工作的形式。
而且還不只這些,如人們所期望的,樣式表可以用匹配的標記符打開和關閉,其中是一套組織良好的單元。?很好,但是還有限制。
第四節:選擇XSL
簡單的<xsl:template?match>還不能完全滿足我們的要求。比如,我希望當<course>標記符出現時取消<meal>標記符的內容。這樣的話我就不用擔心節面上同時顯示"dinner"和"appetizer"。我可能還希望通過在最后的ingredient后面插入大量的空白來調整版面。
如同某個廣告部的人說的:所有這些都是可能的?-?還要更多。SL有一套用來把元素與其父成員或子成員匹配的工具。它也允許位置上的匹配。例如,可以在第一個和最后一個某個特定元素上應用特定的格式,等等。
現在讓我們考慮一些更復雜的事,比如令我在夢中出汗的任務。我需要菜譜名和它們的成分的清單。現在,如果我的網頁與數據庫沒有聯系,我就不得不寫一個查詢語句。因為我對SQL不太熟,所以需要得到的DBA幫助。但是如果知道XSL,我就會擺脫這些麻煩。
<xsl:style?sheet>
???<xsl:template?match?=?"/">
??????<xsl:for-each?select?="list/recipe">
?????????<TABLE>
?????????<TR><TD>
?????????<xsl:process?select?=?"recipe_name"/></TD>
?????????<TD>
????????????<xsl:for-each?select?=?"ingredients/item">
???????????????<BR><xsl:process-children/></BR>
????????????</xsl:for-each>
?????????</TD></TR>
?????????</TABLE>
??????</xsl:for-each>
???</xsl:template>
</xsl:stylesheet>
結果并不神奇。但是在table標記符中加些花樣將沒問題。顯然,我在XML中存儲了信息,但是我認為最好還是仔細看看。
???<xsl:template?match?=?"/">
??????<xsl:for-each?select?="list/recipe">
第一行很熟悉,只是簡單地與模板相匹配。但是第二行卻有些不同?-?在元素清單中出現的每個菜譜元素做每件事,直到</xsl:for-each>標記符。然后我開始HTML表格,用<xsl:process?select="recipe_name"/>標記符把recipe_name元素中的內容輸出到表格單元中。在關閉第一個表格單元后,事情開始變酷。下一行(<xsl:for-each?select="ingredient/item">)開始一個附加的嵌套循環,允許我把全部ingredient輸出到合適的顯示信息中。樣式表的其余部分應該很好理解。
但是等等,我知道你在想:“他說過酷了嗎?什么這么酷?”
for-each函數是XSL的幾個程序化的特征之一。還有if-then和選擇函數。這些特征允許任何人都可以以任何能想到的方式(或至少是可行的方式)容易地操縱XML內容。如果你能實現這些特征,就很酷。
第五節:從規范到實現
既然你已經看到XML的一些功能,那么我想提出一個問題:通過把內容分離到組織良好和有效的XML文件中,XML對這些內容有哪些不能做的呢?如我前面顯示的,數據可以被操縱然后放入你選擇的版面中。或者數據可以被處理成可以被其它應用程序使用的形式。那么,還有其它的嗎?
我們再一次面對擴展性的核心。一旦定義了數據,我們可以做任何想做的事。如果我們來到一個有能處理XML的字處理、電子表格和表現程序的時代,同一套數據幾乎可以被用在任何用途上。
但是,哎!這依然是個夢。
我們只能希望瀏覽器能實現這些功能,但是我們沒有理由樂觀。即使Tim?Bray,XML的教父,也說過對XSL的嘗試只能在CSS標準完全實現之后才能實現。誰知道什么時候才能實現呢?而且這也不是唯一的問題。
XSL要排除另一個障礙。XSL規范有兩個截然不同的部分。第一部分,是我們這里討論的,處理數據結構。另一部分是一套用來應用樣式的有格式的對象。這部分需要做大量工作。在我看來,現在需要很多人去做很多事。例如,應該有既適合屏幕又適合打印輸出的命令。如果規范的制定者繼續這種“無所不包”的嘗試,此規范將最終很難實現,而且最終用戶用起來也困難。但是現在,我們做不了什么?-?只能過我們自己快樂的小日子,同時盼望負責的同志們別把事情弄糟。
在這期間,做了甜夢吧!
---
轉載自 http://bbs.xml.org.cn/dispbbs.asp?boardID=8&ID=7632
摘要: XML 路徑語言(XPath) 版本 1.0
萬維網協會 (W3C) 建議 1999November16
本版本:
http://www.w3.org/TR/1999/REC-xpath-19991116
(其它文件格式: XML [英文] HTML [英文] )
最新版本:
...
閱讀全文
Properties that are useful to set on JVMs* that export remote objects
-
java.rmi.activation.port
(1.2 and later)
- This property is used to set the TCP port number on which this VM should communicate with
rmid
(by default, rmid
listens on port 1098, but can be set to listen on a different port by using the -port
option on the rmid
command line). The default value of this property is 1098, so this property only needs to be set on VMs that need to communicate with an instance of rmid
that is running on a port other than 1098.
-
java.rmi.dgc.leaseValue
(1.1 and later)
- The value of this property represents the lease duration (in milliseconds) granted to other JVMs that hold remote references to objects which have been exported by this JVM. Clients usually renew a lease when it is 50% expired, so a very short value will increase network traffic and risk late renewals in exchange for reduced latency in calls to
Unreferenced.unreferenced
. The default value of this property is 600000 milliseconds (10 minutes).
-
java.rmi.server.codebase
(1.1 and later)
- This property specifies the locations from which classes that are published by this JVM (for example: stub classes, custom classes that implement the declared return type of a remote method call, or interfaces used by a proxy or stub class) may be downloaded. The value of this property is a string in URL format (or a space-separated list of URLs in 1.2 and later) that will be the codebase annotation for all classes loaded from the CLASSPATH of (and subsequently marshalled by) this JVM.
Note:This property must be set correctly in order to dynamically download classes and interfaces using RMI. If this property is not set correctly, you will likely encounter exceptions when attempting to run your server or client. For more information on this property, see Dynamic code downloading using RMI (Using the java.rmi.server.codebase
Property).
-
java.rmi.server.hostname
(1.1 and later)
- The value of this property represents the host name string that should be associated with remote stubs for locally created remote objects, in order to allow clients to invoke methods on the remote object. In 1.1.7 and later, the default value of this property is the IP address of the local host, in "dotted-quad" format.
-
java.rmi.server.logCalls
(1.1 and later)
- If this value is
true
, incoming calls and exceptions thrown from incoming calls will be logged to System.err
. Setting this property to true
will greatly assist you in debugging your RMI programs. See also sun.rmi.server.exceptionTrace
.
-
java.rmi.server.randomIDs
(1.1.8 and later)
- If this value is
true
, object identifiers for remote objects exported by this JVM will be generated by using a cryptographically secure random number generator. The default value is false
.
-
java.rmi.server.useCodebaseOnly
(1.1 and later)
- If this value is
true
, automatic loading of classes is prohibited except from the local CLASSPATH and from the java.rmi.server.codebase
property set on this JVM. Use of this property prevents client JVMs from dynamically downloading bytecodes from other codebases. This property is ignored in the implementations of 1.2 and 1.2.1 because of a bug.
-
java.rmi.server.useLocalHostname
(1.1.7 and later)
- RMI now uses an IP address to identify the local host when the
java.rmi.server.hostname
property is not specified and a fully qualified domain name for the localhost cannot be obtained. In order to force RMI to use the fully qualified domain name by default, you need to set the this property to true
.
Properties that are useful to set on JVMs that make remote method calls
-
java.rmi.server.codebase
(1.1 and later)
- This property specifies the locations from which classes that are published by this JVM (for example, custom classes that implement an interface that is the declared parameter type of a remote method call) may be downloaded. The value of this property is a string in URL format (or a space-separated list of URLs in 1.2 and later) that will be the codebase annotation for all classes loaded from the CLASSPATH of (and subsequently marshalled by) this JVM.
Note: Classes that exist in both the server's codebase and the client's CLASSPATH will be loaded from the client's CLASSPATH, rather than from the server's codebase as intended. For more information on this property, see Dynamic code downloading using RMI (Using the java.rmi.server.codebase
Property).
-
java.rmi.server.disableHttp
(1.1 and later)
- If this value is
true
, HTTP tunneling is disabled, even when http.proxyHost
is set. The default value is false
. If you know that your program will never need to use HTTP tunneling, then by disabling HTTP tunneling, you should see shorter timeouts for failed connections.
-
java.rmi.server.useCodebaseOnly
(1.1 and later)
- If this value is
true
, automatic loading of classes is prohibited except from the local CLASSPATH and from the java.rmi.server.codebase
property set on this JVM. Use of this property prevents client JVMs from dynamically downloading bytecodes from other codebases. This property is ignored in the implementations of 1.2 and 1.2.1 because of a bug.
Properties that can be set on rmid
sun.rmi.activation.execTimeout
(1.2 and later)
- The value of this property represents the time (in milliseconds) that the activation system will wait for a spawned activation group to start up. Setting this property gives you the ability to shorten or lengthen the maximum time that
rmid
will wait for an activation group to start up. The default value is 30000 milliseconds (30 seconds).
sun.rmi.activation.snapshotInterval
(1.2 and later)
- This property controls the number of updates for which the activation system will wait before it serializes a snapshot of its state to the
rmid
log file on disk. An "update" refers to a persistent change in the state of the activation system (for example, the registration of an Activatable
object) since the last snapshot was taken. Changing the value of this property can be used to make rmid
re-start more quickly (by taking snapshots of the log more often) or to make rmid
more efficient (by taking snapshots of the log less often). The value of this property is a positive integer value. The default value is 200.
sun.rmi.log.debug
(1.2 and later)
- If this value is
true
, details of rmid
's logging activity are sent to System.err
.
sun.rmi.rmid.maxstartgroup
(1.2 and later)
- The value of this property represents the maximum number of activation group VMs that
rmid
will allow to be in the "spawning but not yet active" state simultaneously. If more VMs need to be started, they will queue up until one of the current spawn attempts either succeeds or times out. Note that this property does not limit the maximum number of active VMs; it is intended to smooth out sudden spikes of activity to avoid reaching operating system limits. While setting the value of this property to a lower number may result in a longer start-up time for rmid
, and setting the value to a higher number could shorten the start-up time, setting this value too high can crash rmid
, because your system may run out of resources. The default value is 3.
sun.rmi.server.activation.debugExec
(1.2 and later)
- If this value is
true
, the activation system will print out debugging information to the command line that is used for spawning activation groups. By default, the value is false
, so debugging information is not printed.
Properties that are useful to set on JVMs* that export remote objects
-
sun.rmi.dgc.ackTimeout
(1.4 and later)
- The value of this property represents the length of time (in milliseconds) that the server-side RMI runtime will strongly refer to a remote object (or a reference to a remote object) that has been returned from the current virtual machine as part of the result of a remote method call, until it receives positive acknowledgment from the client that the remote reference has been fully received and processed. This timeout only applies to failure situations (in which the client fails to send the acknowledgment). Setting the value too low can increase the risk of a remote object being prematurely garbage collected when the only known reference to the remote object is the one in transit as part of the remote method call result. The maximum value is
Long.MAX_VALUE
. The default value is 300000 (five minutes).
-
sun.rmi.dgc.checkInterval
(1.1 and later)
- The value of this property represents (in milliseconds) how often the RMI runtime checks for expired DGC leases. The default value is 300000 milliseconds (5 minutes).
-
sun.rmi.dgc.logLevel
(1.1 and later)
- This property controls the logging of incoming and outgoing calls related to DGC lease granting, renewing, and expiration. It sends output to the "dgc" log.
-
sun.rmi.dgc.server.gcInterval
(1.2 and later)
- When it is necessary to ensure that unreachable remote objects are unexported and garbage collected in a timely fashion, the value of this property represents the maximum interval (in milliseconds) that the RMI runtime will allow between garbage collections of the local heap. The default value is 60000 milliseconds (60 seconds).
-
sun.rmi.loader.logLevel
(1.2 and later)
- This property controls the logging of each class name and codebase, whenever the RMI runtime attempts to load a class as a result of unmarshalling either an argument or return value. This property sends output to the "loader" log.
Please note in 1.3 that while the codebase that is printed is the annotated codebase, it may not necessarily be the actual codebase from which the class gets loaded; the RMI class loader defers the class loading to the current thread's context class loader, which may load the class from the CLASSPATH, rather than the annotated codebase. This issue no longer exists in 1.4.
-
sun.rmi.server.exceptionTrace
(1.2 and later)
- This property controls the output of server-side stack traces from exceptions and errors that are thrown by dispatched, incoming remote calls. If this value is
true
, exception stack traces will be printed. By default (false
), exception and error stack traces are not printed.
-
sun.rmi.server.suppressStackTraces
(1.4 and later)
- If this value is
true
, the server-side RMI runtime implementation will clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote calls. This property is useful for certain RMI server applications that may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled out as the result of an incoming remote call (as part of the exception's default serialized form in J2SE 1.4), perhaps for reasons of performance or confidentiality.
-
sun.rmi.transport.logLevel
(1.1 and later)
- This property controls detailed logging throughout the transport layer. It sends output to the "transport" log.
-
sun.rmi.transport.tcp.localHostNameTimeOut
(1.1.7 and later)
- The value of this property represents the time (in milliseconds) that the RMI runtime will wait to obtain a fully qualified domain name for the local host. The default value is 10000 milliseconds (10 seconds).
-
sun.rmi.transport.tcp.logLevel
(1.1 and later)
- This property provides detailed logging for the TCP-specific transport sub-layer. It sends output to the "tcp" log.
-
sun.rmi.transport.tcp.readTimeout
(1.2.2 and later)
- The value of this property represents the time (in milliseconds) used as an idle timeout for incoming RMI-TCP connections. The value is passed to
java.net.Socket.setSoTimeout
. This property is used only for cases where a client has not dropped an unused connection as it should (see sun.rmi.transport.connectionTimeout
). The default value is 2*3600*1000 milliseconds (2 hours).
Properties that are useful to set on JVMs that make remote method calls
-
sun.rmi.client.logCalls
(1.4 and later)
- If the value of this property is
true
, the sun.rmi.client.call
logger will be set to the level Level.FINER
. Remote calls are logged at the level Level.FINER
, and exceptions from remote calls are logged at the level Level.FINE
.
-
sun.rmi.dgc.cleanInterval
(1.1 and later)
- The value of this property represents the maximum length of time (in milliseconds) that the RMI runtime will wait before retrying a failed DGC "clean" call. The default value is 180000 milliseconds (3 minutes).
-
sun.rmi.dgc.client.gcInterval
(1.2 and later)
- When it is necessary to ensure that DGC clean calls for unreachable remote references are delivered in a timely fashion, the value of this property represents the maximum interval (in milliseconds) that the RMI runtime will allow between garbage collections of the local heap. The default value is 60000 milliseconds (60 seconds).
-
sun.rmi.loader.logLevel
(1.2 and later)
- This property controls the logging of each class name and codebase, whenever the RMI runtime attempts to load a class as a result of unmarshalling either an argument or return value. This property sends output to the "loader" log.
Please note in 1.3 that while the codebase that is printed is the annotated codebase, it may not necessarily be the actual codebase from which the class gets loaded; the RMI class loader defers the class loading to the current thread's context class loader, which may load the class from the CLASSPATH, rather than the annotated codebase. This issue no longer exists in 1.4.
-
sun.rmi.server.logLevel
(1.1 and later)
- This property controls the logging of information related to outgoing calls, including some connection-reuse information. It sends output to the "transport" log.
-
sun.rmi.transport.connectionTimeout
(1.1.6 and later)
- The value of this property represents the period (in milliseconds) for which RMI socket connections may reside in an "unused" state, before the RMI runtime will allow those connections to be freed (closed). The default value is 15000 milliseconds (15 seconds). See also
sun.rmi.transport.tcp.readTimeout
.
-
sun.rmi.transport.logLevel
(1.1 and later)
- This property controls detailed logging throughout the transport layer. It sends output to the "transport" log.
-
sun.rmi.transport.proxy.connectTimeout
(1.1 and later)
- The value of this property represents the maximum length of time (in milliseconds) that the RMI runtime will wait for a connection attempt (
createSocket
) to complete, before attempting to contact the server using HTTP. This property is only used when the http.proxyHost
property is set and the value of java.rmi.server.disableHttp
is false
. The default value is 15000 milliseconds (15 seconds).
-
sun.rmi.transport.proxy.eagerHttpFallback
(1.4.1 and later)
- If this value is true and the
java.rmi.server.disableHttp
system property is not set, then RMI's default socket factory will fall back to HTTP tunneling when any java.net.SocketException
is thrown from an initial (direct) connection attempt, as opposed to the default behavior of falling back to HTTP tunneling only if an initial connection attempt throws a java.net.UnknownHostException
or java.net.NoRouteToHostException
.
This setting can be useful when dealing with firewalls that deny (instead of ignore) connection attempts to unauthorized ports, resulting in java.net.ConnectionException
s inside the client's default RMI socket factory. If this system property is not enabled, then such ConnectionException
s will not trigger HTTP fallback, since they are neither UnknownHostException
s nor NoRouteToHostException
s. However, if this system property is enabled, then the ConnectionException
s will cause HTTP fallback to occur, because ConnectionException
is a subclass of SocketException
.
-
sun.rmi.transport.proxy.logLevel
(1.1 and later)
- This property controls the logging of events (
createSocket
and createServerSocket
) when the default RMISocketFactory
class is used. This type of logging is likely to be useful for applications that use RMI over HTTP. Events in custom socket factories are not logged by this property. It sends some messages to the "proxy" log, and others to the "transport" log.
-
sun.rmi.transport.tcp.handshakeTimeout
(1.4 and later)
- The value of this property represents the length of time (in milliseconds) that the client-side RMI runtime will use as a socket read timeout when reading initial handshake data (protocol acknowledgment) when establishing a new JRMP connection. This property is used to configure how long the RMI runtime will wait before deciding that a TCP connection accepted by a remote server cannot actually be used, either because the entity listening on the remote host's port is not actually an RMI server, or because the server is somehow not functioning correctly. The maximum value is
Integer.MAX_VALUE
, and a value of zero indicates an infinite timeout. The default value is 60000 (one minute).
-
sun.rmi.transport.tcp.logLevel
(1.1 and later)
- This property provides detailed logging for the TCP-specific transport sub-layer. It sends output to the "tcp" log.
Microsoft Outlook 可以自動選擇要發送的郵件的字符集。但是,有時這種自動選擇的字符集并不是我們所希望的。在這種情況下,需要手動更改字符集。
更改辦法如下
1. 在“工具(Tools)”菜單上,單擊“選項(Options...)”。
2. 單擊“郵件格式(Mail Format)”選項卡,再單擊“國際選項(International Options...)”。
3. 在“編碼選項(Encoding Options)”下,清除“自動選擇待發郵件的編碼(Auto select encoding for outgoing messages)”復選框。
兼容的API標準
J2EE????? 1.3?
JSP?????? 1.2?
Servlets? 2.3?
EJB?????? 2.0?
JTA?????? 1.0?
JMS?????? 1.0?
JNDI????? 1.2?
Java Mail 1.1.2?
JDBC????? 2.0 Extension?
JAAS????? 1.0?
JCA?????? 1.0?
JAXP????? 1.1?
適用的JDK平臺
JDK 1.3和1.4.1
需要設置環境變量
%J2EE_HOME% = %OC4J_INSTALL_PATH%/j2ee/home
安裝
java -jar oc4j.jar -install
啟動
java -jar oc4j.jar
停止
java -jar admin.jar ormi://host:port admin_name admin_passwd -shutdown
重啟動
java -jar admin.jar ormi://host:port admin_name admin_passwd -restart
強行停止
java -jar admin.jar ormi://host:port admin_name admin_passwd -shutdown force
默認HTTP端口
8888
默認RMI端口
23791
快速運行Servlet和JSP
@ 把Servlet放在j2ee/home/default-web-app/WEB-INF/classes下, 然后從host:8888/servlet/pkg.class訪問.
@ 把JSP放在j2ee/home/default-web-app下, 然后從host:8888/jsp訪問.
發布應用程序
方法一, 自動發布
把ear文件拷貝到%J2EE_HOME%/applications下
方法二, 手工發布
1. 修改server.xml, 加入
<
application?name
=
"
myapp
"
?path
=
"
/private/applications/MyApp.ear
"
?auto
-
start
=
"
true
"
?
/>
2. 修改...-web-site.xml, 加入
<
web
-
app?application
=
"
myapp
"
?name
=
"
myapp-web
"
?root
=
"
/myapp
"
?
/>
方法三, 通過工具發布
java?
-
jar?admin.jar?ormi:
//
host:port?admin_name?admin_passwd?-deploy?-file?filename.ear?-deploymentName?app_name?-targetPath?path/destination
java?
-
jar?admin.jar?ormi:
//
host:port?admin_name?admin_passwd?-bindWebApp?app_name?web_app_name?web_site_name?context_root
卸載應用程序
java?
-
jar?admin.jar?ormi:
//
host:port?admin_name?admin_passwd?-undeploy?app_name?-keepFiles
?
?
最近遇到一個問題, 某系統, 有外部系統通過RMI調用來訪問此系統. 現在有一個問題是, 如果當此系統某調用花費時間過長, 那么就需要使此次調用timeout. 而默認地, timeout的時間是2小時, 現在需要找到一種辦法縮短這個時間.
解決辦法
查閱資料發現, 可以設置sun.rmi.transport.tcp.responseTimeout(Java1.4 and above)來達到這個效果. 在Sun RMI上測試通過.
測試方法, 首先, 讓某remote method執行2分鐘左右, 模擬一個long time method.
?1?public?void?aMethod()?throws?RemoteException?{
?2?????
?3?????//long?time?op.
?4?????try?{
?5?????????Thread.sleep(100000L);
?6?????}catch?(Exception?e)?{
?7?????????e.printStackTrace();
?8?????}
?9?????
10?????System.out.println("It's?a?long?time?method.");
11?????
12?}
在客戶端執行調用的時候使用如下代碼, 則可以避免2分鐘的調用等待, 使其盡快timeout, 釋放資源.
1?java?-Dsun.rmi.transport.tcp.responseTimeout=50?mongoose.TestClient
相關資料
Re: Is there timeout parameter
Re: socket timeouts taking 2 hours
FAQ of RMI
Does RMI have a timeout period...
Connection reset
sun.rmi Properties
啟動了一個ajax的項目, 項目地址
http://mongoose.sf.net/?.
Mongoose是一個ajax的純Javascript的framework. 目前提供唯一一個component —— 一個輸入檢查的component.
使用方法
1
var?checker?=?new?Checker("http://localhost:8080/webctx/checker");
2
checker.check(this); 也可以帶一個callback函數
1?checker.check(this,?
2???????????????function(resp)?{
3???????????????????document.getElementById('msg').innerText?=?decodeURIComponent(resp.responseText);
4???????????????});
目前Mongoose在Shift_JIS/GB2312/UTF-8下測試通過,在Microsoft Internet Explorer 6.0 sp2測試通過。
Mongoose還帶有一個簡單的log模塊,可以用來調試Javascript.