煩惱歲月

Mave is good at jar management. so maven can help me to package the java application. with maven help, we can make the release application zip smaller.

for the smaller:we use the maven ant task to manager jars:

build.xml

<project basedir="." default="all" name="jars" xmlns:artifact="antlib:org.apache.maven.artifact.ant">
<property name="build.compiler" value="modern"/>
     <path id="maven-ant-tasks.classpath" path="${basedir}/maven/maven-ant-tasks-2.0.10.jar" />
  <typeset resource="org/apache/maven/artifact/ant/antlib.xml"
           uri="antlib:org.apache.maven.artifact.ant"
           classpathref="maven-ant-tasks.classpath" />

    <target name="all">
          <antcall target="get_server_jars"/>
          <antcall target="get_orchis_jars"/>
    </target>

    <target name="get_server_jars">
        <artifact:dependencies pathId="dependency.classpath"  filesetId="maven.fileset">
        <dependency groupId="junit" artifactId="junit" version="3.8.2"/>  
        <dependency groupId="activation" artifactId="activation" version="1.1"/>    
        <dependency groupId="castor" artifactId="castor" version="1.1"/>    

        </artifact:dependencies>

    <copy todir="${basedir}/lib">
        <fileset refid="maven.fileset" />
        <!-- This mapped strips off all leading directory information -->
        <mapper type="flatten" />
    </copy>
</target>

    <target name="get_orchis_jars">
        <artifact:dependencies pathId="dependency.classpath"  filesetId="maven.fileset">
            <dependency groupId="junit" artifactId="junit" version="3.8.2"/>       
            <dependency groupId="javax.servlet" artifactId="servlet-api" version="2.4"/>      
        </artifact:dependencies>

    <copy todir="${basedir}/webapps/ROOT/WEB-INF/lib">
        <fileset refid="maven.fileset" />
        <!-- This mapper strips off all leading directory information -->
        <mapper type="flatten" />
    </copy>
</target>

so we can use maven to update you application.

as we know maven can manager you jars, I am maven funs, Maven can give me lots of good idea. Compare with ant.

(1)no class path problem.

    Sometimes Many use of ant complained because of class path. They can not direct know which jars they used in project, almost version.

(2)lots of plug-in to use with maven.(maven-jetty-plug-in)

(3)maven report is usefully for improve you code.

(4)manager your jar of application.

(5)good for team.

(6)easy to use.

About this point, user of ant do not agree with me. but i think maven easy to use, you do not need to care class path, you can easily to get all report.

運行自己配置的web應用，往往只能看見weblogic編譯之后的class文件。而看不見編譯前的java的文件。為了調試方便，我們有時候是想看編譯前的java文件。
在weblogic.xml中加入
<jsp-descriptor>
  <jsp-param>
    <param-name>keepgenerated</param-name>
    <param-value>true</param-value>
  </jsp-param>
</jsp-descriptor>

即可。
如果沒有，在WEB-INF中建立一個weblogic.xml文件。
增加
<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE weblogic-web-app
    PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
    " >
<weblogic-web-app>   
    <jsp-descriptor>
        <jsp-param>
            <param-name>keepgenerated</param-name>
            <param-value>true</param-value>
        </jsp-param>
    </jsp-descriptor>
</weblogic-web-app>

看看web應用在weblogic中生成臨時文件中，有java文件了吧！！

    as we know, in weblogic 10. the weblogic.jar just has more than 30MB. so if you want use the client to invoke weblogic ejb method, you need the weblogic.jar. of course, if you use the weblogic9, it work well, but when you upgrade your weblogic server to weblogic10. the weblogic.jar does not work. the weblogic.jar of the weblogic10 is not enough.

you need do next:

     Use the following steps to create a wlfullclient.jar file for a client application:

      Change directories to the server/lib directory.
cd WL_HOME/server/lib
Use the following command to create wlfullclient.jar in the server/lib directory:
java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar
where X.X.X.X is the version number of the jarbuilder module in the WL_HOME/server/lib directory. For example:

      java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar
You can now copy and bundle the wlfullclient.jar with client applications.
Add the wlfullclient.jar to the client application’s classpath.

