移植问题及解决
移植問(wèn)題及解決
By CFR(mudboy)
摘要：本文檔包括將現(xiàn)在系統(tǒng)：從tomcat5移植至WAS5.1，以及從WAS5.1移植到WAS6.0的一些問(wèn)題的解決過(guò)程。
?
1、概述
應(yīng)用架構(gòu)：
WebStart/jsp + struts1.1 + spring115 + hibernate2.1
?
2、問(wèn)題及解決
2.1 癥狀：用了JSTL標(biāo)簽的JSP頁(yè)面運(yùn)行出錯(cuò)。
解決：由于was512不支持jstl2.0（標(biāo)準(zhǔn)的寫(xiě)法將自動(dòng)使用該版本的標(biāo)簽而不用配置），因此，使用它時(shí)，需要web.xml中顯式的增加配置，或直接寫(xiě)明使用：
<%@ taglib uri="/WEB-INF/tld/c-1_0.tld" prefix="c" %>
而不是2.0
在web.xml中增加如下即可
<taglib>
??? <taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>
??? <taglib-location>/WEB-INF/tld/c-1_0.tld</taglib-location>
</taglib>
如果支持，則可以直接用而不需要配置！
注意：jstl并不是WEB容器必須支持的東東！
?
2.2 癥狀：URLConnection調(diào)用Servlet，有兩種方法設(shè)置我當(dāng)前的SESSION（后端傳過(guò)來(lái)的）：
設(shè)置Cookie的：JSESSIONID，或重寫(xiě)URL，這在tomcat完全沒(méi)有問(wèn)題，但在WebSphere5.1下卻不行，到服務(wù)器又創(chuàng)建了一個(gè)新的SESSION，不知道為什么？
解決：一般而言，有兩種最常用的會(huì)話跟蹤機(jī)制，一種就是URL重寫(xiě)。在客戶端不接受cookie的情況下可以使用URL重寫(xiě)進(jìn)行會(huì)話跟蹤。URL重寫(xiě)包括向URL路徑添加一些容器可以解釋的數(shù)據(jù)。規(guī)范要求會(huì)話ID必須編碼在URL路徑中，參數(shù)名稱必須是jsessionid，
例如: http://www.myserver.com/catalog/index.html;jsessionid=1234
一種就是現(xiàn)在最常用的cookie了，規(guī)范要求所有的servlet都必須支持cookie。容器向客戶端發(fā)送一個(gè)cookie，客戶端在后續(xù)的處于同一個(gè)會(huì)話的請(qǐng)求中向服務(wù)器返回該cookie。會(huì)話跟蹤cookie的名字必須是JSESSIONID。
httpUrl=http://localhost:9080/Agile/getFlightList.do;jsessionid=-JW0T70Esp9QZlyfUKOsO7o?currentCity=PEK
上面的方式在WAS下也不行，也不知道還需要做什么設(shè)置？
原來(lái)，在WAS中，SESSIONID不止這些，而應(yīng)該是：<your_session>:<websphere_clone_id>,而返回的只有：前的部分，當(dāng)然沒(méi)有呀！！
看下面的日志：
swt process,sessionID is :uEVqj3UC4yYmIAZvmyZzuPw
2005-06-21 13:24:06 [com.ibatis.struts.SwtAction]-[DEBUG] other:0000uEVqj3UC4yYmIAZvmyZzuPw:-1,JSESSIONID=0000uEVqj3UC4yYmIAZvmyZzuPw:-1
2005-06-21 13:24:06 [com.ibatis.struts.SwtAction]-[DEBUG] cookie:JSESSIONID=0000uEVqj3UC4yYmIAZvmyZzuPw:-1
即SESSIONID還包括冒號(hào)后的部分。
在鏈接頁(yè)面中，將代代碼做如下修改：
<%
String sessionid = "";
Cookie[] cookie = request.getCookies();
for(int i = 0; i < cookie.length; i++)
{
?????? if(cookie[i].getName().trim().equalsIgnoreCase("JSESSIONID"))
?????? {
?????? ?????? sessionid = cookie[i].getValue().trim();
????????????? break;
?????? ?????? //logger.debug("cookie:"+cookie[i].getName() + "=" +cookie[i].getValue());
?????? }
??????
}
?
%>
?
<a href="/Agile/swt/index.jnlp?sessionid=<%=sessionid%>">lanuch agile client here</a>
?
實(shí)際上，解決此方法唯一要改的地方就是鏈接處（見(jiàn)上）：
但為了以后其它的兼容性，也可將URL重寫(xiě)也加上，這在HTTPUTIL文件中。
即不能通過(guò)調(diào)用getSession().getId()得到，而應(yīng)該自己從Cookie中找
?
?
2.3 癥狀：ORB得不到，通過(guò)JNDI無(wú)法得到，也無(wú)法得到SUN的ORB。
解決：由于WAS用的是IBM自己改造過(guò)的JRE，因此，通過(guò)實(shí)驗(yàn)，無(wú)法更換到SUN的JRE，而且也無(wú)法讓相關(guān)的SUN的ORB組件介入。最終還應(yīng)通過(guò)JNDI獲取。
將通過(guò)JNDI得到ORB的代碼改成如下：
orb = (org.omg.CORBA.ORB) ctx.lookup("java:comp/ORB");
orb =(org.omg.CORBA.ORB)javax.rmi.PortableRemoteObject.narrow(
???????????????????? ?????? ?????? ctx.lookup("java:comp/ORB"),
???????????????????? ?????? ?????? org.omg.CORBA.ORB.class);
運(yùn)行正常。
?
?
?
2.4 癥狀：從WAS5.1到WAS6.X 出現(xiàn)的問(wèn)題，即URL重寫(xiě)導(dǎo)致STRUTS相關(guān)的請(qǐng)求均無(wú)法正常完成。
解決：主要原因是：getPathInfo,getServletPath的實(shí)現(xiàn)有變動(dòng)，這會(huì)影響到struts,acegi等獲得路徑的行為。
?
解決方法：
?????? 將SWT中的URL重寫(xiě)部分去掉
?????? 創(chuàng)建新的RequestProcess，可以只在WAS6.X上才配置用該RequestProcess，在該process中，取得路徑后，如果有URL重寫(xiě)部分則將其去掉
?????? 配置上新的processor后，工作正常。
?
?
附錄1：
得到ORB異常信息：
org.omg.CORBA.INTERNAL:?? vmcid: 0x4f422000? minor code: 77? completed: No
[05-6-21 13:50:59:656 CST] 2dbf5794 SystemErr???? R ?? at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[05-6-21 13:50:59:656 CST] 2dbf5794 SystemErr???? R ?? at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:79)
[05-6-21 13:50:59:656 CST] 2dbf5794 SystemErr???? R ?? at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java(Compiled Code))
[05-6-21 13:50:59:656 CST] 2dbf5794 SystemErr???? R ?? at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code))
?
附錄2：
有關(guān)InitServlet晚于listener執(zhí)行的問(wèn)題，解決無(wú)非兩種：
1）讓Spring在需要時(shí)才生成對(duì)象
2）自己寫(xiě)listener載入配置（不在InitServlet中進(jìn)行），且必須在Spring的listener之前執(zhí)行。
3）規(guī)定不要在SPRING管理的類構(gòu)造函數(shù)中調(diào)用配置。
目前已按方法2進(jìn)行。
?
?
?
附錄3：
以下是IBM BBS上的一些問(wèn)答，供參考：
?
附錄：
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=4023650&cat=9&thread=54497&treeDisplayType=threadmode1&forum=266#4023650
?
JSESSIONID cookie - Help!
Originally posted: 2004 July 15 05:39 AM
? Nau????? Post new reply?
?
Hi, All
?
I have a need to call a servlet from another one withing the same session:
?
URL url = new URL( someURL );
URLConnection connection = url.openConnection();
connection.setDoInput( true );
connection.setRequestProperty( "Cookie", "JSESSIONID=" + request.getSession().getId() );
?
This piece of code works fine for Tomcat but on Webspere I'm getting a new session.
?
Any help please!
Thanks a million
?
Re: JSESSIONID cookie - Help!
Originally posted: 2004 July 19 07:15 AM
? Ben_????? Post new reply?
?
WebSphere generates a cookie named JSESSIONID with value
<your_session>:<websphere_clone_id>.
?
It can be JSESSIONID=000024N1ZDMZZH022EANUW2ZO5I:u7078j8m, for example.
?
You can see this if you look at the cookies the browser received or dump the
HTTP request headers.
?
You built an HTTP request containing the JSESSIONID cookie with
"JSESSIONID=" + request.getSession().getId(), but this code is broken
because getSession().getId() only return the value before the ':' sign in
the cookie value.
?
Since only the *name* of the cookie is standardized in J2EE (JSESSIONID),
it's a bad idea to assume the format of the cookie is simply the session id,
because the way the *value* of the session cookie is computed is not J2EE
standardized.
?
You'd better read the actual value from the HTTP request header instead.
?
?
?
Re: JSESSIONID gets overwritten
Originally posted: 2005 Feb 28 05:01 PM
? sjostrand2@hotmail.com????? Post new reply?
?
?
Lukasz Szelag wrote:
> JSESSIONID gets overwritten in the following scenario:
>
> 1. HTTP Request is sent to "A" URL.
>
> 2. HTTP session is created for "A" and session ID is stored in
> JSESSIONID cookie.
>
> 3. "A" stores an object in the session.
>
> 4. "A" calls "B" ("B" provides a menu)
>
> 5. HTTP session is created for "B" and session ID is stored in
> JSESSIONID cookie overwriting the previous value ("A" session ID).
>
> 6. Second HTTP request is sent to "A" URL.
>
> 7. "A" fails to lookup the object in the session stored in step 3.
> request.getSession(false) returns null.
>
> Is there a way to cure this problem? Thanks.
>
> PS. Not sure if that matters but "A" and "B" are deployed on two
> different servers. Specifying a different names for cookies seems to
> help, i.e. JSESSIONID_A and JSESSIONID_B but this is WebSphere
specific
> extension (Servlet specification requires that the cookie name is
> JSESSIONID).
>
> Lukasz
?
I assume that A and B are in two different WAR files and therefore have
different context roots, right?
?
In that case you could use WebSphere's admin console and change the
cookie path from the default (which is /, meaning the cookie is sent as
long as the URL starts with a /, which is always) to the context root
for each application.
So for application A, set the cookie path to /appA_contextRoot and for
application B, set the cookie path to /appB_contextRoot.
?
In WebSphere's admin console, go to Enterprise Applications ->
Application A -> Session Management -> {click the Enable Cookies link}
and change the Cookie path.
Good luck
/Henrik Sjostrand
總結(jié)
