CR172370

When the Administration Console created an Application MBean, the associated WebAppComponent MBean incorrectly inherited the Application MBean name instead of the WebAppComponent's URI name. This caused the deployer tool to incorrectly create an additional deployment repository for this application when it was updated.

This defect was corrected by a code change.

CR105735

Navigation through the directories did not go through action servlet, so encoding was not set properly.

A change was made to set the encoding explicitly in the page, so the correct encoding is used to produce the response.

CR087598

Propagation from list page to realm deletion changed the MBean class name specific to the MBean to be deleted. Because of this MBean showed only the last deleted type MBeans in the list.

A attribute (original class name from list) has been introduced which will be propagated in the above described flow. This attribute provides a way to recover the original class name and listing remains undisturbed. This solution applies to all MBean types.

CR184891

The console jsp that was used to upload applications to remote servers was calling the ApplicationManager.update() method even when the server was not in development mode.

Removed the call to ApplicationManager.update() if ProductionMode is enabled. Uploaded applications are no longer automatically deployed when Production Mode is enabled.

CR097378

A NullPointerException sometimes appeared on the Administration Console while the WebApplication Deployment Descriptor was being edited.

WebLogic Server was not checking for the descriptor being null, which is the case when it can not be parsed. For this reason a NullPointerException was thrown.

If the descriptor is null, the proper error action will now be called to display the correct message.

CR097036

The correct icons were not being retrieved by the console pages due to changes in the getServletContext code to be in compliance with the Servlet 2.3 specification.

Code changes were made to buildIconList() to provide the path to the images subdirectory in the console.war.

Correct icons now appear in the navigation applet.

CR044503

Creating a new ACL with a blank Permission caused an unexpected error. This was due to names not being checked for null and blank values under some circumstances.

Appropriate checks have been added, and messages for null names have been corrected.

CR08296

The getParameter() method in GraphApplet is used to get the value of the min/max heap size. Although the return type is long, WebLogic Server was using Integer.parseInt to convert the string values. When the heap size was over 2G, there was an overflow in the integer value. Because of this, the current free memory was sometimes reported as a negative number.

WebLogic Server now uses Long.parseLong to avoid overflow and to get the correct value of the heap even if it is over 2G .

CR079771

WebLogic Server was sending a file link to the browser to report the results of start cluster and start/kill domain operations. That link worked only if the browser was running on the same machine as the administration server. This occurred on all platforms.

WebLogic Server now sends a action link which will process the file and send the output to the browser in an HTML format.

CR077058

When a JMSJDBCStore was created, the "None" option was eliminated from the Connection Pool drop down list.

Adding the ability to make JDBCConnectionPool null restored "None" to the list.

CR069130

When an application with an incorrect web.xml file was added to the applications directory, the Administration Console reported it as having been deployed even though it was not deployed at startup.

WebLogic Server now correctly reports such applications as undeployed.

CR075168

WebLogic Server was using the greater than symbol, '>', as the Token delimiter. Because of this, if a custom message contained a '>', it was being truncated while being displayed.

WebLogic Server no longer truncates the last token when writing to the log.

CR128510

readClassDescriptor() of MsgAbbrevInputStream was trying to resolve a class and throwing a ClassNotFoundException for unknown classes. Java serialization will skip this ClassNotFoundException if corresponding data is not being read.

readClassDescriptor() of MsgAbbrevInputStream no longer tries to resolve unknown classes and MsgAbbrevInputStream implemented resolveClass().

CR129234

CR189793

ReplicatedSessionContext has two hashtables, one of which stores the sessions for which the server is primary, and the other stores sessions for which the server is secondary. The hashtable with secondary sessions has sessionId as a key and ROID as value.

When a session was invalidated and the request to remove the session came to the secondary server, WebLogic Server passed the ROID to the ReplicatedSessionContext, iterated over the values in the hashtable in order to compare ROID with that value, and then removed the entry. WebLogic Server now avoids iterating over the hashtable by passing the sessionId instead of ROID.

CR135131

weblogic.cluster.MulticastObjectListener was locked on a call to objectAdded and waited to lock a HashMap while in a different thread MulticastReceiver locks the HashMap and attempted a lock on MulticastObjectListener. This caused a Java Level Deadlock.

Changing the lock order eliminated the deadlock.

CR127765

When a node in cluster was restarted, it first tried to synchronize with other cluster members resulting in one server adding the other to the cluster view.

Before that cluster node opened the listen port, if a request came in with this cluster node as a secondary, it resulted in an error and from that point on all requests to create secondaries on that cluster node failed.

Now during cluster synchronization, when a node is coming up, it first identifies all the running nodes in a cluster and then sends out a broadcast identifying itself. This ensures that the cluster node coming up is identified by other nodes after it opens a listen port.

CR127643

When a Dynamic Proxy that implemented interfaces declared inside the web application was put into the HttpSession and the session was replicatable, WebLogic Server was not able to load the interface classes on the secondary server.

Dynamic Proxies implementing interfaces stored in the application archive can now be put into HttpSession and be correctly replicated.

CR111029

The cluster members timed out if they did not receive a heartbeat within the default 30 second timeout period. Heartbeats were sent every 10 seconds and servers waited for 3 periods (total wait time was 30 seconds) to get a heartbeat before the cluster member was timed out and declared unavailable. For example, during session replication if the secondary server was unavailable at TCP level, the 30-second period was sometimes too long for a very busy web site. Before the secondary was removed from the cluster view, the primary tried to replicate many sessions to the secondary and thus caused the server to hang or made the server slower.

The timeout value IdlePeriodsUntilTimeout is now tunable. It is set on the <Server IdlePeriodsUntilTimeout="3"> tag in the config.xml file. In general customers should not tune this value and should leave it at the default (3). However, in certain cases depending on the load, available redundancy in the architecture and specific application problems and/or certain production scenarios, tuning this value carefully might alleviate the problem temporarily until the root cause is identified and fixed.

BEA WebLogic recommends that you use HIGH caution when changing this value and ensure sufficient testing of your application at peak load scenarios to ensure the expected behavior. There is no recommendation that fits all scenarios, so testing for load and stress is a must if this value needs to be changed.

CR190507

Fixed a problem with oneway calls for ReplicationManager..

CR190417

When a request landed on a server that was neither primary nor secondary, it got the session from the existing secondary by looking it up on the secondary server with the host port information from the session id.After it successfully got the session from existing secondary it removed the existing session and tried to create a new session.

When two such requests occurred at the same time a distributed deadlock could occur since these requests landed on the 'Replication' thread queue and the 'Replication' thread queue had only two threads and there was no other thread available for reading the response.

Code was added to WebLogic Server which fixed the problem so that it will not deadlock.

CR183210

In WebLogic Server 7.0 and higher, the javax.ejb.TransactionRolledbackLocalException's SVUID was changed and when WebLogic Server 7.0 or 8.1 experienced a javax.ejb.TransactionRolledbackLocalException when a WebLogic Server 6.1 client made a remote call to ejb hosting by a WebLogic Server 7.0 or 8.1 server instance, it experienced an InvalidClassException.

This problem is fixed in WebLogic Server 6.1 so that it now understands the incoming final-ejb20 ClassDescriptor for javax.ejb.TransactionRolledbackLocalException.

CR133631

Stopping a windows service configured with beasvc.exe sometimes caused a timeout when a stopclass was specified. The service was timing out because there was a race condition between the stop and main threads of beasvc.exe.

The race condition has been corrected and the windows service no longer times out.

CR121483

A ConcurrentModificationException was thrown when the monitoring subsystem was trying to read the values of the abbrev table and at the same time the abbrev table was being modified by the rjvm layer.

Cloning the key set before sending the data to the monitoring subsystem so that the HashMap is not modified simultaneously by two threads eliminates the ConcurrentModificationException.

CR188371

When an application cached a stateless session bean remote stub, and all the servers in the cluster were restarted, the stub was unable to refresh its lists of server nodes where the remote object was available and failover did not succeed. This was happening because the stub did not have the information needed to re-establish the initial context with the cluster nodes, hence the remote method invocation failed.

WebLogic Server code was not propagating the thread environment for the stateless session bean stubs in WebLogic Server 6.1 versions and it is required in WebLogic Server 7.0 and higher versions for unmarshalling to set the environment so failover works.

The runtime descriptors for the clusterable stateless session beans now have the propagate-environment attribute set to true by default.

The descriptor is now read and the propagateEnvironment is set so the environment is passed on during unmarshalling. This will allow the failover logic to reconnect to the cluster nodes to retrieve the new list of server nodes where the remote object is available and allow for proper failover.

CR182684

Every time the beasvc service handler was called, the beasvc log added a line indicating that it was called.

For example:

Tue Apr 27 11:52:17 2004] [I] [service_ctrl] 4

This caused the log to fill up when there was no real activity on the server.

The debug statement was removed, eliminating the log problem.

CR181986

WebLogic Server running as a service sometimes ran out of memory if it was using a large number of threads.

Reducing the reserve stack size used by beasvc.exe and beasvc64.exe from 1mb to 256kb eliminated the memory problem.

CR176614

Stateful Session Bean handles taken from the 70 (or 81) WebLogic Server servers to WebLogic Server 61 server/client were failing with a ClassNotFoundException in the serialization code.

Compared to the WebLogic Server 6.1 server, WebLogic Server 70 and 81 servers used a different PK mechanism for SFSB in the ejb container.

Adding the necessary classes to 6.1 line to support the inter-op requirement eliminated the ClassNotFoundException.

CR174605

According to the documentation in "Starting and Stopping Servers" if the CLASSPATH is too long, it can be added as a single line to a file and then accessed as -classpath @filename. However, when beasvc attempted to load the contents of CLASSPATH file, it truncated the last character when the file did not end with a new line.

Now beasvc determines whether the file terminates properly and then reads the file accordingly.

CR173958

Interoperability between 6.1 SP04 and 8.1 SP02 us t3 was failing when the protocol was changed from "secure" to "non-secure" between the front-end and back-end. The front-end QOS was being propagated to the back-end for the authentication call and it was failing.

The problem was resolved by using "anonymous" when doing the bootstrap authenticate call.

CR172366

Messages printed by beasvc.exe to the event log were not readable in Japanese locale.

A code fix ensures that English messages are printed for all non-English locales.

CR135225

A deadlock was occurring between RJVM and NTSocketMuxer.

Code was added to ensure that WebLogic Server does not hold a lock on IORecord during dispatch, thus ensuring that a deadlock will not occur.

CR134971

When <<no stack trace available>> was sent out as part of the exception message field (from the server side) rmi layer was recursively adding / appending the exception as server side stack trace. This was filling up the log files. This manifested when the server was running out of heap and there was a NullPointerException thrown by the application code (EJB + Servlets)

WebLogic Server now parses the exception message field, traps this specific exception and ensures that it is appended only once.

CR133880

Under heavy load, T3File client often threw an ArrayIndexOutOfBoundsException when closing OutputStream/InputStream.

WebLogic Server now acquires the lock on the Vector before starting the loop.

CR175607

Installing WebLogic Server as a Windows service immediately after uninstalling it sometimes created wrong registry keys, which could lead to startup problems.

A code fix ensure that the registry keys are flushed and properly closed.

CR130409

When setting the maximum length of an execute queue with the -Dweblogic.kernel.allowQueueThrottling flag to throttle "slow moving resource intensive" requests on a custom queue, clients did not receive a 503 response and therefore waited for the timeout.

This problem was resolved by a code fix to check for the dispatch return value on the caller and use the sendError() API to return the 503 response.

CR130376

According to the documentation at "Starting and Stopping Servers" if the CLASSPATH is too long, it could be added as a single line to a file and then accessed as -classpath @filename. However, this was not working because when beasvc attempted to load the contents of CLASSPATH file, it sometimes truncated the last character. This only happened when the file did not end with a new line.

A code change was made so beasvc figures out whether the file terminates properly and is then read accordingly."

CR129094

Performance issues that involved TCP window shrinkage in the t3 protocol on the AIX platform have been resolved.

CR122939

A distributed deadlock occurred due to a failure to maintain session stickiness with the primary server. When a request lands on the server which is neither primary nor secondary, it will try to remove the existing session from the primary as well as the secondary and create a new one on the current server and register a new secondary to it. In doing so, this server makes a remote request to the primary to remove the session on non-blocking queue, the primary server makes a remove call to the secondary server to remove itself on non-blocking queue. If there are more than one such requests, there will be no other thread to receive the response on the current server since there will be only two threads available in non-blocking queue and hence there is a distributed deadlock.

WebLogic Server now makes no new remote requests while processing requests that come in on a non-blocking queue. This fixes the problem, as it ensures that there will always be a thread available in the non-blocking queue to receive a response.

CR Number

Description

CR134122

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_57.00.jsp.

CR124991

When <validate-db-schema-with>MetaData</validate-db-schema-with> was used AND a cmp-field and a cmr-field were mapped to the same column, a java.lang.IndexOutOfBoundsException was being thrown.

WebLogic Server has been modified and this exception is no longer thrown under these circumstances.

CR055396

When a EJB QL syntax error occurred, WebLogic Server generated an error message with an incorrect xml file reference.

WebLogic Server now generates the message as follows if there are syntax errors in EJB QL.

[java] ERROR: Error from ejbc: Error while reading 'META-INF/ejb-jar.xml' or 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was:

CR185643

For BLOBs, in the generated code, WebLogic Server calls ObjectOutputStream.writeObject and ObjectInputStream.readObject to serialize/deserialize the object before writing/reading it to the database. These calls add extra header information. The writeObject method writes the class of the object, the signature of the class, the values of the non-transient and non-static fields of the class, and all of its supertypes are written. (This is the reason for the extra header seen in the database.) These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because it uses readObject to convert the bytes into the appropriate object, which needs that extra header information. However, if the BLOB has been inserted directly into the database by some other vendor or programmer using:

OutputStream os = ((weblogic.jdbc.common.OracleBlob) lob).getBinaryOutputStream(); os.write(this.tiffImage); // byte[] tiffImage

then problems may occur because WebLogic Server uses readObject and the header information is missing. For the data inserted using WebLogic Server, the other programs that would read the bytes directly get the extra header information and fail.

A system property has been added which allows WebLogic Server to correctly report header information.

CR187121

A high value for idleTimeoutSecs, for instance, 60000000, in the Deployment Descriptor when multiplied by 1000 to convert it into msecs was overflowing into a negative value. This caused the trigger that cleans the passivated beans from the disk to constantly fire, causing high CPU usage.

The variables within the EJB container which held the timeout values in milliseconds, such as idleTimeoutMS, sessionTimeoutMS, and readTimeoutMS, have been changed from the int type to long. This prevents any numeric overflow.

CR135367

EJBStatelessHomeRuntimeMBean's implementation class did not provide correct details of pool statistics.

Code was changed to provide the correct pool statistics in the runtime mbean methods.MBean calls now show the correct data.

CR127097

The Stateful EJB monitoring page did not have the machine name prefixed to its output

so it was impossible to see to which machine the entry referred.

The machine name was added to the Stateful EJB monitoring page.

CR124026

The read-only concurrency strategy in 6.x used Exclusive concurrency. This guaranteed exclusive access to the bean, but not to the generated Set for the 1-N relationship. It was possible for two clients to get access to the same Set. In such a case, when some method was called on the relationship Set, it caused a NullPointerException.

Relevant code changes were made to guarantee exclusive access to the relationship Set to fix the issue.

CR104539

CR102308

In WebLogic Server 6.1 SP04, the Administration Console reported incorrect values for waiters for entity beans.

The problem was solved by adding a waiterCurrentCount attribute that is incremented when a client starts waiting for a lock and decremented when the lock is acquired or the client times out.

CR096398

EJBContext.getRollbackOnly() returned "true" if a transaction marked for rollback and had not yet been rolled back. After the transaction was rolled back, it returned "false".

EJBContext.getRollbackOnly() now returns "true" even if the transaction has already been rolled back.

CR060229

The Administration Console was not exposing the Transactions Committed Total Count, the Transactions Rolled Back Total Count or the Transactions Timed Out Total Count for Stateful and Entity EJBs.

The Administration Console now allows monitoring of these items.

CR087261

The EJBDeployer was writing an incorrect deployment message to the log for Message Driven Beans.

The correct message is now being logged when a Message Driven Bean is deployed.

CR079432

MessageLocalizer was not setting the l10n_package attribute in localized catalog files using the l10ngen utility.

MessageLocalizer now correctly sets the l10n_package attribute in a localized catalog file.

CR142730

After a long database outage, a JDBC connection pool that used the XA jDriver for Oracle with TestConnectionsOnReserve="true" could not recover and recreate connections to the database. The following error messages were thrown:

<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: open failed for XAResource 'oracleXAPool' with error XAER_RMERR: A resource manager error has occurred in the transaction branch.

and

<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: LDA pool exhausted - make sure you call Connection.close()

The problem was that during the outage, the JDBC connection pool attempted to recreate connections, but on failure, those connection attempts were not cleaned up and were depleting Oracle client resources (in the LDA).

