|
|
| |
Resolved Problems
The following sections describe problems that have been resolved by Service Packs for WebLogic Server 6.1. Service Packs are cumulative; the current release, Service Pack 7 contains all the fixes made in earlier Service Packs released for WebLogic Server 6.1.
WebLogic Server 6.1 Service Pack 7 Solutions
The following sections describe problems that have been resolved for the release of WebLogic Server 6.1 Service Pack 7.
Administration Console
Classloader
Cluster
Core
Deployment
CR Number |
Description |
CR134122 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_57.00.jsp. |
EJB
Internationalization
JDriver
JDBC
CR Number |
Description |
---|---|
CR095876 |
In previous releases, methods in the weblogic.jdbc.common.Pool and weblogic.jdbc.common.JDBCServices interfaces were referenced in the Programming WebLogic JDBC guide, but the Javadocs for those interfaces were not published. In WebLogic Server 6.1 SP7, the Javadocs for these interfaces are published at ../javadocs/weblogic/jdbc/common/package-summary.html. Note, however, that the methods in these interfaces have been deprecated and are not available in WebLogic Server 7.0 and 8.1. |
CR128888 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_53.00.jsp. |
CR127949 |
Statement.getResultSet() sometimes generated an unnecessary new ResultSet wrapper for the one underlying DBMS resultset, if a result set had already been returned to the user code. If the user code had run an executeQuery() call first, without retaining the result set it returned, garbage-collecting could close it immediately, with the underlying DBMS resultset, invalidating and prematurely closing any result set returned by a subsequent getResultSet() call. WebLogic Server no longer generates unnecessary wrappers due to a code change. |
CR184143 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_53.00.jsp. |
CR182410 |
Under a high load condition, WebLogic Server slowed significantly. Removing synchronization In weblogic.jdbc.common.internal.MultiPool.searchLoadBalance() method eliminated the slowdown under high load conditions. |
CR133612 |
In Service Pack 7, the Oracle thin driver is modified with latest 9.2.0.4 drivers in classes12.zip in the 3rdparty/oracle/920 directory |
CR131575 |
WebLogic Server sometimes threw an incorrect warning about a JDBC connection leak that began: [SerialConnection]: Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n The leak detection code that sent this warning is obsolete. A code change resolved the problem. |
CR130306, CR135909 |
In jta.DataSource, when doing refreshAndEnlist, WebLogic Server called tx.enlist(), but the connection was not returned to the pool if there was an exception in the refreshAndEnlist call. A code change catches the exception and releases the connection to the pool. |
CR129379 |
When an EJB transaction created many new entities or otherwise engaged many beans that all use JDBC, WebLogic Server risked running out of Oracle cursors, because in an attempt to avoid a suspected Oracle driver bug, WebLogic Server delayed closing JDBC statements until the end of a transaction, holding the cursors for the statement until then. This behavior has been changed so that the session need not hold cursors until the transaction ends. |
CR127720 |
New versions of JDBC drivers track the transactional state of connections. If a local transaction was active on a connection, XA operations could not be performed on it, resulting in an XAER_PROTO or XAER_RMERR when an xa_start() was called on the connection. As a result, applications had to go through the tedious process of narrowing down where in their code they had started but not ended a local transaction. The problem was resolved by a code change in the recovery method that prevents special XA connections from being released to the pool twice. |
JMS
JNDI
CR Number |
Description |
---|---|
CR136746 |
Enhancement request to allow explicit naming of JDBC driver being used in class VendorId. This customer enhancement was made through a code change. |
JSPs and Servlets
JVM
Operations, Administration and Management
Plug-Ins
RMI-IIOP
RMI
Samples
Security
SNMP
WLEC
WebLogic Tuxedo Connector
WebLogic Server 6.1 Service Pack 6 Solutions
This section lists problems resolved in WebLogic Server 6.1 SP06.
Classloader
Cluster
Connector
Console
Core
Change Request Number |
Description |
---|---|
CR071415 |
In WebLogic Server 6.1 SP02, when the WebLogic Server security manager starts and sets the policy file, the path /usr/lib was prepended to javac during JSP compilation, causing a java.security.AccessControlException. The problem was solved with a code fix. |
CR094410 |
When DebugHttp was activated in ServerDebugMBean, WebLogic Server reported SocketResetExceptions as errors, rather than simple debug messages. To address this problem, logMuxableSocketResetException() was added to the message catalog for reporting this debug message. |
CR096091 |
In WebLogic Server 6.1 SP04 and SP05, when starting WebLogic Server as an Windows service using a classpath from a file, the error "Thread created successfully! Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/Server" is thrown if classpath file is over about 2k length. The problem was solved by correcting an error related to reading the classpath from a file. |
CR102058 |
When using URLClassLoader on the client, a remote method call resulted in a NoClassDefFoundError. c:\java\java131_07\bin\java -classpath ".;client.jar;C:\home\ravia\weblogic\dev\src700\3rdparty\weblogicaux.jar" URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:401) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:162) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:190) at weblogic.utils.classfile.utils.CodeGenerator.generateClass(CodeGenerator.java:71) at ... The problem was solved by setting ThreadContextClassLoader as the parent for AugmentableSystemClassLoader. |
CR103525 |
In WebLogic Server 6.1 SP04, this error occurred: weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Old socket closed and released FD before FDRecord still exists,... The problem was solved with a code change to Ensure that socket closes outside the muxer are handled gracefully. |
CR103774 |
The Solaris and Windows 2000 versions of WebLogic Server logged socket exceptions similar to: <Apr 3, 2003 11:40:07 AM EST> <Error> <socket> <000424> <IOException on socket: weblogic.servlet.internal.MuxableSocketHTTP@1eca988 - idle timeout: '30000' ms, socket timeout: '0' ms, fd: 53 java.net.SocketException: Connection reset java.net.SocketException: Connection reset However, these messages do not indicate a defect with the server or application. The code changed so that the above exceptions are displayed only when the server is in debug mode. |
CR103967 |
In WebLogic Server 6.1 SP04, child threads of WebLogic Server execute threads did not inherit the correct context classloader. This problem common occurred when a servlet or an ejb created a timer (java.util.Timer). Analysis revealed that WebLogic Server execute threads maintained their own context classloader and child threads of these execute threads did not inherit the context because java.lang.Thread directly assigned the member variable of its own to the child threads. The problem was solved with a code fix. |
CR104218 |
In WebLogic Server 6.1 SP04, the following exception occurred on a Solaris 8 server with patch for CR100665_61sp4.jar: <Apr 23, 2003 3:36:27 PM CDT> <Error> <Posix Performance Pack> <Uncaught Throwable in processSockets java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:750) at java.util.HashMap$EntryIterator.next(HashMap.java:792) at java.util.HashMap.putAllForCreate(HashMap.java:408) at java.util.HashMap.clone(HashMap.java:624) at java.util.HashSet.clone(HashSet.java:217) at weblogic.socket.PosixSocketMuxer.closeSockets(PosixSocketMuxer.java:486) at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:589) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) The problem was solved with a code fix. |
CR105426 |
WebLogic Server ships with a file named wlntio_g.dll, which is a debug version of of wlntio.dll (and is required only for debugging purposes). WebLogic Server 6.0 Service Pack 2 included the wrong version of wlntio_g.dll, which could cause stack traces similar to the following when used for debugging: <NT Performance Pack> NATIVE.malloc(): allocated at 0x08DAD008 numAllocs 1 Service Pack 6 now includes the correct version of wlntio_g.dll. |
CR105516 |
In WebLogic Server 6.1 SP04, stateful session EJB failover did not work when multiple failovers were required In a three node cluster a JSP creates or calls a replica-aware stateful session EJB. The remote EJB stub is stored in the http session. After each call to the stateful session EJB the updated EJB stub is also updated in the http session to reflect any changes for the EJB replica list (primary/secondary). The following call sequence with the same browser window leads to a java.rmi.ConnectException when only one node of the cluster survives: 1. All three cluster nodes are running. 2. Making a call to node1, create EJB and store remote in http session (http session replication is enabled) 3. Kill node1 4. Make a call to the secondary node2, the EJB remote is retrieved from the replicated http session and the call to the EJB works fine. After this EJB call again the remote is stored in the http session. 5. Kill node2 6. Make a call to node3, get the EJB remote from http session. WebLogic Server tries to lookup the EJB on node2 and does not try to use node3 (this should now be the new secondary?). The following exception is thrown on node3: java.rmi.ConnectException: Could not establish a connection with -3088833905169218734S:172.23.64.38:[7001,7001,7002,7002,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination The problem was solved with a code fix. |
CR105814 |
In WebLogic Server 6.1 SP04, a customer saw close_waits running under AIX. Analysis revealed that when WebLogic Serve 6.0 clients connected to a WebLogic Server 6.1 instance, WebLogic Server leaked sockets. This occurred when WebLogic Server attempted to close the MuxableSocket via the muxer without registering the socket with the muxer—the socket was rejected after being claimed by t3, before it could be registered with the muxer. The problem was corrected with a code fix. |
CR106957 |
In WebLogic Server 6.1 SP04, running with IBM's MQWorkflow on AIX 5.2., invocation of an MQWorkflow Java API by a servlet in WebLogic Server resulted in an error in MQWorkflow. The problem was not exhibited under Window, if Native IO (Performance Pack) was disabled, or if the libmuxer.so library was removed from the classpath. Analysis revealed that WebLogic Server did not set the "language code", an encoding parameter, to "en-us" as it should, but to "c". The problem was corrected with a code fix. |
CR107598 |
In WebLogic Server 6.1 SP03 and SP04, restart of the Administration Server resulted in this error: java.rmi.ConnectException: This RJVM has already been shutdown The problem was reproduced consistently when beforing these steps:
The following error resulted: <Feb 5, 2003 7:03:27 PM PST> <Info> <J2EE> <Undeployed: ejb_basic_statelessSession> java.rmi.ConnectException: This RJVM has already been shutdown -7152222714009328 37S:172.17.25.250:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver |
CR109339 |
In WebLogic Server 6.1 SP05, a security exception initializing kernel in applets. A code fix solved the problem. |
CR109590 |
In WebLogic Server 6.1 SP04, running with AIX, a method call made over IIOP to a remote object hung. The customer has a server (non-WebLogic Server) hosting remote objects. An EJB running on WebLogic Server calls a remote object on the non-WebLogic Server over IIOP. The method call hung indefinitely. The method call was simple—it returns a boolean type. The thread dump showed: "ExecuteThread: '11' for queue: 'default'" (TID:0x300C12A8, sys_thread_t:0x35649A58, state:CW, native ID:0x1011) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at weblogic.iiop.SequencedRequestMessage.waitForData(SequencedRequestMessage.java:24) at weblogic.iiop.EndPointImpl.sendReceive(EndPointImpl.java:641) at weblogic.iiop.OutboundRequestImpl.sendReceive(OutboundRequestImpl.java:43) at weblogic.iiop.IIOPRemoteRef.invokeInternal(IIOPRemoteRef.java:128) at weblogic.iiop.IIOPRemoteRef.invoke(IIOPRemoteRef.java:90) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy70.isRunning(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at weblogic.iiop.IIOPInvocationHandlerImpl.invoke(IIOPInvocationHandlerImpl.java:285) at $Proxy71.isRunning(Unknown Source) at... Analysis revealed a classloader problem. A code fix resolved the problem. |
CR110347 |
In WebLogic Server 6.1 SP05 a lookup on context (and assigning to object) throws IllegalArgumentException if EJB stubs is not in classpath The problem occurred with a stateful session EJB (examples.ejb20.basic.statefulSession, shipped with WebLogic Server) deployed to a single WebLogic Server server. A JDNI lookup was performed on the EJB home object and the returned value was assigned to the class object. The client classpath contained weblogic.jar and no client classes. This code was used to perform the lookup on the context. Context ctx = new InitialContext(ht); Object objref = ctx.lookup("ejb20-statefulSession-TraderHome"); The lookup succeeded for latter succeeds for WebLogic Server 6.1 SP03 but failed on WebLogic Server 6.1 SP05. The exception was: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: interface examples.ejb20.basic.statefulSession. TraderHome was not visible from the class loader With verbose classloading set for the JVM, it was found that the examples.ejb20.basic.statefulSession.TraderHome class was successfully loaded by the In WebLogic Server 6.1 SP03, although it was not in the classpath. With In WebLogic Server 6.1 SP05, the failure occurred when attempting to load that class. The problem was solved by a code change to ensure the ClientRuntimeDescriptor uses the current classloader, if it is a GenericClassLoader. |
CR110892 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp. |
CR116712 |
In WebLogic Server 6.1 SP04, the WLECConnectionRuntime MBeans were not updated when an INVOKE was issued on WLECConnectionPoolRuntime using Admin tool. Analysis revealed that when resetConnectionPool() was invoked on the WLECConnectionPoolRuntime MBean, the pool was not reset. Old connections were not removed The problem was solved with a code change. Now, the mbeans that correspond to old connections are unregistered before the resetConnectionPool() invocation. |
CR117200 |
In WebLogic Server 6.1 SP05, a deadlock in weblogic.socket.PosixSocketMuxer was detected when a Managed Server could note connect to the Administration Server. This is an extract from the thread dump: 1wasLKDEADLOCK Deadlock detected!!! The following exception is also thrown: java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@2a7512ad - id: '8419466038107054512S:10.32.197.52:[7001,7001,-1,-1,7001,-1,-1]:bossapp:AdminServer' connect time: 'Fri. Aug 01 09:43:07 CST 2003'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java(Compiled Code)) at... Analysis revealed that PosixSocketMuxer hit the deadlock due to contention for the FDRecord and ConnectionManager locks. One thread holds the FDRecord lock and waits for a ConnectionManager lock, which is held by another thread which is waiting for the FDRecord lock to do a cleanup. A code fix removed the contention. Now, the FDRecord lock is not held during dispatch. |
CR122280 |
For context-wide sessions, WebLogic Server did not check if an object was Serializable before placing it in the session. This could lead to the error: Could not deserialize context attribute The code was modified so that setAttribute() checks for a serializable object before adding it to the session. |
CR123571 |
When starting several T3 clients on the same machine simultaneously, there was a possibility that two or more of the clients could obtain the same JVMID, cause exceptions or hanging on the clients. The problem occurred only when starting multiple T3 clients on the same machine at the same time. This problem was solved by modifying the code used to generate JVMIDs. |
CR124763 |
Prior to WebLogic Serve Service Pack 6, all server instances in a cluster used the server listen port as the multicast port for cluster communication. There was no way for a cluster to use a multicast port different from the server listen port. This Service Pack introduces a new, optional Java property, -Dweblogic.cluster.multicastport=port_number, to specify the multicast port used in a cluster. To use the new property, all cluster members must specify the same -Dweblogic.cluster.multicastport value in their startup scripts. If the -Dweblogic.cluster.multicastport is not specified at startup time, servers continue to use the listen port as the multicast port for cluster communication. |
Deployment
EJB
JDBC
jDriver
JMS
JNDI
JSP
JTA
Node Manager
Change Request Number |
Description |
---|---|
CR104285 |
Node Manager's shared object code could cause a segment violation if certain code paths were taken while starting a server instance. The same code paths also failed when using IBM's zLinux JDK. These problems were solved with a code fix to Node Manager. |
CR125829 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. |
OA&M (Operations, Administration, and Management)
Plug-ins
Change Request Number |
Description |
---|---|
CR087204 |
[Apache] In WebLogic Server 6.1 SP03, PathTrim and PathPrepend added unexpected "/" at the end of URL. After PathTrim was applied to the original URL and it results to '/', an extra '/' was appended to the PathPrepend variable. This problem was solved with a code fix. |
CR091910 |
[Apache] In WebLogic Server 6.1 SP03, the Apache plugin did not read PathPrepend when using <IfModule mod_weblogic.c>. The problem occurred with plugins for Apache 1.3.x and Apache 2.0.43. The problem was solved with a code fix. |
CR092970 |
[Apache] In WebLogic Server 6.1 SP04, the Apache plugin caused sockets to remain in the CLOSE_WAIT state. Analysis revealed that WebLogic Server did not close the socket when returning a sendRedirect. The problem was solved with a code fix. |
CR092327 |
[Apache] In WebLogic Server 6.1 SP04, setting the WLLogFile did not work when VirtualHosts were used. The log file defaulted to /tmp/wlproxy.log |
CR100070, CR107200 |
[Apache] When two virtual hosts are used in Apache server, each virtual host has defined its own WLLogFile. The value of this parameter keeps changing among two WLLogFile values defined for two virtual hosts. There were two problems: one, WebLogic Server was only setting WLLogFile once upon server startup; two, WebLogic Server set it before getting it from VirtualHost. Setting WLLogFile for each virtual host in the Apache plugin fixed the problems. |
CR100601, CR105658, CR108747 |
(NSAPI) The plug-in that shipped with WebLogic Server 6.1 Service Pack 3 used the WL-Proxy-Client-IP header to send client IP addresses. This caused problems in heterogeneous environments, because earlier servers expected the plug-in to use the X-Forwarded-For and Proxy-Client-IP headers to transmit client IP addresses. The code was fixed to include both the X-Forwarded-For and Proxy-Client-IP headers, as well as WL-Proxy-Client-IP, so that heterogeneous environments can retrieve client addresses without modification. |
CR101937 |
(NSAPI) If an HTTP request contained an expect-continue header, the plug-in would send a 100 (Continue) response even if the plug-in's client used HTTP/1.0. The code was fixed to comply with the HTTP/1.1 specification—the plug-in does not respond with a 100 (Continue) status if the client uses HTTP/1.0 or earlier (or if there was no expect-continue header in the request). |
CR102616 |
(NSAPI, Apache) The plug-in now supports dynamic DNS lookups on a DNS name when the name returns a list of IP addresses from the DNS server and the plug-in is configured with WebLogicHost = 'DNS name'. |
CR105123 |
(ISAPI) In all versions of WebLogic Server, DefaultFileName does not work if iisforward.dll is not used. The problem is exhibited when:
On a request for a directory that has no filename, the DefaultFileName is not used. The problem was corrected with a code fix. |
CR105173 |
(WLS-NSAPI) In WebLogic Server 6.1 SP04, when a client stopped a response from being sent to it (for example, closing the browser before the response is completely received), a 500 [WRITE TOCLIENT ERROR] is logged in the webserver logs. This is unacceptable to our client who uses a webserver health monitoring tool to determine his server's health and this issue typically comes up when a request - > response takes a fair amount of time. The webserver health monitoring tools use a 500 error to indicate that something is wrong with the server's health and that since this is not a server health issue but the client terminating the response, the error if any should not be 500. Request response path is as follows: client -> proxyWebserver->plugin->wls and the expected response path is client <- proxyWebserver<-plugin<-wls However, after the Weblogic server has successfully sent the response, but the webserver has not completely sent it to the client, the client aborts the communication and a 500 error is logged in the webserver's access.log which normally indicates that something is wrong with the server. The Customer is of the opinion that a different error or none at all should be logged for such a situation A code change was implemented so that 500 errors are not generated if the client breaks the connection. |
CR106764 |
(NSAPI) A thread in the plug-in could obtain a critical lock for a long duration (5 minutes by default, or configured using WLIOTimeoutSecs), blocking all other threads and making WebLogic Server appear to hang. This problem was fixed with a code change to the plug-in. |
CR107254 |
(Apache) Because Hewlett-Packard ceased to support the HP Apache-based Web Server version 1.3.x, WebLogic Server removed the Apache 1.3 plug-in for HP. |
CR108092 |
(ISAPI) In WebLogic Server 6.1 Service Pack 4, the ISAPI plugin logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line: The HTTP Server encountered an unhandled exception while processing the ISAPI Application. This problem was solved with a code fix to the ISAPI plugin. |
CR109755 |
[Apache] The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (*/?). This could cause 404 errors to occur when using parameters such as: LocationMatch "/weblogic/(abc|def)/ghi" This problem was solved with a code fix. |
CR110664 |
(NSAPI) The plug-in code failed to catch an exception, which in turn caused iPlanet server to crash during the sendResponse phase. The plug-in code was changed to catch the exception. |
CR111167 |
(ISAPI) In WebLogic Server 6.1 Service Pack 2, using the ISAPI plugin resulted in HTTP responses having two Date headers: one inserted by WebLogic Server and one inserted by IIS. This duplication of Date headers caused problems with certain caching services that expected a single Date header. The problem was solved by updating the ISAPI plugin to filter out the Date header inserted by WebLogic Server. |
CR113033 |
(ISAPI) In WebLogic Server 6.1 Service Pack 4, the plug-in did not recognize the WLTempDir flag for the _wl_proxy folder. The code was fixed to use the flag. |
CR113093 |
[Apache] When using multiple MatchExpression parameters in httpd.conf to route requests to different locations, as in: MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001 Each request overwrote the same global parameter info, which caused requests to go to the wrong location. In the above example, this problem resulted in *.jsp requests going to the server at port 8003. The code was fixed to ensure that each request uses its own copy of the parameter information. |
CR121341 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp. |
CR121688 |
(Apache) The plug-in failed to parse a cookie if the exclamation character, "!", was replaced by "%21" in a URL This replacement is commonly done by WAP gateways when using URL rewriting. The code was fixed to correctly parse the characters in the URL. |
CR121943 |
[Apache] The plug-in did not parse cookies when "%1" is replaced with "%21" in the URL. This replacement occurred when using a WAP gateway and URL rewriting. The problem was solved with a code fix. |
CR122207 |
(NSAPI) If KeepAliveEnabled and DynamicServerList were both enabled, the plug-in could leave sockets in a CLOSE_WAIT state. This problem was solved with a code fix. |
CR122754 |
(ISAPI) In WebLogic Server Service Pack 4, the plug-in parameter WLExludeByPathOrMimeType did not work when forwarding by mime type. This problem was solved with a code fix. |
CR122755 |
(ISAPI) In WebLogic Server Service Pack 4, the plug-in filter was bypassed if ".wlforward" was manually appended to a URL. The code was modified to throw a 404 error if the initial request has a mime type of .wlforward. |
CR123120, CR123775 |
(Apache, NSAPI) If the POST method was used through the plug-in and the Content-Length was not defined, the proxy log file would contain message such as: POST and PUT requests *must* contain a Content-Length The code was modified to set a content length of zero (0) if Content-Length is undefined. |
CR123925 |
(ISAPI) The plug-in would sometimes respond to the browser with a 500 error message. This problem had three additional symptoms:
This problem was solved with a code fix. |
CR124433 |
(ISAPI) If IIS was configured with WlForwardPath=/, the plug-in would try forward requests even if the server was down. The error page was never served to clients. The plug-in was modified to properly exclude paths in this situation. |
CR124464 |
(NSAPI) A memory leak was detected that could cause the plug-in to crash. The problem occurred because the plug-in accessed an exception object after the object had been deleted. The code was fixed to retrieve the exception code from the exception object and then delete the object, which prevents the memory leak from occurring. |
CR125545 |
(NSAPI) When a client stopped a response from being sent to it (for example, by closing the browser before the response had completed), the plug-in wrote a 500 [WRITE TO CLIENT ERROR] to the Web server log file. This could cause problems with health monitoring tools that interpret the 500 error as a problem in the Web server. This problem was solved with a code fix. |
CR125690 |
(ISAPI) In a configuration that included nine IIS servers and nine clustered WebLogic Server instances, IIS crashed every a few hours, writing an Event 37 to the event log. The wlproxy log contained this message: Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .\iisproxy.cpp Diagnosis revealed that the Reader::fill() method was not allocating enough memory while growing the initial buffer. 4 bytes to mark the end of buffer were getting lost and which resulted in the core dump. The problem was solved with a code fix. |
CR126103 |
(NSAPI) During load testing, when NSAPI running on HP11.00 proxying to a 6 node cluster on 2 Solaris boxes (3 WebLogic Server instances on each), memory consumption steadily increased, and after approximately 50 minutes, the ns-httpd process crashed. The same load test did not crash on HP11.00 or Solaris. Analysis revealed that codes in proxy.cpp used strdup(), a native system call. strdup() allocates system memory to the program's heap space. WebLogic Server uses Iplanet's FREE macro to free previous allotted space when it is no longer needed. Because FREE does not free the allocated space by strdup() call, the memory leak occurred. The problem was solved by replacing all native strdup()system calls in proxy.cpp with Iplanet's STRDUP macro so the FREE macro knows what to free. |
CR126568 |
(NSAPI) Plugin does not handle %0A in the post request gracefully A POST request %0A at the end sent to WebLogic Server through the NSAPI plug-in was not handled gracefully. The request added extraneous data into the body stream, and headers appeared at the end of the body. Requests sent directly to WebLogic Server were processed correctly it works fine. Customer needs a plugin which can handle %0A at the end gracefully. The problem was corrected by code change to the plug-in to detect and handle HTTP/0.9 responses correctly. |
CR126982 |
(NSAPI) When WLExcludePathOrMimeType was set, the file types were cut in the request to WebLogic Server, but iplanet failed to serve those files instead. For example, this request for a .jsp that contained a .jpg was made: <Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object> The request for the .jsp was proxied to WebLogic Server, and the .jsp was displayed without the .jpg. Iplanet failed to server the jpg.The iplanet access log contained this message: 10.40.4.117 - - [28/Oct/2003:11:45:34 -0500] "GET /weblogic/images/logo_tm_onwt.jpg HTTP/1.1" 500 305 I get the following in wlproxy.log: Tue Oct 28 11:45:35 2003 ============================= new request =============================== Tue Oct 28 11:45:35 2003 INFO: SSL is not configured Tue Oct 28 11:45:35 2003 URI=[/hello.jsp] Tue Oct 28 11:45:35 2003 attempt #0 out of a max of 5 Tue Oct 28 11:45:35 2003 general list: trying connect to '10.40.4.117'/7001/7001 at line 1224 for '/hello.jsp' Tue Oct 28 11:45:35 2003 INFO: New NON-SSL URL Tue Oct 28 11:45:35 2003 Going to check the general server list Tue Oct 28 11:45:35 2003 WLS info : 10.40.4.117:7001 recycled? 0 Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept]=[*/*] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-language]=[en-us] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-encoding]=[gzip, deflate] Tue Oct 28 11:45:35 2003 Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)] WLExcludePathOrMimeType should cause WebLogic Server to not service the request, and to pass control to the web server, allowing it to continue processing the request. The problem was solved with a code change. |
RMI
RMI/IIOP
Security
Change Request Number |
Description |
---|---|
CR067670 |
If you configured WebLogic Server to use a custom security realm, and the realm was unavailable, WebLogic Server would not boot. This Service Pack introduces a new startup command, -Dweblogic.security.RealmFailureOk=true, that allows the server to start if the realm is unavailable. The command forces the server to start using the file realm, rather than the configured custom realm. This command is available only for WebLogic Server 6.x, and is not implemented in other server versions. Warning: Administrators must be cautious when using this command. If you have a custom realm that is configured only for authorization (not authentication) and the user store is the file realm, booting the server with -Dweblogic.security.RealmFailureOk=true may result in having no security. Use this option only to access the Administration Console and reconfigure the custom realm so that the server can boot normally. Do not allow applications to access the server you have booted with -Dweblogic.security.RealmFailureOk=true. |
CR093292 |
When the CR093292 patch was applied to WebLogic Server Service Pack 5, the server began logging messages such as: java.io.IOException: Length is Zero These messages were intended only for debugging purposes. The code was fixed so that the messages are no longer logged. |
CR093813 |
The password used to access the encrypted private key in the Node Manager key file, weblogic.nodemanager.keyPassword, was in plain text and accessible. The problem was resolved by the creation of the Node Manager properties file, nodemanager.properties. |
CR100703 |
Authenticated users could become unable to access WebLogic Server 6.1 SP04 after another user had been locked out. This problem could occur with Novell eDirectory. After a user had entered an incorrect password enough times to become locked out, other, authenticated users would become unable to access the server, receiving a 500 error similar to: <[WebAppServletContext(7814505,security,/security)] Servlet failed with Exception netscape.ldap.LDAPException: error result (53); NDS error: login lockout (-197); DSA is unwilling to perform [...] The problem was fixed in WebLogic Server by catching the LDAPException thrown in this case, and destroying the connection to the LDAP server. |
CR102452 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp. |
CR102712 |
Java clients that used HTTPS tunneling to access EJBs experienced poor performance and increased socket usage, as compared to clients that used HTTP tunneling. WebLogic Server created a new socket, rather than reusing sockets, for each request. This problem was solved with a code fix. |
CR105443 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp. |
CR105513 |
This Service Pack includes a new property, weblogic.security.SSL.trustManager, that you can use to specify the custom trust manager if you are using HttpsURLConnection to connect to another server. Using this property enables you to obtain the CA root in the SSL handshake for business logic purposes. Warning: This feature is implemented only in WebLogic Server 6.1, and it will not be made available in WebLogic Server 7.x or later releases. |
CR108265 |
In WebLogic Server 6.1 SP04, HTTP requests occasionally failed when CachingRealm.refresh() was called. This servlet synchronizes the cache and the database. The cluster used the RDBMS Realm as the Basic Realm. A simple health check HTTP request calling index.html of an Web application occasionally failed with this exception. <Error> <HTTP> <hanptl02> <managedServer2> <ExecuteThread: '9' for queue: '__weblogic_admin_rmi_queue'> <> <> <101020> <[WebAppServletContext(1014083,healthcheck02,/healthcheck02)] T_[ubgÍ Exception Éæè_¸"sµÜµ½_B> java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.security.acl.GroupImpl.addMember(GroupImpl.java:46) at weblogic.security.acl.OwnerImpl.<init>(OwnerImpl.java:32) at weblogic.security.acl.AclImpl.<init>(AclImpl.java:164) at weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.java:358) Analysis revealed that two threads were accessing the CachingRealm simultaneously; for example, the refresh servlet has cleared the cache, but the request to the index.jsp is attempting to find a user that has been cleared from the cache. The problem was solved with a code fix. |
CR111041 |
When a Web Application attempted to make an HTTPS connection and the handshake with the remote server stalled, WebLogic Server never timed out the associated SSL socket. This resulted in execute threads becoming "stuck" indefinitely, eventually locking the server. The code was fixed to ensure that timeout values are enforced with HTTPS connections. |
CR112563 |
WebLogic Server did not encrypt the private key password when storing the password to a file. The code was fixed to automatically encrypt the password when writing the password back to a file. Upon the first booting, WebLogic Server checks to verify that the password is encrypted, and encrypts it in the file if necessary. WebLogic Server uses the encryption service associated with the domain. This means that you can use the password file only with the domain in which it was created. Note: Secure a plain text copy of the private key password before you allow WebLogic Server to write the password to a file. You will not be able to retrieve the plain text password from the file after booting the server at this Service Pack level. |
CR113459 |
In WebLogic Server 6.1 SP05, with CR093813_61sp5.jar, removing the Node Manager properties file caused problems. The Node Manager properties file is always created in the <saved logs dir>/NodeManagerInternal directory. This customer periodically archives and deletes the contents of NodeManagerInternal. This removes the Node Manager properties file, so that the certificate password stored in the Node Manager properties file cannot be decrypted, and Node Manager will not work correctly. The problem was solved by a code change to create the Node Manager properties file in the directory specified by user.dir, if the file is not found in NodeManagerInternal, or in the user.dir directory. |
CR120850 |
In WebLogic Server 6.1 SP05, weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. The problem was exhibited in this scenario: client <--> Proxy <---> Server The client can be running within WebLogic Server or be a stand-alone Java program Requests always went through the proxy even if the targeted host was specified in https.nonProxyHosts. If instead, the host is specified in http.nonProxyHosts, the problem does not occur: a direct connection to the host, not to the proxyHost is established, not to the proxyHost, if defined. Analysis revealed that logic for connecting directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. This problem did not exist for http.nonProxyHosts, only with https.nonProxyHosts. Appropriate logic was developed to connected directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. |
CR121206 |
In WebLogic Server 6.1 SP05, the number of open LDAP connections kept increasing when using an external LDAP server. The problem was solved with a code fix. |
CR121920 |
In WebLogic Server 6.1 Service Pack 3, calling Socket.getSendBufferSize() when using WebLogic Server JSSE caused the following error: java.net.SocketException: Socket closed The code was fixed to properly override and delegate getSendBufferSize(). |
CR121921 |
The LDAPDelegate.groupContainsInternal() method performed a recursive search of the list of groups without first checking if the list contained the desired group. This performance problem was fixed by updating groupContainsInternal() to first iterate through the group list to determine if it contains the desired group. |
Servlets
Change Request Number |
Description |
---|---|
CR080998 |
Versions of WebLogic Server 6.1 earlier that SP06 did not support the Range header field definition as described in section 14.35 of the HTTP/1.1 specification. This problem was solved with a code fix. |
CR084455 |
When WebLogic Server 6.1 SP03 was configured to log all HTTP requests in extended format, at the rotation time, the following error is thrown at approximately one minute intervals after the rotation is scheduled (which is the log flush time interval setting): ####<Aug 20, 2002 9:00:00 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '6' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file> java.io.IOException: Failed to rename log file on attempt to rotate logs at weblogic.servlet.logging.LogManagerHttp.rotateLog(LogManagerHttp.java:168) at weblogic.servlet.logging.LogManagerHttp.access$2(LogManagerHttp.java:148) at weblogic.servlet.logging.LogManagerHttp$RotateLogTrigger.trigger(LogManagerHttp.java:432) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:69) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) ####<Aug 20, 2002 9:00:05 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '7' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file>... Analysis revealed that the log had been flushed inappropriately. The problem was solved with a code change to ensure that the log is not flushed on rotation, and to check for a null value for the log file name. |
CR086234 |
The indexDirectories feature of FileServlet was not internationalized, and therefore could not list or use multi-byte file names. This problem was solved with a code fix. |
CR088785 |
In HTTP access logs, WebLogic Server recorded only the stem portion of the URI, rather than both the stem and query portions, when the cs-uri field was specified. This problem was solved with a code fix. |
CR092625 |
WebLogic Server threw a NullPointerException when you enabled HTTP logging on a Managed Server that was booted with HTTP logging disabled and had no existing log file. On each HTTP access to the Managed Server, the following exception was thrown: java.lang.NullPointerException The problem was solved with a code fix. |
CR095945 |
In WebLogic Server 6.1 SP05 running under Unix, CGIServlet, which extracts the cgiscripts in a WAR so that it can execute them, was calling the scripts without setting the current working directory. A fix was implemented to ensure that the current working directory is set so that cgi scripts can call subscripts, even in WAR webapps. |
CR095981 |
In WebLogic Server 6.1 SP01, SP02, SP03, and SP04, <charset-mapping> in weblogic.xml is ignored when compiling JSP file with precompile=true. As a result, some of double bytes characters are garbled because of the mismatch between the character's encoding specified in <charset-mapping> and in the compiled classes. Analysis revealed an error in the precompiler. The problem was solved with a code fix. |
CR096459 |
When invoking a flush in a Servlet or JSP in HTTP 1.0, WebLogic Server sometimes failed to close the socket, causing the client to wait for a period of time until the socket timed out. The problem was solved with a code fix. |
CR100590 |
An update to the HttpClusterServlet implementation changed the default SSL port number in the WebLogicCluster parameter to 443. The updated implementation also failed to report an error when the WebLogicCluster parameter was not specified correctly. A code fix was made to ensure that the HttpClusterServlet implementation matched the earlier behavior: |
CR100645 |
Objects that implement the HttpSessionAttributeListener interface did not receive the correct value when calling HttpSessionBindingEvent.getValue() on events received via attributeReplaced(). Instead of returning the old attribute value, as stated in the Servlet 2.3 specification, getValue() returned the newer value. The problem was solved with a code fix. |
CR101061 |
Prior to this Service Pack, a call to weblogic.version did not show the correct version information if a patch had been applied to the WebLogic Server instance. The code was modified so that weblogic.version now shows the correct version and patch information in the format: WebLogic Server version date build with patch [, patch] [...] For example: WebLogic Server 8.1 03/20/2003 246620 with CRXXXX, CRXXXX, CRXXXXX |
CR101838 |
In WebLogic Server SP04, there was a change in the behavior of the CGIServlet that could affect the execution of CGI scripts having no filename extension. For example, if a web.xml file defined the CGI directory and Servlet mapping in the following way: <param-name>cgiDir</param-name> and stored a script named myscript in the /home/user/cgi-bin directory, a URL such as http://localhost/mywebapp/cgi-bin/myscript would map to /home/user/cgi-bin without specifying the script name. (This problem did not occur with scripts having an extension, such as myscript.ksh). The code was fixed to make the behavior match earlier releases of CGIServlet. Using the above example, the code fix ensures that the URL http://localhost/mywebapp/cgi-bin/myscript maps to /home/user/cgi-bin/myscript. |
CR102262 |
After parsing an HTTP request containing a null HTTP-Version field, WebLogic Server would throw the following exception: java.lang.NullPointerException The code was fixed to use HTTP/0.9 as the default version when none is specified in the request. |
CR102574 |
Forcibly shutting down a client to a servlet caused increased memory usage in WebLogic Server, potentially leading to an OutOfMemoryError. The problem was solved with a code fix. |
CR102689 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp. |
CR102769 |
When logging HTTP transactions using extended log format, WebLogic Server did not record query parameters (cs-uri-query) for requests made from one Servlet or JSP to another. Also, WebLogic Server recorded the URI (cs-uri-stem) of the forwarded request, rather than the original request URI from the client. The code was fixed to ensure that the URI and query string of the original request are recorded in access.log when logging forwarded HTTP transactions. |
CR103059 |
A <url-pattern> value with a single character in a <servlet-mapping> element was not honored in a web.xml deployment descriptor. For example, <url-pattern>*.f</url-pattern> produced a 404 File Not Found error when attempting to access welcome.f, but <url-pattern>*.oop</url-pattern> worked properly when attempting to access welcome.oop. This problem has been resolved so that single character <url-patterns> now work as expected. |
CR103256 |
A code change resulted in performance improvement in JDBC regarding bubble caches in JDBCSessionContext and JDBCSessionData. |
CR103289 |
The HttpClusterServlet was not correctly parsing the session id from post data. If you sent a request through HttpClusterServlet to a cluster, establishing a session, and then sent a second request without a cookie but with the session id in the post parameters, the servlet did not recognize the session. The servlet is now able to extract the session id from the post data. |
CR103339 |
Servlet output capitalized the Transfer-Encode value, Chunked, instead of using lowercase chunked as required by the HTTP/1.1 specification. The code was fixed to ensure that Servlets use the Transfer-Encode type of "chunked" in lowercase. |
CR103925 |
The setAttribute method only checked for hashCode equality. It now also checks the result of the equals method for the old and new objects. |
CR104975 |
If a log rotation failed, WebLogic Server failed to reopen the log file. When this occurred, the trigger to flush the log file could throw a java.io.IOException: Bad file descriptor. The problem was solved with a code fix. |
CR105016 |
HttpClusterServlet failed to increase its failure count if a WebLogic Server in the cluster was hung. This caused HttpClusterServlet to go into an infinite loop if each server in a cluster slept for a time longer than HungServerRecoverSeconds, or if 2 out of 3 servers in a cluster slept longer than HungServerRecoverSeconds. The code was fixed to ensure that the failure count is properly incremented. |
CR105339 |
In Service Pack 5, WebLogic Server did not create variable definitions for tag calls that used the TagExtraInfo class. The code was fixed to ensure that the variable definitions are again created (as they were in Service Pack 4 and earlier). |
CR106186 |
If you set the buffer size to zero in a servlet, it would fail to respond and would initiate an infinite loop in the server. WebLogic Server would ultimately display a warning similar to: "Suspend Checker Thread" prio=10 tid=0x23eb90 nid=0xfec runnable This problem was solved with a code fix. |
CR107419 |
JSP code that intended to set double byte characters as a parameter's value—for example: <jsp:include page="included.jsp"> —resulted in specified double byte characters being changed to their URL-encoded code. This problem has been resolved. |
CR108607 |
WebLogic Server produced errors when applications used XSL with the FOP output method to get an image from an archive file. This problem did not occur for applications deployed in exploded format. This problem was solved with a code fix. |
CR108350 |
The Administration Console incorrectly indicated that the log file format could be dynamically changed between Common Log Format (CLF) and Extended Log Format (ELF), when such a change actually requires a server reboot. The code was changed to properly indicate the required server reboot when changing this configuration parameter. |
CR109958 |
When processing requests through a proxy servlet, WebLogic Server only honored the SecureProxy setting for incoming requests that used HTTPS. If the incoming request used HTTP, WebLogic Server did not use an HTTPS connection even when SecureProxy was enabled in the proxy servlet. This problem was solved with a code fix. |
CR110798 |
Calling weblogic.servlet.security.ServletAuthentication.killCookie(req) in a JSP caused the session to remain in WebLogic Server without ever being cleaned up. The code was fixed to ensure that the session is invalidated just before killCookie(req) completes. |
CR110914 |
If TrackingEnabled was set to false, WebLogic Server created a new session for each request, but the sessions were not getting invalidated. The code was modified to invalidate a session immediately if TrackingEnabled is set to false. This is the correct behavior. |
CR111752 |
Under certain conditions, WebLogic Server threw a NullPointerException when using CGIServlet with the useByteStream parameter set to true. The problem occurred when using framesets where one frame contained static URL links and another frame used CGIServlet. If a user selected the frame containing static links before the other frame completed downloading a page, an IO exception was caught and presented to the user as: java.lang.NullPointerException This problem was solved with a code fix. |
CR112799 |
WebLogic Server attempted to write to an output stream even after an IOException occurred. This led to 100% CPU utilization if an unexpected socket disconnection occurred with a Web Application that did not handle IOException. org.apache.xml.serialize.XMLSerializer ignores IOException until the end of its process. This caused the problem to occur if an IOException was thrown in the middle of returning XML documents as part of an HTTP response. The code was modified to ensure that writes to an output stream stop after an IOException occurs. |
CR120440 |
When multiple Web Applications were deployed in a Single Sign-On configuration and one application called weblogic.servlet.security.ServletAuthentication.invalidateAll(request), the HttpSessionListeners in the other applications were not invoked until their session timeouts occurred. This happened because only the session associated with the first Web Applications was registered for invalidation; after the user was authenticated, subsequent sessions were not registered. The code was fixed to ensure that both the session ID and context path of all Web Applications are registered for invalidation as necessary by invalidateAll(request). |
CR122177 |
The fix for CR060023 in Service Pack 3 caused the FileServlet to return a response code of 200 instead of 404 when a file is not found. The code was fixed to return 404 for when a file is not found. |
CR121846 |
In WebLogic Server Service Pack 3, it was possible for the server to write standard log entries to a log file before the writing Extended Log Format headers. This situation could occur during a log rotation when multiple threads attempted to write to the new log file at the same time. The code was fixed to ensure that the thread handling the log rotation has exclusive access to the new log file until after the log headers are written. |
CR125718 |
WebLogic Server Service Pack 5 could throw a NullPointerException when used with Apache and Netegrity's SiteMinder. An initial request forwarded through Apache to SiteMinder, and authenticated by SiteMinder, would also be successfully authenticated by WebLogic Server. However, if the user used the browser's Back button to return to the login page and authenticated again using a different username and password, WebLogic Server threw a NullPointerException: java.lang.NullPointerException This problem was solved with a code fix. |
SNMP
Web Services
WTC-ATMI
XML
WebLogic Server 6.1 Service Pack 5 Solutions
The following sections describe problems resolved in WebLogic Server 6.1 Service Pack 5.
Cluster
Change Request Number |
Description |
CR082443 |
In an environment with multiple clusters using the same multicast address, large log files resulted, causing overly frequent file rollover. The debug messages are similar to: ####<Jul 23, 2002 4:06:26 PM EDT> <Debug> <Cluster> <ustrntda01> <wts-cluster_test> <ExecuteThread: '9' for queue: 'default'> <> <> <000000> <dropped fragment from foreign domain/cluster domainhash=95475927 clusterhash=-1674453961> The problem occurred because, in weblogic.cluster.ClusterDebug.java, the flag controlling whether or not debug messages are logged was set to true. The problem was solved with a code fix. |
CR087240 |
HTTP session failover resulted in a ClassCastException, when the Managed Server hosting the session was shut down. Failover was successful when error message was ignored. This problem was reliably reproduced in this configuration: 1) Two clustered server instances, running 6.1 SP02. 2) Cluster hosted a WLP 4.0 sSP002 portal application. 3) One IPlanet web server with WebLogic Server plug-in pointing to the two-node cluster. The problem was not consistently reproducible in other configurations. This problem was associated with a problem in the WebLogic Server shutdown sequence. This problem was resolved by a new service to shutdown RMIServerService. |
CR092146 |
Failover did not work for a stateful session bean in a cluster. The request URL contained the local server name instead of the cluster DNS name. The following exception occurs: java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statefullCluster' on server: 't3://172.23.135.83:7600 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java:80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:204) at com.bea.cluster.testClusterEJBServlet.doGet(testClusterEJBServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2359) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) Problem was solved by modifying the getURL() method in weblogic.ejb20.internal.BaseEJBHome.java to provide the cluster address as the host portion for the URL. |
CR093809 |
A stack trace resulted from a error looking up a session. A secondary server instance was being shutdown. While making a log entry for a request it served, the HTTP server tried to get the user information from the session. As a result it tried to look up the secondary server even though it was down, resulting in this stack trace. <Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking up session for id:2LcR6Ool2IC5qNtFZhThJClYVYEXt9KWG2ciXmAXZ4XiBAHPiHx4!-1379505194!stcasfi01b.usa-ed.net!8001!7002!-1127797657!stcasfi02b.usa-ed.net!8001!7002 java.rmi.ConnectIOException: Server is being shut down Start server side stack trace: java.rmi.ConnectIOException: Server is being shut down at weblogic.rjvm.RJVMImpl.dispatchRequest(RJVMImpl.java:692) at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:666) at... The primary server correctly selected a new secondary from the available server list, and no session data was lost. This problem was resolved with a code fix. Now, the server obtains user information from ThreadLocal, instead of the session. |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp. |
|
CR101609 |
In WebLogic Server 6.1 SP04, session replication stopped working after a failure to replicate a non-serialized object. Invocation of a JSP that tried to set non-serialized data into the session object, resulted in the expected exception: <Mar 19, 2003 2:58:23 PM PST> <Error> <Cluster> <All session objects should be serializable to replicate. Please check the objects in your session. Failed to replicate non serializable object> Then, for all subsequent requests, sessions were not replicated, and this exception occurred: <Mar 19, 2003 2:58:48 PM PST> <Debug> <Cluster> <Unable to create secondary for -8956818414963087828> The problem was solved with a code change. Now, when a non-serializable object is encountered, the method returns, instead of trying other secondaries. |
CR102655 |
Duplicate of CR101609. See above. |
Connector
Console
Change Request Number |
Description |
CR062102 |
A customer with large application (40 MB) migrating from 6.1 SP01 experienced network overload and slow WebLogic Server startup, as a result of WebLogic Server copying the application to Managed Servers at startup. A code change was made to address this problem. Now, unchanged applications are not copying to Managed Servers at startup. Use the forceApplicationCopy parameter to cause applications to be copied to Managed Servers at startup, whether changed or unchanged. See New Parameter for Forced Application Update. |
CR069284 |
When the "Auto Deployment Enabled" attribute on the Domain -> Configuration -> Applications page was turned off, application components were still deployed automatically when application file was copied to the applications directory. Investigation revealed that the "Auto Deployment Enabled" attribute is not used in WebLogic Server. Instead, auto deployment is controlled by the DomainMBean.setProductionModeEnabled property, which is set at startup on the command line. The AutoDeployedEnabled attribute has been removed from the Administration Console. |
CR084607 |
In WebLogic Server 6.1 SP03, an InstanceNotFoundException occurred when creating a JMS Topic at runtime in a cluster. The Topic was created with JMSHelper.createPermanentTopicAsync in a startup class targeted to a Managed Server in a cluster. After the Topic was created, when the user clicked Destination Link for the JMS Server in the Administration Console, this message was displayed : java.lang.reflect.UndeclaredThrowableException: javax.management.InstanceNotFoundException: mydomain:Name=testTopic12,Type=JMSTopic at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1680) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1152) at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:187) |
CR088842 |
In WebLogic Server 6.1 SP02, in a configuration with an Administration Server and three Managed Servers, a deadlock when one of the Managed Servers was restarted. Analysis revealed that lookupServerRuntime() on a Managed Server resulted in unnecessary getMBean() calls to the Administration Server. The problem was resolved with a code fix. |
CR089747 |
In WebLogic Server 6.1 SP03, on Solaris Sparc 2.8, the domain log file did not rotate by time. Under Windows 2000, 3 log files were created, then rotation stopped. When old log files were deleted, rotation started again. For Windows 2000, log rotation worked after an upgrade from SP01 to SP03, but not with the fresh installation of SP03. The configuration for the domain log is: <Log FileName="config/mydomain/logs/wl-domain.log" FileTimeSpan="1" Name="mydomain" RotationType="byTime" RotationTime=10:00/> The problem was solved with a code fix. |
CR091359 |
In WebLogic Server 6.1 SP03 and SP04, the Administration Console option: Web Application->webapp1->Monitoring->Monitor all Active Web Applications... did not work for a web application inside an .ear file. The problem was resolved with a code fix. |
CR093409 |
A configuration with one Administration Server and five Managed Servers, running under WebLogic Server 6.1 SP02, Solaris 2.8, and JDK1.3.1_04, an attempt to deploy an EAR with 3 EJB components using weblogic.deploy utility from a different machine caused the Administration Server to hang. The thread dump reported a deadlock. The stack trace contained: Execute thread 4(admin_rmi queue) holds lock of the com.sun.management.jmx.MBeanServerImpl and waiting to acquire lock on weblogic.logging.LogManager. Execute thread 8(default queue) holds lock of the weblogic.logging.LogManager and waiting to acquire lock on com.sun.management.jmx.MBeanServerImpl. Analysis revealed a deadlock in the LogManager and FileStreamLogger. A code fix resolved the error. |
CR096726 |
In WebLogic Server 6.1 SP02, invocation of MBeanHome.deleteMBean() resulted in a null point exception. The configuration was four managed servers, each on a different physical machine, with a JMX client running against each (on one-to-one basis). The JMX clients encounter NullPointerException when doing a MBeanHome.deleteMBean. Analysis revealed that the problem was related to the asynchronous deletion of multiple Managed Servers. One Managed Servers deleted its references in other mbeans before deleting itself, while another Managed Servers does the same thing, resulting in null pointer exception. The problem was resolved by implementing try/except blocks around the code that obtains the metadata for an MBean (i.e., mbean.getMBeanInfo()). When deleting an MBean, a list of current MBeans in the MBeanServer is first obtained, then references to the bean being deleted are removed. The problem is, is that other delete threads are doing the same thing and thus may delete a bean in our (static) list, so when we go to get the meta-data on the bean to update it, we NPE. This patch ignores that NPE and we go to the next one in our list. |
CR096950 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.jsp. |
CR098623 |
When a portal application, such as <beahome>\wlportal4.0\applications\portal was deployed as an EAR file, it was not possible to modify parameters in application-config.xml with the Administration Console. A code fix resolved the problem. |
CR098739 |
In WebLogic Server 6.1 SP02, a Java deadlock was detected in an Administration Server. The thread dump indicated a java level deadlock as follows, where Thread 8 holds the lock on RemoteMBeanServerImpl and tries to obtain one on LogManager, which is held by Thread 6 who is in turn waiting on RemoteMBeanServerImpl. Java Stack for "ExecuteThread: '8' for queue: '__weblogic_admin_rmi_queue'": at weblogic.logging.LogManager.addSubsystem(LogManager.java: Java Stack for "ExecuteThread: '6' for queue: 'default'": at com.sun.management.jmx.MBeanServerImpl.getMBean(MBean The problem was solved by a code change to remove unnecessary locks in LogManager. |
Core
Change Request Number |
Description |
CR036602 |
The ClusterMBean.setClusterAddress()method accepted an illegal value and did not throw an IllegalArgumentException. The problem was resolved by checking that the cluster address is during server startup. |
CR036603 |
The ClusterMBean.setMultiCustAddress() method accepted an illegal value and did not throw an IllegalArgument Exception. The problem was resolved by a code change. |
CR077170 |
In WebLogic Server 6.1 SP03, stopping a Managed Server after its Administration Server was shutdown caused an exception. The problem occurred with this sequence of actions:
This exception resulted: Unexpected Exception Start server side stack trace: java.rmi.ConnectException: Unable to get direct or routed connection to: '-19546889165621794S:dwarkamai:[7001,7001,-1,-1,7001,-1,-1]:OAMdomain:adminServer' at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109) at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:127) at... The shutdown command from weblogic.Admin was successful. The problem was solved by catching the exception that occurs when shutting down Managed Server when Administration Server is down. |
CR079354 |
In WebLogic Server 6.1 SP02 a Java client accessing a DataSource via the Apache plug-in received a TunnelDeadResponse . WebLogic Server was running under running under Windows2000, and had patch CR061847. The plug-in was running under Solaris. The exception was: <May 31, 2002 4:16:35 PM PDT> <Error> <HTTPClientJVMConnection> <java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '2' at weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch (HTTPClientJVMConnection.java:413) at weblogic.rjvm.http.HTTPClientJVMConnection.execute (HTTPClientJVMConnection.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)> When the plug-in was removed, the exception did not occur. Analysis revealed that WebLogic Server could not find an RJVM for the host/port combination, although one existed, because the rjvm manager's synonym cache did not maintain the port information. When WebLogic Server failed to find a match in the cache when bootstrapping, it created a new RJVM. After bootstrapping, WebLogic Server identified the new RJVM as a duplicate, and attempted to close it. In some cases, the message was not delivered to the server if queued. This caused the server to timeout on the RJVM and send a DEAD response. This problem was resolved by a code change to make the synonym cache maintain port information. |
CR089470 |
In WebLogic Server 6.1 SP03, Node Manager threw NumberFormatException when a client socket connects and then closes: <Oct 28, 2002 3:38:18 PM CST> <Info> <NodeManager@localhost:5555> <SecureSocketListener: listening on localhost:5555> java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Integer.java:382) at java.lang.Integer.parseInt(Integer.java:463) at weblogic.nodemanager.SocketInputHandler.run(SocketInputHandler.java:109) There were no discernible side effects. Node Manager could still start and stop Managed Servers after the error. A code fix was implemented to handle exceptions on sockets that are opened and closed with out any transfer of data. |
CR070887 |
In WebLogic Server 6.1 with or without SP02, setInstanceFollowRedirects() does not work. JDK1.3.1 introduced the following methods in java.net.HttpURLConnection: getInstanceFollowRedirects() and setInstanceFollowRedirects(). These methods can be used to disable URL redirects for a specific HttpURLConnection. HttpURLConnection was ignoring the flag set by setInstanceFollowRedirects(). The problem was solved by a code fix to HttpURLConnection's redirect logic to ensure process redirects in accordance with the setting of InstanceFollow |
CR077108 |
During load testing of a 35-plus node cluster, a null pointer exception was encountered at weblogic.utils.collections.NumericValueHashtable. <May 9, 2002 5:08:22 PM BST> <Error> <Management> <InvocationTargetException getting attribute SecondaryDistributionNames on MBean bluemartini:Location getSecondaryDistributionNames(ClusterRuntime.java:100) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:511) at weblogic.management.internal. Analysis determined that the getSecondaryDistributedNames() method should allow for null value from getOtherHost(). Problem resolved. |
CR079354 |
In WebLogic Server 6.1 SP02 and patch CR061847, a Java swing client obtaining context and accessing a JDBC data source received a TunnelDeadResponse. The client gets an initial context, gets a connection via a datasource, closes the initial context, closes the connection, and then repeats this sequence of processing. This error results: On the server, this exception was thrown: ####<Nov 21, 2002 12:24:20 PM CST> <Debug> <HTTPServerJVMConnection> <hpwlinc03> <admin> <ExecuteThread: '14' for queue: 'default'> <> <> <000000> <Closing JVM socket: 'weblogic.rjvm.http.HTTPServerJVMConnection@4cfbd8 - id: '0', closed: 'true', lastRecv: '1037903025816''> java.lang. The client threw this exception: <Nov 21, 2002 12:24:18 PM CST> <Error> <HTTPClientJVM Diagnosis revealed that a timeout occurred after WebLogic Server failed to find an RJVM for host/port combination, although it existed. The RJVM's synonym cache did not maintain port information. The problem was solved with a code fix to maintain port information in the RJVM's synonym cache. |
CR080822 |
In the Solaris distribution with Performance Pack, log messages showed an incorrect value for the file descriptor soft limit. The value of file descriptor hard limit was shown for both the soft limit and hard limit. This is the error in weblogic.log: ####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <System has file descriptor limits of- soft: '1024', hard: '1024'> ####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <Using effective file descriptor limit of: '1024' open sockets/files.> This error was exhibited under Solaris 2.6 and Solaris 2.8. The error was corrected by a syntax correction to associated script template. The incorrect syntax: [ !$? -a "$maxfiles" != 1024 ]; was replaced by: [ ! $? -a "$maxfiles" != 1024 ]; |
CR085259 |
Session data was replicated across two separate WebLogic Clusters, hosted in a common domain, when each cluster used the same name for the session cookie. Problem was solved by implementing a check to verify that the secondary host/port is in the same cluster as the primary host for the session. |
CR086425 |
Duplicate of CR085259. See above. |
CR086758 |
In a multi-tier implementation, after ten hours of stress testing, the web tier hung. This occurred while the web tier (consisting of servlets, jsps, and custom classes that implement a custom cache) was communicating with the EJB tier (all stateless session beans), after the EJB tier closed the Connection Manager, due to missed RJVM heartbeats. Before the web tier hangs the following are the exceptions are thrown in the ejb tier. <Sep 24, 2002 8:43:58 AM PDT> <Info> <RJVM> <Failure in heartbeat trigger for RJVM: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@3bedf2 - id: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' connect time: 'Tue Sep 24 06:15:16 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1348) at weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1306) at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:497) at weblogic.rjvm.RJVMImpl$HeartbeatChecker.trigger(RJVMImpl.java:1032) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) Problem was solved by adding logic to assure that pending responses are notified of peer gone events. |
In WebLogic Server 6.1 SP03 on a Sunblade 100 single-CUP Solaris machine, two independent server instances could not look up InitialContext on each other. After one server instance looked up InitialContext, when a second server instance on the the same machine tried to look up InitialContext on the same machine this exception resulted: <2002/10/09 4:23:56:JST> <Debug> <ConnectionManager> <Attempt to sendMsg using a closed connection> javax.naming.CommunicationException. Root exception is java.rmi.ConnectException: Attempt to sendMsg using a closed connection at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:85) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:262) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy45.lookup(Unknown Source) at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341) at javax.naming.InitialContext.lookup(InitialContext.java:345) at com.bea.samples.servlet.TestServlet.service(TestServlet.java:40) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) The problem was not replicated on Sun Enterprise. The problem did not occur on Sun Blade, if the lookup was done using an IP address instead of localhost. Analysis indicated that client RJVM tried to close duplicate T3JVMConnections. It issued a CMD_REQUEST_CLOSE to the server and closed the RJVM. However, if the server queued this message, then the RJVM was marked as closed. The problem was solved by a code change to prevent RJVM shutdown when detecting duplicate connections and CMD_REQUEST_CLOSE does not get delivered to server. |
|
CR087944 |
Running under Windows XP resulted in a java.lang.UnsatisfiedLinkError: no muxer in java.library.path error. This is because WebLogic Server does not correctly report Windows XP as the host operating system. With JDK 1.3.1_03, os.name is returned "Windows 2000". Modification of a method in the SocketMuxer resolved the problem.. |
CR088022 |
After starting Managed Servers with Node Manager, information about communications between the Administration Server and Managed Servers, such as the network channel used and the JVM ID, could not be viewed by right-clicking the server name in the left pane of the Administration console and selecting "View connections". Analysis revealed that the getConnections() method of ServerRuntimeMBean was returning zero connection object instances, due to an underlying bug in ConnectionManagerServer. The problem was resolved by a a code fix to ensure that connection manager reports on connections for which the RJVM is null. |
CR088056 |
WebLogic Server muxer libraries did not have build dates, making it difficult to determine which version of a library was in use. Although NTSocketMuxer had the build date/time embedded, PosixSocketMuxer did not. Problem solved by adding build date/time to PosixSocketMuxer. Now, the following message will be displayed when the muxer initializes: <Oct 15, 2002 3:44:04 PM PDT> <Info> <socket> <000406> <PosixSocketMuxer was built on Oct 15 2002 15:05:11> |
CR089060 |
Under OS/390 Linux (SuSE Linux Kernel 2.2), libmuxer.so threw this error: java.lang.UnsatisfiedLinkError: /opt/weblogic6/lib/linux/s390/libmuxer.so: /opt/weblogic6/lib/linux/s390/libmuxer.so: ELF file machine architecture not s390 at java.lang.ClassLoader$NativeLibrary. The problem was resolved by providing binaries for the Linux Kernel 2.2. |
CR089144 |
Deployment of an EJB with a custom call router in the jar failed with IllegalArgumentException. The class failed to load because the classForName() method of the ReplicaAwareInfo class looked for classes in the system classloader instead of the ContextClassLoader on the current thread. Stacktrace: java.lang.reflect.InvocationTargetException: java.lang. Problem was resolved by setting the context classloader to the application classloader while calling deploy() on ClientDrivenBeanInfoImpl and checking in the context classloader to load the call router class. |
CR089454 |
A new ability to throttle incoming request traffic by configuring the maximum length of an execute queue has been provided. The maximum length of an execute queue can be set with the new -D flag, weblogic.kernel.allowQueueThrottling. This capability is provided to help customers throttle "slow moving resource intensive" requests on a custom queue. Queue throttling is supported for custom application queues, not for default or WebLogic Server internal queues. When the configured queue length is exceeded calls to Kernel.execute() will result in client receiving a recoverable remote exception, and a 503 response. |
CR090071 |
A high volume of assertion failed errors occurred in PosixSocketMuxer.cleanup(), accompanied by a steady growth in the number of sockets in the CLOSE_WAIT state. ulimit was reached, and server instance restart was required. Problem was solved by implementing logic that checks if fdr.sock is null before throwing an assertion error in cleanup. |
CR090341 |
Erroneous failure duration was reported in t3.srvr.ListenThread calling logListenFailed(). This was a numeric error in a message generated when the server failed to listen due to an underlying IOException. Example of the message: <Jun 11, 2002 2:37:33 PM PDT> <Critical> <WebLogicServer> <Failed to listen on port 7772, failure count: 3, failing for 1,023,831,450 seconds, java.net.SocketException: File table overflow> The problem was fixed by correcting a typographical error in t3.srvr.ListenThread. |
CR090823 |
JSPs were recompiled unnecessarily for the e2e sample. The JSPs in e2edomain always got recompiled when running b2c and b2b examples. The time stamps of those JSPs were properly backdated, however. This problem resulted from a bug in the JspStub.getClassLoader method. Problem resolved by fixing the bug. |
CR091420 |
WebLogic Server 6.1 SP04 failed to start if the "Enable Post-Bind UID" option for a Unix Machine was checked. (This attribute can be configured in the Machines node of the Administration Console; its purpose is to return the Unix UID a server instance running a UNIX machine will run under after it has carried out all privileged startup actions). The problem was corrected with a code fix. |
CR092704 |
In WebLogic Server 6.1 SP02, hangs occurred frequently because socket reader threads were blocked. The thread that owned the POLL lock was attempting to close an SSL socket, but could not progress because it could not obtain the lock on the output stream required in the sendRecord() method. Stack trace: "ExecuteThread: '23' for queue: 'default'" daemon prio=5 tid=0x6d6c40 nid=0x24 waiting for monitor entry [0xe4e81000..0xe4e81a28] at weblogic.security.SSL.SSLSocket.sendRecord(SSLSocket.java:1049) at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1007) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1153) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1141) at weblogic.socket.SocketMuxer.closeSocket(SocketMuxer.java:236 A code fix was implemented to ensure that SSL sockets do not write data to sockets on close for abortive shutdowns. |
Thread dump error occurred with this configuration: Thread dumps failed because the JVM_DumpAllStacks symbol had not been globally declared for Hotspot client and Version 1.3.1_x virtual machines. Thread dumps using weblogic.Admin are now possible with 1.3.1_X hotspot client/server JVMs. |
|
CR093416 |
An EmptyStackException was thrown by a Managed Server when the Controller servlet was being deployed. The following error is thrown by a managed server when the Controller servlet is being deployed: [WebAppServletContext(35527,btn,/btn)] Servlet failed with Exception> java.util.EmptyStackException at weblogic.utils. The problem was related to the btn.utils.JndiUtils.getEnv() method—it closed the context that it got on lookup—java:com/env—so javaURLContextFactory was not pushing the environment. Problem resolved. |
CR094101 |
There was an interoperability issue between WebLogic Server 6.1 SP02 and WebLogic Server 7.0 SP01. An MDB in WebLogic Server 6.1 called an EJB in WebLogic Server7.0. The EJB is timed out and threw a weblogic.transaction.TimedOut The problem was solved by adding a weblogic.transaction.Timed |
CR094724 |
In WebLogic Server 6.1 SP03 and later, WebLogic Server native libraries on HPUX were not being compiled using cfront, instead of aCC. aCC is the ANSI C compiler which replaced cfront in 1998. As a result incompatible runtime libraries were loaded(libC.2 from cfront compilation, and libCsup.2 from SUN's Java, compiled with aCC). Incompatible runtime libraries can cause crashes. The problem was solved by changing WebLogic Server builds to use aCC for hpux11 |
CR095267 |
Duplicate of "CR094561". |
CR095487 |
Duplicate of "CR087808". |
CR095949 |
In WebLogic Server 6.1 SP04,when FailureIsFatal option for a startup class is true and and the startup class fails, WebLogic Server was not shutdown as expected. The StartupClassRunner is invoked before and after applications are deployed . Analysis revealed that if a startup class failed before application deployment, and was marked failureIsFatal, the fatalException was lost. The problem was solved by a code fix to ensure that the fatalException is not lost, and the the server instance is shutdown appropriately. |
CR096114 |
The change associated with "CR092933" which enables thread dump redirection in 1.3.1_x versions of Sun JDK, did not work in NT Services because the stdio handles were invalid. The problem was resolved by a code change, to create stdio handles in beasvc. |
CR101322 |
A customer used a custom realm that makes an outbound RMI call. This happens from BootServicesImpl.invoke() from within the RJVM layer on a reader thread. when many such calls are made, reader threads were blocked making outbound calls leaving no threads for reading the response. The problem was solved by moving BootServices into the RMI layer so that it can dispatch to the default execute queue. |
CR102021 |
In WebLogic Server 6.1 SP04, under load test, PosixMuxer threw the following exceptions <Nov 21, 2002 9:38:29 AM EST> <Error> <socket> <000421> <Uncaught Throwable in processSockets java.io.IOException: unexpected exception in poll: (4) Interrupted system call java.io.IOException: unexpected exception in poll: (4) Interrupted system call at weblogic.socket.PosixSocketMuxer.poll(Native Method) at... The problem was solved with a code change to restart poll if interrupted. |
CR102058 |
Use of URLClassLoader on the client on a remote method call resulted in a NoClassDefFoundError. c:\java\java131_07\bin\java -classpath ".;client.jar;C:\home\ravia\weblogic\dev\src700\3rdparty\weblogicaux.jar" URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at... Analysis revealed that when creating AugmentableSystemClassLoader, it was always set to SystemClassLoader. This caused the client to use its system classloader, resulting in the NoClassDefFoundError. The problem was solved by setting ThreadContextClassLoader as parent for AugmentableSystemClassLoader. |
Deployment
EJB
Installer
Change Request Number |
Description |
CR092156 |
The WebLogic Server 6.1 SP04 upgrade installer build did not include latest beasvc.exe. For related CRs, see See CR091420, and 091420. The SP05 upgrade installer does not exhibit this problem. |
JDBC
Change Request Number |
Description |
CR085559 |
When a user transaction failed to rollback because Oracle database was down, the JDBC connections used in the transaction were not released, resulting in connection pool depletion. This problem was exhibited under WebLogic Server 6.1 SP02, Oracle8.1.6, 8.1.7 jDriver for Oracle, and Oracle thin driver. Analysis revealed that the internalrollback method in the JTS connection was not calling the internalclose() method, so if the rollback failed the connection leaked. A code fix solved the problem. |
CR089713 |
In WebLogic Server 6.1 SP03, weblogic.Admin RESET_POOL did not re-initialize connections to not-reserved. After using weblogic.Admin RESET_POOL, the log indicated that all connections were refreshed, but if they were reserved before the reset, they are still reserved after the reset. The problem was solved with a code change to put reserved resource back on resourcesFree list and clear the associated flag. |
CR090379 |
In previous releases of WebLogic Server, if application code created JDBC objects that were abandoned without being closed, the objects would be lost but would still hold memory or open cursors, even after being garbage collected. If too many such objects were created, the server would eventually run out of memory and the database may run out of cursors. In WebLogic Server 6.1SP5, the code was changed so that abandoned JDBC objects are closed before being garbage collected. Note: If you immediately create a JDBC object that is identical to an abandoned object, WebLogic Server creates a clone of the original JDBC object. However, when the original leaked object is closed, the clone will also be affected. |
CR090761 |
A StringIndexOutOfBoundsException occurred in the OCI driver. The problem occurred occasionally in multiple queries when running a CMP entity bean, always when dealing with an integral at or near (depending on the precision of the number in the database) weblogic.jdbc.pool.ResultSet.getLong(ResultSet. The full exception is:java.sql.SQLException: java.lang.StringIndex Analysis revealed that in weblogic.db.oci.OciCurser.getValue A code fix solved the problem. |
CR091577 |
In WebLogic Server 6.1 SP03, connection pool reset methods were unnecessarily synchronized. The ResourceAllocator method resetThisOne()was synchronized. As a result, when all execute threads performed a testConnOnReserve, and replaced a dead connection, they queued up, instead of establishing connections in parallel. A code fix solved the problem. |
CR092453 |
In WebLogic Server 6.1 SP04, with Oracle Thin XA with the CLASSES12.zip from Oracle 9.2, a stateless session bean calling EJB caused XAER_PROTO after "Configuration Changes saved to the repository" message appeared. START SLEEP 2: After updating thevalue to 1... DONE SLEEP 2: After updating thevalue to 1... START SLEEP 2: After updating thevalue to 2... DONE SLEEP 2: After updating thevalue to 2... START SLEEP 2: After updating thevalue to 3... DONE SLEEP 2: After updating thevalue to 3... START SLEEP 2: After updating thevalue to 4... DONE SLEEP 2: After updating thevalue to 4... START SLEEP 2: After updating thevalue to 5... DONE SLEEP 2: After updating thevalue to 5... Current value is 5 < Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0 The problem caused by a known problem in Oracle client 9.2.0.[01], that is solved in 9.2.0.2. A code change to in WebLogic Server was implemented to work-around the 9.2.0.[01] issue. |
CR092791 |
In WebLogic Server 6.1 (any SP), it was not possible to use specific Oracle objects (Array, Struct, ...) through a connection pool based on the Oracle Thin Driver. The objects returned by the Oracle thin driver were not serializable nor remote and therefore could not be passed over RMI. A new package has been introduced : weblogic.jdbc.vendor.oracle that contains "proxies" for these objects and allow them to be passed through the connection pool. |
CR093245 |
After calling JDBCConnectionPoolRuntimeMBean.resetStatement A code fix solved the problem. |
CR093563 |
A deadlock occurred between "Finalizer" and weblogic/jdbc/jta/Statement. The problem was exhibited under Solaris 5.8 - WebLogic Server 6.1SP3 - java v1.3.1_03 (build 1.3.1_03-b03), Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode). This error occurred: "ExecuteThread: '5' for queue: 'default'": waiting to lock monitor 0xe1ba8 (object 0xf1327fb0, a java.util.HashSet), which is locked by "Finalizer" "Finalizer": waiting to lock monitor 0xe1b70 (object 0xf1327fe8, a weblogic.jdbc.jta. The problem occurred on a server instance that runs a web application that queries and updates an Oracle database. The code where the deadlock was encountered was part of a common user management interface that gathers user information when the user is logging in. It uses the oracle.jdbc.xa.client.OracleXADataSource from a connection pool configured in WebLogic Server. Analysis revealed that connection tests were synchronized, causing waits to obtain a lock, even when none was available. A code fix solved the problem. |
CR093734 |
Under WebLogic Server 6.1, an error code was not returned correctly when a client tried to get a connection to an unavailable database using Oracle Thin Driver.
Analysis revealed that weblogic.jdbc.common.internal.ConnectionEnv A code fix solved the problem. |
CR094645 |
When a non-zero starting index was passed to the getStatementProfiles() method, the traces returned start from the top of the .tsf file, instead at the specified starting index. A code fix solved the problem. |
CR095059 |
In WebLogic Server 6.1 SP04, the the value returned by the JDBCStatement A code fix to weblogic/jdbc/common/internal/ProfileStorage.java solved the problem. |
CR095994 |
weblogic.jdbc.rmi.internal.ConnectionImpl lacked connection leak profiling and connection leak detection logic. Three events can trigger the release of a connection back to the pool.
The first two events should trigger a warning to the user to that there is a potential connection leak. This logic was added to SerialConnection.java and ConnectionImpl.java. |
CR096710 |
Weblogic Server 6.1 SP04 did not throw an ORA-00020 message to the log when a connection pool failed to create with the given initial capacity due to not having sufficient number of processes (max_processes) for the database. The problem was solved by a code change to log the message. |
CR096922 |
Under load conditions, when WebLogic Server was calling ResourceAllocator.markBorrowed() and JMX was calling ConnectionPoolRuntimeMBeanImpl.getConnectionDelayTime(), a deadlock condition resulted. A code fix to ResourceAllocator.java solved the problem. |
CR097832 |
Weblogic Server 6.1 SP04 thin driver, Solaris 8, JDK 1.3.1_04, and Oracle 8.1.7.4., deadlocks occurred when connection refresh is turned on. Customer stack trace: "ExecuteThread: '35' for queue: 'default'" daemon prio=5 tid=0x45ac68 nid=0x30 waiting for monitor entry [0xce901000..0xce9019d8] at weblogic.jdbc.common.internal.ConnectionEnv.destroy(ConnectionEnv.java:571) at weblogic.common.internal.ResourceAllocator Both the weblogic.jdbc.common.internal.ConnectionEnv.destroy and weblogic.common.internal.ResourceAllocator.release are synchronized methods (). The problem was solved with a code fix to weblogic/jdbc/common/internal/ConnectionEnv.java. |
CR099363 |
In WebLogic Server 6.1 SP04, under load testing, a connection pool with the refresh minutes set to 15, and TestConnsOnReserve and TestConnsOnRelease set to false threw the following exception: weblogic.common.ResourceException: No available connections in pool ODSConnectionPool This problem occurred because when only a few of the connections in the pool are used, all the other connections in the pool are reserved for testing at the expiration of the refresh test minutes. At that point, if client asked for a connection the exception was thrown. The problem was resolved with a code fix that implements two things:
|
CR101093 |
In WebLogic Server 6.1 SP04, when the incorrect password is set in the connection pool properties, the following exception is thrown: <Mar 13, 2003 10:35:45 AM IST> <Info> <JDBC> <Sleeping in createResource()> <Mar 13, 2003 10:35:46 AM IST> <Info> <JDBC Pool DemPool> <Pool DemPool is created with initial capacity 0> In the earlier versions of WLS. The exception was more descriptive. The following exception is thrown when the incorrect password is specified in sp 3. <Mar 12, 2003 9:41:38 AM IST> <Error> <JDBC> <Cannot startup connection pool "Dpool" weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: java.sql.SQLException: ORA-01017: invalid username/password; logon denied The problem was resolved with a modification to weblogic/common/internal/ResourceAllocator.java. |
jDriver
Change Request Number |
Description |
CR083694 |
Calling getTimeStamp(), getTime(), getDate() or getJavaDate() on weblogic.db.oci.OciCursor with a null Calendar object, resulted in creation of a new calendar. To improve performance, now a single calendar is created and stored in the cursor the first time one of these methods is called. |
CR088387 |
Using a XADataSource on top of jDriver resulted in shrinking heap size until OutOfMemoryError was encountered. In the weblogic.jdbc.oci.Connection class, LOB fields of result sets in a transaction are registered under a connection through the Connection.addLob() method. The registered LOBs are freed (along with the corresponding object in native jDriver library) when one of these conditions occurs:
When an XADataSource is being used, none of the above conditions apply. As a result, LOB fields of jDriver in result sets were never released in the JVM heap. This problem was corrected by a code change in weblogic.jdbc.oci.xa.DataSrcThreadInfo.java to call closelob (). |
CR090025 |
In WebLogic Server 6.1 SP04 jDriver for Oracle 9.2 does not support the AL32UTF8 character set (unicode version 3.1). When NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8, the following error is generated by weblogic.jdbc.oci.Connection.<init>(Connection.java:246): java.sql.SQLException: Unsupported Oracle codeset: al32utf8. Set weblogic.codeset in your connection Properties to a valid JDK codeset which is compatible with the Oracle codeset defined in your NLS_LANG setting. When NLS_LANG=AMERICAN_AMERICA.UTF8, this error occurs: ORA-01461: can bind a LONG value only for insert into a LONG column, indicating a mismatch between the character set on the client and database. This problem was corrected by a code fix to weblogic/db/oci/OciConnection. |
CR091151 |
In WebLogic Server 6.1 SP03 and SP04, jDriver for Oracle ResultSet#getBigDecimal() method did not return correct value. For example, value of 9999999999.999999 was rounded to 9999999999.999998. This problem was solved with a code fix. |
CR093795 |
The "Euro" currency symbol was retrieved as "?" using statement.getString() with WebLogic jDriver for MSSQL Server 2000. The problem was solved by a code fix to use new String constructor to handle character set correctly |
CR098071 |
The version of the Oracle Thin driver 9.2.0 bundled with previous releases of WebLogic Server contained errors that occasionally resulted in data errors. The driver was replaced with a new version from Oracle. |
CR101517 |
Oracle's SQL DATE type supports date values between 4712 B.C. and 4712 A.D., but jDriver for Oracle can not handle dates '1899-12-31' and before. Such dates that are stored by jDriver cannot be queried by other tools, like Oracle Thin Driver or SQL*Plus. This issue happens only if you use a prepared statement, and bind such date to DATE column using setDate() method. The problem was solved by a code fix to weblogic/db/oci/OciColumn.java. |
CR102060 |
In WebLogic Server 6.1 SP02, with jDriver for Oracle, and Oracle 8.1.7, the PreparedStatement for sql UPDATE did not work after using CallableStatement on the same connection. This was a regression of "CR080931". getUpdateCount() returned zero, and nothing was changed in the database. This occurred when setting the weblogic.oci.min_bind_size property for the jdbc connection. props.put("weblogic.oci.min_bind_size", "660") Analysis revealed that jDriver was using min_bind_size=33000 for the statement. weblogic.jdbc.oci.Connection#prepareCall internally set min_bind_size to 33000. The problem was solved with a code fix to db\oci\OciConnection.java. |
JMS
JNDI
JSP
JTA
Miscellaneous
Plug-ins
The plug-in(s) in which the problem was resolved is shown in parentheses in the Description column.
Change Request Number |
Description |
091740 |
(HttpClusterServlet) During benchmark tests, 503 and 500 HTTP error were being returned by the proxy server running the HttpClusterServlet. The errors were random and occasional. The configuration was JRockit 7.0 SP2 Load 2 and the Sun JDK 1.3.1_06. AcceptBacklog and the thread count were increased to 1000 and 50 respectively. The benchmark was run with 100-200 client threads. This problem occurred when the servlet's dynamic server list contained no entries. The problem was solved with a code fix to check the size of the dynamic server list of servers before creating an array out of that list. |
CR084625 |
(NSAPI) All version of the iPlanet plugin had /_wl_proxy/_post hardcoded: #else /* UNIX */ sprintf(name,"/tmp/_wl_proxy/_post__%d_%d", pid, postCounter); fsep = '/'; #endif This poses problems for customers that have multiple servers using different user IDs and groups. For example, uploaded files from clients are saved temporarily in /tmp/_wl_proxy of web servers that proxy to WebLogic Server. The _wl_proxy directory is removed each time the web server is rebooted. If the environment is shared (multiple instances on the same physical servers) the user process that creates this directory blocks other users from writing to it, because it uses its default umask to create the permissions (i.e., application A [running as User ID A] creates /tmp/_wl_proxy/<some temp file> and then application B tries to upload a file and gets the following error in the error file: [27/Aug/2002082140] failure (14367) for host 172.18.5.122 trying to POST /filetransfer/TransferUtility.do, wl-proxy reports exception occurred 'READ_ERROR [os error=13, line 501 of proxy.cpp] Cannot open TEMP file '/tmp/_wl_proxy/_post__14367_5' in $TMP/_wl_proxy for POST of 2867 bytes This problem was solved by adding a configurable WLTempDir argument. This argument applies to both wlproxy.log and _wl_proxy. For backward compatibility, WLLogFile overrides WLTempDir during log file creation. |
CR085192 |
(NSAPI and ISAPI) Performance degradation occurred when connection pooling was turned off. Resource requirements for URL creation were high. WebLogic closed the connection before the plug-in did, resulting in "half-open" connections, and PROTOCOL_EXCEPTIONS in the plug-in. The problems were addressed by multiple code changes: |
CR085285 |
(NSAPI) The web application container returned 404 messages for InitJVMID requests from the plugins, resulting in log files filling up with messages: ####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <petunia> <ms1petunia> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1petunia) found no context for "/WLDummyInitJVMIDs". The problem was solved by sending InitJVMID requests to the internal web application which is always deployed on WebLogic Server. |
CR085541 |
(all plug-ins) __WebLogicBridgeConfig returned internal representation of Debug—a confusing 10 character code. A code fix was made to return the value represented by the code. |
CR085695 |
(ISAPI) When KeepAlive was enabled, the time to close the connection is about 30 seconds with a HEAD HTTP request. This problem was exhibited under 6.1 SP01, Windows 2000, IIS 5.0. This problem was corrected with a code fix to close the connection immediately for HEAD request. |
CR085921 |
(ISAPI) For all plug-ins, it was not possible to differentiate between WRITE_ERRORS that occurred while writing to the request/post-data to WebLogic Server and WRITE_ERRORS that occurred while writing response headers/data to the browser in the __WebLogicBridgeConfig statistics. This deficiency made it more difficult to use the statistics displayed by __WebLogicBridgeConfig for plug-in/cluster health monitoring. This deficiency was corrected by implementing two new error types WRITE_ERROR_TO_CLIENT and WRITE_ERROR_TO_SERVER. |
CR085923 |
(ISAPI) For all plug-ins, setting Debug=ERR caused INF messages to also be logged. This problem was corrected by a code fix. Now, only ERR messages are logged when Debug=ERR. |
CR086224 |
(NSAPI) Plug-in did not read the SESSIONID from post data. Analysis revealed a problem in getPreferredServersFromCookie(). When session.getId() was kept as post data. getId() included an extra string: |time. The problem was solved by a code fix:, |
CR086490 |
(ISAPI) For all plug-ins and HttpClusterServlet, the MaxSkips feature was disabled, because its default value of 10 proved to make the feature less useful than desired. The lack of this feature posed potential performance degradation when one or more servers in the cluster are unresponsive. This problem was resolved by providing a new parameter, MaxSkipTime. MaxSkipTime can be used to specify the time in seconds to wait after marking a server bad until forcing a new server list. |
CR086518 |
(NSAPI) If performing a redirect using a URL that contains both a query string and an anchor, the anchor was incorrectly considered part of the value portion of the last query string member. This problem only occurred when using Internet Explorer in a three-tier environment, using iPlanet 6.0 for the HTTP server). Using Netscape or Mozilla, or if running the server in a two-tier environment, the problem did not occur. To replicate, invoke foo.jsp. foo.jsp: <% String redirectURL = "http://hostname/T/foo2.jsp?a=b#foo";; response.sendRedirect(redirectURL); %> foo2.jsp: <%= request.getParameter("a") %> The Administration Console displayed the value for "a" as "b#foo"., instead of "b". The problem was solved by a code fix to trim the anchor from the query string, because Internet Explorer does not do so for sendRedirected URL |
CR088914 |
(NSAPI) See CR088915 |
CR088915 CR088914 |
(ISAPI, NSAPI) A changed was made to reduce vulnerability to SSL certificate chain attacks. Code to check BasicConstraints for CA certificates was added. Constraint checking is controlled with the plug-in parameter EnforceBasicConstraints. The parameter settings are now:
This change may result in security exceptions that did not occur in WebLogic Server 6.1 SP04. For example, an attempt to make an outbound SSL call, resulted in this error when the certificate presented by the remote server instance did not have a basic constraint: <May 8, 2003 4:36:18 PM MDT> <Notice> <WebLogicServer> <SSLListenThread listening on port 7002> <May 8, 2003 4:36:19 PM MDT> <Notice> <Management> <Starting discovery of Managed Server... This feature is on by default, you may turn this off by passing -Dweblogic. <May 8, 2003 4:36:19 PM MDT> <Notice> <WebLogicServer> <Started WebLogic Admin Server "myserver" for domain "412253" running in Production Mode> EXCEPTION: Socket Closed java.io.IOException: Socket Closed at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1086) at... Such errors may be prevented by setting the plug-in parameter EnforceBasicConstraints to false. You can set disable checking of basic constraints at the command line with this command: -Dweblogic.security.SSL.enforceConstraints=false |
CR089746 |
(NSAPI) WebLogic Server supported the following scenarios:
A customer requested support for SSL session caching and keep-alives between the plug-in and and WebLogic Server, for T3s and HTTPS. The request was satisfied by adding the KeepAliveEnabled flag , and adding SSL session cache. |
CR091635 |
(NSAPI) The SP03 version of the plug-in failed to parse the the JVMIDs for the following request: 2002 Found Encoded Session=[JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES] Thu Nov 21 15:16:09 2002 Parsing cookie JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES Thu Nov 21 15:16:09 2002 getpreferredServersFromCookie: 805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES Thu Nov 21 15:16:15 2002 parseJVMID: could not resolve hostname 'r', treating it as invalid The problem was solved with a code fix to check JVMID portion of session cookie contains '/' instead of the whole sessionid. |
CR092756 |
(ISAPI) ISAPI plug-in was not failing over on receipt of a HTTP 503 response from the backend. A code fix was implemented to solve this problem. |
CR093196 |
(NSAPI) JSP sendRedirect() failed when web application is deployed on a cluster and the JSP is accessed through the iPlanet proxy plug-in. An IE browser returns the message The page cannot be displayed... and Netscape returns The document contained no data... The problem was solved with a code fix to check for null value of secondary session. |
CR093530 |
(ISAPI) The PathTrim value was case-sensitive, causing problems for environments that prefer to allow clients to access an application with a case-insensitive URL. This problem was resolved by changing the PathTrim value to be case-insensitive. |
CR093662 |
(NSAPI) A call to encodeRedirectURL() failed when: (a) A webapp is deployed as a .war file on a cluster; (b) A JSP in the webapp is accessed through the iPlanet proxy plug-in; and (c) The JSP invokes encodeRedirectURL() in a FORM using the HTTP GET method A core dump occurs on the iPlanet Web Server. An Internet Explorer browser returns The page cannot be displayed...Cannot find server or DNS Error and Netscape returns The document contained no data... 1. Analysis revealed that the problem was caused by storing primary or secondary jvmid in a fixed length buffer without trimming the query string. The problem was solved by a code change to should trim the query string before parsing the session cookie |
CR094109 |
(Apache) Failover from primary server did not occur when response time exceeded the time limit set by HungServerRecoverSecs, and the Indempotent primitive is on. Analysis revealed that the problem was related to an error in the exception handling source code in ap_proxy.cpp. The problem was solved by rewriting the failover code. |
CR094282 |
(NSAPI) If the server listed in WebLogicHost and WebLogicPort or in WebLogicCluster was not up and running, or for example, Solaris started in single user mode, the plug-in hung until the operating system timed out the connection. By default, this timeout is lengthy. A new introduce plug-in parameter, WLSocketTimeoutSecs, was added. Use of this parameter prevents long delays when a machine is down. This default value is 2 seconds. The value must be greater than 0. |
CR094663 |
Same problem and resolution as CR095166. |
CR094768 |
(ISAPI) Parsing post data for cookies not implemented correctly in plugins. This error resulted "Bad request in the post data [NameField=aaaaa&ValueField=111111111111&AddValue=+Add+]" The UrlUnescape() method was returning incorrect return type, and parsing post data for content-types other than application/x-www-form-urlencoded. The bug was corrected with a code fix. |
CR095009 |
(ISAPI) The plug-in could not successfully resolve to the appropriate server instance. The error in the log files was: Primary JVMID not found in the server list, ignore preferred servers. Analysis revealed an error in getPreferredServersFromCookie(). The problem was solved with a code fix. |
CR095558 |
(ISAPI) The plug-in did not differentiate properly between read failures from the browser and write failures to the server. A code change was made to process connection aborted messages (10053/10054) only when failure is between the client and the plug-in. |
CR095559 |
(Apache) After failover of primary server, the plug-in continued to search for the primary server instance, instead of search for the secondary server instance and sending the it the request upon which the primary server failed. The problem was solved by a rewrite of the failover code. |
CR095166 |
(ISAPI) The IIS plug-in parsed cookies incorrectly when the client sent multiple cookies, resulting in the plug-in not sticking to the primary server instance. Analysis revealed an error in the string checking logic, strstr() did not correctly parse the session cookie name. |
CR096625 |
(Apache) The X_WEBLOGIC_FORCE_JVMID header was sent to to a server instance in a cluster. X_WEBLOGIC_FORCE_JVMID should only be sent when the server list is non-clustered and the current server does not have a jvmid yet. This problem was solved by a code fix. |
(All plug-ins) A customer need to determine a browser's cipher strength on the WebLogic side, in a configuration that included a plug-in with 128 bit step up certs between WebLogic Server and the browser. The browser had 40 bit or 128 bit strength. The customer used this code to obtain the browsers cipher strength: (Integer)httpRequest.getAttribute("javax.servlet.request.key-size") to get the browser's strength. The value returned was always 128, although the browser was set to use a cipher size less than 128 bit. The https_keysize determines the strength of the connection that is made. Because 128 bit certs were used on plug-in, 128 was returned, regardless of the strength used by the browser. When the request was directed to WLS, 40 or 128 was returned, depending on the browser strength. The plug-in does not modify the HTTPS_KeySIZE or HTTPS_SECRETKEYSIZE headers. To meet this need, to new headers were implemented: WL-Proxy-Client-Keysize and WL-Proxy-Client-Secretkeysize. Both headers values can be obtained with request.getHeader(). |
|
CR096850 |
(NSAPI) The iPlanet server, running under Windows2000, crashed when a load testing application is trying to make multiple connections to the server. The iPlanet server crashes after multiple attempts are made to connect to the server. Analysis revealed the iPlanet server crashed because of access violation and it points to MSVCRT!CxxThrowException. The problem was solved by a code fix to sendResponse, to return and handle the exception, instead of throwing the exception. |
CR100361 |
The following new exception types were added: READ_ERROR_FROM_CLIENT—error when reading data from client READ_ERROR_FROM_SERVER—error when reading data from backend server READ_ERROR_FROM_FILE—error when reading from temporary file which stores post data WRITE_ERROR_TO_FILE—error when writing post data to the temporary file |
CR101222 |
(NSAPI and Apache) Failover to a secondary server instance when the primary server instance hung did not occur reliably. After establishing a primary and a secondary session, the client sent a recovery request that slept for longer then the value of HungServerRecoverySecs if the request.getParameter("primary") was equal to the server name. The web server did not detect that the primary server was hung and fail over the request to the secondary. Analysis revealed that the secondary server was marked bad, which caused the plug-in to skip it, and use the general server list. The problem was solved by a code change to reset the server to good after MaxSkipTime. |
CR101428 |
(ISAPI) When requests contained multiple cookies, if cookies not named JSESSIONID were after the JSESSIONID cookie, they were stripped off and not delivered to WebLogic Server. The problem was solved be a code change. |
CR101596 |
(NSAPI) In WebLogic Server 6.1 SP04, ssl_certchain_verify_callback() incorrectly returned SSLNoErr for certain error conditions. The problem was solved be a code change to return X509CertChainInvalidErr when the error conditions are encountered. |
CR103126 |
(Apache) When starting Apache using the plugin on Linux for ssl128, this error occurred: Cannot load /usr/local/apache/libexec/mod_wl_ssl128.so into server: /usr/local/apache/libexec/mod_wl_ssl128.so: undefined symbol: pthread_mutexattr_init Analysis revealed a build problem, which was solved by rebuilding the plug-in. |
CR103161 |
Duplicate of "CR097202". |
RMI-IIOP
RMI
Security
Servlets
Change Request Number |
Description |
CR077922 |
During testing, the session binding listener's (HttpSessionBindingListener) valueBound() and valueUnBound() methods were called multiple times for a single invocation. A code fix was implemented to prevent duplicate method calls. |
CR083624 |
A new configuration parameter, UseHighestCompatibleHTTPVersion, was added to the WebServer element in config.xml.This parameter causes WebLogic Server to send responses in the highest version of the HTTP protocol that is compatible with the version used in the request. For instance, setting this parameter to be true causes WebLogic Server to respond to an HTTP/1.0 request with an HTTP/1.1 response. This affects only the version-string portion of the response. The default setting for the parameter is false in WebLogic Server 6.1 The parameter value can be changed by editing config.xml. The Administration Console does not provide an interface for setting the parameter value. |
CR086579 |
Using the NSAPI proxy plug-in with form-based authentication through iPlanet listening on port 80, j_security_check was not redirecting correctly, and authentication failed. Analysis revealed that the form based authentication module did not call processRedirectedURL in the case of default port. |
CR086587 |
In WebLogic Server 6.1 SP03, the web server log (access.log), and the JDBC sub-system log (jdbc.log) were created relative to the product installation directory, instead to the RootDirectory. This problem was corrected with a code fix. |
CR087573 |
In WebLogic Server 6.1 SP01, when using JDBC persistence for a session and storing a complex object that contained nested hashMaps and TreeMaps, a subsequent request came before the session was persisted, resulting in loss of session data. The problem was solved with a code fix to move removeSession(id) to the end of method sync() in FileSessionContext.java. |
CR087647 |
The fix associated with "CR055987" introduced a timeout to solve the connection not being released problem. The fix introduced an InterruptedIOException that was not handled. When the exception was encountered, unwanted retries occurred. The problem was resolved with a code fix to catch InterruptedIOException and re-throw the exception to prevent retries. |
CR087984 |
In WebLogic Server 6.1SP02, ServletContextListener was invoked before HttpSessionListener. According to the 2.3 servlet specifications, session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown. A code fix was made to ensure compliance with the specification. |
CR088166 |
In WebLogic Server 6.1SP03, a web application generated a java.lang.ClassNotFoundException without indicated the name if the missing file: <[WebAppServletContext(4730538,olam,/olam)] Error loading servlet: ""> java.lang.ClassNotFoundException: Analysis revealed that WebLogic Server did not correctly handle a null or empty string value for the auth-filter tag. The problem was resolved with a code fix. |
CR088350 |
Using HttpProxyServlet to proxy to a 3rd party event server from KnowNow caused Internet Explorer 6 to wait indefinitely with no response. Analysis revealed that the KnowNow server : If there is no content length, and the data is not chunk transferred, WebLogic Server reads until the end of stream. If the KnowNow server keeps sending data, HttpProxyServlet keeps reading data. The problem was resolved with a new configuration parameter, UseKnowNow, that causes HttpProxyServlet to: To use this parameter, add this syntax to the web.xml for the HttpClusterServlet webapp. <init-param> <param-name>UseKnowNow</param-name> <param-value>true</param-value> </init-param> |
CR088384 |
In WebLogic Server 6.1SP02, getContextPath from HttpServletRequest returned incorrect value. For instance, for the request http://localhost//webapp/foo getContextPath returned /webap This error was corrected with a code fix. |
CR088478 |
The MaxSkips parameter for HttpClusterServlet and all plug-ins has been deprecated, and replaced with the MaxSkipTime parameter. With this parameter, |
CR088747 |
Session was lost when trying to re-establish a WebLogic Server session after a request to a web application that did not explicitly set CookiePath in weblogic.xml. Analysis revealed the browser (IE6) sent back two session cookies with different paths: According to J2EE, multiple cookies in the header are ordered such that those with more specific Path attributes precede those with less specific. WebLogic Server searched the cookie vector backwards for the JSESSIONID, for performance reasons, and hence encountered the less specific path . A code change was implemented to ensure that WebLogic Server uses the first cookie in the header. |
CR088759 |
In WebLogic Server 6.1 SP03, redirect-with-absolute-url = false did not work for j_security_check. This is because j_security_check stores a absolute path and passes it to the sendRedirect() method. j_security_check also should be aware of redirect-with-absolute-url. A code change was implemented to make FormSecurityModule redirect requests in accordance with the setting of redirect-with-absolute-url. |
CR089582 |
In WebLogic Server 6.1 SP03 under Solaris 8, when receiving a HTTP/1.1 request that did not have a Host header field, the value of Date header field that WebLogic Server returned was "Date: Thu, 01 Jan 1970 00:00:00 GMT". This made it impossible to determine when the erroneous request was generated. The problem was solved by a code change to set the request invoke time before sending the bad request error. |
CR089868 |
A performance fix introduced in WebLogic Server 6.1 Service Pack 3 (083654) caused multi-byte headers to become garbled. A work-around is available, but in SP03 and SP04, a patch was required to employ the work-around. (See 089868 for details.) In SP05, the CR089868 patch is no longer necessary. |
CR090033 |
WebLogic Server 6.1 SP03 threw a null pointer exception while parsing request when the WL-Proxy-SSL header precedes the Host header. This occurred with client running over HTTPS, and SSL accelerator, IPlanet, and WebLogic Server running over HTTP. The problem was only replicated when configuration included the SSL accelerator. java.lang.NullPointerException at weblogic.servlet.internal.ServletRequestImpl.setField(ServletRequestImpl.java:1903) at weblogic.servlet.internal.RequestParser.parse(RequestParser.java:254) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch(MuxableSocketHTTP.java:390) at weblogic.socket.MuxableSocketDiscriminator.dispatch(MuxableSocketDiscriminator.java:275) at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:633) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133) The error occurred because the context is null, as the request was still being parsed, and context was not yet known. The WL-Proxy-SSL went before the HOST header. Problem was resolved with a code fix. |
CR090188 |
For chunked data transfer WebLogic Server 6.1 SP03 prepended the chunk size to the data to bet transferred, hence adding extra characters to the data transferred. The problem was resolved with a code change, to move setChunking out of mergePostParams of ServletRequestImpl to MuxableSocketHttp after request.setInputStream. With this change, servlets and JSPs no long needs to decode chunk data. The WebLogic Server servlet engine will merge chunk data automatically. |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-14.jsp. |
|
CR090465 |
When hosting a web application with user-defined error pages, WebLogic Server returned the following response for 400 error and closed the connection immediately, with no Connection: close header: 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> The problem was solved with a code fix. |
CR090555 |
WebLogic Server threw a null pointer exception to HttpClusterServlet when checking for X_WEBLOGIC_CLUSTER_HASH. Stack trace: <Tue Nov 05 15:58:00 PST 2002>: Start connection timeout scheduler <Tue Nov 05 15:58:00 PST 2002>: GenericProxyServelt: init() <Tue Nov 05 15:58:00 PST 2002>: HttpClusterServlet:init() <Tue Nov 05 15:58:00 PST 2002>: ===New Request===GET /base;JSESSIONID=9G8ZGUTNwnNTXm8B5V5z41e hG0T3oChTPvhnXe7EHCZ1IQI5lgF4!822557425 HTTP/1.1 <Tue Nov 05 15:58:00 PST 2002>: Found cookie: 822557425 <Tue Nov 05 15:58:00 PST 2002>: Trying to get JVMID id from server: coolant!7003!443 <Tue Nov 05 15:58:00 PST 2002>: Update dynmaic hash: WakHYk8LlxQ7XrnhkSXEohfZMAw <Tue Nov 05 15:58:00 PST 2002>: java.lang.NullPointerException at weblogic.servlet.proxy.HttpClusterServlet.initDynamicServerList(HttpClusterServlet .java:761) at weblogic.servlet.proxy.HttpClusterServlet.getPreferred(HttpClusterServlet.ja va:622 ) at weblogic.servlet.proxy.HttpClusterServlet.service(HttpClusterServlet.java:21 |
CR090665 |
WebLogic Server 6.1 SP03, servlet filters had to explicitly call flushBuffer() on the response wrappers after having called chain.doFilter() to send the response to the client. This caused customers to have to write separate versions of the filter for different application servers. Not doing so causes the response to contain no data. This happens because of bytes being buffered in the printWriter's OutputStreamWriter object. A code change was implemented to ensure that user code does not need to explicitly call flushBuffer(). |
CR091410 |
When "extended format" is selected for the HTTP logging option and the server is restarted, the following Null Pointer Exception was thrown: <Oct 9, 2002 6:45:48 PM PDT> <Error> <kernel> <000802> <ExecuteRequest failed java.lang.NullPointerException java.lang.NullPointerException The problem was solved with a code fix to open access.log file if filename is null |
CR091759 |
RequestDispatcher.forward dropped the version number at the end of the URL header. The request should have been forwarded as: Request URI: /RequestDispatcher/SnoopServlet/myTest.txt;37 Instead, it was forwarded as: Request URI: /RequestDispatcher/ProxySnoopServlet/myTest.txt The problem was resolved to a code fix to set processPathParameters to false in setRequestURI() when doing forward(). |
CR091878 |
When HttpClusterServlet was undeployed during a load test, an .IndexOutOfBoundsException resulted: <Nov 27, 2002 4:05:11 PM PST> <Error> <HTTP> <101268> <ServletContext(id=5220998,name=proxywebapp,context-path=): Failed while destroying servlet: java.lang.IndexOutOfBoundsException: Index: 2, Size: 2 IndexOutOfBoundsException while destroying HttpClusterServlet Analysis revealed an error occurred when removing the last element in the connection pool with pool.remove(i). The problem was resolved with a code fix. |
CR092255 |
WebLogic Server 6.1 SP04 ignored the quote character (") if cookie valued includes a quote character. For example, this syntax: Cookie cookieWithQuotedValue = new Cookie("TestQuotedCookie", "\"TestValue\""); assigned TestValue is added as cookie value, not "TestValue". A code change was made to preserve quote characters in cookie values. |
CR092428 |
In WebLogic Server 6.1 SP04, comma character (,) in a Netscape cookie resulted in a Got bad cookie header error message. A code fix resolved the problem. |
CR092778 |
In WebLogic Server 6.1 SP04, JISAutoDetect encoding for HttpRequest resulted in this UnsupportedEncodingException: java.io.UnsupportedEncodingException: JISAutoDetect at sun.io.Converters.getConverterClass(Converters.java:102) at sun.io.Converters.newConverter(Converters.java:133) at sun.io.CharToByteConverter.getConverter(CharToByteConverter.java:62) at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding(ServletRequestImpl.java:344) ... This problem did not occur with WebLogic Server 6.1 SP03. The problem occurred because ServletRequestImpl.java used the CharToByteConverter class instead of sun.io.ByteToCharConverter. CharToByteConverter is the one for input converter. CharToByte is for output converter. JISAutoDetect is only available for input stream. The problem was corrected with a code fix. |
CR093167 |
In WebLogic Server 6.1 SP03, when using the HTTPClusterServlet to access a secure webapp on a backend cluster, Internet Explorer 5.5 hung for 30 seconds after the username and password were entered. The problem was not replicated in other browsers, and did not occur under Internet Explorer when accessing a back end server directly, rather than through the plug-in. The problem occurred because Internet Explorer does not close the connection when it gets a Connection: Close header from the server. When accessing WebLogic Server directly, WebLogic Server closes the connection when it throws a 401 error. However through the HttpProxyServlet, the browser-to-ProxyServlet connection was kept alive even though the backend server had closed the connection. The problem was solved by a code fix to GenericProxyServlet which causes the front end connection to disable KeepAlives when a Connection: Close header is returned from the back end server. This causes Internet Explorer to send the authentication details back straight away instead of hanging while waiting for WebLogic Server to timeout the connection. |
CR093209 |
A new installation of WebLogic Server 6.1 SP04 threw a null pointer exception when a successfully deployed web app that has a property set to java protocol is accessed. The browser returned Error 500--Internal Server Error. The problem did not occur with an upgrade installation. <Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP> <[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with Exception java.lang.NullPointerException at weblogic.servlet.JSPServlet.service(JSPServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2359) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) > Analysis revealed an error in ZipSource.getURL(). The problem was resolved by adding logic to check for null value of source.getURL(). |
CR093634 |
In WebLogic Server 6.1 SP03 the HttpRequest.getRemoteAddr() method returned the IP address of HttpClusterServlet instead of the client browser's IP address. Analysis revealed that HttpClusterServlet does not set the proprietary header, "WL-Proxy-Client-IP", and instead returns the IP address of the socket upon which it is listening. The problem was solved by a code fix to HttpClusterServlet to set the "WL-Proxy-Client-IP" header when WebLogic Plugin Enabled parameter is enabled. |
CR093755 |
The error message: <Warning> <HTTP> <WebAppServletContext(5294080,blue,/blue) One of the getParameter family of methods called after reading from the ServletInputStream, not merging post parameters> was erroneously generated. A code fix was implemented to ensure that the message is not generated erroneously. |
CR094488 |
A new capability was added to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add AuthCookieEnabled="true" to the WebServer element in config.xml: <WebServer Name="myserver" AuthCookieEnabled="true"/> This will cause an new secure cookie to be sent to the browser when authenticating via an HTTPS connection. Once set, the session can access other security-constrained HTTPS resources only if the cookie is sent from the browser. Note: If authenticating via plain HTTP, the secure cookie will not be set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie will not be verified (since it will not have been sent from the browser). This allows the browser to access non-protected HTTPs resources without the user logging in. |
CR094773 |
Duplicate of "CR094561". Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp. |
CR094997 |
In WebLogic Server SP02, when two interacting web applications use different session cookie names, the session ID was lost. Analysis revealed that session attributes were not updated correctly when a web application specifies cookieName, a resource from another web application is included, and a RemoteUser exists in the request prior to the inclusion of the external resource. The problem was solved by a code fix. |
CR095548 |
During testing, session data was lost intermittently, when the persistence type was JDBC. The following exception occurred: weblogic.qa.tests.cluster.webapp.plugins.RequestSessionBeforeInvalidateTest.testRequestSessionBeforeInvalidationTest() Session Was Invalidated Sent: http://qa47-1:7771/pluginsjdbc/SessionBeforeInvalidate.jsp?count=1 Received: <html><body>PROBLEM: session is not the same as the first request!FirstRequest sid: 2tjgF02nPIGgHGyojFubyOIjqt0ZAVK4no1Ny0afTxGKMrOj25z5!2356550501043194848402Sid The problem was resolved with a code fix to the isRequestedSessionIdValid() method. |
CR095570 |
WebLogic Server 6.1 SP04 threw a NullPointerException when a null value was set in a servlet HTTP header: <Jan 22, 2003 11:11:53 AM KST> <Error> <Kernel> <Execute Request failed java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.servlet.internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal. ServletResponseImpl.writeHeaders(ServletResponseImpl.java:902) at weblogic.servlet.internal.ServletOutputStreamImpl. sendHeaders(ServletOutputStreamImpl.java:239) at weblogic. servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal. ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStream Impl.finish(ServletOutputStreamImpl.java:531) at weblogic. servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.Servlet RequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread. java:120) End server side stack trace at weblogic.servlet. internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal.ServletResponseImpl. writeHeaders(ServletResponseImpl.java:902) at weblogic. servlet.internal.ServletOutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:239) at weblogic.servlet.internal. ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal.ServletOutputStream Impl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStreamImpl.finish(ServletOutputStreamImpl.java:531) at weblogic.servlet.internal. ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread. execute(ExecuteThread.java:139) at weblogic.kernel.Execute Thread.run(ExecuteThread.java:120) The problem was resolved by added logic to check for null values in ResponseHeaders.java. |
CR096459 |
Response time for a web application deployed to WebLogic Server 6.1 SP02, when accessed from a browser set to HTTP Version 1.0 with flushRes=true. The problem did not occur with flushRes=false. Analysis revealed that useKeepAlive was reinitialized inappropriately. The socket connection was not closed when it should have been, and the client waited for the socket to time out. A code fix was implemented to initialize useKeepAlive when setting request and response. |
CR097719 |
In WebLogic Server SP02, SP03, and SP04, when getting certain POST requests from WAP devices, a web application encountered a java.util.ConcurrentModificationException <29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at weblogic.utils.enumerations.IteratorEnumerator.nextElement(IteratorEnumerator.java:25) at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML(XMLSwitch.java:347) at ... Analysis revealed that when a charset is associated with the request's content-type, the code read the data again using the encoding, and reset the query parameters, in the application. The application already has the enumeration object and iterates it (request.getParameterNames), and then tries to get the value of the parameter (request.getParameterValues(k)). At that point, the query parameters are wiped out and getParameterValues method tries to set it, resulting in the exception. The problem was resolved by a code change to set query parameters after they are wiped, so that the data can be read again when a charset is associated with the request's content-type |
CR098955 |
The scheduled log rotation time for a WebLogic Server HTTP server log was calculated incorrectly when weblogic.httpd.logRotationBeginTime was a date in the past. The error was corrected by changing the data type of operands used in the calculation from INT to LONG. |
CR099984 |
The input stream was consumed by the servlet engine before the servlet code could access it. This problem was resolved by a code change to ensure that internal reads do not consume the input stream. |
CR100265 |
If the request received has no cookie but does have valid credentials WebLogic Server should allow access to the protected resource. Instead, this exception occurred: java.lang.NullPointerException at weblogic.servlet.security.internal.SecurityModule.checkAuthCookie(SecurityModule.java:579) at weblogic.servlet.security.internal.BasicSecurityModule.checkUserPerm(BasicSecurityModule.java:157) at ... The problem was solved with a code fix. |
CR100572 |
When a request with an incorrect URI was received from a from plug-in, WebLogic Server threw this stack trace <Mar 8, 2003 3:27:20 PM PST> <Error> <Socket> <BEA-000421> <Uncaught Throwable i n processSockets java.lang.NullPointer Exception. java.lang.NullPointerException at weblogic. servlet.internal.ServletResponseImpl.writeHeaders(ServletResponseImpl.java:968) at weblogic.servlet.internal.Servlet OutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:244) at weblogic.servlet.internal.ServletOutputStreamImpl. flush(ServletOutputStreamImpl.java:121) at weblogic.servlet. internal.ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:486) at weblogic.servlet.internal.ChunkOutput. commit(ChunkOutput.java:269) at weblogic.servlet.internal. ChunkOutputWrapper.write(ChunkOutputWrapper.java:91) at weblogic.servlet.internal.ChunkWriter.write(ChunkWriter.java:37) at java.io.Writer.write(Writer.java:150) at java.io.PrintWriter.write(PrintWriter.java:230) at java.io.PrintWriter.write(PrintWriter.java:247) at java.io.PrintWriter.print(PrintWriter.java:378) at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:420) at weblogic.servlet.internal. ServletResponseImpl.sendError(ServletResponseImpl.java:373) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch (MuxableSocketHTTP.java:512) at weblogic.socket.MuxableSocket Discriminator.dispatch(MuxableSocketDiscriminator.java:281) at weblogic.socket.NTSocketMuxer.processSockets(NTSocket Muxer.java:102) at weblogic.socket.SocketReaderRequest. execute(SocketReaderRequest.java:32) at weblogic.kernel. ExecuteThread.execute(ExecuteThread.java:178) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151) This problem was solved with a code fix. |
CR100172 |
When multiple chunked requests are posted to a servlet a number of the requests fail with a NumberFormationException. Mostly of the time alternate requests are fulfilled and the next request fails. It seems to be occurring as the requests are being made on the same connection. The exception stack trace is: <ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException: at java.lang.Integer.parseInt(Integer.java:430) at weblogic.utils.http.HttpChunkInputStream.readChunkSize(HttpChunkInputStream.java:118) at weblogic.utils.http.HttpChunkInputStream.initChunk(HttpChunkInputStream.java:72) Analysis revealed two problems in PostInputStream:
The problem was solved by a code fix to read until end of stream in PostInputStream and correctly detect end of chunk in HttpChunkInputStream. |
CR100837 |
WebLogic Server 6.1 SP04 misdirected output for JSP includes in JSP pages. The problem was corrected with a code fix. |
WLS-Tour/Examples
Web Services
Change Request Number |
Description |
CR087529 |
In WebLogic Server 6.1SP03, the client for the sample web service at samples\examples\webservices\rpc\weatherEJB was built by wsgen and deployed using only the client.jar (no weblogic.jar). When the non-SSL web service was invoked by the Java client, the following exception was thrown: << Missing class files in servicegen client.jar. Getting Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/net/http/HttpsURLConnection at weblogic.soap.http.SoapContext.lookup(SoapContext.java:87) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.verizon.client.client.main(client.java:72) >> Analysis revealed that the weblogic.net.http.HttpsURLConnection class is necessary for minimal out-of-the-box functionality and should be included in the client.jar. The problem was solved by adding weblogic.net.http.HttpsURLConnection to client.txt |
CR091862 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-23.jsp. |
CR095044 |
In WebLogic 6.1 SP03, when org.apache.soap.Fault was used (to represent the contents and semantics of a <SOAP-ENV:Fault> element), the Fault.getDetailEntries() method call should result in a Vector of exceptions, when the web service operation throws an exception. Instead, in WebLogic 6.1 SP03, this call returns a null and the client does not get to see the exception stack trace. This problem does not exist in SP02. The client runs with the same CLASSPATH while hitting either the WebLogic 6.1 SP02 or WebLogic 6.1 SP03 server instances. The problem was reproduced with the client CLASSPATH: CLASSPATH=.;.\soap.jar;.\xerces.jar;.\j2ee.jar The difference in behavior is that in SP03, the content of the fault detail is wrapped in <![CDATA[ ]]>. This is done to prevent the parser from failing if the stack trace contains something like <<no stacktrace available>> The problem was resolved by the addition of a new servlet initialization parameter, cdata-fault-detail, which if set to false, causes fault detail to not be wrapped in <![CDATA[ ]]> <servlet> ... <servlet-class>weblogic.soap.server.servlet.StatelessBeanAdapter</servlet-class> <init-param> <param-name>cdata-fault-detail</param-name> <param-value>true</param-value> </init-param> ... If cdata-fault-detail to false, if the stack trace contains something like <<no stacktrace available>> a parser error will result. |
CR096906 |
WebLogic 6.1 SP04, did not return dateTime entries correctly when a web service generated by WebLogic Server was called. The "+" char was omitted from the time zone offset part of the dateTime entry, when the time zone offset is positive (i.e., GMT+1 = CET [time zone for Denmark]). Example: February 3rd, 2003 09:12:04 CET should be dateTime: <date xsi:type="xsd:dateTime">2003-02-03T09:12:04.000+01:00 Weblogic sent it as: <date xsi:type="xsd:dateTime">2003-02-03T09:12:04.00001:00 The problem was resolved with a code fix. |
CR098364 |
In WebLogic 6.1 SP03, when Ant was used to generate a .war file with Web Services using this WebLogic task: <taskdef name="wsgen" classname="weblogic.ant.taskdefs.ejb.WSGen"/> and the Transactions.jar file had more than 155 EJBs, the wsgen failed. The problem was resolved by a code fix to CompilerInvoker. |
CR099255 |
In WebLogic 6.1 SP04, in the weblogic.soap.WebServiceProxy class, the invoke() method did not check if certs had been set in the class. This caused two-way authentication to fail, or alternatively if the certs are passed to the InitialContext the http protocol did not work. The problem was solved with a code fix. |
WebLogic Tuxedo
XML
Change Request Number |
Description |
CR091862 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-23.jsp. |
WebLogic Server 6.1 Service Pack 4 Solutions
The following sections describe problems that have been resolved with WebLogic Server 6.1 Service Pack 4.
Classloader
Cluster
Console
EJB
Examples
JDBC and jDriver
JMS
Change Request Number |
Description |
063743 |
Fixed a problem that was resulting in Message Driven Beans not acknowledging object messages |
079547 |
Fixed a deadlock that created problems while creating Durable Subscribers to JMS servers deployed in a clustered environment. |
081525 |
Calling TopicSubscriber.close() in a cluster no longer throws a weblogic.management.NoAccessRuntimeException. |
080668 |
In a clustered environment that sets listeners for the JMS Server, a NoSuchObjectException was being thrown if one of the nodes of the server was started after some time, rather than immediately. This has been fixed. |
082298 |
The number of durable JMS subscribers was incorrect. An extra increment was occurring each time a consumer attached to a durable subscription. The number is now incremented when the subscribers are created and decremented when they are deleted. |
082438 |
Prior to Service Pack 4, for JDBC connection pools that were created dynamically, the STATEMENT_CACHE_SIZE parameter was not implemented. This is corrected in SP04, so that dynamic connection pools can use the Statement Cache to cache and reuse prepared and callable statements. |
083290 |
Fixed problems with JMS recovery in managed servers when the primary server goes down and then is restarted. |
083503 |
Fixed a problem with JMS and Message-Driven-Bean recovery when starting and stopping managed servers. |
084175 |
Messages were being lost when sent through MessagingBridge and interrupted by a server re-start. If while messages were being processed by the MessagingBridge (messages being processed from MQ Queue to WebLogic JMS Queue), and the WebLogic server was stopped and then re-started, then in some cases, some messages were lost. The number of messages lost corresponded to the BatchSize of the MessagingBridge. This problem has been fixed. |
084182 |
The setExceptionListener method no longer throws a NullPointerException when exceptionListener is set to null. |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-24.jsp. |
|
CR086487 |
see CR83503 |
CR093060 |
Duplicate of "CR084374" above. |
Miscellaneous
Change Request Number |
Description |
049340 |
The DeploymentOrder on the ComponentMBeans can now be initially set based on the ordering in the application.xml file making re-deployment consistent with initial deployment. |
053054 |
Fixed a problem where the server was not copying the transaction context. There were rjvm errors when a client that spawned a new JVM after binding an implementation class into the JNDI tree; the new JVM was not able to make RMI calls on the method. |
053957, 071626, 075394, 076265, 078527, 079652, 079655, 082693, 082830 |
This Service Pack improves WebLogic's handling of RJVMs in multiple ways. Fixes include: WebLogic Server now ensures that a valid connection has been fully established between servers running on local and remote Java virtual machines before it attempts to send a message to an RJVM. Possible deadlocks resulting from establishing a valid connection between servers running on local and remote Java virtual machines have now been fixed. Previously, it was possible for RJVMs to get into an infinite-wait state while waiting for the connection to be established because the notification of a successful connection was issued before the RJVMs went into a wait state. The fix makes it possible for a success notification to be detected, even if it happens before a wait. Multiple threads trying to establish a connection to an RJVM at the same time now rely on the success or failure of the first thread that actually manages to establish the connection. Previously, each thread would always attempt to establish a connection in turn, rather than using the connection established by the first thread that succeeded. Peer WebLogic Servers running on different computers now correctly detect when a peer server with which it has previously established a connection has gone, and correctly cleans up the broken connection. The Remote Method Invocation (RMI) layer now receives proper exceptions to failover when an attempt to get an OutputStream fails. Previously, when two peer servers where trying to establish a connection but failed to, an exception was not thrown to the RMI layer, causing improper failovers or delays to a proper failover. Possible deadlocks have been fixed between 2-way calls from T3JVMConnection to ConnectionManager to RJVM. |
056403, 063910, 076409, 076903, 078288, 078918, 079599, 080292, 080744, 081010, 081116, 081856, 082700,083623, 086362. |
We fixed multiple muxer problems and added improvements including: Collections in all muxers (Java and native-code) that map to sockets now have unique keys. This has solved a variety of problems, including data corruption, bad pointer references, WebLogic Server hangings and crashes. Data structures and state machines in muxers now have proper synchronization. This fixed certain classic deadlocks caused by conflicting order of locking. The call stacks between the muxer and the protocol layers above the muxer are now 2-way, which means a close of a socket or connection can be initiated from any point in the stack. Safeguards have been added to prevent deadlocks. State machine transitions in the muxer have been fixed, resulting in sockets no longer remaining in a CLOSE_WAIT state. |
064301 |
If the application server is killed abruptly, there is a high probability of creating a distributed in-doubt transaction. In WebLogic Server 6.1 SP01, the distributed in-doubt transaction still continued to exist and needed to be resolved by manual DBA intervention. In WebLogic Server 6.1 service pack 4, the transaction log file is re-scanned and a recovery process is initiated after re-starting the application server. |
071510 |
It was not possible to start the server using JMX through the NodeManagerMBean. In WebLogic Server 6.1 service pack 4, new methods were added in the ServerMBean to start and kill ManagedServers via the JMX client. |
072188 |
The admin server was not closing the network connection that it established with NodeManager after completing the task. This has been fixed. |
073023 |
Node manager no longer randomly throws the OutputHandler error when trying to start a remote server. |
074844 |
Fixed a problem that was causing an assertion error when using dynamic proxies. |
075406, 076002 |
Fixed problems occurring under heavy load where NullPointer and ClassCast exceptions were occurring; also made some improvements to the NT muxer. |
076605 |
Fixed a problem that was causing the message: <ExecuteThread: '12' for queue: 'default'> <> <> <000000> <No IORecord present for fd> to appear. |
076705 |
Message Driven Bean deployment no longer fails and results in a NoAccessRuntimeException for guest if the destination is remote. |
076997 |
Now, when deploying an EAR component to a cluster through MBeans, the JNDI bindings appear in all managed servers without the need to re-start the servers. |
077248 |
Fixed problems connecting to EJB's over IIOP when native IO is turned off. |
077831 |
When the AppletArchiver utility was used to generate a client JAR file and if the applet in question used the javax.swing.JApplet class in its code, then the AppletViewer was producing an error. This has been fixed. |
077919 |
Using patch CR064447_61sp2.jar was causing an error in the log file after calling ObjectOutputStream.writeObject() on EJBHandle. The output of the EJBObject in the log was changing from LocalServerRef to LeasedRemoteRef. This has been fixed. |
078431 |
Fixed a problem that was causing a deadlock between MuxableSocketHTTP and PosixSocketMuxer. |
078952 |
An org.omg.CORBA.MARSHAL exception is no longer thrown while a null value in a serializable object from an EJB's remote method is being returned. |
079220 |
When running JMS, the client was getting the exception: |
079672 |
A VM crash is possible when WarClassFinder.getSource is invoked. Sun's fix for this problem are in JDK's 1.4.1_02 and 1.3.1_07. The Sun bug is: http://developer.java.sun.com/developer/bugParade/bugs/4369396.html. |
080177 |
Using weblogic.deploy no longer causes memory leaks if you continually deploy and delete the same EJBs. |
080740 |
If a web application that creates a file that got deleted when the server was shutdown, when running as a Windows Service, this file got deleted as expected when the server was shutdown from the command line (using the java weblogic.Admin SHUTDOWN command) or from the administration console. However, this file did not get deleted when the server was shut down by going to: Start Menu --> Settings --> Control Panel --> Services --> Press Stop button for the service. This capability is now implemented. |
080895 |
When a stand-alone java client was calling a stateless session EJB, after about 500000 iterations, the following exception was being thrown on the client side: This has been fixed. |
080901 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-19.jsp. |
080929 |
Now, if using wildcards, weblogic.refresh can refresh files. |
081311 |
A SAXParseException on the DTD now has a severity of <Warn> instead of <Info>. |
081404 |
The JMS Bridge Resource Connectors (jms-xa-adp.rar, jms-notran-adp.rar, jms-notan-adp51.jar) for Messaging Bridge are packaged with WebLogic Server 6.1 Service Pack 4. |
081568 |
SNMP Agent can now monitor the ServletRuntime of Servlets. |
081732 |
Using WebLogic Server 6.1 SP03, an exception was being thrown when using the Sybase database while trying to start the server. This has been fixed. |
081765 |
There were problems with SSL closing sockets prematurely and causing muxer errors. |
081853 |
Fixed some complicated problems with RMI-IIOP and the marshalling of complex objects, notably in environments using a mixture of JDKs. |
081868 |
In WebLogic Server 6.1 service pack 2, when the admin server was shutdown using java weblogic.Admin SHUTDOWN, the SNMP agent was not generating the serverShutDown trap. It was able to generate serverStart trap when the server started up. Now, when the admin server is shutdown, the SNMP Agent will issue a self shutdown trap. |
CR081870 |
In the WebLogic Server distribution of Xalan, when the XSLT output method was set to HTML (required): <xsl:output method="html"/> the spaces in HREF attributes in anchor tags are encoded to "%20". For example: <a href="javascript: var win = openWindow()">Link</a> erroneously outputs as: <ahref="javascript:%20var%20win%20=%20openWindow()">Link</a> Netscape fails to interpret the "%20" as a space, breaking the link. If the output type is changed to "XML" (not an applicable workaround in this case), the attribute outputs correctly. The vanilla Xalan distribution (i.e. not the BEA-enhanced version) performs the transformation correctly with identical input. WebLogic Server distribution of Xalan performed inappropriate URL encoding on the HREF attribute. This works fine for normal URLs (i.e., http://somehost/...) where spaces are not allowed, however javascript URLs (i.e. javascript: doSomething()) are also valid and should not be encoded. The XSLT transformer should not be doing anything to the URL as there are already ways to explicitly encode URL's in stylesheets. Problem occurred in WebLogic Server 6.1 SP2, SP3, and SP4. Problem was solved by modifying the XSLT transformer to not encode the URL. . |
082004 |
The CR073910_61sp2.jar patch on WebLogic Server 6.1 service pack 2 was resulting in a memory leak. when getting a new InitialContext(). |
082263 |
The weblogic.deploy tool is now able to update the web application .war file from Win2k to a server running on Solaris. |
082533 |
Debug messages were being written to std.out when using the Xerces Parser. These messages have been removed. |
082693 |
In WebLogic Server 6.1 service pack 1 and 2, if the server received a call from the old generation stubs, the server correctly sent peerGone to the client and logged an error. In WebLogic Server 6.1 service pack 3, the server printed a NullPointeException and the client waited until timeout. Now we have restored the earlier, correct, behavior. |
083102 |
When deploying a couple of EJBs (that conform to the EJB 2.0 specification) with J2EE12OnlyModeEnabled="true", the server was throwing a couple of warning messages for a few beans and then crashing with a DistributedManagementException. This has been fixed. |
083485 |
When invoking a t3 client, the client no longer hangs in JavaSocketMuxer with t3 as the default protocol. |
083652 |
In WebLogic Server 6.1 service pack 3, applications were undeployed at startup and then redeployed twice. This has been fixed. |
083654 |
Improved the performance of WebLogic Server 6.1 service pack 3, when continuous requests are issued from the Microsoft WAS tool. International users, see 089868 for related information. |
083721 |
The FailureIsFatal option of the startup class no longer suppresses the runtime exception on a Solaris Environment. |
083920 |
Suppressed any startup traps when the admin server is re-started and it discovers that managed servers are up to avoid redundant traps being sent when the admin server is re-started. |
084127 |
In production mode, even with auto-deployment turned off, WebLogic Server was still validating some application files that were not configured in the config.xml file. This has been fixed. |
084622 |
Using ZAC no longer results in an assertion error when getInitialContext() is called. |
085463 |
JNDI lookup failover now no longer takes such a long time when the network plug is pulled. |
085914 |
SNMP request was timing out after a managed server was dropped. The SNMP agent no longer becomes unresponsive for a while on getnext requests when a managed server is down. |
085979 |
Fixed a problem with MBeanHome.getAllMBeans() unnecessarily throwing an exception when a custom Mbean is defined. |
086108 |
We improved performance; the ListenThread now consumes less memory than in Service Pack three. |
086248 |
The component type for boxed RMI sequences was being forwardly declared twice-once correctly and once as an interface; the wrong type for sequences of valuetypes. |
086350 |
Fixed a problem where if an exception's classname ended in a capital 'I' the IDL generated from it is mangled and corrupt. |
CR086362 |
Under heavy loads SocketException: Connection timed out errors occurred. Stack trace: ####<Sep 18, 2002 9:37:07 AM EDT> <Error> <Posix Performance Pack> <lpsapp01> <LPSAPP01_C> <ExecuteThread: '34' for queue: 'default'> <> <> <000000> <IOException on socket: 'weblogic.rjvm.t3.T3JVMConnection@67cf01', fd: '1046'> java.net.SocketException: Connection timed out: Connection timed out Start server side stack trace: java.net.SocketException: Connection timed out: Connection timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:824) at weblogic.socket.PosixSocketMuxer. and the server instance hung with sockets in the CLOSE_WAIT state. Thread dump: "ExecuteThread: '3' for queue: 'default'" daemon prio=5 tid=0x7f79a8 nid=0x10 waiting for monitor entry [0xa6101000..0xa6101a40] at weblogic.socket.PosixSocketMuxer. Thread dump analysis indicated that the thread in native AddFdToPollSet did not finish writing to PollSet Loopback FD, and release POLLSET_LOCK properly. Problem was resolved by tracking the number of bytes written to pipe, and waiting to write more to pipe (using an array instead) until thread reader notification that it is OK to write to the pipe. |
086761 |
The Weblogic.admin tool now correctly creates an execute queue so that it will be functional on server start-up. |
087265 |
Fixed several incompatible serialVersionUID's so as to keep interoperability between WebLogic versions. |
088372 |
Now, under load, we have fixed the problem that was generating multiple exceptions like: ArrayIndexOutOfBoundsException in weblogic.security.acl.TTLCache.cleanup. |
089044 |
Loading the Administration Console no longer causes a browser/OS compatibility check. |
Plug-ins
Servlets, JSPs, and Web Applications
Change Request Number |
Description |
042655 |
When using the access.log in the extended log format, the times at which the http requests are made are no longer given as the local time, instead of the GMT time. |
053974 |
Besides being able to configure the name of the access.log, users can now select the convention for the rotated log for manageability. |
058389 |
When getInputStream() is called against javax.servlet.http.HttpServletRequestWrapper, it no longer returns null. |
063630 |
If a Web Application failed to deploy, then no other applications were getting deployed to a cluster. This problem has been fixed. |
065967 |
Taglibs no longer fail when <type> is specified and the type is an array. Weblogic Server no longer sees it as a string when it is actually an array. |
068577 |
In the generated code, the method _releaseTags() was not being called upon a <jsp:forward> although according to the JSP specification 1.2, all tag handlers need to be released upon DO_END_TAG. This has been fixed. |
069731 |
When using JSPs in a webapp, the .java files that get created from the JSPs live under _tmp_war (under the webapp root). If it does not exist already, the _tmp_war directory is created at the time of WebApp deployment (during the initialization period after you start the server). If the server is run as root, the _tmp_war directory gets created by, and is owned by, root. At the end of initialization, nonPrivUser was being used to switch to a nonpriviledged user and the _tmp_war directory was inaccessible by the JSP servlet and WebLogic. This has been fixed. |
071513 |
WebLogic Server is now validating the weblogic.xml file in the webapp. |
073780 |
Improved the performance of JSP tags when using WebLogic Server 6.1 service pack 2 and the following three patches: CR065452A_610sp2.jar, CR063457A_610sp2.jar, and CR063829_610sp2.jar |
073791 |
Fixed problems were customers were getting a NullPoinerException in the ChunkUtils.getEnd method after calling ServletOutputStreamImpl.write from their servlet code. |
074265 |
The ServerMBean has a new attribute called MaxBackoffBetweenFailures. The default is 10 seconds. Set this to change the time period in which the server listen thread will send a "Failed to listen on port" if it is still trying to accept the socket connection. |
074940 |
A NullPointerException is no longer thrown when using the size Cache Tag Attribute of the Cache Tag of the weblogic-tags.jar. |
075471 |
JRun tag libraries are working on WebLogic Server service pack 4. |
075721 |
The jsp:useBean tag with the beanName of TimeExpression is no longer interpreted incorrectly. |
076375 |
weblogic.log and access.log (HTTP Logs) will now be renamed based on the configuration of the log filename. Usage of % symbols in the logfile name will invoke the logic which renames log files based on the date/time when it gets rotated. The file being currently logged into will be the log filename stripped off its % symbols if they exist. Examples of valid formats: weblogic_%yyyyMMdd%_%HH%_%mm%.log foobar_%yyyy%-%MM%-%dd%_%HH%_%mm%.log Note: Y (capital) does not represents anything in the SimpleDateFormat. Use lower case y (small) to represent the year. Invalid formats will fall back to WebLogic Server default log file names. A string enclosed between percentage signs (%) will be decoded based on SimpleDateFormat. This format applies to the filename, not the directories. |
077018 |
Prevented a ClassCastException in ServletAuthentication when using request/response wrappers. |
077306 |
Temporary patches no longer cause recompilation of included (precompiled) JSP classes. |
077422 |
The CookieParser.cookieToString creates the expires cookie with a SimpleDateFormat that contains a comma, ','. The comma in the expires date is causing the cookie to be parsed incorrectly when it is returned in the request. The comma is interpreted as a cookie separator and breaks the parse of the expires date. This has been fixed. |
077888 |
setCharacterEncoding will now throw UnsupportedEncodingException. |
078090 |
According to the JSP specification, if you use jsp_precompile in the request parameter, the container should compile the JSP (if not compiled), but must not display the JSP. Since WebLogic Server parses the query string and finds the jsp_precompile, it was not displaying the page on the browser. |
078262 |
Added getResourcePaths(String) to the ServletContext. |
078325 |
Fixed a problem that was resulting in an UnsupportedEncodingException if there were extra quotes around the charset value. |
078698 |
The access.log file is now rotating by size when the log size exceeds 2MB. |
079582 |
WebLogic Server 6.1 service pack 3 threw a SocketException during data sync. This has been fixed. |
079767 |
When redeploying EAR, WAR, or JAR files to WebLogic Server, with every redeployment of an application or component, the .wlnotdelete directory of the managed server no longer increases in size. |
079892 |
The CPU usage no longer pegs to 100% while executing a CGI script and hitting the stop button in the middle. |
080090 |
When re-directing, the location header will always use the following parameters, if they are specified: FrontendHTTPPort |
080384 |
The HttpClusterServlet was marking a server as bad, even if just one response had been scrambled in the status code header. This has been fixed. |
080751 |
Custom exceptions extending servlet exceptions will now be redirected to error page if configured. |
080791 |
Folded headers in the cluster/proxy servlets are now considered. |
080837 |
Added a new element in the weblogic.xml file: <!-- |
081071 |
There is no longer a NullPointerException thrown at weblogic.servlet.internal.ServletContextManager.trimAbsUrl. |
081484 |
Session attributes are no longer lost when using the HttpSessionListener with PersistentStoreType as replicated but able to retrieve the session attributes when non-replicated. |
081521 |
It is now possible to call a CGI script from a JSP. |
082156 |
isRequestedSessionIdValid() always returned the value, true, which means that the request session ID is valid, even if you changed the session ID in the URL. Invalid sessions are now correctly detected and reported as invalid. |
082238 |
CreateSessionServlet was checking for the existence of the Cache-Control header, setting it to a valid value if it exists, or adding it to the header list if it does not exist. In both cases, it added another bogus header. This problem was fixed by setting CacheSessionCookie to true in weblogic.xml. |
082310 |
JSPs with a page contentType directive can now be deleted or overwritten in an exploded WAR file. |
082580 |
HTTP POST parameters were not preserved if a form-based authentication is invoked and authentication is successful when accessing a URL in WebLogic Server 6.1 service pack 3. |
082671 |
Made HttpSession.getServletContext() public in the internal implementation. |
083191 |
The console is no longer displaying incorrect values for Servlet Average Execution Time. |
083200 |
WebLogic Server is now filtering correctly with nonProxyHosts. |
083487 |
CGIServlet now works with exact match <url-pattern>. |
083517 |
HttpClusterServlet was not proxying a request to SSL even when SecureProxy was ON. This has been fixed. |
083597 |
In WebLogic Server 6.1 service pack 3, if the content type using the page directive is set as: |
083912 |
An ORA-01461 error no longer occurs while the server is trying to write the session data in the JDBC managed persistence when using the Oracle thin Driver. |
084002 |
When WebLogic Server returned an HTTP code 204, it set the Content-length to 886 with an HTML error page. Therefore, the load runner client was failing and generating an error stating that "204 responses codes should not have a body but the Content-length was set to 886 (with an HTML error page)". This has been fixed. |
084030 |
When an exploded web-app was shared by two servers, the generated tmp lib directory got deleted at the second server's start. The directory is no longer deleted. |
084058 |
The request.getUserPrincipal() method was returning guest after ServletAuthentication.logout(). Now, the getRemoteuser() returns null. |
084536 |
Fixed a problem where the patch for CR083377 was causing problems with security and the SSL connection. |
084649 |
There are certain environment variables that a CGI server is expected to provide to scripts that run within it. SERVER_URL, HTTP_COOKIE, and QUERY_STRING, which are present in Netscape's CGI server, were unavailable when running the same CGI program inside of WebLogic's CGI servlet. When a request was made for one of these variables, NULL was returned instead of a value. This has been fixed. |
084785 |
The GenericProxyServlet can now handle wrapped responses. |
084847 |
For chunked transfer, WebLogic Server was including a hexadecimal number which other servlet engines used to ignore. This has been fixed. |
085754 |
If newlines/comments were put in the intermediate JSP BEATestCase2.jsp, when used with a request dispatcher, the client got a blank page. There was no exception thrown on the server side. This has been fixed. |
086026 |
The parameter, CacheSessionCookie, used to default to false. Now, it defaults to true. |
086052 |
HTTPS connections outbound from WebLogic Server did not work without a trailing slash '/' on the URL. This has been fixed. |
086280 |
There is no longer a NullPointerException thrown when accessing a servlet over a Keep alive connection. |
086481 |
Fixed some problems when a web application downloads a larger file and the buffer overflows while reading the multi-part form data. |
088301 |
Fixed problem where an included resource was not sent to the servlet output stream when dispatched from another resource that was Forward dispatched inside a JSP BodyTag. NOTE: The nested BodyTag tag output stream was not being flushed since the forward dispatched request caused the tag to exit - but WebLogic still presumed the output should go to the Tag's nested output stream. This was resolved by clearing out reference to the BodyTag nested output stream when the Forward request was dispatched. |
CR089803 |
Duplicate of "CR090225". Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-14.jsp. |
Security
System Administration
Web Services
WebLogic Tuxedo
Change Request Number |
Description |
Integer array object passed by value from Tuxedo to WebLogic Server threw a weblogic.utils.AssertionError. The problem was resolved with a code fix. |
XML
WebLogic Server 6.1 Service Pack 3 Solutions
The following sections describe problems that were resolved for the release of WebLogic Server 6.1 Service Pack 3.
Classloader
Cluster
Console
Core
Change Request Number |
Description |
CR073529 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-20.jsp. |
EJB
Examples
JDBC
Change Request Number |
Description |
052393 |
Updated the thin driver so that it does not have an error in JDBC session persistence while putting StringBuffer object. |
054864 |
In 6.1 service pack 2 the server was hanging when using MultiPool with more than one database under heavy load. The MultiPool request would hang because the database was not responding which resulted in the whole server locking up at weblogic.jdbc.common.internal.MultiPool.searchHighAvail(MultiPool.java:200).The cause was over-synchronization in the code which has been fixed in 6.1 service pack 3. |
057340 |
When a connection pool is empty, the message now says "No available connections in pool." |
057977 |
Connection pool does not rollback anymore on cleaning up JTS connections |
059020 |
Deadlock no longer occurs if weblogic.jdbc.common.pool.shutdownSoft() is called when the connection pool is used by another user. |
061786 |
CREATE_POOL now fires the connection pool just after DESTROY_POOL. |
064198 |
Several classes were directly referencing optional Oracle classes in the server side code. This no longer occurs. |
066001 |
Added a property to the JDBCConnectionPool XAPassword to encrypt the database's password. |
066964 |
When using the WebLogic jDriver for Oracle/XA for a JDBC connection pool, refreshing the connection pool after a DBMS failure and restoration occasionally resulted in a core dump. This has been fixed. |
066966 |
The ResourceAllocator monitor is no longer held while making a JDBC call to test table. |
068490 |
Synchronized the call to xa_open at the java level. |
068952 |
Provided automated build scripts for jDrivers. |
070209 |
It is now possible to use the Oracle 9.0.1 Thin Driver to connect to an Oracle database. To use the driver, include the path to the driver class files (classes12.zip) to your CLASSPATH before the entry for weblogic.jar. |
071974 |
PreparedStatement cache size set to 0 by default. |
073640 |
Added a new attribute for a JDBC connection pool: Open String Password (or XAPassword in the config.xml file). This new attribute allows for encryption of the database password in the open string for connection pools that use an XA JDBC driver that requires an open string. For more information, see Database Passwords in Connection Pool Configuration in the Administration Guide. |
076090 |
Improved the behavior of database passwords included in the Properties attribute of a JDBC connection pool. If you specify a database password as part of the connection properties or open string, WebLogic Server parses the values and moves them to the Password and Open String Password attributes, respectively, which are encrypted when stored in the config.xml file. For more information, see Database Passwords in Connection Pool Configuration in the Administration Guide. |
jDriver
JMS
JTA
Miscellaneous
Change Request Number |
Description |
042372 |
The API URL() provided in WebLogic now functions properly. For some URLs, it was causing an exception error. |
050388 |
Statistical information for the Jolt connection pool is now being displayed in the console. |
052478 |
A timing related JVM bug on Solaris is encountered that causes the VM to exit during object de-serialization of management objects at server startup. If you run into this JVM bug: |
053029 |
The RA component is now removed during delete. |
054080 |
In 6.1 service pack 2 on a Solaris machine, when WebLogic Server was using SSL to communicate (both as a client and a server) and was using NativeIOEnabled="true", the JVM instance consumed more and more memory and eventually hit the heap size limit. This bug was encountered at a WebLogic Integration installation which relied on SSL communication between trading partners. In 6.1 service pack 3, this problem no longer exists. |
055007 |
Created a configurable parameter, weblogic.system.openSockCount, that would determine the number of allowable connections. |
056622 |
Added a new system property: weblogic.net.http.URLStreamHandlerFactory |
056698 |
Fixed a problem with installing customer protocol handlers. |
057313 |
Fixed ConcurrentModificationException while iterating through AbbrevMap. |
057357 |
Fixed a problem that occurred when defining an error page 401. |
057743 & 060981 |
The WebLogic Server verboseToZip and logToZip utilities have corrected problems with versioning information. Manifest entries, on which WebLogic classes depend for versioning information, are now pulled from weblogic.jar. The verboseToZip output file no longer includes entries for dynamic proxy classes. If a message log contains any instance of i18n messages, then logToZip now pulls all of the i18n related files from weblogic.jar to the client jar. |
058327 |
Getting ClassCastException when trying to make a look-up to DataSource from an Applet |
058358 |
The <alt-dd> tag in the application.xml file is now being recognized. |
059054 |
Added the following symbol as a cookie separator: "," |
059104 |
A property called javaHome which specifies the JVM that is used to start up a managed server was added for node manager. |
060062 |
The Connections High column in the connection pool monitoring screen no longer includes connections refreshed by WebLogic Server. |
060079 |
When using JMS over t3s, a MaxMessageSizeExceededException was being randomly thrown even though the message size never exceeded 50k. |
060211 |
Fixed the placement and quotation of startup arguments passed to node manager from the Remote Start tab in the Console. |
060739 |
UserTransaction now works properly under load. Now, transaction-managed EJBs control the isolation level automatically if the EJB starts the transaction as well as if the user starts the transaction. |
061059 |
It is no longer possible to find a record after it has been removed from a database. |
061458 |
WebLogic Server now supports starting NodeManager on Solaris and HP-UX without using Native libraries. |
061512 |
Fixed problems starting WebLogic Server as a service on Windows NT and Windows 2000. |
061847 |
There are no more error messages when using HTTP with examples.io.FileBrowser. |
062086 |
Using DDConverter to convert from CMP 1.1 to CMP 2.0 no longer throws exceptions for JAR files that contain more than one EJB. |
062177 |
There are no longer any peer to peer connections in clustered nodes. |
062375 |
PeerInfoable.getPeerInfo no longer returns null when marshalling a transaction's propagation context in a clustered environment. |
062439 |
Added error handling code in the native layer of Windows. |
062565 |
The 1.2 JVM client no longer causes a socket connection leak. |
062752 |
jDriver was giving an ORA-24347 error on an outer join operation which selected more than 100 rows. This has been fixed. |
062926 |
JSP page tags can now handle MS932 specific characters on Solaris or HP. |
062989 |
A JMS client running on a slow modem connection and trying to establish a JMS topicConnection with a cluster of two WebLogic Servers no longer gets a ClassCastException. |
062997 |
The servlet engine now removes the servlet stub of the generated JSP file if the source file has been deleted. |
063103 |
Context lookup was failing within a spawned thread. This has been fixed. |
063147 |
Applets no longer fail during downloading of Home interface Stub with the JDK 1.3.1_01 plug-in. |
063310 |
CGIServlet no longer fails under load due to File Descriptor leak. |
063354 |
No longer receiving a ClassCastException from rjvm.MsgAbbrevInputStream.readClassDescriptor() when looking up a session bean from a servlet. |
063671 |
Client side using HTTPS tunneling was producing the get java.net.ProtocolException: Tunneling result not OK, result: 'DEAD' |
063830 |
No longer throwing a javax.transaction.TransactionRolledbackException when the cache is full. |
064117 |
Fixed a problem that was causing the server to abort the connection and result in a java.net.SocketException. |
064125 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-15.jsp. |
064130 |
ReplicaLists are now serializable in order to allow more than one lookup under IIOP. |
064391 |
When deploying applications that contain malformed MANIFEST.MF entries, exceptions are no longer being thrown. |
064404 |
When the same instance of IE is used to configure a webApp using the console and then to access the same webApp (containing French characters for instance), sometimes accented characters were not being displayed correctly. This has been fixed. |
064434 |
If a servlet used RequestDispatcher.include() to include the output of a JSP, the post-processing filter was not able to add a header to the response. This has been fixed. |
064860 |
WebLogic Server no longer fails to execute CGI scripts with JSPs that use page buffering. |
065697 |
When SetUID was enabled, the server wouldn't start. This has been fixed. |
066130 |
Corrected an error message that was being thrown by the ejbc during compliance checking. |
066158 |
When a Log Filter is defined and targeted to the managed server, the trap is now invoked when using the NonCatalogLogger. |
066252 |
Using a specific Factory/Trader pattern, a ReplicaAwareRemoteRef warning log was being displayed on the client side. This log is no longer displayed. |
066504 |
Updated the SP installer with JDK 131_02 for Solaris and Windows. |
067508 |
A generic classloading exception was being thrown when generating a thin client with AppletArchiver. This has been fixed. |
067516 |
The appletArchiver now spools the i18n and manifest files to the thin client jar. |
067517 |
AppletArchiver no longer generates L10n type exceptions when building the client jar. |
067648 |
Fixed a problem that was causing WebLogic Server to hang due to the PosixSocketMuxer code. |
068570 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-16.jsp. |
069043 |
When using HttpProxyServlet in conjunction with a filter, a SocketResetException no longer occurs in NTSocketMuxer. |
069675 |
Reading from a file with @file option on the BEASVC command line no longer has a limitation of 4K. |
069991 |
No longer receiving a ClassCastException from rjvm.MsgAbbrevInputStream.readClassDescriptor() when looking up a session bean from a servlet. |
070575 |
After the server had been running about two days, a client running on a separate JVM was not able to look up a bean due to the JNDI tree and JNDI objects eventually becoming out of sync. This had been fixed. |
071580 |
WebLogic Time service thread is now setting Context Class Loader. |
071822 |
In order for jCOM to successfully find the WebLogic license file, the beahomelist file must be located in C:\bea. |
072010 |
Configuring WLEC connection pool was interfering with command line properties. This has been fixed. |
072061 |
The node manager -Dweblogic.nodemanager.sslHostNameVerificationEnabled=true option now performs host name verification. |
072211 |
Improved the Solaris native implementation of node manager for handling error conditions. |
072228 |
WebLogic Server was not firing a trap for the JDBCConnectionPoolRuntime on the admin server. This has been fixed. |
072278 |
Improved the HPUX native implementation of node manager for handling error conditions. |
072327 |
Attributes with type LONG can now be monitored with SNMP. |
072495 |
Fixed a memory leak caused by Timer Services. |
072904 |
When CallRouter was used, ReplicaList was being corrupted. This has been fixed. |
073116 |
Fixed the weblogic.Admin SERVERLOG command-line utility. |
073201 |
When running multiple HTTP tunneling clients over a modem connection, the server was eventually hanging. This has been fixed. |
073400 |
Modified verboseToZip to exclude javax classes from the output file to reduce the size of the client jar. |
073529 |
Fixed a problem that was causing clustered servers to lock under heavy stress testing. |
073569 |
Eliminated <DGCserver> info messages in the weblogic.log file in order to save space in the file. |
073578 |
Installing Windows NT service by specifying JRE directory as its JAVA_HOME failed with an error when trying to start the service. This has been fixed. |
073788 |
The HP Installer was failing to build. This has been fixed. |
074991 |
Fixed a problem that was resulting in WebLogic Server crashing in the performance pack under heavy load. |
075271 |
A NullPointerException is no longer thrown at weblogic.utils.BubblingAbbrever.getValue (BubblingAbbrever.jaava:163). The Abbrev tree is no longer getting corrupted. |
075700 |
For WebLogic Server instances that run as a Windows service, you no longer need Windows Administrator privileges to start the service. |
076395 |
For WebLogic Server instances that run as a Windows service, using the Administration Console or the weblogic.Admin utility to shut down the server no longer causes the Windows service to report an error condition. |
076705 |
Deploying a MessageDriven Bean no longer fails with a NoAccessRuntimeException for guest if the destination is remote. |
077238 |
Startup scripts now specify the correct value for the Oracle jDriver path. Before this service pack, startup scripts specified LD_LIBRARY_PATH=oci816_8, which is no longer supported. Now the scripts specify oci817_8. |
077278 |
Removed the Oracle 816/806 driver from the WebLogic Server 6.1 service pack 3 installation. |
077919 |
Fixed a problem with an earlier bug fix that was causing calls to ObjectOutputStream.writeObject() on EJBHandle to throw the following error: Closing:'weblogic.rjvm.t3.T3JVMConnection@49c89f' because of: 'Server received a message over an uninitialized connection. |
078523 |
The java version bundled with the WebLogic Server 6.1 service pack 3 installer is: |
Plug-Ins
RMI over IIOP
Security
Change Request Number |
Description |
061659 |
WebLogic Server now starts with NTrealms configured |
061694 |
When running the SSLClient example, a NullPointerException was being thrown at weblogic.security.provider.MD2.<init>(MD2.java:24). This has been fixed. |
062172 |
Now, if cookies are disabled in a browser, form-based authentication redirects to the secure JSP/Servlet. |
062261 |
Fixed a security issue with EJB SessionContext.getCallerPrincipal(). |
062988 |
Fixed a problem with the NT realms and multiple PDCs. |
063349 |
When implementing an AuthFilter class, the methods doFailAuth() and doSuccessAuth() are now being called. |
063763 |
Two-way SSL java client connection now works with encrypted private keys. |
064250 |
The web server is no longer vulnerable to session ID forcing. This applies to web applications protected with form-based authentication. |
064263 |
Lockout Duration above 322122 will now lock out the user. |
064285 |
When running the SSLClient with ssl.proxyHost/ssl.proxyPort, the SSLHostnameVerifier now works as expected. |
064342 |
It is now possible to redirect the echo $password command output to the Java interpreter to start WebLogic Server other than by using password.ini or by specifying the -Dweblogic.management.password=$password property. |
065046 |
ManageableRealm.newAcl() no longer returns NULL when the System password is changed. |
065314 |
LDAP version 2 no longer causes issues with user names containing natural language. |
066232 |
The 2-way SSL with RMI/IIOP PingClient example is now working. |
066264 |
Fixed a problem with the lockout mechanism using Japanese Windows 2000. A 500 error was occurring. |
066491 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-17.jsp. |
067726 |
Fixed a problem with form-based authentication. |
068524 |
Two-way SSL with RMI/IIOP and EJB access and authentication is now working for the SimpleCertAuthenticator example. |
069083 |
Fixed a problem with perimeter authentication. |
069160 |
There is now a way to set ClientCertProxyEnabled for unclustered servers. |
070870 |
LDAPRealmv2 is now fully implemented. |
071167 |
There is no longer a ProtocolException when tunneling HTTPS through iPlanet proxy server. |
072096 |
Now able to start a managed server using SSL and DebugRC4="true". |
072916 |
Changed class weblogic.security.X500Name to implement Serializable. |
075109 |
LDAPRealmv2 now caches memberships. |
Servlets, JSPs and Web Applications
Change Request Number |
Description |
044528 |
Under certain situations, isUserInRole was returning false when it should have been returning true. This has been fixed. |
051065 |
XML fragments on the XML view of a JSP page were not being passed to out. Non-standard fragments, which are neither standard nor custom tags (tag libraries), are now being sent to the current value of out as is. |
054694 |
RequestDispatcher will now invoke filters upon include/forward properly. |
055333 |
When detecting contentType directive at the middle of the JSP, the JSP compiler was failing. |
056153 |
The File Servlet now supports initialization parameters as well as context parameters. |
058352 |
It is now possible to access a web application that has a one-character name like "i.war" or "j.war". |
059026 |
In a web application that contains a servlet, when the mapping defined for this servlet is in the form of *.aBc, accessing the servlet no longer fails. |
059102 |
The compression filter now works correctly with RequestDispatcher. The forward was causing an invocation of the filter, but the servlet engine was sending the empty response back to the client. This has been fixed. |
059219 |
WebLogic Server no longer returns the default port number if Host Header is missing. |
060023 |
The FileServlet now includes the SERVLET_PATH when calculating the source filename which means that it is possible to only explicitly serve files from specific directories by mapping the FileServlet to "/dir/*" etc. |
060184 |
PathInfo is now decoded and preserves characters in the original URI. |
060351 |
The method PageContext.include(String relativeUrlPath) was not throwing any exception when the URL to be included was not found. Added a log message that appears in the context log file and indicates the parent resource and which resource could not be included. The log message appears in the mycontext.log file - where mycontext is the context-path of the webapp. |
060825 |
BodyTagSupport method, getBodyContent(), incorrectly returned null when body tag was empty. |
061377 |
jspc no longer generates EVAL_BODY_TAG instead of EVAL_BODY_AGAIN. |
061782 |
ServletResponseImpl.setContentType() can now handle multipart type properly. |
061784 |
While getting the log from a managed server, the admin server java process was pegged at 90%. This has been fixed. |
061864 |
WebLogic Server now prevents the display of secure cookies. |
061948 |
Added a new semantic-predicate to distinguish between tags with body-content set to "tagdependent" or "jsp". Added a new rule before the existing opening-tag rule in the lexer. When the tagdependent rule is invoked, it does the same as the ordinary open-tag rule, but also looks ahead and matches the content of the JSP until it finds a matching closing tag. Everything it finds is escaped for \n, \r, and \ and printed to "out". It then returns to the parent lexer rule which should immediately find the closing tag. |
061968 |
HEAD method no longer returns request body with use of jsp:include. |
062109 |
Fixed a problem with JSP scripting variable synchronization |
062160 |
The parameters <compileFlags>, <encoding>, and <compilerSupportsEncoding> are no longer ignored during precompilation. |
062289 |
WebLogic Server now decodes the spaces in a URL. |
062395 |
load-on-startup in web.xml is now be optional |
062536 |
The JSP response that contains Japanese characters is no longer garbled when filtered with HttpServletResponseWrapper. |
062538 |
Pages will now be properly parsed regardless of the location of the contentType. |
062542 |
Now, requesting aux.jsp / AUX.jsp / PRN.jsp / prn.jsp on a WebLogic Server that is running on a Windows box either succeeds or fails instead of staying in an undetermined state. |
062579 |
CGI scripts will now be resolved properly even if CGIServlet is registered as a default servlet. |
062896 & 063009 |
When the JSP parameter, precompile, was set to true in the web app (WAR) weblogic.xml, only the document root level JSPs were being recompiled each time the server restarted. The subdirectory JSPs were not being recompiled. JSPs are now recompiled, even during pre-compilations, only if they have changed. |
062920 |
When specifying an <exception-type> in web.xml in a webapp (the exception class is located under WEB-INF/classes) when the webapp is deployed, WebLogic Server was not finding the exception class and throwing a ClassNotFoundException. This has been fixed. |
063007 |
Session table name for JDBC persistence is now configurable. |
063127 |
ServletInputStream now returns data if the session is new. |
063169 |
Having accented characters and a Charset=UTF-8 no longer yields the weblogic.utils.ParsingException and the nested TokenStreamException. |
063288 |
WebLogic Server now only looks for SessionCookie in the cookies if CookiesEnabled is true. |
063414 |
When trying to migrate applications from WebLogic Server 5.1 to 6.1 SP1, there is no longer high CPU utilization. |
063524 |
A NullPointerException is no longer thrown using FileServlet with nativeIO turned on. |
063563 |
weblogic.jspc was not passing -encoding JAVAENCODING value to javac from the page tag. This has been fixed. |
063904 |
The inclusion of each page directive in a JSP was leading to the insertion of an extra line feed character in the generated HTML output. If the HTML consisted of an image, the image lost its formatting. This has been fixed. |
063925 |
If a language-specific character encoding is specified for a web application, binary data written to the response output stream is no longer garbled. |
064294 |
Fixed a problem with the WebLogic Server SessionID reuse using a virtual host. |
064383 |
HEAD request from an applet no longer issues a ClassCastException from ClasspathServlet. |
064446 |
When using two levels of proxying, a call to getRemoteUser was always returning NULL. This has been fixed. |
064449 |
Web application deployment was failing and resulting in a StringIndexOutOfBoundsException. This has been fixed. |
064650 |
WebLogic Server threw a NoClassDefFoundError and was unable to load a class from a JAR file with a period in its name. WebLogic Server is now able to load a class from a JAR file with a period in its name. |
064880 |
In form-based authentication, when the user directly went to the login page, WebLogic Server was forwarding the user to the welcome page. This has been fixed. |
064988 |
JSP precompilation no longer aborts after a compile error when the -k flag is set. |
065104 |
Fixed by 064650 and 065213. |
065194 |
A multi-part request in the SSL process was failing through a slow connection. This has been fixed. |
065213 |
A NoClassDefFoundError occurred if more than one jar file was defined in the manifest classpath entry. For example, when xalan.jar was in WEB-INF/lib of war file, this problem happened because it specified two jar files in the manifest classpath entry. WebLogic Server no longer throws a NoClassDefFoundError under these circumstances. |
065924 |
In a non-clustered environment, web applications with cluster-specific properties can now be deployed using the new option: replicated_if_clustered |
066395 |
response.addHeader was failing with null character being inserted erroneously. This has been fixed. |
066500 |
Forwarded JSP pages will now terminate the execution of the current page. |
066569 |
request.getParameter() is now returning the parameter for post request with Javaclient. |
066708 |
request.setCharacterEncoding was not working for JSP includes. This has been fixed. |
067001 |
When using the Http Proxy/Cluster servlet, a request was sent to some back-end server and the response body was not returned to the client if the request came back with a status of 100. This has been fixed. |
067072 |
When a JSP had pageEncoding without contentType charset specification, the generated .java file was in VM default encoding and the compile failed. This has been fixed. |
067073 |
Generated .java and -encoding for javac did not match when both contentType and pageEncoding existed. This has been fixed. |
067077 |
When there was an encoding setting in jsp-param of weblogic.xml at a JSP file with pageEncoding, pageEncoding was not used. This has been fixed. |
067292 |
Latin one characters in request parameters, when re-directing from one JSP to another, were getting lost. This has been fixed. |
067505 |
Fixed a problem with port in Location header for an HTTP re-direct. |
067748 |
It is now possible to compress the output stream of a servlet. |
067948 |
Page buffer directive is no longer ignored if it is in an included JSP page. |
068024 |
Removed the need to use sync blocks in HttpServer or HttpClusterServlet. A new enumeration is constructed each time it is required that references a Set that is guaranteed not to change. |
068560 |
Certain JSP pages' source code was being shown on the browser. This has been fixed. |
068648 |
Limiting maximum POST size now works properly. |
068674 |
There is no longer a ClassCastException thrown when using HttpProxyServlet in conjunction with a filter. |
068809 |
Now, the write signature is honored when using encoding that is different from the default. |
068821 |
getRequestURI from Request Object is now returning the full length of the URI. |
069304 |
HttpClusterServlet now re-reads the post data from the input stream up to the declared content-length. |
069511 |
Error page attributes are now being set on request for JSP error directives. |
069630 |
If the property of a custom tag in a JSP contained an escape sequence (\"), the JSP was not compiling. This has been fixed. |
069652 |
The response header (ContentType) and the JSPWriter now have the same character set while serving a page to client. |
069809 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-03.jsp. |
069956 |
For replicated sessions, the open session count is incremented only once. |
070090 |
When sending session cookies in the response to the client, WebLogic Server did not specify the cache-control appropriately to prevent caching proxies from caching the cookie. This has been fixed. |
070132 |
It is now possible to request a filename with Chinese characters. |
070151 |
weblogic.jspc no longer silently exits when <load-on-startup> contains an empty value. |
070470 |
Subsequent reload/refresh was at times executed by the old code that was still deployed in the container. This is now prevented by reloading of the stale class in the case where the JSP fails to parse. |
070755 |
No longer sending wlsproxy specific headers if the requests are not coming via wlsproxies. |
070823 |
Eliminated inconsistent behavior of index directories parameter across WAR and EAR components. |
071076 |
Fixed classloading behavior problem that resulted in having both child1 and child2 using the same classloader, BUT additional classloaders being created and destroyed. |
071082 |
Fixed broken URLEncoding. |
071634 |
Fixed chunked transfer encoding issues that occurred when WebLogic Server 6.1 was communicating with WebLogic Server 5.1. |
072557 |
response.addCookie(name) now honors the order in which cookies are sent to the browser. |
073203 |
Now able to use the + character in a <url-pattern>. |
073380 |
Improved the error messages for CGIServlet. |
073516 |
Fixed a problem with the CGI NonParsedHeader. |
073792 |
Active sessions will no longer be invalidated. |
073797 |
JSP useBean tag is now parsed properly. |
074015 |
There was a NegativeArraySizeException if PROTOCOL is missing in the first line of the request. This has been fixed. |
075201 |
The security-constraint is now working when the url-pattern refers to a two-character directory. |
075607 |
Socket exceptions squashed by PrintWriter could have tied up execute threads in servlets and JSPs. This has been fixed. |
075628 |
When a program submitted data to a servlet using Content-Type that was set to include a charset, getParameterValues("..."), returned every submitted value twice. This has been fixed. |
076056 |
When a JAR file's MANIFEST.MF contained a JAR file that was in a different directory, WebLogic Server was throwing a StringIndexOutOfBoundsException and the web app was not being deployed. This has been fixed. |
076476 |
When using multiple frames, the last accesstime set by one frame was not being honored by the other frame. This has been fixed. |
076742 |
Added a check for the <env-entry-value> element. |
077329 |
HttpSessionListener failed to work correctly when the session is set to replicated. This has been fixed. |
078930 |
Requesting http://host:port/webApp/aux%20.jsp no longer hangs the thread servicing the request. |
System Administration
Web Services
WebLogic Tuxedo Connector
Change Request Number |
Description |
052022 |
Codeset translation between WebLogic Tuxedo domains and Tuxedo domains is provided using the WebLogic Server weblogic.wtc.encoding property. For more information, see Configuring WebLogic Tuxedo Connector for Non-ASCII Codesets. |
055170 |
Fixed problem with Fchg method of the TypedFML(32) class in the WTC package. |
056230 |
tbridge no longer fails to initialize the wlsErrorDestination JMS queue |
062843 |
Fixed a problem with the Fdel method of the TypedFML(32) class in the WTC package. |
063290 |
When loading large code tables from Tuxedo to WebLogic Server, the duration of service calls (tpcall) is no longer dramatically longer with WTC compared to with Jolt. |
066489 |
Now able to call an EJB from a Tuxedo client when using FML32 buffer. |
XML
Third-Party JAR Files in WebLogic Server 6.1 Service Pack 3
WebLogic Server 6.1 Service Pack 2 Solutions
The next sections describe problems that were resolved in WebLogic Server 6.1 Service Pack 2.
EJB
Examples
JDBC
jDriver
Change Request Number |
Description |
046149 |
Fixed a problem where when WebLogic Server wrote a multibyte string to a CLOB or NCLOB column, it wrote an incorrect string length. |
JMS
Miscellaneous
Change Request Number |
Description |
036679 |
The Administration Console now functions correctly when resizing the Netscape browser frames on Solaris. |
041873 |
Fixed problems with the weblogic.policy file when users started up the server with -Djava.security.manager. Even when the user had correct permissions, a java.security.AccessControlException: access denied exception was being generated. |
041991 |
When attempting to get the MBeanHome from the RemoteMBeanServer, an application no longer receives "null". |
043010 |
If WebLogic is running as a Windows service it will no longer shut down when you log out of the Windows session that the server is running in. |
050437 |
When running under WebLogic Express, WebLogic no longer prints out: <Error> <JMS> <JMSServer "null", JMS license validation failed, com.bea.utils.misc.NoSuchProcessException: No such license: WebLogic Server 6.1, JMS.>. This message was misleading and harmless. |
053732 and 054781 |
Introduced a -delay option to the beasvc.exe utility which ensures that Managed Servers only start up provided that an Administration Server is already running. The new -delay option lets users delay the Managed Server's JVM thread execution for a specified number of milliseconds. Previously, a Managed Server failed to start up because it depended on a running Administration Server. Note: For information about related changes in WebLogic Server 6.1 SP04, see Change in Behavior of -delay Argument for beasvc.exe. |
053990 |
The Node Manager will now load up servers that have whitespace in their names. |
055007 |
WebLogic Server now implements a throttling mechanism to reject outstanding requests after a certain limit. Previously, the acceptBacklog value was not effective in limiting the number of new connections that could possibly overwhelm the server. |
055442 |
Fixed a problem involving sending XML over HTTP. The problem was that WebLogic Server was erroneously calling the getInputStream() method. |
056332 |
Fixed a problem causing an IllegalStateException when calling a RPC-style Webservice. |
057091 |
Fixed a problem with applets in Internet Explorer, where `didn't meet stated Content-Length' errors were being thrown because the content length check was being performed at the wrong time. |
058832 |
Fixed a problem where HttpSession failover service failed and a session was lost if a client accessed the session just when a primary server was shutting down. This occurred only in a two-server cluster. |
059119 |
Fixed a problem where a Java client talking to a Weblogic cluster performed more slowly on a 3-server cluster than on a 2-server cluster. Moreover, performance would keep degrading with addition of more servers until the client ensured that there were at least as many socket reader threads on client as the number of servers in the cluster. This involved configuring Execute Thread count and Percent Socket readers client-side properties. This fix removes the dependency of such a configuration, as the number of servers can grow or shrink dynamically. Now, WebLogic Server creates new threads for socket reading on fly making sure there is one thread per outgoing socket from client. This means customers don't have to tweak those properties for the client for optimal performance when a WebLogic client talks to a WebLogic cluster. |
059219 |
Fixed a problem encountered by wireless application where WebLogic was retrieving the port number from a location that could have incorrect information. |
060557 |
The FileT3 attribute now creates a file with the correct path when the path is targeted to a managed server. |
061060 |
The getTimeout() and setTimeout() methods are no longer missing from the class HttpURLConnection. |
056911 |
Previously, if an entry was added to the manifest Class-Path for a |
051220 |
Fixed a problem where multi-byte system messages in WebLogic Server log or console were corrupted and, therefore, unreadable. |
054871 |
The Administration Console now displays a JNDI tree correctly. Previously, deployments were appearing under the wrong context. |
057466 |
Fixed a problem where executing the weblogic.Admin PING command to a server running on Solaris with Japanese locale (LANG=ja_JP.PCK) resulted in a java.net.SocketException displaying on the server. |
058786 |
The Netscape Enterprise Server Plug-In (NSAPI plug-in) enables requests to be proxied from Netscape Enterprise Server (NES, also called iPlanet) to WebLogic Server. The plug-in enhances an NES installation by allowing WebLogic Server to handle those requests that require the dynamic functionality of WebLogic Server. Previously, reading the HTTP header in the NSAPI plug-in resulted in an unexpected EOF: "PROTOCOL_ERROR [line linenumber of filename]: unexpected EOF reading HTTP headers at line linenumber. The underlying problem proved to be with parsing large cookies. This problem is now fixed. |
061460 |
You can now configure Weblogic 6.1 to restrict the number of client 1. Edit the config.xml file to set the weblogic.system.openSockCount parameter, which limits the number of permitted connections:
|
051882 |
If web.xml is missing from your web application and you attempt to edit or enter a deployment descriptor through the console, a blank screen no longer appears. |
Plug-Ins
RMI over IIOP
Change Request Number |
Description |
056233 |
ejb11.security.HomeMethodPermissionTest.testHandleRemoveWithoutPermission() no longer fails with an out of memory error. |
Security
Change Request Number |
Description |
060491 |
Fixed a problem where single sign-on (SSO) did not work when the initial resource in the web application was not a protected resource. |
CR061313 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-13.jsp. |
Servlets, JSP and Web Applications
System Administration
Change Request Number |
Description |
045780 |
Multiple server definitions with the same name are now disallowed. If you have started a server and then attempt to start up the second server with the same name, the server startup aborts, with this error message: "Server: <yourservername> already exists, make sure that you do not have duplicate copies of this Server name in your XML config file" |
055190 |
Fixed a problem where JSP refresh failed if the application was targeted to a cluster. Previously, you could not add new JSPs or change or delete existing JSPs from a running web application without having to undeploy and redeploy the application. |
056091 |
A new procedure is available to restart an Administration Server on a different machine while Managed Servers are still running. For more information, see the section "Failover Considerations for the Administration Server". |
058946 |
Fixed a problem where precompiled JSP's on a Managed Server would recompile even without if the pages hadn't been modified. As a result it took a long time to start up the Managed Server. With this fix, if classes are already compiled on an Administration Server, when the Managed Server starts up the classes are shipped and their timestamps are preserved, to the Managed Server will not try to recompile them. |
054624 |
weblogic.deploy now behaves as expected when its -component option is invoked. Previously, it did not behave as expected when using the -component option: the application was unintentionally deployed to a server that was not in the component list of servers. |
054573 |
Fixed a problem where any configuration error involving a JDBCConnectionPool, MultiPool, or (Tx)DataSource, did not get reported in an error dialog in the console. Rather, it appeared to be correctly configured. |
058183 |
Fixed a problem where WebLogic Server was deploying .war files before .jar files, At server startup, a web application would deploy before an EJB, resulting in a NameNoteFoundException. |
059702 |
Fixed a problem where web applications could not be deployed when network cards were disabled. Previously, WebLogic Server would try to validate with the DTD at http://www.bea.com/servers/wls610/dtd/weblogic-web-jar.dtd. When it cannot reach www.bea.com, it failed. Now, when there is no network access, the server find weblogic-web-jar.dtd in weblogic.jar and continues. |
060244 |
Fixed a problem where, when using the Administration Console to target a cluster for just one application, individual servers were also pulled into the target list. With this fix, the cluster is no longer expanded to a list of servers. |
061642 |
Fixed a problem with converting a 5.1 weblogic.properties file to a 6.1 config.xml file. The conversion utility was not converting the password for the JDBCConnectionPool correctly. As a result, attempts to start the server in the new domain failed. |
055067 |
Fixed a problem that caused web applications that had dependencies on classes in EJB .jar files not to deploy when precompile was turned on. |
060411 |
(EJB 1.1) Fixed a problem where a second call to a required EJB transaction method cause the transaction to roll back. The first call removed some entities and then created some. The second call removed the previously created entities and then created some new ones. |
042052 |
Fixed a problem occurring in migration from one release to another: the weblogic.properties file was not converting completely, such that the web.xml file of the web application did not contain all of the properties. |
061300 |
Fixed a problem where the WebLogic Server console was executing in the default queue (a lower priority queue) instead of "__weblogic_admin_html_queue" (a higher priority queue). This compromised the console's ability to respond when the server was experiencing heavy load. |
Web Services
WebLogic Tuxedo Connector
WebLogic Server 6.1 Service Pack 1 Solutions
The next sections describe problems that were resolved in WebLogic Server 6.1 Service Pack 1.
Deployment Descriptor Editor
JTA
RMI over IIOP
Change Request Number |
Description |
C043505 |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA00-09.jsp. |
043659 |
Shortened the session ID for WAP in a cluster. |
049139 |
The following JSP no longer fails to compile. <%@ taglib uri="accents.tld" prefix="accents" %> |
049147 |
When you start the default server, a warning message referencing the servlet 2.2 DTD no longer occurs. |
050343 |
ResponseHeaders.writeHeaders() generates an HTTP header for single byte strings only. |
050370 |
Added the PrefetchTag class to the weblogic-tags.jar file. |
050398 |
Added the weblogicx.jsp.tags.PrefetchTag class to the weblogic-tags.jar. |
051396 |
Load-on-startup now produces a warning if an invalid value is entered. |
052109 |
A NullPointerException is no longer thrown every time ServletSessionRuntimemBeanImpl.getMainAttribute() is called. |
052134 |
Added support for two Web applications or two ejb-jars with the same name in different ear files. Previously, deploying two ear files that each contained a web application foo.war file caused an InstanceAlreadyExists error. |
052665 |
Added the capability to configure a <run-as> element for a servlet from the web application deployment descriptor editor. |
052786 |
Exception-type mapping implementation no longer looks at the exact match for the exception type. Multiple classes can now be registered in the hierarchy. Exception-type mapping picks up the closest match. |
053314 |
Added performance optimizations for in-memory replication and memory session persistence. |
053333 |
The JSP page is now used as an error page if an exception is thrown in the Web application. |
053344 |
Fixed a problem caused by using multiple slashes in a URL. |
053377 |
The exception weblogic.servlet.internal.session.MemorySessionDataMissing no-arg constructor for class is no longer thrown when: |
053573 |
When more than one call for Forward() of RequestDispatcher is made within a Servlet service method, the container now throws an exception instead of returning a blank response. |
053634 |
The query parameters added in a forward or an include now take precedence over the existing ones, in accordance with the servlet specification. |
053722 |
Introduced a switch in the weblogic.xml file that redirects the client using the absolute URL. For example: <container-descriptor> <redirect-with-absolute-url>true</redirect-with-absolute-url> If set to true, the absolute URL is used. |
053743 |
Now, in accordance with the servlet spec, an IllegalStateException is thrown if ServletA tries to forward the same request to the JSP after having forwarded it to ServletB. |
053932 |
The HttpClusterServlet no longer throws a Null Pointer Exception and weblogic.utils.AssertionError if secureProxy is on. |
053959 |
BodyTags can now return EVAL_BODY_INCLUDE from their doStartTag method. |
054016 |
Fixed the response header format corruption problem when the Content-Disposition header is present. |
054194 |
The content in the response buffer is now flushed as soon as the amount specified by the setContentlength is fulfilled. |
054427 |
Added a mapping for jnlp files to the weblogic/servlet/internal/web applicationServletContext.java file. |
054694 |
RequestDispatcher now invokes Servlet 2.3 filters. |
055002 |
A file can now be downloaded, instead of only appearing in the browser, after setting up mime-type in the web.xml file. |
055106 |
Parameters for the request are now returned after the HttpServletRequest.getParameter (param) method for a POST request is executed in the doPost() method in a servlet. |
055241 |
The request.getAttribute and request.setAttribute are no longer broken when Content-Type=text/xml and the method is POST. |
055265 |
New parameters no longer appear lost when getServletContext().getRequestDispatcher and request.getParameter are used in the arguments. |
055591 |
A null pointer exception is no longer thrown in request.getParameterMap() if the method is called with any of the getParameter() methods. |
055630 & 055962 |
Fixed a problem with internal ServletResponse implementation. |
056188 |
Fixed a parse error. The JSP container was failing to parse when pageEncoding was omitted. |
056277 |
There is no longer an ArrayIndexOutOfBoundsException thrown on POSTs when using the Netscape browser. |
057022 |
The JSP compiler no longer generates a classpath that is too long for the Win32 command line when Class-Path is used. |
System Administration
Change Request Number |
Description |
045203 |
The message produced due to an incorrect password when using weblogic.Admin is now consistent regardless of the command used. |
049177 |
Fixed an error related to Web application deployment in clusters. |
049178 |
Fixed an error that occurred when deploying the default Web application. |
049919 |
Redundant copies of ServerConfigMBeans are no longer created on the Administration Server and the Managed Server. |
050374 |
Converting the weblogic.properties file no longer fails when DeliveryMode=persistent. |
050853 |
Configuration and deployment can no longer take place with the wrong path and URI. |
050874 |
A cloned server can now be started as a Managed Server. |
051618 |
weblogic.Admin now fetches the information from MBeanHome of the server running at the address specified in the -URL option. If the -URL option is not specified, weblogic.Admin fetches information using the AdminHome of Domain. |
052046 |
When a password is not specified using the -password option in the command line for weblogic.Admin, the user is prompted to enter the password. |
052095 |
When launching the Admin startup script, the Administration Server was started but did not detect running Managed Servers. Now, when the Administration Server starts up, it always loads the root directory from the properties directory (-Dweblogic.RootDirectory) or uses the default directory (current directory). |
052198 |
A cloned server no longer fails during start-up. |
052261 |
Fixed a problem with using the weblogic.deploy utility to deploy multiple EJB targets. |
052326 |
If an erroneous root directory is specified in the config.xml file, WebLogic Server gives a warning message and the configuration is persisted to the directory where the Server is booted. |
052349 |
When the deployment descriptor converter is run to generate a config.xml file from the weblogic.properties file that has the property weblogic.security.realmClass=weblogic.security.LDAPRealm set, a Password attribute now gets created in addition to the ConfigurationData for the CustomRealm. Values for both ConfigurationData and Password are based on the information contained in the ldaprealm.properties file. When the config.xml gets saved, the Password gets encrypted. |
052656 |
Applications in the auto-deploy directory are no longer deployed twice. |
052753 |
Starting the Administration Server and then starting two Managed Servers simultaneously no longer causes a server failure. |
052804 |
If the <charset-params> entry exists in the weblogic.xml, then the deployment descriptor editor displays it. Previously, it failed to display and gave a ClassCastException. |
053053 |
Fixed a problem with redeploying a message-driven bean after undeployment. |
053485 |
This is a known issue with the conversion utility for customers migrating from earlier releases of WebLogic Server as well as those users following the migration tutorial. The JDK automatically specified by the conversion process under the compileCommand tag in the weblogic.xml is set to JAVA_HOME\javac. This setting is no longer missing the bin subdirectory, which is set to JAVA_HOME\bin\javac. A corrected version of the conversion utility has been posted at http://developer.bea.com/tools/techguides.jsp. |
053926 |
When the Administration Console was used to convert weblogic.properties on src510sp10_117sj to the config.xml file on src_ag_131sj, the root directory was not converted. This has been fixed. |
053980 |
Fixed a problem that involved deploying a Web application in a cluster that was using an MBean API. |
053991 |
MBean name patterns specified by JMX can now query the MBean server and find MBeans. |
054173 |
Fixed a problem with starting Managed Servers simultaneously in a clustered environment. |
054485 |
Improved the accuracy of Managed Server startup URL error messages. |
055150 |
Fixed serialVersionUID for outer and inner classes following Sun's recommendation. |
055945 |
A ClassCastException was caused by deleting MBean references. This has been fixed. |
Web Services
WebLogic Server 6.1 Release Solutions
The following sections describe problems that were resolved for WebLogic Server 6.1.
Deployment Descriptor Editor
RMI-IIOP
Web Services
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|