Based on the popular and very useful mod_rewrite for apache, UrlRewriteFilter is a Java Web Filter for any J2EE compliant web application server (such as Resin, Orion or Tomcat), which allows you to rewrite URLs before they get to your code. It is a very powerful tool just like Apache's mod_rewrite.

URL rewriting is very common with Apache Web Server (see ) but has not been possible in most java web application servers. The main things it is used for are:

• URL Tidyness / URL Abstraction - keep URLs tidy irrespective of the underlying technology or framework (JSP, Servlet, Struts etc).
• Browser Detection - Allows you to rewrite URLs based on request HTTP headers (such as user-agent or charset).
• Date based rewriting - Allows you to forward or redirect to other URL's based on the date/time (good for planned outages).
• Moved content - enable a graceful move of content or even a change in CMS.
• Tiny/Friendly URL's (i.e. blah.com/latest can be redirected to blah.com/download/ver1.2.46.2/setup.exe)
• A Servlet mapping engine (see Method Invocation)

UrlRewriteFilter uses an xml file, called urlrewrite.xml (it goes into the WEB-INF directory), for configuration. Most parameters can be Perl5 style Regular Expressions or Wildcard Expressions. This makes it very powerful indeed.

example:

web.xml

  <filter>
        <filter-name>UrlRewriteFilter</filter-name>
        <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>UrlRewriteFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
    </filter-mapping>

urlrewrite.xml