The jDriver now cleans up connection creation attempts that fail.

CR134285

class weblogic.db.oci.OciLob defined two class level variables to hold the returned byteArray for either BLOB or CLOB data from database. As this byte array could be quite large each instance of OciLob filled up the heap quickly until a garbage collection occurred.

Further testing and a modified OciLob moving the class level variables retBArray[] and retCArray[] into the methods caused the variable to be allocated on the stack and reduced the size of the OciLob object instance and thus overall heap usage was reduced.

Code was added to move the global variables retBArray and retCArray to the method level in order to reduce the size of the memory heap usage.

CR172462

The WebLogic Server jDriver was not functioning properly with Oracle 9.2 when using the AL32UTF8 character set.

This problem was resolved with a code fix.

CR136168

WebLogic jDriver may cause the server to crash with Oracle error message ORA-02392 when using the long raw type under heavy loads.

A code fix was implemented to resolve this issue.

CR129220

WebLogic Server Oracle jDriver was not properly releasing Clob Objects for garbage collection.

WebLogic Server now releases Clob Objects correctly.

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.

CR188040

WebLogic JMS was not receiving notification when ServerDebugMBean() JMS attributes were changed.

The ServerDebugMBean() can now be used to dynamically enable and disable "DebugJMS" ServerDebugMBean attributes. This allows customers to dynamically enabled or disable JMS Debugging flags.

CR099554

Under certain circumstances when a server with JMS messages in a pending state was shut down or crashed, pending messages were not recovered when the server was restarted.

Pending messages are now recovered upon restarting the server.

CR123194

In previous WebLogic Server 6.1 service packs, when the server instance went down but its clients remained active, JMS threw a runtime exception weblogic.rmi.extensions.RemoteRuntimeException, instead of a JMSException as expected per the JMS specifications.

A code change has resolved the problem in this Service Pack.

CR126192

Long-lived JMS connections lacked a periodic heartbeat check.

Following a code change, when JMS is idle the connection pings the database every five minutes to keep connection fresh.

CR182338

A receiver stops processing messages when a RedeliveryLimit is configured and the number of times the RedeliveryLimit is reached is greater than the MessagesMaximum setting on the ConnectionFactory.

Example: RedeliveryLimit=0, MessagesMaximum=10. Receiver receives a message and calls sesssion.recover() 10 times. Receiver will stop processing messages and the console will show 10 messages pending.

Code was added to adjust the window counter when a message is removed from the queue because the RedeliveryLimit had been reached.

CR126183

An idle bridge was logging a message after the maximum idle time setting had been reached.

Code was added to suppress the repetitive log message "Bridge X start transferring messages" logged by an idle bridge.

If the bridge is stopped and restarted, or if it encounters an exception and is restarted you will see the "Bridge "bridgename" starts transferring messages" log message, but you will not see the repetitive message logged by an idle bridge.

CR133155

WebLogic Server took too long to recover JMS messages from the JDBC store at boot time. Including JMS in the getTables prefix resolved the problem.

CR136746

Enhancement request to allow explicit naming of JDBC driver being used in class VendorId.

This customer enhancement was made through a code change.

CR122556

HTTP tunneling requests were sometimes producing ProtocolExceptions.

Code was added to WebLogic Server to eliminate the ProtocolExceptions.

CR087857

When the character encoding was set by JSP pages or servlets, the ServletOutputStream.write(int) method, which takes int type as its argument, received the data encoded using the specified charset encoder.

WebLogic Server no longer encodes the binary data when ServletOutputStream.write(int) is called.

CR180425

WebLogic Server was sending wlsproxy specific headers even when the request did not originate with a proxy.

Code was added to check if the request is coming from a proxy and send the appropriate header.

CR077922

CR063304

The HttpSessionBindingListener were not getting fired correctly. In some cases they were invoked twice.

Re-implementing the callbacks strictly per the Servlet Specification fixed this problem.

CR123308

T3ServicesDef and LogServicesDef interfaces have been

deprecated beginning with the WebLogic Server 6.1 SP5 release.

CR101992

A web application that had a local EJBObject reference in its session, sometimes got an javax.ejb.EJBException after it was redeployed.

Code was added to catch the exception and log a message. An error message is now logged to indicate serialization failure and the getAttribute() of HttpSession, ServletRequest or ServletContext returns null under these circumstances.

CR085091

There was a problem that was preventing serving custom error pages, if the request was a conditional GET (Is-Modified-Since header set) for a protected resource.

The logic was fixed to serve the custom error page if one is defined.

CR127959

Code that used a response wrapper and called getOutputStream on the original response passed into a JSP resulted in NestedBodyResponse always throwing an IllegalStateException.

Mixed use of getWriter() and getOutputStream() from NestedBodyResponse are now allowed, so the exception will only be thrown when appropriate.

CR133291

A protocol exception, excjava.net.ProtocolException: Didn't meet stated Content-Length, was occurring when a client cancelled a request while the default fileServlet was sending a file.

This was resolved with a code change.

CR127708

WebLogic Server decoded the path /foo/bar%c0%baz/ to /foo/bar because sun.io.ByteToCharConverter stopped converting the remaining bytes if it encountered bytes that were not valid in UTF8 (for example, 0xc0). This problem does not occur on JDK 1.4.

The problem was resolved with a WebLogic Server UTF-8 converter that replaces invalid UTF-8 sequences with U+FFFD characters. As a result of this fix, the path /foo/bar%c0%baz/ is decoded to /foo/bar?%baz.

CR143448

The java.lang.IllegalStateException: HttpSession is invalid exception occurs in the servlet container's internal call. If other threads using the same session ID invalidate the session object during processing of ServletRequestImpl.syncSession(), an IllegalStateException may occur while calling SessionData.putValue() or SessionData.isNew().

Ignore the IllegalStateException if the session has been invalidated by other threads.

CR134414

When a Serializable Servlet request attribute was added, and then overwritten it with a non-Serializable value, the original value masks the new one.

A code change was made to try to remove the value from a HashMap table of serializable attributes if necessary, when replacing a Serializable value with a non-Serializable one.

CR132522

On a Web server without a default Web application, an HTTP request for a missing resource received a response that included an incorrect date header:

HTTP/1.1 404 Not Found Date: Thu, 01 Jan 1970 00:00:00 GMT

This header is not valid according to section 14.18 of RFC2616. A code change resolved the problem.

CR173042,

CR110910

HttpClusterServlet threw this exception, when KeepAliveEnabled was set to true after a large file download was canceled.

Analysis revealed that when a client canceled a file download, the remaining data was left in the inputstream. If the socket was recycled for a subsequent request, the servlet read the remaining data, resulting in the exception.The problem was solved with a code fix to drain the inputstream and if the download is canceled we will read this remaining data.

CR133558

ServletContext.setAttribute threw a NullPointerException when a null value was passed to it.

The problem was resolved by a code change that calls removeAttribute() when a null value is passed to the setAttribute().

CR129211

Using ServletOutputStream.write(byte) to write more than the buffer size caused infinite loop.

A code change resolved the problem by updating the check for boundary conditions when the buffer is full and autoflush is set to false.

CR128986

After a protocol exception, the server hung while trying to process a new license because of a problem with the ensureContentLength method.

A code change ensured that the server no longer hangs during this process.

CR128420

breakUpAndWriteItOutAsNecessary() tried to separate a manifest header to enforce a maximum of 72 bytes per line, and wrote one line to an outputstream at a time. The cause of this problem was that the start offset for the new line is wrong.

A code change resolved the problem.

CR127836

A JSP in a subcontext of the root context was precompiled when deployed as a Web application packaged in a WAR file, but not if it was deployed in exploded format.

JSPs now precompile when deployed in an exploded format.

CR127090

Jsp used several MBeans with attributes that had the same names, thus when they were displayed, it looked as though there were duplicates, when in fact, there were none.

The display labeling of the MBean attributes was changed for the mbeans that had the same attribute names. They are now distinguishable.

CR116209

When a Serializable ServletContext attribute was added and then overwritten with a non-Serializable value, the original value masked the new value.

When replacing a Serializable value with a non-Serializable one, WebLogic Server now removes the original value from the attributes hashtable.

CR121343

A race condition arose during the computation of a secondary JVMID when more than one frame was used. It appeared that the computation of the secondary JVMID was resetting the member variable value by one thread, causing the race condition.

Following a code change, the computation of the secondary JVMID no longer leads to the race condition.

CR120932

The HTML page served by the CertificateServlet displayed the wrong value for the radio button—it displayed 2048 for the radio button, but using the button resulted in a 1024 bit certificate.

The radio button now produces the correct 2048 bit certificate.

CR091831

The WebLogic Server implementation of HttpURLConnection did not check whether keep-alive connection had been timed out on the server side when using POST method, resulting in the error: Connection aborted by peer: socket write error on flush.

Checks were added to ensure that the HttpClient is non-null before updating the timestamp.

CR108034

Inappropriate error messages generated by a user breaking a connection have been suppressed.

CR132228

Harmless IOExceptions were not being suppressed on Japanese locales.

WebLogic Server now sets the locale to C by default when enabling nativeIO. Customers who do not want to set the locale to C can use the system property

-Dweblogic.nativeIO.useDefaultLocale=true

On non-english locales, the harmless exceptions are now suppressed.

CR122811

A change to support piping of passwords into weblogic.Admin. That change locked up the System.in stream, preventing automated scripts from working correctly.

The change that locked the System.in. stream has been corrected and scripts can now be automated.

CR097343

When a deployment was done where the targets were across two different platforms (such as unix and windows), the deployment files were not found.

The deployment location was not being localized for the local machine type. If one deployed a webapp from an administration server running on windows and targeted it to a unix based machine, the location of the deployment was malformed for that platform.

The deployment path has now been localized for each machine type.

CR190237

The WebLogic Server MBeanHome method getAllMBeans() threw an exception when running in a WebLogic Portal environment.

WebLogic Server MBeanHome Helper needed additional knowledge of WebLogic Portal mbean class locations and a correction to existing logic.

The ClassNotFound exception is no longer thrown in the WebLogic Portal environment.

CR190212

when an exception was thrown while retrieving attributes via MBeanServer.getAttributes(), any exceptions thrown by the JMXServer were handled and a null value was returned.

WebLogic Server now rethrows the exception instead of returning a null value.

CR188030

CounterMonitor.stop() was synchronized causing a deadlock.

Synchronization was removed, as called for in the documentation, eliminating the deadlocks.

CR187170

When the attributes of an array type changed(meaning certain elements of the array were added or deleted or both), AttributeAdd/Remove notifications were not being sent out. Thus certain deployments were not being carried out properly.

The WebLogic Server now sends AttributeAdd/Remove notifications, in addition

to the AttributeChange notification, when an array type attribute values change.

CR113085

When the value of SqlStmtProfilingEnabled was set through MBeans or manually in config.xml file and then you tried to retrieve that value through MBeans it did not show the value. Instead, it returned a message, "It appears that no attributes have been specified for this MBean".

Exposing the SqlStmtProfilingEnabled attribute of JDBCConnectionPoolMBean eliminated the error.

CR104435

The KernelDebugMBean options, DebugDGCEnrollment and ForceGCEachDGCPeriod, could not be enabled. There was no way to "set" the enable attribute in weblogic.management.configuration.KernelDebugMBean.

The setter signature did not take boolean for these attributes, so the values for these flags could not be changed from the default.

These attribute setters now accept boolean.

CR081349

When printing the ExecuteQueueRuntimeMBean, the ExecuteThreads attribute was not being displayed correctly with the weblogic.Admin tool.

The entries in the ExecuteThreads attribute are now displayed as a readable string value.

CR094219

When Domain and Server logfile names were date and time based (SimpleDateFormat), the following features were not fully functional:

1. These type of logs were not being rotated.

2. The total number of log files were not restricted even when the FileCount was set.There was no code in place to delete the older log files because the FileFilter could not list these files because of their file name patterns.

File rotation has been implemented for these types of file names.After each rotation, WLS now checks to see whether the files exceed the limit, if restricted. It then deletes the older log files.

CR180724

The initial cookie was created through web server one and sent to cluster one. When ithit the application again it went through web server two and instead of being directed to cluster 1 it went to cluster 2 and created a new session.

The WLCrossOverEnabled functionality now works correctly in WebLogic Server.

CR132699

The Apache 2.0.x plugin for Redhat Linux AS 2.1 returned an incorrect status code. The problem was resolved with a code change, which sets the status code to 500 when the backend WebLogic Server instance is not available.

CR178792

Apache) HTTP requests can contain either one of the following headers: Content-Length or Transfer-Encoding

Requests with a Transfer-Encoding header set to "chunked" were failing with an IO error.

Code was added to support requests using the Transfer-Encoding header set to "chunked".

CR190562

Requests were not retried when the plug-in encountered a broken pipe error on Solaris while sending post data to WebLogic Server.

WebLogic Server now throws a HALF_OPEN_SOCKET_RETRY exception when sendPostData reports a broken pipe on Solaris

CR189251

Under load, Segmentation errors occurred while retrieving plugin Properties for a virtual host.

Replacing the strtok API with strchr, as the strtok API is not thread safe, eliminated the errors.

CR182971

ServerList was deleted after every DNSRefreshInterval which resulted in a core dump.

WebLogic Server now does a dns lookup of all the servers in the list and updates the ServerInfo structure if any server has changed from the last time it was checked.

CR187282

Because the plugin did not follow a part of the HTTP1.1 specification, which states that if a request/response contains both a Content-Length header as well as a Transfer-Encoding: Chunked header, the Content-Length header MUST be ignored, there was a unique scenario involving a recycled connection from the pool that sometimes caused an error.

WebLogic Server now returns contentLength as -1 if CTE is on.

CR095984

When the file size exceeded 30KB, a DNS error message of IE 6.0 was received instead of a 413 message when using the NSAPI plug-in.

The behavior of MaxPostSize configuration is now the same with or without a plug-in.

CR188811

CR188808

WLExcludePathOrMimeType did not work correctly when a request had a query string.

Requests such as http://webserver:port/weblogic/something.jsp?value=123 were not excluded and requests such as http://webserver:port/weblogic/something.do?name=test.jsp were not forwarded.

The plug-in now ignores query strings while checking for excludes.

CR187578

When KeepAliveEnabled ON was configured in httpd.conf, KeepAliveSecs defaulted to 20. This default setting could not be changed.

Code was added to ensure KeepAliveSecs is configurable.

CR187577

When using multiple Location tags in a VirtualHost tag, the Apache plug-in generated a strange URL if the requests matched two more Locations.

The Apache plug-in no longer uses regular expression match, unless specified.

CR186470

When using the IIS plug-in, the creation of a large number of new connections through a firewall resulted in an HTTP status 302, and the connection was closed.

WebLogic Server now recycles the connections if the HTTP status code is 302.

CR186148

When the Apache plug-in encountered a missing page, it was returning a 500 error, rather than the correct 503 error.

The plug-in now returns the correct error.

CR185668

When using the Apache plug-in to proxy to multiple clusters using MatchExpressions, the PathTrim attribute was failing to trim off the segment of the url used to direct the request.

Reimplementing MatchExpressions parsing without using the strtok API corrected the problem.

CR185089

The IIS plug-in was sending an Http status code of 500 (internal Server Error) when it encountered a WRITE_ERROR_TO_CLIENT exception due to a connection closed by the client.

The IIS plug-in no longer sends Http status code of 500 when a WRITE_ERROR_TO_CLIENT exception is caught.

CR180417

If a cookie was part of the POST data then plugin would corrupt the post data while extracting the cookie.

Code was added to fix the cookie extraction from Post Data.

CR136816

If the PRIMARY server could not be located, then the request was served by the next available server in the list. It ignored the Secondary server.

If the Primary server can not be located, but the Secondary server is present then the request will be forwarded to Secondary server rather than being served by another server on the list.

CR183390

WebLogic Server was throwing an exception from inside the catch block which sometimes caused iPlanet to fail.

WebLogic Server no longer throws an exception from the catch block.

CR183311

When Apache was stopped while using a single-thread multi-process module, it would try to stop the timer thread first. This timer thread never existed, thus a core dump occurred.

WebLogic Server no longer creates timer threads when Apache is being used with a single-thread multi-process module.

CR183188

The ISAPI plug-in was unable to handle requests with the Transfer-Encoding header set to chunked.

Functionality was added to enable ISAPI to handle such requests.

CR182434

Headings passed to rq->srvhdrs were not entirely in lower-case instead of mixed case.

Content-type, content-length and transfer-encoding headers are now passed to NSAPI entirely in lower case.

CR175787

WebLogic Server was throwing CONNECTION_REFUSED errors with the Iplanet plugin.

After polling a socket for WRITE operation, if the state of the socket is in any one of the following states, then the plug-in will not throw aCONNECTION_REFUSED exception.

Valid states are:

POLLOUT

POLLWRBAND

POLLWRNORM

CR173985

(Apache) The plug-in was dropping sessions after WebLogic Server was restarted.

