|
要求
番号
|
|
|
|
|
GenericProxyServlet で処理できるようになりました。
|
|
|
|
/////」の JSP パラメータは、getParameter() によって値「/」と解釈されました。
|
|
|
|
Connection: close ヘッダなしで即座に閉じられました。
HTTP/1.1 400 Bad Request Date: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 463 Content-Type: text/html Last-Modified: Thu, 07 Nov 2002 21:56:52 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html>
|
|
|
|
weblogic.Deployer に伝播された JSP コンパイル例外には、スタック トレースだけで、正確なエラー メッセージがありませんでした。
weblogic.Deployer に伝播されるようになりました。 したがって、例外にはより詳しい情報とコンテキスト情報が含まれています。
|
|
|
|
HttpURLConnection の WebLogic Server 実装でチェックされませんでした。そのため、フラッシュ時に Connection aborted by peer: socket write error が発生しました。
|
|
|
|
JspParser によって UnsupportedEncodingException が送出されました。
<%@ page contentType="text/html; charset=\"Shift_JIS\"" %>
java.lang.RuntimeException: Unknown/unsupported charset: "Shift_JIS" - java.io.UnsupportedEncodingException: Charset: '"Shift_JIS"' not recognized, and there is no alias for it in the WebServerMBean
Content-Type ヘッダの charset 属性値に、引用符で囲まれた文字列およびコメントのサポートを追加することで解決しました。
|
|
|
|
NullPointerException が送出されました。管理対象サーバへの HTTP アクセスのたびに、次の例外が送出されました。
java.lang.NullPointerException at
weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292) at
weblogic.servlet.internal.HttpServer.log(HttpServer.java:865) at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044) at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265) at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
|
|
|
|
<22.07.2002 14:12:24 CEST> <Error> <HTTP>
<[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at ....
|
|
|
|
|
|
|
|
|
|
|
|
getAttributeString ではなく getAttribute を使用するように修正することで解決しました。
|
|
|
|
__jspService メソッドの 64KB 制限を超えてしまうことがありました。
<my:tag ... /> 形式の空の BodyTag に遭遇した場合、通常その本体のスコープを設定する生成コードが、StandardTagLib.java の静的メソッドに対する 1 回の呼び出しに置き換えられます。その結果、BodyTag ではそれが JSP ソースから通常どおりに呼び出されているものと判断されるようになります。
|
|
|
|
|
|
|
|
cookieName を指定する際に、セッション属性が正しく更新されていなかったことが判明しました。別の Web アプリケーションのリソースが含まれ、外部リソースを追加する前のリクエストに RemoteUser が存在していました。
|
|
|
|
|
|
|
|
HttpServletResponseWrapper getWriter ではなく OutputStream と通信していました。その結果、次のエラーが発生していました。
RequestCallback を実装することで解決しました。
|
|
|
|
|
|
|
|
|
|
|
|
Servlet Filter1 --> WebApp1 -- forward to WebApp2 ctx --> Servlet
Filter2(WebApp2) --> Ejb Lookup (fails)
|
|
|
|
CGIServlet の動作が変更されていたため、ファイル名に拡張子がない CGI スクリプトの実行に影響するおそれがありました。たとえば、ファイル web.xml で CGI ディレクトリを定義し、サーブレット マッピングを次のようにしたとします。
<param-name>cgiDir</param-name>
<param-value>/home/user/cgi-bin</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>
myscript というスクリプトを /home/user/cgi-bin ディレクトリに格納すると、http://localhost/mywebapp/cgi-bin/myscript のような URL は、スクリプト名を指定しないと /home/user/cgi-bin にマップされました (この問題は、myscript.ksh のように拡張子を付けたスクリプトでは発生しませんでした)。
CGIServlet の動作が以前のリリースと一致するようにコードを修正しました。上記の例であれば、URL http://localhost/mywebapp/cgi-bin/myscript は /home/user/cgi-bin/myscript にマップされるようになりました。
|
|
|
|
JspFileNotFoundException 例外が発生していました。2 回目以降のアクセスでは、問題なく 404 が返されました。
|
|
|
|
<jsp:plugin type="applet"
code="examples.applets.PhoneBook1.class"
codebase="/bea_WebLogic
Server_internal/classes/DefaultWebApp@DefaultWebApp/"
height="800" width="500" type="applet" jreversion="1.3.1_06"
nspluginurl="http://java.sun.com/products/plugin/1.1.3/plugin-install.html";
iepluginurl="http://java.sun.com/products/plugin/1.1.3/jinstall-113-win32.cab#Version=1,1,3,0" >
<embed type="application/x-java-applet;version=1.3.1_06"
pluginspage="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; height="800" width="500"
code="examples.applets.PhoneBook1.class"
codebase="/bea_WebLogicServer_internal/classes/DefaultWebApp@DefaultWebApp/">
|
|
|
|
browser output: が次のようになっていました。
Error 500--Internal Server Error From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.
<[ServletContext(id=287644,name=jspVal.war,context-path=/jspVal)] Servlet
failed withIOException java.io.IOException: javax.servlet.jsp.JspException: The taglib validator
rejected the page: "Exception TestValidator XML parsing: org.xml.sax.SAXParseException:
Attribute "xmlns:valtest" was already specified for element "jsp:root". -- stack trace written to stderr., "...
weblogic.servlet.jsp.jsp2xml.Jsp2XmlOutputter のように修正したことで、JSP の XML ビューの生成において重複するタグ プレフィックスが無視されるようになりました。
|
|
|
|
access.log に queryString のログが記録されませんでした。また、転送されたリクエストのログは access.log に記録されましたが、元のリクエストのログは記録されませんでした。
RequestDispatcherImpl のように修正することで解決しました。
|
|
|
|
JDBCSessionContext および JDBCSessionData 内のバブル キャッシュに関係したパフォーマンスが向上しました。
|
|
|
|
jsp_precompile が、拡張されたカスタム クラスを含むすべての JSP で機能するようになりました。
|
|
|
|
compilerclass を設定すると、起動ログに次のような compilerclass=null メッセージが記録されていました。
JSPServlet with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler= C:\61sp4\jdk131/bin/javac,compileFlags=,workingDir=C:\61sp4 wlserver6.1\config\examples\applications\examplesWebApp\WEB-INF\_tmp_war_examples_examplesWebApp, pageCheckSeconds=1,superclass=weblogic.servlet.jsp.JspBase, keepgenerated=false,precompileContinue=false, compilerSupportsEncoding=true,encoding=null,defaultfilename index.jsp,compilerclass= null,noTryBlocks=false]'>
compilerclass の設定が使用されていたために発生していました。JSP のコンパイルでは正しい設定が使用されていました。サーバの起動時に正しいパラメータ値が取得されるようにコードを修正しました。
|
|
|
|
Transfer-Encode の値が「Chunked」と大文字になっていました。HTTP/1.1 仕様では小文字で「chunked」とする必要があります。コードを修正したことで、Transfer-Encode タイプが小文字で「chunked」と出力されるようになりました。
|
|
|
|
JSESSION および _wl_authcookie_ という 2 つのクッキーを受信します。サーバが _wl_authcookie_ なしで 2 つめのリクエスト (HTTPS) を保護されていないページに送信すると、401 エラーが返されていました。
_wl_authcookie_ を返信しないと保護されていない (つまり、セキュリティ制限のない) HTTPS ページへのアクセスが拒否される問題は修正されました。保護されていないページでクッキーが要求されることはなくなりました。
|
|
|
|
UnsafeFilenameExceptions が発生していました。
|
|
|
|
pageCheckSeconds 属性が、JSP を初めて変更したときには機能していませんでした。
lastStaleCheck の時刻を設定していなかったために発生していました。
lastStaleCheck が設定されていなくても、現在の時刻が設定されるようになりました。これにより、JSP が無駄に再コンパイルされることがなくなりました。
|
|
|
|
getOutputStream を呼び出すコードを実行すると、NestedBodyResponse で常に IllegalStateException が送出されていました。
NestedBodyResponse から getWriter() と getOutputStream() を一緒に使用できないようしました。これにより、例外が誤って送出されることがなくなりました。
|
|
|
|
http://server:port/mywebapp/foo%20%20
mywebapp 内のリソース foo を解決します。この URI は 404 エラーになります。
|
|
|
|
filter-dispatched-requests-enabled コンフィグレーション パラメータを weblogic.xml に追加して、サーブレットのフィルタ処理を制御できるようにしました。
|
|
|
|
<jsp:include page="included.jsp">
<jsp:param name="title"
value="<%= java.net.URLEncoder.encode(\"[double byte characters]\")
%>"/>
</jsp:include>
|
|
|
|
getHeaderFields() メソッドが、weblogic.net.http.HttpURLConnection に実装されていませんでした。このため、weblogic.net.http.HttpURLConnection.getHeaderFields() が空のマップを返していました。
getHeaderFields() の実装が weblogic.net.http.HttpURLConnection に追加されました。この修正の結果、weblogic.net.http.HttpURLConnection.getHeaderFields() がヘッダ フィールドのマップを正しく返すようになりました。
|
|
|
|
|
|
|
|
JnlpDownloadServlet は、WAR ファイルのタイムスタンプを利用して、クライアントのリソースが Web サーバ上のものより古いかどうかを判断します。タイムスタンプを取得するため、JnlpDownloadServlet は URLConnection.getLastModified() メソッドを呼び出します。しかし、getLastModified() メソッドからは 0 が返されていました。
ZipURLConnection.getLastModified() メソッドが zip ファイルの (したがって WAR ファイルの) 更新時刻を返すようにコードが修正されました。
|
|
|
|
|
|
|
|
|
|
|
|
SecureProxy 設定を尊重していました。受信リクエストが HTTP を使用する場合、プロキシ サーブレットで SecureProxy が有効になっていても WebLogic Server は HTTPS 接続を使用しませんでした。この問題は、コードを修正することで解決しました。
|
|
|
|
becomePrimary、becomeSecondary、および becomeUnregistered コールバックではインクリメントおよびデクリメントされていませんでした。
|
|
|
|
TrackingEnabled が false に設定されていると要求ごとに新しいセッションが作成されますが、それらのセッションが無効にされていませんでした。
TrackingEnabled が false に設定されているとセッションが即座に無効になるようになりました。これが正しい動作です。
|
|
|
|
save-sessions-enabled プロパティが true に設定されていても、java.lang.NoClassDefFoundError が発生していました。
|
|
|
|
request.isUserInRole メソッドが WebLogic Security フレームワークのロール マネージャのセキュリティ ロールをクエリしていませんでした。
request.isUserInRole メソッドがロール マネージャのセキュリティ ロールをクエリするようになりました。
|
|
|
|
destroy() メソッドを呼び出します。しかし、Web アプリケーション クラスローダでは、destroy がスレッドの ContextClassLoader として呼び出されていませんでした。
destroy() メソッドが常にスレッドの ContextClassLoader として呼び出されるようになりました。
|
|
|
|
ClusterMBean のプロパティ FrontendHost、FrontendHTTPPort、および FrontendHTTPSPort がエクスポーズされました。ClusterMBean の値は、クラスタ内のサーバのデフォルト Web サーバに対してのみ有効です。仮想ホスト プロパティは別途設定する必要があります。この修正でこれまでの動作が変更されることはありません。
|
|
|
|
IOException が発生した後にも、WebLogic Server が出力ストリームに書き込みをしようとしていました。このため、IOException を処理しない Web アプリケーションで予期せぬソケットの切断が発生すると、CPU 使用率が 100% になるおそれがありました。
org.apache.xml.serialize.XMLSerializer は、そのプロセスが終了するまで IOException を無視します。このため、HTTP 応答の一部として XML ドキュメントを返している最中に IOException が送出されると、この問題が発生していました。
IOException が発生した後は出力ストリームへの書き込みが停止するようになりました。
|
|
|
|
appc の実行時、参照先となる EJB の JNDI 名へのマッピングが ejb-ref にないことを示す例外が誤って送出されていました。
weblogic.xml 内の対応する JNDI 名のマッピングが web.xml で宣言された ejb-ref にある場合は正しく認識されるようになりました。この結果、appc を実行しても、誤ってこの例外が送出されることはなくなりました。
|
|
|
|
weblogic.servlet.jsp.JspException: (line -1): cannot load TLD: weblogic.xml.dom.ChildCountException: missing child tagclass in tag ...
TLDDescriptor では 1.1 と認識されることが原因で発生していました。
TLDDescriptor コンストラクタがブール値 flag _12 と org.w3c.dom.Element をとるようにすることで、Document.getDoctype() を呼び出してドキュメントのタイプを調べるようにしました。
|
|
|
|
IOException が発生しても、GenericProxyServer はこの接続を再利用せず、後続のリクエスト用に新しい接続を作成するようになりました。
|
|
|
|
ServletContext 属性を追加し、これをシリアライズできない値で上書きすると、元の値が新しい値をマスクしていました。この問題は、属性ハッシュテーブルから古い値が削除されないことが原因で発生していました。
|
|
|
|
useByteStream パラメータが true に設定されている状態で CGIServlet を使用するときに WebLogic Server は NullPointerException を送出していました。この問題は、1 つのフレームに静的 URL リンクが含まれ、別のフレームで CGIServlet が使用されているフレームセットの使用時に発生していました。もう一方のフレームがページのダウンロードを完了する前に静的リンクの含まれているフレームをユーザが選択すると、IO 例外が捕捉され、次のように表示されていました。
java.lang.NullPointerException at
weblogic.utils.Executable$Drainer.run(Executable.java:366)
|
|
|
|
ServletRequestWrapper を拡張する ServletRequest を使用して RequestDispatcher.include() メソッドを何度も呼び出します。WebLogic Server で ServletRequestWrapper オブジェクトを処理するにはキャストを実行する必要があります。RequestDispatcherImpl.include() メソッドでは、参照された ServletRequest オブジェクトが ServletRequestImpl クラスのインスタンスでない場合は、このキャスト処理が試行されて ClassCastException が捕捉されていました。このため、許可されていないキャストによって生成される例外の負荷が大きく、WebLogic Portal 8.1 のパフォーマンスが低下していました。
ClassCastException の代わりに instanceof 演算子を使用して、特定のキャスト処理が許可されているかどうかが識別されるようになりました。
weblogic.servlet.internal.RequestDispatcherImpl.forward() メソッドおよび include() メソッドでのフロー制御に instanceof 演算子が使用されるようになりました。
|
|
|
|
|
|
|
|
/foo* が /foo と一致していました。これは、サーブレット 2.3 仕様では無効でした。
URLResource が追加されましたが、誤ってそのサポートが停止されていました。また、サーブレット コンテナの動作不良により、URL パターン /foo* は fullyDelegateAuthorization フラグが無効になっていると機能し、有効になっていると機能しませんでした。これにより、WebLogic Server 6.x から 7.x または 8.x へのアップグレードでセキュリティが低下するおそれがありました。
/ で始まり /* で終わる文字列のみが使用されるようになりました。古いマッピングを使用している場合に備えて、<security-constraints> の <url-pattern> が /foo* に設定されている Web アプリケーションはデプロイされないようにすることでセキュリティの脆弱性を回避しています。
/foo* のような URL パターンは完全な一致として処理され、<security-constraints> の <url-pattern> が /foo* に設定されている Web アプリケーションはデプロイされなくなりました。
|
|
|
|
serverShutdown フラグを適切に渡さなかったので、チェック ロジックは無視されていました。
|
|