<?xml version="1.0" encoding="utf-8"?>

    <!DOCTYPE urlrewrite
        PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
        "http://tuckey.org/res/dtds/urlrewrite3.0.dtd">

    <urlrewrite>
        <rule>
           <from>^/some/olddir/(.*)$</from>
           <to type="redirect">/very/newdir/$1</to>
        </rule>

        <rule match-type="wildcard">
           <from>/blog/archive/**</from>
           <to type="redirect">/roller/history/$1</to>
        </rule>
    </urlrewrite>

HttpSessionBindingListener雖然叫做監聽器，但使用方法與HttpSessionListener完全不同。HttpSessionBindingListener接口中共定義了兩個方法：

valueBound()和valueUnbound()，分別對應數據綁定，和取消綁定兩個事件。

所謂對session進行數據綁定，就是調用session.setAttribute()把HttpSessionBindingListener保存進session中。我們在LoginServlet.java中進行這一步。

// 把用戶名放入在線列表

session.setAttribute("onlineUserBindingListener", new OnlineUserBindingListener(username));

這就是HttpSessionBindingListener和HttpSessionListener之間的最大區別： HttpSessionListener只需要設置到web.xml中就可以監聽整個應用中的所有session。 HttpSessionBindingListener必須實例化后放入某一個session中，才可以進行監聽。

從監聽范圍上比較，HttpSessionListener設置一次就可以監聽所有session，HttpSessionBindingListener通常都是一對一的。

正是這種區別成就了HttpSessionBindingListener的優勢，我們可以讓每個listener對應一個username，這樣就不需要每次再去session中讀取username，進一步可以將所有操作在線列表的代碼都移入listener，更容易維護。

valueBound()方法的代碼如下：

public void valueBound(HttpSessionBindingEvent event) {

HttpSession session = event.getSession();

ServletContext application = session.getServletContext();



// 把用戶名放入在線列表

List onlineUserList = (List) application.getAttribute("onlineUserList");

// 第一次使用前，需要初始化

if (onlineUserList == null) {

onlineUserList = new ArrayList();

application.setAttribute("onlineUserList", onlineUserList);

}

onlineUserList.add(this.username);

}

username已經通過構造方法傳遞給listener，在數據綁定時，可以直接把它放入用戶列表。

與之對應的valueUnbound()方法，代碼如下：

public void valueUnbound(HttpSessionBindingEvent event) {

HttpSession session = event.getSession();

ServletContext application = session.getServletContext();



// 從在線列表中刪除用戶名

List onlineUserList = (List) application.getAttribute("onlineUserList");

onlineUserList.remove(this.username);



System.out.println(this.username + "退出。");

}

這里可以直接使用listener的username操作在線列表，不必再去擔心session中是否存在username。

valueUnbound的觸發條件是以下三種情況：

1. 執行session.invalidate()時。

2. session超時，自動銷毀時。

3. 執行session.setAttribute("onlineUserListener", "其他對象");或session.removeAttribute("onlineUserListener");將listener從session中刪除時。

因此，只要不將listener從session中刪除，就可以監聽到session的銷毀。

1、關于文本編輯器；

文本編輯器有很多，比如圖形模式的gedit、kwrite、OpenOffice ... ... ，文本模式下的編輯器有vi、vim（vi的增強版本）和nano ... ... vi和vim是我們在Linux中最常用的編輯器。我們有必要介紹一下vi（vim）最簡單的用法，以讓Linux入門級用戶在最短的時間內學會使用它。

nano 工具和DOS操作系統下的edit操作相似，使用簡單，我們不作介紹了，如果您有興趣，不妨嘗試一下；

2、vi 編輯器；

為什么要學會簡單應用vi

vi或vim是Linux最基本的文本編輯工具，vi或vim雖然沒有圖形界面編輯器那樣點鼠標的簡單操作，但vi編輯器在系統管理、服務器管理中，永遠不是圖形界面的編輯器能比的。當您沒有安裝X-windows桌面環境或桌面環境崩潰時，我們仍需要字符模式下的編輯器vi；

vi或vim 編輯器在創建和編輯簡單文檔最高效的工具；

3、vi 編輯器的使用方法；

3.1 如何調用vi ；

[root@localhost ~]# vi  filename

~
~
~
~
~
~
~
~

3.2 vi 的三種命令模式；

Command（命令）模式，用于輸入命令；
Insert（插入）模式，用于插入文本；
Visual（可視）模式，用于視化的的高亮并選定正文；

3.3 文件的保存和退出；

Command 模式是vi或vim的默認模式，如果我們處于其它命令模式時，要通過ESC鍵切換過來。

當我們按ESC鍵后，接著再輸入:號時，vi會在屏幕的最下方等待我們輸入命令；

:w  保存；
:w  filename 另存為filename；
:wq! 保存退出；
:wq! filename 注：以filename為文件名保存后退出；
:q! 不保存退出；
:x 應該是保存并退出 ，功能和:wq!相同

3.4 光標移動；

當我們按ESC進入Command模式后，我們可以用下面的一些鍵位來移動光標；

j 向下移動一行；
k 向上移動一行；
h 向左移動一個字符；
l 向右移動一個字符；
ctrl+b  向上移動一屏；
ctrl+f  向下移動一屏；
向上箭頭    向上移動；
向下箭頭    向下移動；
向左箭頭    向左移動；
向右箭頭    向右移動；

我們編輯一個文件時，對于 j、k、l和h鍵，還能在這些動作命令的前面加上數字，比如 3j，表示向下移動3行。

3.5 插入模式（文本的插入）；

i  在光標之前插入；
a  在光標之后插入；
I 在光標所在行的行首插入；
A  在光標所在行的行末插入；
o  在光標所在的行的上面插入一行；
O  在光標所在的行的下面插入一行；
s  刪除光標后的一個字符，然后進入插入模式；
S  刪除光標所在的行，然后進入插入模式；

3.6 文本內容的刪除操作；

x 一個字符；
#x 刪除幾個字符，#表示數字，比如3x；
dw 刪除一個單詞；
#dw 刪除幾個單詞，#用數字表示，比如3dw表示刪除三個單詞；
dd 刪除一行；
#dd 刪除多個行，#代表數字，比如3dd 表示刪除光標行及光標的下兩行；
d$ 刪除光標到行尾的內容；
J 清除光標所處的行與上一行之間的空格，把光標行和上一行接在一起；


3.7 恢復修改及恢復刪除操作；

u  撤消修改或刪除操作；

按ESC鍵返回Command（命令）模式，然后按u鍵來撤消刪除以前的刪除或修改；如果您想撤消多個以前的修改或刪除操作，請按多按幾次u。這和Word的撤消操作沒有太大的區別；

3.8 可視模式；

在最新的Linux發行版本中，vi提供了可視模式，因為這個功能是vim才有的。如果您用的vi沒有這個功能，就換成vim就有了。打開可視模式，按ESC鍵，然后按v就進入可視模式；

可視模式為我們提供了極為友好的選取文本范圍，以高亮顯示；在屏幕的最下方顯示有；

-- 可視 --  
或
--VISUAL--

如圖：

進入可視模式，我們就可以用前面所說的命令行模式中的光標移動指令，可以進行文本范圍的選取。

選取文本范圍有何用？

我們可以對某部份刪除作業，按d鍵就刪除了我們選中的內容。
選中內容后，我們按y就表示復制；按d表示刪除；

值得一提是的刪除的同時，也表示復制。我們返回到命令模式，然后移動光標到某個位置，然后按shift+p鍵，就把剛才刪除的內容貼上了。我們先在這里提一句，在后文，我們還得詳細說說。

退出可視模式，還是用ESC鍵；

3.9 復制和粘帖的操作；

其實刪除也帶有剪切的意思，當我們刪除文字時，可以把光標移動到某處，然后按shift+p鍵就把內容貼在原處，然后再移動光標到某處，然后再按p或shift+p又能貼上；

p 在光標之后粘帖；
shift+p 在光標之前粘帖

來舉一例：

比如我們想把一個文檔的第三行復制下來，然后帖到第五行的后面，我們應該怎么做呢？

有兩種方法；

第一種方法：

先把第三行刪除，把光標移動到第三行處，然后用dd動作，接著再按一下shift+p鍵。這樣就把剛才刪除的第三行帖在原處了。

接著我們再用k鍵移動光標到第五行，然后再按一下p鍵，這樣就把第三行的內容又帖到第五行的后面了；

第二種方法；

進入可視模式，按ESC鍵，然后按v鍵。移動鼠標指針，選中第三行的內容，然后按y鍵復制；再移動指針到第五行，最后按p鍵；

所以復制和粘貼操作，是命令模式、插入模式及可視模式的綜合運用；我們要學會各種模式之間的切換，要常用ESC鍵；更為重要的學會在命令模式下移動光標；

3.10 關于行號；

有時我們配置一個程序運行時，會出現配置文件X行出現錯誤 。這時我們要用到行號相關的操作；

為所有內容添加行號；

按ESC鍵，然后輸入：

:set number

光標所處位置

在屏幕的右下角，有類似如下的；

         57,8          27%

在這之中，57表示第57行，8表示第8個字符；

3.11 查找和替換功能；

3.11.1 查找；

首先，我們要進入ESC鍵，進入命令模式；我們輸入/或?就進入查找模式了；

/SEARCH  注：正向查找，按n鍵把光標移動到下一個符合條件的地方；
?SEARCH  注：反向查找，按shift+n 鍵，把光標移動到下一個符合條件的

舉一例：比如我想在一個文件中找到swap單詞，我應該如下做；

首先按ESC鍵，進入命令模式，然后輸入；

/swap
或
?swap

3.11.2 替換；

按ESC鍵進入命令模式；

:s /SEARCH/REPLACE/g  注：把當前光標所處的行中的SEARCH單詞，替換成REPLACE，并把所有SEARCH高亮顯示；
:%s /SEARCH/REPLACE  注：把文檔中所有SEARCH替換成REPLACE；
:#,# s /SEARCH/REPLACE/g  注：＃號表示數字，表示從多少行到多少行，把SEARCH替換成REPLACE；

注：在這之中，g表示全局查找；我們注意到，就是沒有替換的地方，也會把SEARCH高亮顯示；

舉例說明：

比如我們有一篇文檔要修改；

我們把光標所在的行，把所有單詞the，替換成THE，應該是：

:s /the/THE/g

我們把整篇文檔的所有的the都替換成THE，應該是：

:%s /the/THE

我們僅僅是把第1行到第10行中的the，替換成THE，應該是；

:1,10  s /the/THE/g

參考：man vi 和vi –help

      一個Maven項目發布版本號用version 編碼，用來分組和排序發布。Maven中的版本包含了以下部分：主版本，次版本，增量版本，和限定版本號。一個版本中，這些部分對應如下的格式：

<major version>.<minor version>.<incremental version>-<qualifier>

例如：版本“1.3.5”由一個主版本1，一個次版本3，和一個增量版本5。而一個版本“5”只有主版本5，沒有次版本和增量版本。限定版本用來標識里程碑構建：alpha和beta發布，限定版本通過連字符與主版本，次版本或增量版本隔離。例如，版本“1.3-beta-01”有一個主版本1，次版本3，和一個限定版本“beta-01”。

當你想要在你的POM中使用版本界限的時候，保持你的版本號與標準一致十分重要。在版本界限，允許你聲明一個帶有版本界限的依賴，只有你遵循標準的時候該功能才被支持。因為Maven根據本節中介紹的版本號格式來對版本進行排序。

如果你的版本號與格式<主版本>.<次版本>.<增量版本>-<限定版本>相匹配，它就能被正確的比較；“1.2.3”將被評價成是一個比“1.0.2”更新的構件，這種比較基于主版本，次版本，和增量版本的數值。如果你的版本發布號沒有符合本節介紹的標準，那么你的版本號只會根據字符串被比較；“1.0.1b”和“1.2.0b”會使用字符串比較。

1. 版本構建號

       我們還需要對版本號的限定版本進行排序。以版本號“1.2.3-alpha-2”和“1.2.3-alpha-10”為例，這里“alpha-2”對應了第二次alpha構建，而“alpha-10”對應了第十次alpha構建。雖然“alpha-10”應該被認為是比“alpha-2”更新的構建，但Maven排序的結果是“alpha-10”比“alpha-2”更舊，問題的原因就是我們剛才討論的Maven處理版本號的方式。

Maven會將限定版本后面的數字認作一個構建版本。換句話說，這里限定版本是“alpha”，而構建版本是2。雖然Maven被設計成將構建版本和限定版本分離，但目前這種解析還是失效的。因此，“alpha-2”和“alpha-10”是使用字符串進行比較的，而根據字母和數字“alpha-10”在“alpha-2”前面。要避開這種限制，你需要對你的限定版本使用一些技巧。如果你使用“alpha-02”和“alpha-10”，這個問題就消除了，一旦Maven能正確的解析版本構建號之后，這種工作方式也還是能用。

2. SNAPSHOT版本

       Maven版本可以包含一個字符串字面量來表示項目正處于活動的開發狀態。如果一個版本包含字符串“SNAPSHOT”，Maven就會在安裝或發布這個組件的時候將該符號展開為一個日期和時間值，轉換為UTC（協調世界時）。例如，如果你的項目有個版本為“1.0-SNAPSHOT”并且你將這個項目的構件部署到了一個Maven倉庫，如果你在UTC2008年2月7號下午11:08部署了這個版本，Maven就會將這個版本展開成“1.0-20080207-230803-1”。換句話說，當你發布一個snapshot，你沒有發布一個軟件模塊，你只是發布了一個特定時間的快照版本。

那么為什么要使用這種方式呢？SNAPSHOT版本在項目活動的開發過程中使用。如果你的項目依賴的一個組件正處于開發過程中，你可以依賴于一個SNAPSHOT版本，在你運行構建的時候Maven會定期的從倉庫下載最新的snapshot。類似的，如果你系統的下一個發布版本是“1.4”你的項目需要擁有一個“1.4-SNAPSHOT”的版本，之后它被正式發布。

作為一個默認設置，Maven不會從遠程倉庫檢查SNAPSHOT版本，要依賴于SNAPSHOT版本，用戶必須在POM中使用repository和pluginRepository元素顯式的開啟下載snapshot的功能。

當發布一個項目的時候，你需要解析所有對SNAPSHOT版本的依賴至正式發布的版本。如果一個項目依賴于SNAPSHOT，那么這個依賴很不穩定，它隨時可能變化。發布到非snapshot的Maven倉庫（如http://repo1.maven.org/maven2）的構件不能依賴于任何SNAPSHOT版本，因為Maven的超級POM對于中央倉庫關閉了snapshot。SNAPSHOT版本只用于開發過程。

3. LATEST 和 RELEASE 版本

      當你依賴于一個插件或一個依賴，你可以使用特殊的版本值LATEST或者RELEASE。LATEST是指某個特定構件最新的發布版或者快照版(snapshot)，最近被部署到某個特定倉庫的構件。RELEASE是指倉庫中最后的一個非快照版本。總得來說，設計軟件去依賴于一個構件的不明確的版本，并不是一個好的實踐。如果你處于軟件開發過程中，你可能想要使用RELEASE或者LATEST，這么做十分方便，你也不用為每次一個第三方類庫新版本的發布而去更新你配置的版本號。但當你發布軟件的時候，你總是應該確定你的項目依賴于某個特定的版本，以減少構建的不確定性，免得被其它不受你控制的軟件版本影響。如果無論如何你都要使用LATEST和RELEASE，那么要小心使用。

Maven 2.0.9之后，Maven在超級POM中鎖住了一些通用及核心Maven插件的版本號，以將某個特定版本Maven的核心Maven插件組標準化。這個變化在Maven 2.0.9中被引入，為Maven構建帶來了穩定性和重現性。在Maven 2.0.9之前，Maven會自動將核心插件更新至LATEST版本。這種行為導致了很多奇怪現象，因為新版本的插件可能會有一些bug，甚至是行為變更，這往往使得原來的構建失敗。當Maven自動更新核心插件的時候，我們就不能保證構建的重現性，因為插件隨時都可能從中央倉庫更新至一個新的版本。從Maven 2.0.9開始，Maven從根本上鎖住了一組核心插件的版本。非核心插件，或者說沒有在超級POM中指定版本的插件仍然會使用LATEST版本去從倉庫獲取構件。由于這個原因，你在構件中使用任何一個自定義非核心插件的時候，都應該顯式的指定版本號。

Often times you will have 3rd party JARs that you need to put in your local repository for use in your builds. The JARs must be placed in the local repository in the correct place in order for it to be correctly picked up by Maven. To make this easier, and less error prone, we have provide a goal in the install plug-in which should make this relatively painless. To install a JAR in the local repository use the following command:

mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> \
    -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>

for example:

mvn install:install-file -Dfile=jazzy-core-0.5.2.jar -DgroupId=jazzy-core  -DartifactId=jazzy -Dversion=0.5.2 -Dpackaging=jar

ResultSet 接口提供用于從當前行獲取列值的獲取 方法（getBoolean、getLong 等）。可以使用列的索引編號或列的名稱獲取值。一般情況下，使用列索引較為高效。列從 1 開始編號。為了獲得最大的可移植性，應該按從左到右的順序讀取每行中的結果集列，每列只能讀取一次。
對于獲取方法，JDBC 驅動程序嘗試將底層數據轉換為在獲取方法中指定的 Java 類型，并返回適當的 Java 值。JDBC 規范有一個表，顯示允許的從 SQL 類型到 ResultSet 獲取方法所使用的 Java 類型的映射關系。

注意： JDBC 驅動程序目前不支持 SQL Server sqlvariant 數據類型。如果使用查詢從包含 sqlvariant 數據類型列的表中檢索數據，則會發生異常。

Getter 方法轉換

基于 SQL Server 2005 的數據類型，以下圖表包含 SQLServerResultSet 類的 get<Type> 方法的 JDBC 驅動程序轉換圖，以及 SQLServerCallableStatement 類的 get<Type> 方法支持的轉換。

JDBC 驅動程序的 getter 方法支持三種基本的轉換類別：

• Non-Lossy (x) ：在 getter 類型等于或小于基礎服務器類型的情況下執行轉換。例如，對基礎服務器的十進制數列調用 getBigDecimal 時，無需進行轉換。
• Converted (y) ：從數字服務器類型到 Java 語言類型的轉換，此時的轉換為常規轉換，并遵循 Java 語言轉換規則。對于這些轉換，總是直接截取有效位數（從不四舍五入），而溢出則按目標類型取模處理，以較小者為準。例如，對包含“1.9999”的基礎十進制數列調用 getInt 將返回“1”；如果基礎十進制數值為“3000000000”，則 int 值將溢出為“-1294967296”。
• Data Dependent (z) ：從基礎字符類型轉換到數字類型時，要求字符類型所包含的值可轉換成數字類型。不執行其他轉換。如果值對于 getter 類型過大，則該值無效。例如，如果對包含“53”的 varchar(50) 列調用 getInt ，則該值作為 int 返回；但如果基礎值為“xyz”或“3000000000”，則發生錯誤。