This is because Apache 1.3.x creates multiple child processes to handle incoming requests. Each process maintains its own serverlist where each server entry is uniquely identified by the JVMID (provided by WebLogic Server, and which is updated when a request is successfully processed). Whenever a server instance is restarted, it generates a new JVMID. So a request whose cookie contains a new JVMID will fail to locate the corresponding primary server plug-in if the JVMID is not refreshed in the plug-in.

A code fix ensures that if the JVMIDs extracted from cookie do not match with the ones stored in the serverlist, then WebLogic Server will try to refresh the JVMIDs once again.

CR136968

Weblogic Server was not accepting more than one header when the response.addHeader method was used.

The plug-in now allows WWW-Authenticate to have multiple values.

CR135002

In an Apache configuration with multiple virtual hosts, if only one of the virtual hosts was configured with SecureProxy=ON for the WebLogic Server plug-in, and the other virtual hosts did not use SecureProxy or WLProxySSL, the virtual hosts with no SSL configured saw that the plug-in attempted an SSL connection with the backend WebLogic Server. This caused a performance problem.

A new argument was added to an internal method to determine if a SSL connection needs to be initiated.

CR134413

Apache plugin caused a duplicated http header and body for the 302 response. There was no problem between the plugin and backend servers, but the Apache server added an additional 302 response.

Code was added which reverted the return value of the request_handler method to OK.

CR132840

Apache access logs improperly recorded a 200 code rather than a 500 error when application servers were down. A code change resolved the problem.

CR132426

When the plug-in parameter "QueryFromRequest" was used in the httpd.conf file

it gave the following syntax error during Apache Server startup

Syntax error on line 971 of C:/Program Files/Apache

Group/Apache2/conf/httpd.conf:Invalid command 'QueryFromRequest', perhaps misspelled or defined by a module not included in the server configuration.

The Apache 2.0 plug-in now supports the "QueryFromRequest" parameter.

CR131640

WebLogic Server was requested to provide a plug-in for the Sun One 6.1 web server.

The SUN ONE 6.1 Web Server is now fully supported.

CR180236

The release 8.1 SP02 plug-in with client certificates reported the following error:

Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException.

The error occurred because the plug-in truncated the WL-Proxy-Client-Cert header when sending it to the WebLogic Server instance.

The problem was resolved with a code fix.

CR179537

(ISAPI) The IIS proxy plug-in caused heap corruption on the Microsoft Windows platform.

The problem was resolved with an internal code fix.

CR177707

When using the release 7.0 SP02 plug-in with client certificates, WebLogic Server worked correctly. However, after an upgrade to release 8.1 SP02, the server log reported the following error:

Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException

The error occurred because the 8.1 SP02 plug-in truncated the WL-Proxy-Client-Cert header when it sent it to the server instance.

The code was changed so that WL-Proxy-Client-Cert is lazily added to the request sent to WebLogic Server.

CR175989

(Apache) The Apache server generated core dumps when using the worker (multi-threaded) option instead of the prefork (only multi-process) option.

This was resolved by fixing the Locking and Unlocking logic.

CR175672

(Apache) The Apache server was hanging when the WebLogic plug-in tried to open the wlproxy log file, even though Debug was OFF.

The code has been fixed so that the log file is not set if debugging is turned off.

CR174777

[iPlanet] POST_TIMEOUT errors occurred in the iPlanet log file due to a broken pipe.

Code was added to throw a HALF_OPEN_SOCKET_RETRY exception if an EPIPE error is encountered while sending POST data to WebLogic Server.

CR174431

(NSAPI) The Iplanet plug-in now gracefully handles an EINTR OS error.

CR173653

When the WLExcludePathOrMimeType property was defined within a Location tag, it should not have had a global scope. (However, when the property was defined outside a Location tag, then it should have had a global scope.)

This was resolved by a code change to ensure that the WLExcludePathOrMimeType property is applied only to the requests that match the appropriate Location path for the defined property.

CR173581

CR173878

(Apache) The plug-in was logging a confusing "error page is unavailable" log message to the apache error.log, even when the client had closed the connection.

This was resolved by a code change that commented out the erroneous log message.

CR172497

(NSAPI) The "pluginparams.ErrorPageTest" failed when attempting a proxy by extension.

The workaround for the ErrorPage to be loaded locally is to use the WLExcludePathOrMimeType property if proxying by MIME type.

For the SUN One Web Server, version 6.1, some additional configuration steps are required:

1. Remove NameTrans fn="ntrans-j2ee" name="j2ee" from the default object in the obj.conf file.

2. Remove Init fn="load-modules" shlib="C:/Sun/WebServer6.1/bin/https/bin/j2eeplugin.dll" shlib_flags="(global|now)" from the magnus.conf file.

For more information, refer to Sun's documentation, at http://docs.sun.com/source/817-1831-10/agjava.html#wp1084 323

CR172072

Provided an enhancement to the WLExcludePathOrMimeType parameter allowing it to be used at the Location tag level.

WLExcludePathOrMimeType parameter can now be defined locally at the Location tag level as wells as globally. When the property is defined locally, it does not override the global property but defines a union of the two parameters.

CR171978

When the FilterPriorityLevel was set in the iisforward.ini file, the forwarding path was broken.

A code fix was implemented to ensure that when a virtual host was not defined in the iisforward.ini file, the iisproxy.ini file from the same location as where the iisforward.dll file was loaded is used.

CR133641

iPlanet users experienced a problem with host name verification and received the following:

INFO: Host () doesn't match (), validation failed

ERROR: SSLWrite failed

A code fix resolved this issue.

CR130060

A performance problem in the IIS plug-in has been resolved in Service Pack 5 by a code change that causes the plug-in to check whether data equivalent to a specified content length has already been read.

CR129471

In previous service packs, the Apache plug-in did not recognize the WLTempDir parameter. This has been corrected.

CR129342

The ISAPI plug-in sent the WL-PATH-TRIM HTTP Header value to a WebLogic Server in place of the WL-PATH-TRIM value.

WebLogic Server now receives the correct value.

CR129138

When the NSAPI plug-in performed name resolution on backend WebLogic Server instances, name resolution used sysGetHostByName, which called getHostByName, which called internal methods that had maximum limits for open file descriptors, causing name resolution sometimes to fail.

A fix to cookie parsing and the substitution of JVMIDs to locate primary and secondary servers resolved the problem.

CR129026, CR129323

A memory leak in the ISAPI plug-in was fixed by a code change.

CR127973

The ISAPI plug-in sometimes failed after adding a persistent cookie to a servlet session.

A correction to the cookie parsing code resolved the problem.

CR127658

[ISAPI] When a connection was retrieved from the pool, but the WebLogic Server had already closed the connection, then the HALF_OPEN_SOCKET_RETRY exception was raised.

Requests will be now be retried after receiving the HALF_OPEN_SOCKET_RETRY exception.

CR084303

WebLogic Server proxy plug-ins restrict the HTTP commands that can be submitted from the client to the server. The validation rules in the plug-in code now allow the following HTTP commands that are needed for WebDAV implementations:

DELETE

GET

HEAD

OPTIONS

POST

PUT

*COPY

LOCK

MKCOL

MOVE

PROPFIND

PROPPATCH

SEARCH

UNLOCK

CR127231

A request did not fail over to the next available server in the cluster after receiving 503 HTTP status. The same server was tried repeatedly until a READ_ERROR_FROM_SERVER or a CONNECTION_REFUSED exception was raised.

Code now marks the server as failed on getting a 503 HTTP status error, gets the next available server and re-sends the request. All requests now successfully fail over to next available server.

CR188748

CR180749

During the repository id generation of getter and setter operations, sometimes an extra '_' was added if the getter or setter contained a reserved keyword. This sometimes resulted in the failure of a remote call.

WebLogic Server now ensures it truncates extra underscores.

CR175112

The method used to send IIOP messages was unsynchronized leading to corruption of the underlying data if multiple threads tried to send and receive data at the same time.

The method was made synchronized and the product now works correctly in multi-threaded environments.

CR177353

When a application client code cached the remote stub and invoked a remote method on a SLSB deployed to a cluster, the behavior was that each call refreshed the list which tracked the cluster nodes where the remote object is available. This list was used to failover the calls if any of the node failed with a recoverable exception. The issue here was that failover did not work when the entire cluster was restarted while the application client had cached the stub from a previous invocation.

The retry logic in the failover algorithm was incorrect. This logic originally allowed n-1 number of retries in a cluster with n nodes. When the entire cluster restarted, the cached stub would have stale list. And the retry logic scanned though the stale list and exhausted all the retry attempts. In the last attempt it would have potentially refreshed the list. Even though the client side stub now had a new copy of the list it did not attempt to failover as it has already reached n-1 attempts limit.

The remote stub cached in the application client now ensures it refreshes the list only when remote method invocation fails on all the nodes in the existing list. Then stub is given one last chance for failover if the list got refreshed. If this last chance does not succeed the stub will throw an exception to the application otherwise failover will continue to work as advertised transparently.

CR183199

Building the examples on Windows XP resulted in a StringIndexOutOfBoundsException.

Upgrading to Ant 1.6.1 eliminated the build problem.

CR183527

In WebLogic Server 6.1 SP06, the examples.ejb 1.1 package, examples/ejb/building.html provides incorrect instructions for building samples, and incorrectly describes how the samples build script works. The instructions and description refer to previous version of the build script which used build.cmd or build.sh. The current version of the build script (build.xml) uses ant. To run build.xml, type ant in the directory for the sample you wish to build. To understand how the build script works, refer to the comments in build.xml

CR132509

When using the .NET C# example included with the MedRec application (%WEBLOGIC_HOME%\samples\server\medrec\src\clients\CSharpClient\bin\ReleaseCSharpClient.exe), the client successfully retrieves a patient record, but when attempting to "Save Changes" from the client application, a date field error was flagged.

A code change fixed the date validation.

CR045135

Some internal WebLogic Server objects that are bound into the JNDI tree were insufficiently protected. Some of these objects control key functions of the server. Simply unbinding the appropriate objects renders the server unreachable. It was possible to leave the server operational but to have some confidential data transmitted to a foreign object rather than the internal WebLogic Server object.

The patches available in this release control access to the JNDI tree.

See Security Advisory BEA04-65.00.

CR103309

Whenever an HTTP or HTTPS request was made of the server, information about the WebLogic Server version was supplied.

The default setting for returning a Web Server version upon HTTP or HTTPS request has been changed from true to false.

See Security Advisory BEA04-70.00.

CR125520

A deadlock occurred between two threads when using Netscape LDAP classes - LDAPConnection and LDAPConnThread. This deadlock grew until all the default execution threads were deadlocked with LDAPConnThreads.

After updating to the new Netscape SDK, deadlocks no longer occur.

CR128940

A protection problem occurred when WebLogic Server was running on an operating system that required case-sensitive filenames and cross-mount directories containing Web applications from an operating system that did not support case-sensitive filenames. For example, this problem occurred when mounting Windows-based Web applications onto a Linux-based WebLogic Server.

This resulted in some URL patterns in the web.xml file being incorrectly evaluated so that access control was compromised.The associated patch adds configuration options to specify that Web application files should be treated as case-insensitive even though the operating system may be running in case-sensitive mode.

See Security Advisory BEA04-67.00.

CR123860

The constructor method for a flat group used by a custom realm expected a case-sensitive value. When a case-sensitive value was not found, a NullPointer exception was thrown.

WebLogic Server no longer throws a NullPointer exception when the value for the CachingRealm MBean value is null.

CR136544

A set of enhancements have been added to the WebLogic Server command-line utilities and Administrative ant tasks to eliminate the need for a system administrator to enter a clear-text password. With these fixes, the WebLogic Server command-line utilities and Administrative ant tasks now create and read user-managed configuration files. Like the boot.properties files, this new capability relies on strong encryption and file system protections for security.

See Security Advisory BEA04-68.00.

CR179663

CR188110

A NullPointer exception occurred when using the WebLogic Server Administration Console to list LDAP users.

Code was added to eliminate the NullPointer exception.

CR174299

The Use Java attribute on the SSL tab in the WebLogic Server Administration Console was not working properly.

The behavior of the attribute has been fixed.

CR172187

A password echo occurred intermittently on the Linux operating system when booting WebLogic Server using the Administrative Console.

No-echo capabilities have been added to resolve the issue. See the README file in the patch for further documentation.

See Security Advisory BEA04-69.00.

CR172567

If the certificate name was the same for both an Administration Server and remote Managed Server, WebLogic Server used the certificate for the Administration Server for the remote Managed Server.

The SSL Listen thread has been updated so that is only loads local certificates.

CR161836

WebLogic Server was setting the AuthenticatedUser in the session rather than the AuthenticatedUserName.

Servlet authentication has been changed so that is sets the AuthenticatedUsername resolved in the ClassCast exception.

CR127722

If host name verification failed but the setExpectedName() method was defined, WebLogic Server ignored the host name defined in the method and dropped the connection.

WebLogic Server now performs the host name verification check first. If that check fails, WebLogic Server uses the ExpectedName() method to verify the hostname. If that verification fails, the connection is rejected.

CR112619

A NullPointerException was being thrown when an Applet attempted to obtain an initial

context using the t3s protocol.

The basic constraints check for applets was updated, and this eliminated the NullPointerException.

CR124746, CR175051, CR175045

Following a code change, WebLogic Server does NOT support HTTP TRACE requests by default. If you want to turn on HTTP TRACE support, in WebLogic Server 6.1 and above, set HttpTraceSupportEnabled="true" in cluster/server. In 5.1, set weblogic.httpd.httpTraceSupport.enabled=true.

See Security Advisory BEA04-48.01.

CR112220

WebLogic Server was verifying the hostname of the administration server against the administration certificate in the nodemanager, thus causing an error.

Hostname verification in the nodemanager now only checks against the nodemanager hosts file.

CR113122

The value that the WebLogic Server SNMP agent returned for sysUpTime did not accurately report the duration since the SNMP agent had been initialized.

The duration since initialization is now accurately reported.

CR103678,

CR109869

When SNMP information was collected using a third-party collector task, the following message was logged:

<Error> <SNMP Agent> <000000> < Unable to set Entry Field Value...>

A code fix was implemented to resolve this issue.

CR121105

WLEC clients were experiencing the following problems with WLEC connection pools:

Corruption of the ConnectionPool display in the administration console

COMM_FAILURES caused by unregistered endpoints

A code fix was implemented to resolve these issues and improve the overall performance of WLEC connection pools.

CR133654

Fixed a problem with a race condition between the tBridge spawning threads for each redirect definition and the WTC Service setting an initialized flag to true.

CR185588

Fixed a problem in which the last character in a double byte character set is being cut in the middle and turning into 'null' on the WLS side after passing through WTC.

CR101547

A memory leak occurred when deploying an Enterprise Application that contained a singleton class with static data. The problem did not occur when the singleton class was deployed as a Web Application.

This problem was solved with a fix to the application classloader.

CR104513

With the fix for CR069506 introduced in WebLogic Server 6.1 Service Pack 2, the classloader failed to find files when one manifest finder recursively referenced other manifest entries. The problem was solved by changing Classloader.getResources() to handle this case.

CR111924

WebLogic Server threw a ClassNotFoundException when processing a user-defined exception thrown from an EJB on a remote server to an EJB on the local server. This occurred even though the user-defined exception was included in the classloader for the local EJB. The problem occurred because the socket reader that processed the exception used the system classloader, rather than the application classloader.

This problem was solved with a code fix.

CR124348

Client programs could not use java.lang.reflect.Proxy to access proxy objects deployed in WebLogic Server, unless the proxy classes were added to the system classpath. If an object did not reside in the system classpath, the client would receive a ClassNotFoundException.

The resolveProxyClass() method was implemented to load interfaces from the application-specific classloader as well as the system classloader.

CR103807

WebLogic Server 6.1 SP04 threw a null pointer exception at weblogic.rmi.cluster.BasicReplicaList.add(BasicReplicaList.java:61). The problem occurred when a managed server was restarted after a failure. Upon restart, the NPE occurred and all server instances in the cluster had to be restarted. The error was related to a timing issue, and was solved with a code fix.

CR104430

Clustered servers could lose sessions when a client switched to a third server in the cluster from the first and second servers, which had been the client's primary and secondary servers. A process would remove the session from the first two servers, and when the client switched back to the primary server, the primary server looked for the session on the secondary server, instead of properly looking on the third server.

A code fix resolved the problem by causing the session to be recreated from session information on the third server, completely removing the session from the primary and secondary servers.

CR107471

In WebLogic Server 6.1 SP02, when using HTTP Tunneling with a cluster, the client got this message:

java weblogic.Admin -url http://colma:17683 -username system -password password PING 10

<May 29, 2003 10:14:18 AM PDT> <Error> <RJVM> <000515> <execute failed java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0'java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0'
at
weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch(HTTPClientJVMConnection.java:422)

at
weblogic.rjvm.http.HTTPClientJVMConnection.execute(HTTPClientJVMConnection.java:305)

