Mongoose House

Technical Edition

统计

留言簿(4)

积分与排名

阅读排行榜

#

XSL入门

第一节:理解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

posted @ 2006-08-23 11:26 Mongoose 阅读(219) | 评论 (0)编辑 收藏

XML 路径语言(XPath) 版本 1.0

     摘要: XML 路径语言(XPath) 版本 1.0 万维网协会 (W3C) 建议 1999November16 本版本: http://www.w3.org/TR/1999/REC-xpath-19991116 (其它文件格式: XML [英文] HTML [英文] ) 最新版本: ...  阅读全文

posted @ 2006-08-23 11:20 Mongoose 阅读(747) | 评论 (0)编辑 收藏

Sun标准rmi属性总结(J2SE1.4.2 compatible)

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.ConnectionExceptions inside the client's default RMI socket factory. If this system property is not enabled, then such ConnectionExceptions will not trigger HTTP fallback, since they are neither UnknownHostExceptions nor NoRouteToHostExceptions. However, if this system property is enabled, then the ConnectionExceptions 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.

posted @ 2006-08-22 08:58 Mongoose 阅读(2588) | 评论 (0)编辑 收藏

避免Microsoft Outlook发送邮件自动编码

Microsoft Outlook 可以自动选择要发送的邮件的字符集。但是,有时这种自动选择的字符集并不是我们所希望的。在这种情况下,需要手动更改字符集。

更改办法如下

1. 在“工具(Tools)”菜单上,单击“选项(Options...)”。

2. 单击“邮件格式(Mail Format)”选项卡,再单击“国际选项(International Options...)”。

3. 在“编码选项(Encoding Options)”下,清除“自动选择待发邮件的编码(Auto select encoding for outgoing messages)”复选框。

posted @ 2006-08-15 13:55 Mongoose 阅读(820) | 评论 (0)编辑 收藏

OC4J使用精粹(10.1.2)

兼容的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

 


 

posted @ 2006-08-14 14:16 Mongoose 阅读(1966) | 评论 (0)编辑 收藏

解决RMI调用timeout的问题

最近遇到一个问题, 某系统, 有外部系统通过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


posted @ 2006-08-14 13:20 Mongoose 阅读(2514) | 评论 (0)编辑 收藏

Mongoose v0.9 alpha Released!

启动了一个ajax的项目, 项目地址 http://mongoose.sf.net/ .

Mongoose是一个ajax的纯Javascript的framework. 目前提供唯一一个component —— 一个输入检查的component.

使用方法
1var checker = new Checker("http://localhost:8080/webctx/checker");
2checker.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.

posted @ 2006-08-11 20:28 Mongoose 阅读(236) | 评论 (2)编辑 收藏

仅列出标题
共3页: 上一页 1 2 3