at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213 at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)> Failed to connect to <urldeleted> due to: <urldeleted>:Bootstrap to <urldeleted> failed. It is likely that the remote side declared peer gone on this JVM]

The problem occurred because the plug-in tried to round-robin each tunnel request to the next server. The request did not stick to the same server.

The problem was solved with a code fix to ensure state was maintained in the client by setting the jsessionid cookie and sending it back to the plugin.

CR108127

In WebLogic Server 6.1 SP04, an error occurred when trying to update a secondary session. Given three clustered server instances: Server A, Server B, and Server C.

1) Hit Server A, PRIMARY A, SECONDARY C

2) Hit Server C, PRIMARY C, SECONDARY B

3) Hit Server A again

This error occurred on Server A:

<Jun 4, 2003 4:24:56 PM PDT> <Debug> <Cluster> <Error updating secondary for 3535724191309537720 on 7312270160516507840S:<IPaddressdeleted>: [7005,7005,7002,7002,7005,7002,-1]:<IPaddressdeleted>:7005, <IPaddressdeleted>:7005,<IPaddressdeleted>:7005:mydomain:myserver3. Re-creating secondary.>

This error occurred on Server C:

<Jun 4, 2003 4:24:56 PM PDT> <Info> <Cluster> <Lost 0 replication updates of object 3535724191309537720. Re-fetching secondary.>

The problem was solved by a code change.

CR112874

In WebLogic Server 6.1 SP03, when a client of a stateful session bean accessed a bean deployed on a cluster configured for weight-based load-balancing, and the Managed Servers with the highest and second highest weight are killed in that order, the client gives the following message

<Jul 22, 2003 1:32:56 AM IST> <Warning> <Kernel> <No replica in list has the expected weight. Reverting to round-robin>

When the Managed Servers are restarted, the load balancing algorithm was switched to round-robin.

Analysis revealed that the replica list was getting updated when a Managed Server went down, but due to a race condition the max weight in RichReplicaList was not reset properly.

A code change to recompute max weight whenever the replica list size changes solved the problem.

CR116954

The web application container returned 404 messages for InitJVMID requests from the HTTPClusterServlet, 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.

CR109463

When a transaction obtained connections to two resource adapters and both adapters used the same resource manager, WebLogic Server cleaned up only one connection. The connections were closed before the committing the transaction. This problem appeared as a javax.resource.spi.ResourceAllocationException.

The problem occurred because the transaction manager ignored the second connection that used the same resource manager. This was solved with a code fix.

CR121418

When allocating a new connection, the connector container used the descriptor MBean to obtain configuration information. Because the descriptor MBean resides on the Administration Server, Managed Servers required the Administration Server to be available in order to allocate the new connection. If the Administration Server was down, the process of allocating new connections would throw a exception:

weblogic.rmi.extensions.RemoteRuntimeException

The container was modified so that it stores configuration information locally after an adapter is deployed. Managed Servers use this local configuration information, rather than the descriptor MBean, for allocating new connections.

CR125555

When WebLogic Server Service Pack 5 obtained MetaData information from a Resource Adapter, it did not check the return value for nulls before using the object. This could cause a NullPointerException and connection failure.

The code was modified to check the return value for null after calling getMetaData(). If an adapter's implementation of ManagedConnection.getMetaData() returns a null value, WebLogic Server no longer throws a NullPointerException and no MetaData is logged.

CR100006

WebLogic Server sometimes displayed the following NullPointerException when a domain contained two Administration Servers and you tried to access the servers via the Administration Console:

java.lang.NullPointerException
at
weblogic.management.console.helpers.UrlHelper.buildIconList(UrlHelper.java:149)
at weblogic.management.console.helpers.UrlHelper.getIcon(UrlHelper.java:174)
at
weblogic.management.console.tags.SmartNavNodeTag.getIcon(SmartNavNodeTag.jacva:111)
at
weblogic.management.console.tags.SmartNavNodeTag.inferStuffFromContext(SmartNavNodeTag.java:96)
at
weblogic.management.console.tags.SmartNavNodeTag.doStartTag(SmartNavNodeTag.java:44)
at
weblogic.management.console.webapp._domain.__nav._jspService(__nav.java:301)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:250)

[...]

This problem was solved with a code fix.

CR102824

After upgrading from WebLogic Server SP02 to SP04 on Solaris 8, when customer logs into the console they get the following exception in the log files. The console continues to work.

java.lang.NullPointerException at weblogic.management.console.utils.ConsoleComparator.compare(ConsoleComparator.java:81) at java.util.Arrays.mergeSort(Arrays.java:1176) at java.util.Arrays.sort(Arrays.java:1123) at java.util.Collections.sort(Collections.java:116) at weblogic.management.console.utils.MBeans.sort(MBeans.java:1103) at weblogic.management.console.tags.DeclareBeanSetTag.doStartTag(DeclareBeanSetTag.java:99) at weblogic.management.console.webapp._domain.__nav_services._jspService(__nav_services.java:982) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:490) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:316) at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:116) at...

Analysis revealed that MBeans were returning a null displayName. The problem was solved with a code fix.

CR105598

New testing with an Active Directory LDAP uncovered a problem where a call to group.isMember() would fail if a member name contained a comma character (,). This problem was solved with a code fix.

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
at
java.net.SocketInputStream.read(SocketInputStream.java:168) at
weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:876)
at
weblogic.socket.PosixSocketMuxer.deliverGoodNews(PosixSocketMuxer.java:767)
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:694)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
ad.run(ExecuteThread.java:189)
>

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
numFrees 0
NATIVE: start io on 1972 with addr 0x08dad008
NATIVE: GetQueuedCompletionStatus on 1972 with addr 0x08dad008
<May 6, 2003 11:17:19 AM EDT> <Error> <NT Performance Pack> <failure in
processSockets() - GetData: 'weblogic.socket.NTSocketMuxer$GetData - native
pointer: '0', numBytes: '0''
java.lang.NoSuchFieldError: fd
at weblogic.socket.NTSocketMuxer.getNextSocket(Native Method)
at
weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.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)>

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
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:275)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408) at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:255)

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:

1. Configure a cluster with server instances on at least two machines.

2. Deploy a sample EJB to cluster.

3. Restart the Administration Server.

4. Untarget the EJB from cluster

5. Retarget the EJB to cluster.

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
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:280)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408)
at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:125)
at
weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy7.getMBeanServer(Unknown Source)
at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:253)
The problem was solved with a code change to remove stale MBean references.

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!!!
NULL
NULL
2LKDEADLOCKTHR Thread "ExecuteThread: '0' for queue:
'__weblogic_admin_rmi_queue'" (0x8461B8A0) 3LKDEADLOCKWTR is waiting for:
4LKDEADLOCKMON sys_mon_t:0x84D183A8 inflaming: 0x00000000: 4LKDEADLOCKOBJ weblogic.socket.PosixSocketMuxer$FDRecord@31FD4B10/31FD4B18:
3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "ExecuteThread: '98' for queue: 'default'" (0x767D26E0)
3LKDEADLOCKWTR which is waiting for:
4LKDEADLOCKMON sys_mon_t:0x83AD8C18 inflaming: 0x00000000:
4LKDEADLOCKOBJ weblogic.rjvm.ConnectionManagerServer@31FA3430/31FA3438:
3LKDEADLOCKOWN which is owned by:
2LKDEADLOCKTHR Thread "ExecuteThread: '0' for queue: '__weblogic_admin_rmi_queue'" (0x8461B8A0)

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
java.io.NotSerializableException:
com.app.name
at
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java(Compiled Code))
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))
at
weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java(CompiledCode))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))

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.

CR102324

Prior to this Service Pack release, WebLogic Server did not log a nested exception associated with a deployment error. The logged text indicated only the deployment error, as in:

<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application application_name: Caught IOException for path=path_to_application>

The code was modified to log the nested exception as well as the deployment error itself, as in:

<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application_name: with deployment error Caught IOException for path=path_to_application and nested error java.io.FileNotFoundException: File not found>

CR056023

A CMP2.0 EJB accessing an Oracle database did not timeout when the database was locked.

The problem was exhibited when running the ejb2.0 cmp example, with trans-timeout-seconds to a non-zero value such as "10", against a locked database table (the table was locked using SQLplus "lock table ejbaccounts in exclusive mode"). When the table was locked, and the client ran, the client hung indefinitely trying to create an account. After the database lock was released using SQLplus, a rollback exception occurred in the client. The rollback should occur when at the end of the transaction timeout.

Analysis revealed that, when the timeout period expired, and the timer sent a TransactionRolledBack message to the database, the database did not release the lock.

The problem was resolved, for the Oracle thin driver, for row-level locks by:

• Doing a canceAllStatementsBeingUsed in the internalRollback method of the weblogic.jdbc.jts.Connection class before calling a rollback on the connection.

• Introducing a new method, canceAllStatementsBeingUsed in the weblogic.jdbc.common.internal.ConnectionEnv class that iterates through all the open statements and calls cancel on them for the connection being rolled back, ignoring the SQL exception.

The fix works only for the Oracle thin driver, for row-level locks.

CR098343

In WebLogic Server 6.1 SP02 and SP04, JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute KeepXAConnTillTxComplete was set to true. This sequence of events led to the problem:

1. Start a user transaction on one server instance 1.

2. Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2.

3. Update an EJB on server instance 2.

4. Commit the transaction.

No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the ejb connection pool. After repeating the sequence of steps several times, the connection pool runs out of connections.

The problem did not occur if the actions are executed on a single server instance, or if the JMS message is placed in the queue outside the transaction scope.

The problem was solved with a code change to release the connection in the aftercompletion callback.

CR099041

In WebLogic Server 6.1 SP04, a customer reported random generation of the following exception while invoking methods in a particular EJB in his application:

java.lang.ClassCastException: java.lang.String at weblogic.utils.classfile.DoubleKey.equals(DoubleKey.java:24) at java.util.Hashtable.get(Hashtable.java:318) at weblogic.utils.classfile.ConstantPool.find(ConstantPool.java:58) at weblogic.utils.classfile.ConstantPool.getUtf8(ConstantPool.java:251) at weblogic.utils.classfile.expr.ClassInfo.addField(ClassInfo.java:86) at weblogic.utils.classfile.expr.DotClassExpression.code(DotClassExpression.java:34) at weblogic.utils.classfile.expr.InvokeExpression.code(InvokeExpression.java:31) at weblogic.utils.classfile.expr.ExpressionStatement.code(ExpressionStatement.java:19) at weblogic.utils.classfile.expr.TryCatchStatement.code(TryCatchStatement

The problem was corrected with a code fix to the equals() method in weblogic.utils.classfile.DoubleKey.

CR099626

In WebLogic Server 6.1 SP03 ejbc generated invalid SQL for an ejbSelect query. The query failed because table aliases were generated incorrectly, resulting in this error:

ORA-00904: invalid column name

The problem was corrected with a code fix.

CR099760

A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated, but whose value did not change, are not written to back to the database. The optimization is only done for primitives and immutable objects.

CR100246

A LockTimeoutException occurred during a test, upon attempt to remove a stateful EJB. The sequence of operations was:

1. During test within the remote method of an entity bean, create a stateful session bean (local/localhome interfaces).

2. Call business methods on the stateful session bean, which in turn create different types of beans.

3. Try to remove the stateful session bean.

On calling remove the following exception is thrown:

Nov 18, 2002 12:51:33 AM PST> <Info> <EJB> <010049> <EJB Exception in method: remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default']. weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default'].
at
weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:449)
at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:259)
at
weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:248)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java

The problem was solved by adding a new weblogic-ejb-jar.xml deployment descriptor element, <allow-remove-during-transaction>. When this element is set to true, the exception does not occur

CR101918

The following error was thrown during ejb20 home methods tests, on NT with hotspot, and Native IO disabled:

java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:377)atjava.util.zip.ZipFile.getEntry(ZipFile.java:138)at eblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:225)at weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:155)at weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:53)at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:45)at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:303)at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:161)weblogic.rmi.internal.BasicRuntimeDescriptor.getClientRuntimeDescriptor(BasicRuntimeDescriptor.java:526)...

Analysis revealed that the problem was related to uncanceled triggers during undeployment. The following correction solved the problem:

• rmic code was fixed to remove the static classloader entry in the Utilities class at the end of ejbc

• ExecuteThread was fixed to clean the contextclassloader before re-using the thread.

• ejb code was fixed for canceling the triggers when the cmp/bmp with exclusive concurrency was undeployed.

CR102028

DB QueryString was generated incorrectly when using the Oracle thin driver for Connection Pool creation.

1. Create a connectionPool using oracle thin driver.

2. Run the test case ejb20/relations/FindersTest/testStringFunctionLOCATE().

3. The above test case can be run from the ejb20/relations/finder.ts file.

4. Make sure the EJBs "ComputerEJB", "EmployeeEJB" and "FinderEmployeeEJB" use this connection Pool, created using thin driver.

5. When this is run, we get "Invalid Character" error.

The stack trace is

javax.ejb.FinderException: Problem in findByNameEquals while preparing or executing statement: 'weblogic.jdbc.jts.PreparedStatement@55c5eb': java.sql.SQLException: ORA-00911: invalid character java.sql.SQLException: ORA-00911: invalid character at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol...

THe problem was corrected with a code fix to generate the correct SQL query

CR102180

In WebLogic Server SP03, ejbc failed while compiling stubs and skeletons for a .jar with 100 EJBs. The following exception occurred:

java.io.IOException: CreateProcess: c:\VisualCafe\bin\sj.exe -classpath c:\java\java130\jre\lib\rt.jar;
c:\java\java130\jre\lib\i18n.jar;c:\java\java130\jre\lib\sunrsasign.jar;c:\java\java130\jre\classes;
c:/java/java130/lib/tools.jar;D:/weblogic/dev/src/3rdparty/jconnect/jConnect.jar;D:/weblogic/src_130sj/license;D:/weblogic/dev/src/3rdparty/oracle/816/classes12.zip;
D:/weblogic/src_130sj/classes;D:/weblogic/src_130sj/lib/xmlx.jar;D:/weblogic/src_130sj/lib/ejb20.jar;D:/weblogic
/dev/src/3rdparty/weblogicaux.jar;D:/weblogic/dev/src/3rdparty/cloudscape/lib/cloudscape.jar;D:/weblogic/src_130sj/classes_ifmx4;
D:/weblogic/src_130sj/classes_mssql4;D:/weblogic/src_130sj/tools;c:/java/java130/jre/lib/rt.jar;D:\raviWork\ejb...

The problem was a result of a compiler command line length limitation. It was solved by using the javac @tempfile feature, which allows file names to passed to the compiler using a temporary file.

CR102308

In WebLogic Server 6.1 SP04, the Administration Console reported incorrect values for waiters for entity beans.

The problem was solved by adding a waiterCurrentCount attribute that is incremented when a client starts waiting for a lock and decremented when the lock is acquired or the client times out.

CR103047

It was reported in WebLogic Server 6.1 SP03 that transaction timeouts on MDBs were not logged. When the time an MDB takes to process a message from a JMS Destination exceeds the transaction timeout limit, the transaction is rolled-back and the message is place backed on the destination for re-delivery, but no transaction-timeout or transaction-rollback messages were logged.

This problem was resolved by a code change to the MDListener code to report the transaction timeouts.

CR103978

In WebLogic Server 6.1 SP02, a web application failed to obtain a remote object from a session under the following circumstances:

• A web application deployed on the Administration Server of Domain 1.

• An EJB was deployed to one Managed Server in a cluster in Domain 2.

• The web application did a lookup on the EJB using the URL of the Managed Server to which the EJB was deployed.

• The web application created a remote object and put it on the HttpSession

• The web application failed to obtain the remote object from the session with the following exception:

<Apr 21, 2003 11:42:47 AM PDT> <Error> <HTTP Session> <Error reconstructing the EJBObject put into session for name: trader java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statelessSession.TraderHome' on server: 't3://acaoclust:7001 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java :80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:179) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionDat a.java:390) at jsp_servlet.__remoteejb._jspService(__remoteejb.java:119) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at

The error occurred because the web application used the cluster URL to get the remote EJB object from the HttpSession, although EJB was deployed to a single Managed Server, not to the cluster.

A code fix solved the problem. Now the EJB Handle (HomeHandle) uses the URL of the server to which the EJB is deployed, if the EJB home is not clusterable, as specified in the EJB's home-is-clusterable deployment element in the weblogic-ejb-jar.xml file. The cluster URL is used only when home-is-clusterable is true.

CR104414

In WebLogic Server 6.1 SP04, server-side ejbc compilation errors resulted when the classpath was long. This error resulted:

[EJBCompiler] : Compiling EJB sources Warning: UNIXProcess.forkAndExec native error: The parameter or environment lists are too long. <Apr 24, 2003 2:55:27 PM GMT> <Error> <J2EE> <Error deploying application applicationname: Unable to deploy EJB: monitor/EMAServerManager.jar from monitor/EMAServerManager.jar: Compiler failed executable.exec(java.lang.String[javac, -nowarn, -classpath, ................................long classpath which is not shown here............................................................)
at
weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java(Compiled Code))
at
weblogic.ejb20.deployer.Deployer.runEJBC(Deployer.java(Inlined Compiled Code))
at
weblogic.ejb20.deployer.Deployer.compileEJB(Deployer.java(Compiled Code))

The problem was solved by using in-line compilation by specifying the -compilerclass option, and using noexit instead of the callcompile flag so that the compile method of the compilerclass gets called.

CR105609

A Null Pointer Exception was thrown when a WebLogic Server 6.1 SP04 servlet or stateless session bean invoked a stateful session bean deployed on WebLogic Server 6.1 SP02. The stack trace is:

java.lang.NullPointerException at weblogic.ejb20.internal.HandleImpl.readExternal(HandleImpl.java:101) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2263) at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:519) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1412) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.util.ArrayList.readObject(ArrayList.java:531) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2214) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1411) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at

Analysis revealed that the wire format of the handle is extended after WebLogic Server 6.1 SP02 to resolve handle issues related to differences for stateful session bean handles when the stub is stamped with the handle. In the case of stateless session beans, stubs are not added with handles.

The problem was resolved by a code change to allow for the "no handle" case for stateless session beans.

CR106136

In WebLogic Server 6.1 SP04, getter methods for a EJB 1.1 CMP bean did not call isModified() when delay-updates-until-end-of-tx was set to false

A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to Required. Each call to a getter method is followed by a call to ejbStore() and delay-updates-until-end-of-tx was false. However, before calling ejbStore on the bean the container did not call the isModified method. The isModified() method was only called when the transaction committed.

ejbStore should be called from postInvoke() depending on the result of the isModified method in the bean. The problem was solved with a code fix.

CR111551

In WebLogic Server 6.1 SP05, EJBC generated CMP code that caused a java.lang.ClassCastException: oracle.sql.BLOB error.

Analysis revealed that the CMP RDBMS code generated for the query was incorrect. Prior to WebLogic Server 6.1 SP05, server-side JDBC went through the RMI drive, to the pool driver, then on to the DBMS driver. Starting in WebLogic Server 6.1 SP05, the RMI driver is now only invoked in external clients. Server-side client code accesses the pool driver directly, which returns the DBMS driver BLOBs directly, not wrapped in an RMI wrapper. This change requires that code cast directly to oracle.sql.BLOB instead of weblogic.jdbc.common.OracleBlob.

The problem was solved by correcting the EJBC to generate code that reflects the SP05 and later behavior.

CR111771

In WebLogic Server 6.1 SP02, the database was left in inconsistent state when a bean is undeployed. The problem occurred in this invocation scenario:

webApp <--> OuterBean <--> InnerBean

The beans are stateless session beans, using container-managed transactions, with trans-attribute=Required. OuterBean.m() inserts a row in a table, then calls InnerBean.m(), which inserts a row in a different table. Since the scenario happens within the context of a single transaction, both tables have the same number of rows. The beans are packaged in different jars. OuterBean caches the home of InnerBean and everything is deployed on a single server. InnerBean is untargeted from the server during the course of the test. In this case, the tables are left in an inconsistent state: OuterBean no longer inserts any rows in its table while InnerBean still does.

Analysis revealed that when InnerBean was undeployed, TxManager.undeploy rolls back in-flight transactions and marks the instance as dead, so that no further transactions can be enlisted. OuterBean and InnerBean were packaged in the same enterprise application, and calls were by reference and did go through RMI. The home and the bean are cached in OuterBean, so even after InnerBean has been undeployed, the remote methods called are serviced. After InnerBean was undeployed, when OuterBean called InnerBean.insert(), there was a transaction associated with the call—the one started by OuterBean. In the preInvoke, the TxListener is set up and the transaction is register with the TxManager. While registering with the TxManager, the instance was determined to be dead, and WebLogic Server rolled back the transaction and silently return. As no transaction is enlisted, the database connection obtained within the InnerBean.insert() is not within the called transaction, so the rollback done in OuterBean has no effect on the row inserted by InnerBean—resulting in the situation where OuterBean no longer inserts any rows in its table while InnerBean still does. Silently returning, after rolling back the transaction because the bean is undeployed is the cause of the problem.

The problem was solved with a code change to check the deployment status in the preInvoke of the BaseEJBManager, thus preventing calls from reaching a bean that has been undeployed.

CR115026

In WebLogic Server 6.1 SP02, using MDBs listening on MQSeries, the MQSeries java threads on the WebLogic Server side were not correctly closed upon on an MQSeries failure and re-start of MQSeries. With every failure/restart the number of MQSeries AsyncThreads doubled.

The problem was solved with improvements to the failure and cleanup code in JMSConnectionPoller.createJMSConnection().

CR098343

JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute KeepXAConnTillTxComplete was set to true. This sequence of events led to the problem:

1. Start a user transaction on one server instance 1.

2. Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2.

3. Update an EJB on server instance 2.

4. Commit the transaction.

No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the EJB connection pool. After repeating the sequence of steps several times, the connection pool ran out of connections.

The problem did not occur if the actions were executed on a single server instance, or if the JMS message was placed in the queue outside the transaction scope.

The problem was solved with a code change to release the connection in the aftercompletion callback.

CR099872

The message for the Exception during commit of transaction stack trace exception contained the connection pool name, but not the data source name. <Exception during commit of transaction Xid=39:74a54046e2c2bb30(5962554),Status=Rolled back. [Reason=ja vax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the EnableTwoPhaseCommit property on the corresponding JDBCTxDataSource property, to true. Pool = CatPhase1]...

The stack trace content was enhanced to include the name of the data source.

CR103046

When using a JDBC connection pool, issuing Statement.close() did not release all resources associated with the underlying ResultSet, which could lead to an OutOfMemoryError. This problem occurred only when closing the Statement via a connection pool. It did not occur when explicitly closing the ResultSet itself, or when closing a statement while directly using the driver.

This problem was solved with a code fix.

CR103299

This Service Pack corrects an error in the leak detection code that caused the following stack trace:

[SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: Start server side stack trace:
java.lang.Throwable: StackTrace at creation of connection: at weblogic.jdbc.rmi.SerialConnection.<init>(SerialConnection.java:47) at weblogic.jdbc.pool.Connection.writeReplace(Connection.java:1427) at java.lang.reflect.Method.invoke(Native Method)at java.io.ObjectStreamClass.invokeMethod(ObjectStreamClass.java:1615) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:303) at weblogic.common.internal.ChunkedObjectOutputStream.writeObject(ChunkedObjectOutputStream.java:115) at weblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream .java:82) at weblogic.jdbc.common.internal.RmiDataSource_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:398) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:339) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:850) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:334) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest .java:30)at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:215) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:191) End server side stack trace

CR103321

In WebLogic Server 6.1 SP04, the getConnectionsTotalCount() method of JDBCConnectionPoolRuntimeMBean did not behave as expected. Instead of returning the total number of JDBC connections in the pool since instantiation, it returned the maximum number of connections since instantiation.

The problem was resolved with a code fix the method.

CR103421

In WebLogic Server 6.1 Service Packs 3 and 4, transactions involving the BigDecimal datatype threw a SQLWarning exception if the transaction obtained a local DataSource before obtaining a remote DataSource. The text of the stacktrace was:

java.sql.SQLException: java.sql.SQLWarning: Exhausted Resultset
Start server side stack trace:
weblogic.common.internal.WLSQLWarning: Exhausted Resultset
at
weblogic.jdbc.common.internal.DriverProxy.getWLSQLFromSQLException(DriverProxy.java:2
at
weblogic.jdbc.common.internal.ResultSetProxy.execute(ResultSetProxy.java:716)
at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:769)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace

This problem occurred because the T3 driver always queried the remote result set for getBigDecimal(), rather than querying the cached data.

This problem was solved with a code fix.

CR103619

This Service Pack fixes a problem with the isClosed() method and JTS connections. The problems were detected while running Sun's CTS for JDBC.

CR106767

When applications try to close JDBC objects more than once, WebLogic Server now throws an exception.

CR108580

WebLogic Server failed to check for a null pool name before creating a ConnectionLeakProfile object, causing the exception:

java.lang.NullPointerExceptionat java.lang.String.<init>(String.java:193) at weblogic.jdbc.common.internal.ConnectionLeakProfile.<init>(ConnectionLeakProfile.java:21)at weblogic.jdbc.rmi.internal.ConnectionImpl.unreferenced(ConnectionImpl .java:144) at weblogic.rmi.internal.BasicServerRef$UnreferencedExecuteRequest.execute(BasicServerRef.java:702) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)

This problem was solved with a code fix.

CR112607

If the URL or password for a connection pool was incorrect, WebLogic Server 6.1 Service Pack 4 still created a new JDBC connection pool with an initial capacity of 0. The code was modified to ensure that the creation of a JDBC connection pool fails if either the URL or password are incorrect.

CR120455

A memory leak was discovered in WebLogic Server 6.1 Service Pack 2. The leak occurred when using a TxDataSource to access a BLOB column on a database with the WebLogic XA driver. This problem was solved with a code fix.

CR120531

In WebLogic Server Service Pack 5, resetting a connection pool using weblogic.Admin RESET_POOL (or an equivalent API) caused an exception similar to the following if a connection was already released:

<Aug 13, 2003 1:33:11 PM EST> <Error> <HTTP>
<[WebAppServletContext(7096795,jdbc_webapp,/jdbc_webapp)] Servlet failed with Exception java.lang.Error: 1 Was already released:weblogic.jdbc.common.internal.Connection

After a garbage collection, the server would then display a connection leak warning:

<Aug 13, 2003 1:33:19 PM EST> <Warning> <JDBC> <A JDBC pool connection leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by the garbage collector and returned to the connection pool. The following stack trace at create shows where the leaked connection was created. Stack trace at connection create:
at weblogic.jdbc.pool.Connection.<init>(Connection.java:55)
at
[...]

The code was fixed to eradicate the connection leak warning; the server still correctly displays the initial exception if a connection was already released at the time the pool is reset.

CR121671

In WebLogic Server Service Pack 4, the weblogic.jdbc.jta.ResultSet.getType() method could recursively call itself and lead to a stack overflow exception:

java.lang.StackOverflowError
at weblogic.jdbc.jta.ResultSet.checkIfClosed(ResultSet.java:106)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:507)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:508)

This problem was solved with a code fix.

CR125135

By default, WebLogic jDriver for Oracle/XA Data Source set the value of the oracleXATrace parameter to true, rather than false. This caused the driver to create trace files of the form xa_poolname*.trc that could grow large over time, unless you specifically disabled trace files by setting oracleXATrace="false" in config.xml.

The code was modified to set the default value of oracleXATrace to false if no value is specified.

CR125705

When using a JDBC MultiPool, WebLogic Server threw a resource exception to the client and failed to serve connections from a backup pool if the initial pool was fully reserved at the time of the connection attempt. The code was modified to throw a ConnectDeadException instead, which the MultiPool interprets as a reason to fail over to the next pool in its list.

CR127891

The format of the connection leak file was modified to make the information more readable.

CR104968

WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a java.sql.SQLException when retrieving double or float values if a comma (`,') was used as a decimal separator in the database:

java.sql.SQLException: java.lang.NumberFormatException - '1,2'
at weblogic.jdbc.oci.ResultSet.getFloat(ResultSet.java:312)
at weblogic.jdbc.jta.ResultSet.getFloat(ResultSet.java:190)
at
weblogic.jdbc.rmi.internal.ResultSetImpl.getFloat(ResultSetImpl.java:224)
at
weblogic.jdbc.rmi.internal.ResultSetStraightReader.getFloat(ResultSetStraightReader.java:67)
at
weblogic.jdbc.rmi.SerialResultSet.getFloat(SerialResultSet.java:219)
at examples.servlets.DBAccess.service(DBAccess.java:54)
at
[...]

The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix.

CR107474

In WebLogic Server 6.1 Service Pack 3, OciObjectStream did not nullify a buffer after a close() was performed. This problem was solved with a code fix.

CR113462

WebLogic Server Service Pack 5 threw a NumberFormatException when using BigDecimal types in an environment with Oracle's NLS_LANG setting. The problem did not occur when using Oracle's NLS_NUMERIC_CHARACTERS parameter to match American-style numeric character definitions. This problem was solved with a code fix.

CR103001

WebLogic Server displayed an overly long exception if a server hosting a Messaging Bridge destination was unavailable. The code was fixed to display a shorter exception message.

CR104538

A JMS deadlock was fixed by changing the BESession.java close(long lastSequenceNumber) method. The deadlock could be viewed in the partial thread dump:

ExecuteThread: '9' for queue: 'queue_1'" daemon prio=5
tid=0x2757938 nid=0x5e waiting for monitor entry [0xce97f000..0xce97fc68]
at weblogic.jms.backend.BETopic._addMessageToConsumers(BETopic.java:590)
at weblogic.jms.backend.BETopic.addMessageToConsumers(BETopic.java:296)
at
weblogic.jms.backend.BEMessageWriteListener.storeIOComplete(BEMessageWriteListener.java:85)
at weblogic.jms.store.StoreRequest.execute(StoreRequest.java:342)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

"ExecuteThread: '14' for queue: 'queue_2'" daemon prio=5 tid=0x57b200
nid=0x54 waiting for monitor entry [0xd1b7f000..0xd1b7fc68]
at weblogic.jms.backend.BESession.stop(BESession.java:386)
at weblogic.jms.backend.BESession.close(BESession.java:434)
at weblogic.jms.backend.BESession.close(BESession.java:1083)
at weblogic.jms.backend.BESession.invoke(BESession.java:1024)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:585)....

CR112750

When the server failed to send JMS messages, there was no error message on the client. The transaction manager had declared the messages unhealthy, and JMS was rolling back the messages when it failed to enlist resources.

The failure to enlist the transaction is now communicated back to client, which will be able to report that the commit failed.

CR120619

When you removed all targets from a JMS Server having a JMS Template and then tried to re-target the JMS Server, WebLogic Server threw an exception:

<Aug 13, 2003 4:50:58 PM PDT> <Error> <JMS> <Failed to deploy JMS Server "server_name" due to weblogic.jms.common.JMSException: Error initializing JMSServer server_name.
weblogic.jms.common.JMSException: Error initializing JMSServer server_name
at weblogic.jms.backend.BackEnd.initialize(BackEnd.java:448)
at weblogic.jms.JMSService.createBackEnd(JMSService.java:906)
at weblogic.jms.JMSService.addJMSServer(JMSService.java:1273)
at weblogic.jms.JMSService.addDeployment(JMSService.java:1169)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:364)
at
weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:150)
at java.lang.reflect.Method.invoke(Native Method)
[...]

This problem occurred because the JMS service exported a temporary destination factory to the RMI runtime, and the factory reference was not removed when the factory was unbound from JNDI. The code was fixed so that the reference to the temporary destination factory is now removed when the factory is unbound. Untargeting and retargeting a JMS Server having a JMS Template no longer causes an exception.

CR122749

Fixed a problem where calling EJBComponentRuntimeMBean.getEJBRuntimes() caused an ASSERTION FAILED error followed by an ArrayStoreException.

CR123675

A problem in the optimization code for non-durable messages sometimes caused a destination to be nullified. This would result in the following exception while paging out messages under heavy loads:

<Sep 12, 2003 9:54:12 PM EDT> <Error> <Kernel> <BEA-000802> <ExecuteRequest failed
java.lang.NullPointerException.
java.lang.NullPointerException
at weblogic.jms.common.MessageImpl.writeExternal(MessageImpl.java:1622)
at
weblogic.jms.common.TextMessageImpl.writeExternal(TextMessageImpl.java:92)
at
weblogic.jms.store.ObjectIOBypassImpl.writeObject(ObjectIOBypassImpl.java:155)
at
weblogic.jms.store.BufferDataOutputStream.writeObject(BufferDataOutputStream.java:175)
at weblogic.jms.store.FileIOStream.write(FileIOStream.java:506)
at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:282)
at weblogic.jms.store.JMSStore.execute(JMSStore.java:493)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

The problem was solved with a code fix.

CR105592

In WebLogic Server 6.1 Service Pack 5 the server attempted to pop the environment from a ReadOnlyWrapper that did not push the environment onto a thread. This caused the following AssertionError and EmptyStackException:

java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at
weblogic.jndi.factories.java.ReadOnlyContextWrapper.close(ReadOnlyContextWrapper.java:30)
[...]
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ attempt to pop from an empty stack ] - with nested exception:
[java.util.EmptyStackException]
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:81)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
[...]

The code was modified so that a pop is not attempted on a ReadOnlyWrapper.

CR105761

This Service Pack includes a new JNDI caching mechanism that significantly improves the performance of JNDI lookups in the server.

CR100726

WebLogic Server now properly logs a ClassNotFoundException if you target a stateless session EJB to a single member of a WebLogic Server cluster and you fail to set home-is-clusterable and stateless-bean-is-clusterable to false in the deployment descriptor.

CR110916

WebLogic Server threw an EmptyStackException if a context was created in an ejbCreate() method and Context.close() was subsequently called in an ejbRemove() method. The partial exception text is:

java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at javax.naming.InitialContext.close(InitialContext.java:476)
[...]

This problem was solved with a code fix.

CR088525

In previous WebLogic Server 6.1 Service Packs, JSP parameters with a value of "/////" were interpreted by getParameter() as having the value "/".

The problem was resolved with a code change.

CR092039

WebLogic Server threw an UnsupportedEncodingException if you included extra quotation marks around the charset value of a JSP. For example, the following tag would yield the exception:

<%@ page contentType="text/html; charset=\"Shift_JIS\"" %>

The problem was resolved with a code fix.

CR093014

In WebLogic Server 6.1 SP02, Java comments that start in one scriptlet and end in the next one, cause this exception:

<22.07.2002 14:12:24 CEST> <Error> <HTTP> <[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at weblogic.servlet.jsp.ScriptletScopeLexer.mCLOSE_BRACE(ScriptletScopeLexer.java:527) at weblogic.servlet.jsp.ScriptletScopeLexer.mTOKEN(ScriptletScopeLexer.java:232) at weblogic.servlet.jsp.ScriptletScopeLexer.nextToken(ScriptletScopeLexer.java:159) at weblogic.servlet.jsp.ScriptletScopeLexer.parse(ScriptletScopeLexer.java:119) at weblogic.servlet.jsp.JspLexer.mSCRIPT(JspLexer.java:4367) at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:2173) at ....

The problem was resolved by a code fix to the make the ScriptletScopeLexer to skip an entire Java comment.

CR093520

When you precompiled JSPs on a machine in one time zone, and then deployed those same JSPs on a server in a different time zone, WebLogic Server sometimes re-compiled the JSPs. This occurred because WebLogic Server checked JSPs by comparing the local timestamp of the JSPs (as embedded by the JAR utility) against the timestamps in the generated class files.

The problem was resolved by storing the time zone at compile time and using that time zone at deployment time to determine whether recompilation is necessary.

CR100823

If you refreshed a JSP with a copy, and the copy did not parse correctly, WebLogic Server entered a deadlock condition. The problem involved two separate deadlocks. The deadlocks were removed by throwing and evaluating an exception in the JSP stub level, and by removing unnecessary synchronization of threads in getJarFiles().

CR102628

The following JSP code:

<jsp:plugin type="applet" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/" height="800" width="500" type="applet" jreversion="1.3.1_06" nspluginurl="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; iepluginurl="http://java.sun.com/products/plugin/1.1.3/ jinstall-113-win32.cab#Version=1,1,3,0" >

generated this HTML:

<embed type="application/x-java-applet;version=1.3.1_06" pluginspage="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; height="800" width="500" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/">

The generated HTML code failed on Netscape: Netscape attempted to download the plug-in from WebLogic Server instead from the SUN site.

When the plugins page line was moved before the codebase line, the code worked correctly on Netscape.

A code fix to order the applet attributes properly resolved the problem.

CR103214

When you set the compilerclass JSP parameter, WebLogic Server logged a compilerclass=null message in the startup log, as in:

JSPServlet with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler= C:\61sp4\jdk131/bin/javac,compileFlags=,workingDir=C:\61sp4\wlserver6.1\config\examples\applications\ examplesWebApp\WEB-INF\_tmp_war_examples_examplesWebApp,pageCheckSeconds=1,superclass=weblogic.servlet.jsp. JspBase,keepgenerated=false,precompileContinue=false, compilerSupportsEncoding=true,encoding=null,defaultfilename=index.jsp,compilerclass= null,noTryBlocks=false]'>

The problem occurred because the setting of compilerclass was not used during startup. The correct setting was used for compiling JSPs. The code was fixed to obtain the correct parameter value during server startup.

CR105229

WebLogic Server could fail to evaluate empty BodyTags, causing the exception:

<ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <>
<BEA-101017>
<[ServletContext(id=12216222,name=xmlxTestApp,context-path=/xmlxTestApp)]
Root cause of ServletException.
javax.servlet.jsp.JspException: Could not find file:
java.io.FileNotFoundException: Could not find appropriate xml file
at weblogicx.xml.tags.XsltTag.doEndTag(XsltTag.java:280)
at jsp_servlet.__xsltprocessor._jspService(__xsltprocessor.java:195)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6304)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:361
[...]

This problem was solved with a code fix.

CR105772

WebLogic Server displayed a JSP parsing error if a JSP used a tag library that specified an empty body tag using an empty element tag, as in:

<%@taglib uri="/problem-taglib" prefix="c" %>
<html>
<head><title>Problem scenario</title></head>
<body>
<table border="1"><tr><th>Local file content</th>
<th>Included file content</th></tr>
<tr>
<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" /></td>
</tr>
</table>
</body>
</html>

The problem did not occur if a closing element tag was added to the empty body content, as in:

<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" ></c:import></td>

This problem was solved with a code fix.

CR106072

The pageCheckSeconds attribute, which sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling, did not work the first time a JSP was modified.

This problem occurred because WebLogic Server did not set a lastStaleCheck time the first time a JSP was invoked.

The code was modified so that if lastStaleCheck is not set yet, it is set to the current time. This prevents the JSP from being recompiled unnecessarily.

CR107042

If you specified com.sun.tools.javac.Main as the value of the JSP compilerclass parameter, WebLogic Server would suddenly exit when you accessed the JSP. This problem was solved with a code fix.

CR111423

When packaged in a WAR file, precompiled JSPs stored in a sub-context of the application were always recompiled upon deployment to WebLogic Server. This problem did not occur when JSPs were deployed from an exploded archive directory, or for JSPs in the root-context of a WAR file.

The problem was caused because of a difference in the rounding behavior of timestamps used in the jar and zip formats. The discrepancy in rounding could cause an older timestamp (by one second) to be recorded in class files inside the WAR file, triggering the server to recompile the classes.

The code was modified to advance the timestamps in compiled JSP classes by one second, thereby preventing JSPs from being recompiled.

CR120914

When you used the WebLogic Server form validation tag library, request parameters were not available to subsequent JSPs. This problem was solved with a code fix.

CR127515

In WebLogic Server 6.1 SP02 a javac error message through weblogic.jspc was corrupt in Japanese installation. The problem was corrected by a code change to use InputStreamReader instead of DataInputStream.

CR082504

When using the Sybase jConnect/XA Driver, connections were not reusable after being returned to the connection pool. This would cause the following exception, after all available connections in the pool were used:

XA error: XAER_RMERR : A resource manager error has occured in the
transaction branch start() failed on resource 'ZeusPool': XAER_RMERR : A
resource manager error has occured in the transaction branch
javax.transaction.xa.XAException

The problem occurred because Sybase initiates a local transaction for DDL calls, and the transaction was not cleaned up when the connection was returned to the pool.

The connection cleanup code was fixed to end the local Sybase transaction generated by DDL calls.

CR091192

This Service Pack includes an enhancement to recover transactional resource managers immediately, rather than wait five minutes before recovery.

CR091974

If XA recovery did not return an XID, WebLogic Server 6.1 Service Pack 3 could throw a NullPointerException:

java.lang.NullPointerException
at
weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:721)
at
weblogic.transaction.internal.ServerSCInfo.rollback(ServerSCInfo.java:318)
at
weblogic.transaction.internal.ResourceDescriptor.rollbackXids(ResourceDescriptor.java:1160)
at
weblogic.transaction.internal.ResourceDescriptor.recover(ResourceDescriptor.java:1060)
at
weblogic.transaction.internal.ResourceDescriptor.access$9(ResourceDescriptor.java:1029)
at
weblogic.transaction.internal.ResourceDescriptor$1.execute(ResourceDescriptor.java:770)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

The code was modified to check for the presence of an XID and prevent the exception from occurring.

CR098273

Stale entries in the transaction log sometimes caused unnecessary recovery overhead when a server is restarted. This problem was solved with a code fix.

CR103327

After a transaction has timed out, two threads could try to roll back the same transaction ID, resulting in an error similar to:

XA.end FAILED (rm=pool_name, xar=pool_name, error code: XAER_RMERR : A resource manager error has occured in the transaction branch, message: null>
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:659)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:305)
at weblogic.jdbc.jta.VendorXAResource.end(VendorXAResource.java:47)

This problem was solved with a code fix.

CR103601

In WebLogic Server 6.1 SP03 and SP04, if an object passed in the "equals" method of weblogic.transaction.internal.XidImpl is not an instance of XidImpl (for instance, it is of type String), then this exception is thrown:

java.lang.ClassCastException: java.lang.String at weblogic.transaction.internal.XidImpl.equals(XidImpl.java:114) at test.main(test.java:9)

The problem was solved with a code fix to check and report type mismatches.

CR113226

When a resource name contained more than 64 characters, WebLogic Server 6.1 Service Pack 4 could throw the following exception when testing the connection pool:

java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured in the transaction branch start() failed on resource
'weblogic.jdbc.jta.DataSource' null
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1167)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1133)
at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:153)
at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:241)
[...]

The problem occurred because only the first 64 characters were tested for uniqueness. The code was modified to properly handle resource names longer than 64 characters.

CR126201

In a multiple-server domain, if a Managed Server was rebooted to use a different address or port number, the JTA subsystem failed to update the address information. This would cause the following exception when the changed server was rebooted:

javax.naming.CommunicationException. Root exception is
java.net.ConnectException: t3://ip_address:port_number: Destination unreachable;
nested exception is:
java.net.ConnectException: Connection refused; No available router to destination
[...]

The code was fixed to obtain new address information from the Administration Server in response to an address or port change.

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.

CR090118

In WebLogic Server 6.1 SP03 and later, temporary directories created by the Administration Console deployment descriptor editor in under the bea\wlserver6.1 directory with name jarxxxx (for example, bea\wlserver6.1\jar7018) were not deleted.

Analysis revealed that the temporary directories were not deleted because of a open file stream on an inner file.

The problem was resolved with a code change.

CR093653

In WebLogic Server 6.1 SP04, updates to an exploded web application that was deployed to a Managed Server were reflected in the exploded application staged on the Managed Server, but not in the .war file in the .wlnotdelete directory. After server restart the old version of the application was deployed.

Refreshing the application using weblogic.refresh caused the updated .jsp to be copied into the exploded application format staged on the Managed Server, but not the original version of the .war.

The problem was resolve by a code change to remove the application entry from the local deployment file.

As a result of this change, the latest version of an application is copied from its source 
to a Managed Server's staging area when the Managed Server is restarted after a 
refresh. 

CR093687

In WebLogic Server SP03, a startup class that created a dynamic connection pool and targets it to a server instance, caused the server to hang, when LoadBeforeAppDeployments=true for startup class. No exception was reported.

Analysis revealed a synchronization problem, which was corrected with a code fix.

CR095967

In WebLogic Server SP03 and SP04, when a Managed Server and Administration Server were shutdown at the same time, the Managed Server tried to reconnect to the Administration Server.

The problem was solved with a code change to ensure that Managed Servers do not attempt reconnect to the Administration Server while in shutdown or suspend modes.

CR097152

In WebLogic Server SP03 and SP04, restarting the Administration Server resulted in the error:

Admin restart causes java.rmi.ConnectException: This RJVM has already been shutdown.

The issue was consistently reproduced using these steps:

1. Configure a cluster such that the cluster instances on at least two machines.

2. Deploy a sample EJB and target to cluster.

3. Now restart the Admin server.

4. Now go to console and untarget the EJB from cluster, apply and then retarget the EJB to cluster and Apply the changes.

The problem occurred because weblogic.management.internal.MBeanProxy was using a stale stub of AdminMBeanHome, because the Administration Server was restarted and the AdminMBeanHome object instance (Dynamic Proxy Stub) was no longer valid.

The problem was solved with a code change.

CR099973

In WebLogic Server 6.1 Service Pack 3, using the UpdateLicense utility with the license_update_file failed to properly update the license file. This lead to the following exception when booting the server:

$$$$$$$$$$$$$$$$ License Exception $$$$$$$$$$$$$$$$

Unable to start WebLogic Server !!
WebLogic: license signature validation error!

The problem was solved with a code fix.

CR102593

In WebLogic Server 6.1 SP04, a ClassCastException occurred when retrieving ServletSessionRuntimeMBean.

The problem was exhibited in a two-node cluster, on which an application retrieves the array of ServletSessionRuntimeMBeans from the WebAppComponentRuntime of each cluster node, for use in determining whether a a particular user has already logged on to one of the two nodes.

The call sequence is as follows:

1. call:node1 ---> test.jsp (HTTP Session is created)

2. call:node2 ---> submit data from test.jsp (via GET) to /ctrl/* Servlet

Repeating this call sequence several times in the same HTTP session leads to a ClassCastException in the WebAppComponentRuntime.getServletSessions() method:

ClassCastException: java.lang.ClassCastException: $Proxy79 at weblogic.servlet.internal.session.SessionData.getServletSessionRuntimeMBean(SessionData.java:271) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBean(SessionContext.java:199) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBeans(SessionContext.java:216) at weblogic.servlet.internal.WebAppServletContext.getServletSessionRuntimeMBeans(WebAppServletContext.java:2442) at weblogic.servlet.internal.WebAppRuntimeMBeanImpl.getServletSessions(WebAppRuntimeMBeanImpl.java:126) at java.lang.reflect.Method.invoke(Native Method) at...

The problem occurred because ServletSessionRuntimeMBean was cast incorrectly to the implementation—ServletSessionRuntimeMBeanImpl in SessionData.java.

The problem was solved with a code change.

CR102860

This release solves a JMX memory leak. The leak was detected running load tests on WebLogic Server 6.1 SP02. When running JMX for several days, the heap consumption after garbage collection grew from 17 to 40 MB.

CR103735

In WebLogic Server SP03, if the domain and a cluster in the domain have the same name, duplicate entries appear for the Targets attribute in the domain's config.xml file. The following was observed:

When an application was first targeted to the cluster through the console, there were no problems, and the target was correctly reflected in config.xml.

After restarting the Administration Server, the Administration Console did not show that the application was targeted to the cluster, and a Managed Server in the cluster did not show the application as bound in its JNDI tree. The target was still correctly reflected in config.xml.

After the user re-targeted the application to the cluster using the Administration Console, config.xml showed the cluster name twice in its Targets attribute.

<Application Deployed="true" Name="seb" Path=".\config\rom\applications"> <WebAppComponent Name="seb" Targets="rom,rom" URI="seb.war"/> </Application>

The problem occurred because, in any version of WebLogic Server, all targets domains, clusters, servers, virtual hosts) must have unique names.

The problem was solved with a code change to modify tweblogic.managment.internal.UnresolvedMBean.java to ignore the DomainMBean when resolving in the case where the attribute is a target.

CR105338

In WebLogic Server SP03, WebLogic Server stops logging, on both Administration Server and Managed Servers, when the maximum number of files is reached.

After the following error messages are printed out to the domain log file, the server logging service is shutdown.

####<Apr 21, 2003 3:17:39 PM GMT+09:00> <Alert> <Log Management> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-170017> <The log file .\myserver\myserver.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms like Windows.> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Critical> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised several exceptions. Shutting it down> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:\bea81ga\mydomain\myserver\myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null>

If the problem occurs, all log messages are not printed out to the server log file. This problem occurs on the admin server and the managed server

Analysis revealed that WebLogic Server closed log files during rotation and, if log rotation failed, the log files would remain closed.

Log Rotation failed when WebLogic Server generated the wrong index for the new log file. Since it assumed that the file that had the latest time stamp is the latest index. It never checked to see if a file with the index already existed. WebLogic Server did not attempt to delete the log file if the log file already existed and did not check to see if the rename() was successful.

In addition, for time based log rotation, on multi-CPU machines, multiple rotations happened within the same millisecond. The problems were changed with code fixes.

CR108448

In WebLogic Server 6.1 SP05 restart of a Managed Server resulted in a warning. The Administration Server and Managed Server were running, and the Managed Server was shutdown. The Administration Server showed that the Managed Server was not running. Upon restarting the Managed Server, this warning was issued:

<Warning> <Management> <c4wlg001> <node001> <ExecuteThread: '1' for queue: '__weblogic_admin_rmi_queue'> <system> <> <141029> <Unable to reconnect to Admin Server running at http://c4wlg001:7001 from Managed Server - node001.> weblogic.management.configuration.ConfigurationException: Server: node001 is already running. at weblogic.management.Admin.registerManagedHome2AdminHome(Admin.java:1679) at weblogic.management.Admin.reconnectToAdminServer(Admin.java:1637) at weblogic.t3.srvr.ServerRuntime.reconnectToAdminServer(ServerRuntime.java:413) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636) at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621) at...

The Managed Server starts successfully.

Analysis revealed that a error check was performed at an inappropriate point, preventing the JNDI tree to be appropriately updated. The problem was corrected by a code fix.

CR108727

In WebLogic Server SP04, running with CR071109_610sp2.jar, an Administration Server started with the command-line options:

weblogic.management.discover.interval = 60

weblogic.management.discover.retries = 6

weblogic.management.internal.debug = true

after a failure, (java.rmi.ConnectException is thrown) managed servers were discovered and re-connected successfully, but an OutOfMemoryError occurred.

Subsequently, MBean invocations on managed servers failed with this exception:

java.rmi.NoSuchObjectException: RemoteInvokable - id: '267'

Analysis revealed that ManagedServerReDiscoveryChecker thread had stopped running, causing Managed Servers not to be discovered. The problem was solved with a change to retry logic to ensure that the discovery thread always runs when needed.

CR127860

In WebLogic Server 6.1 SP05, shutdown classes were not called on Managed Servers when the Administration Server was not running. The following exception was thrown:

<29.10.2003 10:48:16 CET> <Notice> <WebLogicServer> <Started WebLogic Managed Server "managed1" for domain "mydomain" running in Production Mode>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The disabling of server logins has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server logins have been disabled.>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server shutdown has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The shutdown sequence has been initiated.> <29.10.2003 10:49:56 CET> <Emergency> <Server> <Unable to initialize the server: 'Fatal initialization exception Throwable: weblogic.rmi.extensions.RemoteRuntimeException - with nested exception: [java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination] java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, java.rmi.ConnectException: Destination unreachable; nested exception is:
java.net.ConnectException: Connection refused: connect; No available router to destination
at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:276)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:428)..

The problem was corrected with a code change to run shutdown classes before shutting down the management layer.

CR122538

If a JMX client application used getAllMBeans() on a WebLogic Server, exceptions similar to the following were thrown:

Exception in thread "main" java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
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.management.internal.Helper.findClass(Helper.java:831)
[...]
--------------- nested within: ------------------
weblogic.management.configuration.ConfigurationError - with nested exception:
[java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean]
at
weblogic.management.internal.Helper.getAdminOrConfigMBeanInfo(Helper.java:118)
[...]

This problem was solved with a code fix.

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:

• Virtual Directory is configured.

• Mime type is configured to * (proxy everything).

• DefaultFileName is added to iisproxy.ini

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
MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003

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:

1. The IIS access log would show the message:

   Out-of-process+ISAPI+extension+request+failed. 500 1726 
   99122 2003 84078 
   

2. The Windows Event Log would record Event ID 37:

   Event Type: Warning
   Event Source: W3SVC
   Event Category: None
   Event ID: 37
   Date:  8/26/2003
   Time:  6:45:03 PM
   User:  N/A
   Computer: name
   Description:
   Out of process application '/LM/W3SVC/2/Root/caf' 
   terminated unexpectedly. 
   For additional information specific to this message please 
   visit the Microsoft Online Support site located at:
   http://www.microsoft.com/contentredirect.asp.
   

3. The wlproxy.log entry showed:

   Fri Nov 21 19:06:31 2003 Write to the browser failed: 
   calling URL::close at line 1270 of .\iisproxy.cpp
   Fri Nov 21 19:06:31 2003 *******Exception type 
   [WRITE_ERROR_TO_CLIENT] raised at line 1271 of 
   .\iisproxy.cpp
   

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.

CR106281

In WebLogic Server 6.1 SP04, replicated session beans under heavy load resulted in increasing heap usage and OutOfmemoryErrors.

Analysis revealed that examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl objects were not being garbage-collected even when garbage collection was forced. For clustered stateful session beans, strong references were maintained to the EOImpl object primary in the weblogic.rmi.cluster.PrimarySecondaryRemoteObject. As a remove is never called on the bean, the reference to the EOImpl was never removed from the eoMap.

A code fix was implemented to unexport the EO when the passivated bean has been deleted, after session-timeout-seconds.

CR112991

IIOP calls from a WebLogic Server 6.1 SP04 instance to an EJB running on a WebLogic Server 7.0 SP02 instance resulted in an exception when the IIOP connection idle timed out. The exception occurred on the WebLogic Server 7.0 side, when it tried to send back the response—the connection was closed. The exception is not sent to the 6.1 server, and the client thread hangs.

The WebLogic Server 7.0 SP02 exception was:

<Jul 29, 2003 5:21:55 PM PDT> <Error> <IIOP> <002013> <Complete failure to send exception class java.rmi.MarshalException: java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket. java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket java.io.IOException: Attempt to send message on closed socket at weblogic.iiop.MuxableSocketIIOP.send(MuxableSocketIIOP.java:362) at weblogic.iiop.EndPointImpl.send(EndPointImpl.java:1078) at weblogic.iiop.OutboundResponseImpl.sendThrowable(OutboundResponseImpl.java:194) at weblogic.rmi.internal.BasicServerRef.handleThrowable(BasicServerRef.java:473) at weblogic.rmi.internal.BasicServerRef.postInvoke(BasicServerRef.java:440) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:328) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189) >

Analysis revealed that close connection messages were not being handled properly. The error was solved with a code change.

CR124377

WebLogic Server sometimes threw a java.rmi.UnmarshalException when a client application using the thin-client .jar (wlclient.jar) accessed an EJB. On the server, partial exception was:

java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: Serializable readObject method failed internally.
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: Serializable readObject method failed internally at com.ejb_cvps36_EOImpl_WLSkel.invoke(Unknown Source)
[...]

On the client, the partial exception was:

java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is:
org.omg.CORBA.MARSHAL: vmcid: 0x0 minor code: 0 completed: No
at
com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:97)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
[...]

This problem did not occur when using weblogic.jar on the client. The code was modified to address this problem.

CR128594

Prior to this Service Pack, WebLogic Server could not handle typecode aliases when reading Java objects on AIX. The code was modified to discard the alias wrapper.

CR128660

WebLogic Server used reflection on inbound contexts that it did not understand. This caused IIOP clients on AIX to fail, because the IBM ORB makes assumptions about the stream format based on the service contexts. The code was fixed to correctly handle service contexts so that IIOP clients can be used on AIX.

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
at weblogic.security.SSL.GenericCipher.input(GenericCipher.java:196)
at weblogic.security.SSL.SSLCiphertext.input(SSLCiphertext.java:68)
at weblogic.security.SSL.SSLSocket.getRecord(SSLSocket.java:1147)
[...]

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
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:190)
at java.net.Socket.getSendBufferSize(Socket.java:527)
[...]

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.

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
at
weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292)
at weblogic.servlet.internal.HttpServer.log(HttpServer.java:865)
at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

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:

• WebLogicCluster again uses the format host:port:sslport for specifying the SSL port number.

• WebLogic Server logs an error if the SSL port is not specified, and uses the default SSL port of 7002.

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>
<param-value>/home/user/cgi-bin</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>

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
at
weblogic.servlet.internal.ServletRequestImpl.initInputEncoding(ServletRequestImpl.java:727)
at
weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:565)
at
weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:489)
at
weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:686)
at
weblogic.servlet.internal.ServletRequestImpl.initSessionInfo(ServletRequestImpl.java:1481)
at
weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1345)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:1010)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:910)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:279)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:403)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:285)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)

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
<May 14, 2003 10:53:34 AM PDT> <Warning> <WebLogicServer> <000337>
<ExecuteThread: '10' for queue: 'default' has been busy for "1,181" seconds working on the request "Http Request: servlet_uri", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>

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">
<jsp:param name="title"
value="<%= java.net.URLEncoder.encode(\"[double byte characters]\")
%>"/>
</jsp:include>

—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
at
weblogic.utils.Executable$Drainer.run(Executable.java:366)

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
at
weblogic.servlet.security.internal.SecurityModule.logoutSession(SecurityModule.java:386)
at
weblogic.servlet.security.internal.SecurityModule.checkAuthenticate(SecurityModule.java:292)
at
weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.java:353)
at com.uprr.security.weblogic.SiteMinderAuthFilter.doPreAuth(Unknown
Source)
at weblogic.servlet.security.AuthFilter.service(AuthFilter.java:51)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:530)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:350)
at
weblogic.servlet.security.internal.ServletSecurityManager.checkAccess
(ServletSecurityManager.java:144)
[...]

This problem was solved with a code fix.

CR088000

When WebLogic Server 6.1 SP04, a SNMP shutdown trap was not received.

8-Oct-02 15:57:24 FAILURE mytest!0[41]!oam/systest/snmp/oam_snmp!2[69]!if!3[86]!weblogic.qa.tests.oam.systest.snmp.trap.SNMPTrapTest.testServerShutdownTrap() wlsServerShutdownTrap wasn't received. PARAMETERS: managedServerName = oamserver1 adminServerName = adminServer

Analysis revealed that SNMP traps were not generated for Managed Server if the listen address or listen port are overridden with command line option.

The problem was resolved with a logic change to use the listen port value from ServerMBean, rather than the one in the URL.

CR099255

When using two-way SSL to invoke a Web Service, and the client code uses the WSDL of the Web Service in its invocation, the client API now correctly sends the certificates both when making the WSDL lookup and when invoking the operation. Previously, certificates were sent only for the WSDL lookup and not for the actual invocation of the operation.

This problem was solved with a code fix.

CR099534

The wsgen Ant task has been optimized to use a new classloader for every Web Service it assembles from a single build.xml file.

Previously, wsgen would use a single classloader for its entire execution, even if there were multiple Web Services listed in the build.xml file, and all auxiliary classes for each subsequent Web Service would be obtained from the single classloader and then copied, which was a sub-optimal way of generating all the needed class files. Depending on the number of Web Services in the build.xml file that had to be assembled, a full execution of wsgen could take over 30 minutes.

This problem was solved with a code fix.

CR101383

WebLogic Web Services now correctly represent a null xsd:dateTime value in the SOAP response as xsi:nil='true'.

Previously, if a WebLogic Web Service returned an xsd:dateTime value that was null, it incorrectly represented it in the SOAP response as xsi:null='1', which is how the 1999 version of XML Schema defined null values. WebLogic Web Services support the 2001 version of XML Schema, which defines null values as xsi:nil='true'.

This problem was solved with a code fix.

CR102677

When using the XML Registry for external entity resolution, WebLogic Server no longer returns an error when resolving DTDs using the Public ID.

This problem was solved with a code fix.

CR106892

The generated WebLogic Web Services client stubs, when sending an XML document to a Web service as an org.w3c.dom.Element object, now correctly preserve any new-lines characters inside the body of an element in the XML file. Previously the client stubs would incorrectly convert these new-line characters to spaces.

This problem was solved with a code fix.

CR111151

WebLogic Web Services now correctly send the utf-8 encoding header in SOAP Fault responses that are generated as a result of an exception in the invocation of the Web Service. The complete correct header is:

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

Previously, WebLogic Web Services did not include this header in SOAP Fault responses.

This problem was solved with a code fix.

CR107323

In WebLogic Server 6.1 SP03 configured to use Tuxedo 8.0, when WebLogic Server shut down abnormally (CTRL-C) while there were uncommitted Tuxedo transactions, upon restart, the WebLogic Server instance hung. The problem was exhibited in this scenario:

1. WebLogic was killed while there are still uncommitted transactions with Tuxedo

2. WTC is configure to be started "ON_DEMAND"

3. Start WebLogic

4. WebLogic hangs with the reported problem

The problem was not exhibited when:

1. WebLogic was killed while there are still uncommitted transactions with Tuxedo

2. WTC is configure to be started "ON_DEMAND"

3. Remove WebLogic tlog files "*.tlog"

4. Start WebLogic

5. WebLogic starts without any problem

or when:

1. WebLogic was killed while there are still uncommitted transactions with Tuxedo

2. WTC is configure to be started "ON_STARTUP"

3. Start WebLogic

4. WebLogic starts without any problem

When the hang occurs after a restart, all the threads in the default Group hang with the following stack trace:

at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:415)
at weblogic.wtc.jatmi.TuxXidRply.get_specific_reply (TuxXidRply.java:203)at weblogic.wtc.gwt.TuxedoXA.internalCommit(TuxedoXA.java:259)
at weblogic.wtc.gwt.TuxedoXA.commit(TuxedoXA.java:328)
at weblogic.wtc.gwt.OatmialCommitter.execute(WTCStartup.java:2767)at...

The problem was solved by modifying the weblogic.wtc.gwt.WTCStartup method to sleep for one second after each Kernel.execute(myCommitter).

CR120681

In WebLogic Server 6.1 SP02, WebLogic Tuxedo Connector did not properly translate local resource name to remote service name.

A correction to the translation code solved the problem.

CR102397

The Xerces parser always attempted a call to System.getProperty(). This would throw an exception in an Applet, which does not have permission to retrieve properties. The following partial exception could be observed in an Applet making a JMS call:

----------- Linked Exception -----------
java.rmi.MarshalException: failed to marshal
connectionCreate(Lweblogic.jms.dispatcher.DispatcherWrapper;); nested
exception is:
java.rmi.UnexpectedException: Failed to parse descriptor file; nested
exception is:
java.security.AccessControlException: access denied
(java.util.PropertyPermission weblogic.apache.xerces.maxentityrefs read)
[...]

The code was modified so that the parser does not attempt to read system properties with Applet clients.

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.

CR094561

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.

Change Request Number

Description

CR086251

In WebLogic Server 6.1 SP03 the Messaging Bridge Adapter threw a NullPointerException in unregisterResource during shutdown. This occurred if messages have been sent but not consumed before the shutdown of the server has been initiated. The problem did not occur if Messaging Bridge is not deployed and the Adapter is.

The configuration was: jms-xa-adp.rar Messaging Bridge Adapter and a Messaging Bridge between MQSeries 5.2 and JMS

The problem was corrected with a code fix to check wrappedXARes beforing attempting to unregister.

CR090002

In WebLogic Server 6.1 SP03, JCA-Connection.close throws java.lang.reflect.UndeclaredThrowableException instead of ResourceException

A code fix was implemented to ensure that the resource adaptor's original exception is passed.

CR090792

In WebLogic Server 6.1 SP03 and SP04, RAR deployment failed after any of its descriptor parameters were changed in console.

Analysis revealed that any descriptor change in console caused reset of pool parameters if they had not been changed from default values. Pool parameters were inappropriately defined:

<pool-params>

<initial-capacity>0</initial-capacity>

<max-capacity>0</max-capacity>

<capacity-increment>0</capacity-increment>

<shrinking-enabled>false</shrinking-enabled>

<shrink-period-minutes>0</shrink-period-minutes>

</pool-params>

This caused deployment failure due to max capacity value 0 which is prohibited. No activities could be performed on RA after that.

In 6.1, ResourceAdapterComponentMBean was used when getting descriptor values. However, ResourceAdapterComponentMBean constructor did not automatically have defaults set (the way ConnectorComponentMBean does) and also did not set defaults manually. The fix was to set them manually.

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:
58) - waiting to lock <f55b6358> (a weblogic.logging.Log
Manager) at weblogic.logging.LogOutputStream.getLogManager
(LogOutputStream.java:32) at weblogic.logging.LogOutput
Stream.error(LogOutputStream.java:63) at weblogic.management.
internal.Helper.error(Helper.java:1391) at weblogic.
management.internal.Helper.error(Helper.java:1404) at weblogic.management.internal.ConfigurationMBeanImpl.
postDeregister(ConfigurationMBeanImpl.java:900) at com.sun.
management.jmx.MBeanServerImpl.postDeregisterInvoker
(MBeanServerImpl.java:2314) at com.sun.management.jmx.MBean
ServerImpl.unregisterMBean(MBeanServerImpl.java:967) - locked <f550eec8> (a weblogic.management.internal.RemoteMBean
ServerImpl) at weblogic.management.internal.RemoteMBeanServer
Impl.unregisterMBean(RemoteMBeanServerImpl.java:213) at ..

Java Stack for "ExecuteThread: '6' for queue: 'default'":

at com.sun.management.jmx.MBeanServerImpl.getMBean(MBean
ServerImpl.java:1672) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1150) at weblogic.
management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke
(MBeanProxy.java:187) at $Proxy7.isStdoutEnabled(Unknown Source) at weblogic.logging.ConsoleLogger.isLog(Console
Logger.java:81) at weblogic.logging.ConsoleLogger.log
(ConsoleLogger.java:70) at weblogic.logging.LogManager.log(Log
Manager.java:260) - locked <f55b6358> (a weblogic.logging.LogManager) at weblogic.logging.MessageLogger.log(MessageLogger.java:17) at weblogic.t3.srvr.T3SrvrLogger.logRemovingClientContextSoftDisconnect(T3SrvrLogger.java:1204) at weblogic.t3.srvr.ClientContext.dieIfTimedOut(ClientContext.java:512) at ...

The problem was solved by a code change to remove unnecessary locks in LogManager.

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:

1. Start an Administration Server and a Managed Server.

2. Shutdown the Administration Server.

3. Invoke the 'stop' method on the ServerConfigMBean of the Managed Server.

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
Redirects.

CR077108

During load testing of a 35-plus node cluster, a null pointer exception was encountered at weblogic.utils.collections.NumericValueHashtable.
containsKey(NumericValueHashtable.java:138)

<May 9, 2002 5:08:22 PM BST> <Error> <Management> <InvocationTargetException getting attribute SecondaryDistributionNames on MBean bluemartini:Location
=WebConnectaw01,Name=WebConnectaw01,ServerRuntime=WebConnectaw01,Type=ClusterRuntime. Method: public java.lang.String[] weblogic.cluster.ClusterRuntime.getSecondaryDistributionNames() java.lang.NullPointerException at weblogic.utils.
collections.NumericValueHashtable.containsKey(NumericValueHashtable.java:138) at weblogic.cluster.replication.
ReplicationManager.getSecondaryDistributionNames(ReplicationManager.java:1245) at weblogic.cluster.ClusterRuntime.

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.
DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:477) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1181) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1151) at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServer
Ref.invoke(BasicServerRef.java:298) at weblogic.rmi.
internal.BasicServerRef.handleRequest(BasicServerRef.java:267) at weblogic.rmi.internal.BasicExecuteRequest.execute
(BasicExecuteRequest.java:22) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)

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.
Throwable: Stack trace at weblogic.rjvm.http.HTTPServer
JVMConnection.close(HTTPServerJVMConnection.java:383) at weblogic.rjvm.ConnectionManager.removeConnection(ConnectionManager.java:879) at weblogic.rjvm.ConnectionManager.
shutdown(ConnectionManager.java:508) at weblogic.rjvm.
ConnectionManagerServer.shutdown(ConnectionManagerServer.java:443) at weblogic.rjvm.RJVMImpl.peerGone(RJVMImpl.java:804) at weblogic.rjvm.RJVMImpl.gotExceptionReceiving
(RJVMImpl.java:533) at weblogic.rjvm.ConnectionManager.got
ExceptionReceiving(ConnectionManager.java:736) at weblogic.rjvm.http.HTTPServerJVMConnection.checkIsDead(HTTPServerJVMConnection.java:238) at weblogic.rjvm.http.HTTPServer
JVMConnection$TunnelScavenger.trigger(HTTPServerJVMConnection.java:405) at weblogic.time.common.internal.
ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.
execute(ScheduledTrigger.java:229) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)

The client threw this exception:

<Nov 21, 2002 12:24:18 PM CST> <Error> <HTTPClientJVM
Connection> < java.net.Protocol Exception: Tunneling
result not OK, result: 'DEAD', id: '0' at weblogic.rjvm.
http.HTTPClientJVMConnection.receiveAndDispatch(HTTPCli entJVMConnection.java:413) at weblogic.rjvm.http.HTTPClient
JVMConnection.execute(HTTPClientJVMConne ction.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.
java:120)

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.

CR087808

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.
load(Native Method) at java.lang.ClassLoader.loadLibrary0
(ClassLoader.java:1799)

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.
IllegalArgumentException: Class weblogic.qa.tests.cluster.
ejb.callrouter.BaseCallRouterImpl not found at weblogic.rmi.
cluster.ReplicaAwareInfo.classForName(ReplicaAwareInfo.java:172) at weblogic.rmi.cluster.ReplicaAwareInfo.getCallRouter
(ReplicaAwareInfo.java:132) at weblogic.rmi.cluster.Basic
ReplicaHandler.newReplicaList(BasicReplicaHandler.java:78) at weblogic.rmi.cluster.BasicReplicaHandler.<init>(Basic
ReplicaHandler.java:72) at java.lang.reflect.Constructor.
newInstance(Native Method) at weblogic.rmi.cluster.Replica
AwareInfo.instantiate(ReplicaAwareInfo.java:186) at weblogic.rmi.cluster.ReplicaAwareInfo.getReplicaHandler(ReplicaAwareInfo.java:117) at weblogic.rmi.cluster.ReplicaAware
RemoteRef.initialize(ReplicaAwareRemoteRef.java:79) at weblogic.rmi.cluster.ClusterableRemoteRef.initialize(ClusterableRemoteRef.java:28) at weblogic.rmi.cluster.Clusterable
RemoteObject.initializeRef(ClusterableRemoteObject.java:275) at weblogic.rmi.cluster.ClusterableRemoteObject.onBind
(ClusterableRemoteObject.java:150) at weblogic.jndi.
internal.BasicNamingNode.bindHere(BasicNamingNode.java:346) at weblogic.jndi.internal.ServerNamingNode.bindHere(Server
NamingNode.java:105) at weblogic.jndi.internal.BasicNaming
Node.bind(BasicNamingNode.java:281) at ...

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.

CR092933

Thread dump error occurred with this configuration:

• VM: java.version='1.3.1_02'

• os.name='windows 2000'

• java.vendor.url='http://java.sun.com/'

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.
collections.Stack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.kernel.ResettableThreadLocalStack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.jndi.internal.
ThreadEnvironment.pop()Lweblogic.jndi.Environment;(Unknown Source) at weblogic.jndi.internal.WLContextImpl.close()V
(Unknown Source) at weblogic.jndi.factories.java.ReadOnly
ContextWrapper.close()V(Unknown Source) at be.btn.util.
JndiUtil.getEnv(Ljava.lang.String;)Ljava.lang.Object;(Unknown Source) at be.btn.web.HttpControllerServlet.init()V(Unknown Source) at javax.servlet.GenericServlet.init(Ljavax.servlet.
ServletConfig;)V(Unknown Source) at weblogic.servlet.
internal.ServletStubImpl.createServlet()Ljavax.servlet.Serv let;(Unknown Source) at weblogic.servlet.internal.
ServletStubImpl.createInstances()V(Unknown Source) at...

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
Exception, which is new in WebLogic Server 7.0 and not available in WebLogic Server 6.1. The WebLogic Server 6.1 MDB onMessage() method caught the exception, and threw a ClassNotFoundException when the code Exception.
printStackTrace() was executed.

The problem was solved by adding a weblogic.transaction.Timed
OutException class to prevent ClassNotFoundException when interoperating with WebLogic Server 7.0 servers.

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.

Change Request Number

Description

CR089031

After an upgrade from 6.1 SP02 with cr058358_61sp2.jar to SP03, a degradation in deployment performance occurred on a Managed Server. Degradation was not exhibited on the Administration Server.

The problem was related to the weblogic.j2ee.Component.getModuleMBean() method , which was implemented for CR058358. Because ApplicationDescriptorMBean is only registered in the Administration Server, any requests to that mbean from a Managed Server resulted in RMI calls to the Administration Server.

Problem was solved by building a local cache mbean (ApplicaitonDescriptorMBeanImpl_Cached) on the Managed Server. Now, the first method request goes to the Administration Server to retrieve the information and save locally. Subsequent requests are served locally, and the cache is invalidated when the application is undeployed.

CR089765

Executing weblogic.refresh on Windows 2000 to update files (JSP or HTML) to WebLogic Server Administration Server and Managed Server running on Linux caused a java.util.zip.ZipException.

The ZIP exception happens when WebLogic Server is configured as an Administration Server or Managed Server and the Web Application for which the weblogic.refresh is done is targeted to the Managed Server.

When the Managed Server tries to get the refreshed files from the Administration Server, exceptions are thrown by both server instances.

Exhibited in this configuration:

• WebLogic Server 61SP03 on Linux (Redhat, JDK1.3.1) (1 admin, 1 managed)

• Win2K, calling weblogic.refresh (WebLogic Server61SP3, JDK1.3.1)

Problem diagnosis revealed an error in the file location path for the refreshed file from Managed Server to Administration Server, The problem was corrected by a correction to FileDistributionServlet.doGetMultipleJspRefreshRequest.

CR091897

In WebLogic Server 6.1 SP04, deployment failed for a web application with a short name, such as like ab.war or i.war. This error occurred:

java.lang.IllegalArgumentException: Prefix string too short at java.io.File.createTempFile(File.java:1232 at weblogic.j2ee.Component.retrieveComponent(Component.java:296 at weblogic.j2ee.Component.<init>(Component.java:188)at weblogic.j2ee.WebAppComponent.<init>(WebAppComponent.java:45at weblogic.j2ee.Application.addComponent(Application.
java:149)at weblogic.j2ee.J2EEService.addDeployment
(J2EEService.java:117)...

The bug was corrected.

CR097560

In WebLogic Server 6.1 SP04, when custom InitialContextFactory was set to weblogic.jndi.Environment, getInitialContext() instead used DEFAULT_INITIAL_CONTEXT_FACTORY .

The problem was corrected by a code fix to ensure that the weblogic.jndi.Environment object considers InitialContextFactory, if specified.

Change Request Number

Description

CR063275

WebLogic Server EJB did not provide the ability to write a finder method on a byte [] field. This was non-compliant with the J2EE EJB-QL definition: "The allowable types in EJB QL are the abstract schema types of entity beans and dependent objects, the defined types of cmp-fields, and the entity object types of remote entity beans." This problem was identified in WebLogic Server 6.1 SP01. This error occurred at build time:

ejbc:

[java]

[java] ERROR: Error from ejbc: Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was:

[java]

[java] invalid query: In EJB containerManaged, for a query defined in the ejb-jar.xml file with a method signature, findFk(byte[]), we failed to find a corresponding method in the remote home interface, local home interface, or bean class that matches this signature. Note that class parameters such as java.lang.String must be fully qualified, thus 'String' would not match 'java.lang.String'.[java]

This problem has been fixed. WebLogic Server EJB now supports finder methods on a byte [] field.

CR063837

In WebLogic Server 6.1 SP02, the following error was thrown when the EJB Container tried to verify the existence of database tables and columns that did not exist:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Table: Cmp_Birthday Full Table Check failed, but table all columns were found! ] at weblogic.ejb20.utils.TableVerifier.verifyTableAndColumnsExist(TableVe rifier.java:371) at weblogic.ejb20.utils.TableVerifier.verifyTableExistsAndCreateMaybe(Ta bleVerifier.java:391)

The problem was solved with a code fix.

CR076272

When hot deploying an EJB, compilation errors were not helpful. For instance:

<30 avr. 02 11:03:14 BST> <Error> <Management> <Error deploying application.\config\mydomain\applications\ldapprofile.jar:java.lang.reflect.UndeclaredThrowableException>

Error reporting is now improved for hot-deployed EJBs. Now, run-time exceptions and errors are reported similarly to the method used in standalone ejbc. The server log and stdout will provide information to help the user understand the failure. For instance:

<Oct 1, 2002 4:37:18 PM PDT> <Error> <J2EE> <Error deploying application ldapprofile: Unable to deploy EJB: ldapprofile.jar from ldapprofile.jar: java.lang.NoClassDefFoundError: com/bea/p13n/property/EntityPropertyManager at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at weblogic.utils.classloaders.GenericClass
Loader.findLocalClass(GenericClassLoader.java:394) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:157) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at............

CR076386

In 6.1 SP03, using a cmp-ejb with cmr-fields only generated incorrect SQL insert statements. This problem was exhibited with MS-SQL Server 2000 with Automatic-Primary-Key-Generation-TPYE : SQL_SERVER. The Container Generated SQL-Statement:

Insert into tblLicence(, 5 , 7) values (,licCompID,licOrgID)

where compID and orgID are foreign keys in the table which corresponds to this entity bean. After adding an cmp-field, the unmodified (empty) ejbCreate-Method generates the correct SQL:

Insert into tblLicence(licArchivNR,licCompID,licOrgID)values (null , 5 , 7)

The problem has been resolved, the container no longer generates an incorrect SQL Insert statement when the bean has only (pk) field and cmr fields.

CR080331

In 6.1 SP03, deploying a version 5.1 EJB jar using the Administration Console resulted in a ProcessorFactoryException:

Unable to deploy EJB: TxRolledbackExceptionBean.jar from TxRolledbackExceptionBean.jar:

The XML parser encountered an error in your deployment descriptor. Please ensure that your DOCTYPE is correct. You may wish to compare your deployment descriptors with the WebLogic Server examples to ensure the format is correct. The error was:

weblogic.xml.process.ProcessorFactoryException: The public id, "-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN ", specified in the XML document is invalid. Use one of the following valid public ids:

"-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN"

"-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN"

This problem occurred because WebLogic Server 5.1 supported white space in the DTD declaration for deployment descriptors.

The problem was solved by a code change to trim the extra spaces in the key string before searching for the parser in the hash table with this key.

CR083239

The EJB QL NOT MEMBER clause no longer causes infinite looping.

CR083240

The EJB QL NOT MEMBER clause in conjunction with WHERE no longer creates a bad query.

CR084978

Added the Extra EJBC Options field to the Administration Console, so that heap size and other options can now be passed to ejbc via the Console.

CR087151

For a stateless session bean, when the weblogic-ejb-jar.xml contains:

<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>

and the bean was deployed on a cluster, this error was generated:

<Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.>

This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are note replicated.

CR088526

In WebLogic Server 6.1 SP03, the EJB container breaks the EJB2.0 contract: "Tx not set to rollback when using BMT and exception is thrown".

Problem was exhibited with an MDB with BMT where the onMessage method throws an exception. The container did not handle the exception in accordance with the EJB2.0 specifications (Section 18.3.2 Table 18.) The container should log the exception (done) delete the bean instance (done), and mark the transaction for rollback (NOT done). As a result a transaction remained associated with the thread.

A code fix was implemented to resolve this problem.

CR089759

WebLogic Server 6.1:SP03: [EJB] : When calling context.getCallerPrincipal() from ejbStore() using UserTransaction context, the following exception is thrown:

<Oct 24, 2002 5:52:24 AM PDT> <Info> <EJB> <Exception from ejbStore:javax.ejb.EJBException: ejbStore: nulljavax.ejb.
EJBException: ejbStore: null at AccountBean.ejbStore(Account
Bean.java:99)atAccountBean_t4qrab_Impl.ejbStore
(AccountBean_t4qrab_Impl.java:131)at weblogic.ejb20.manager.
DBManager.storeBean(DBManager.java:266) at weblogic.ejb20.
manager.DBManager.beforeCompletion(DBManager.java:397) at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:494) at weblogic.transaction.internal.
ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551) at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)at weblogic.transaction.
internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:979)at weblogic.transaction.
internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1503) at weblogic.transaction.internal.
ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:215) at weblogic.transaction.internal.Server
TransactionImpl.commit(ServerTransactionImpl.java:189)at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68) at weblogic.transaction.internal.
CoordinatorImpl_WLSkel.invoke(Unknown Source)at weblogic.rmi.
internal.BasicServerRef.invoke(BasicServerRef.java:305)at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274) at weblogic.rmi.internal.BasicExecute
Request.execute(BasicExecuteRequest.java:22) atweblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(Execute
Thread.java:120)><Oct 24, 2002 5:54:53 AM PDT> <Info> <Management> <Configuration changes for domain saved to the repository.>

This problem was a result of changes introduced in SP03 to comply with section 21.2.5.1 of the EJB specification. The problem was corrected.

CR089953

In SP03, BEA tests of ejb20.locks.ExclusiveLockManager indicated a memory leak. The memory leak appears as a result of deploying and undeploying.Analysis revealed that the timer/trigger in DiskSwap was not cancelled when an EJB was undeployed, leaving a reference in TimeGenerator, and that ExclusiveLockManager buckets were not being garbage collected.

Problem was solved by code fix to cancel the time/trigger appropriately and ensure proper garbage collection.

CR090143

The default pool-size for MDBs was larger than the thread pool size default, resulting in MDB instances consuming the entire default thread pool and blocking waiting for non-MDB work to complete—leaving no threads left to do the unblocking work.

Problem was resolved by, when an MDB is assigned to the main thread pool, limiting MDB pool size to a percentage of ((thread pool size) - (socket reader threads)).

CR090515

The Administration Console reported incorrect value for the number of waiters for Entity beans. After clients had timed out, the console reported that there were waiters.

The problem was resolved by by a correction to ExclusiveLockManager to decrement the waiterTotalCount when it is done waiting.

CR091436

In SP03, JMSConnectionPoller did not close its initial contexts. When an MDB used external InitialContextFactory for lookups and the JMS provider was not accessible, the connections and other resources accumulated rapidly.

The problem was corrected with a code fix to close the context when it is done for active memory clean up.

CR091722

In SP03, under heavy loads, an MDB threw an IllegalStateException when resuming a transaction after invoking a business method; the JVM crashes when the transaction is being resumed.

This behavior was exhibited with these application characteristics: a client sends messages to a Queue and an MDB listens on it. The tx.attribute for this MDB is "Required". The create method of the MDB is doing a home.create for creating some BMT SLSBs and the onMessage method is invoking the business method for this SLSB. The business method of this SLSB is sends messages to two different queues.

The following error was observed:

<EJB Exception during invocation from home: com.gfs.corp.batch.cost.costupdate.ejb.NextOrderCostUpdateProcessorEJB_xtvwzj_LocalHomeImpl@54b120 threw exception: java.lang.StackOverflowError> java.lang.StackOverflowError <<no stack trace available>>

The local interface was not handing exceptions properly.

The problem was solved by a code fix to correct the error handling so that the container properly rolls back the transaction when exception occurs.