CR097378

A NullPointerException sometimes appeared on the Administration Console while the Web Application 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.

CR106965

In the Administration Console, "Monitor All Entity EJBRuntimes..." or "Monitor All Message Driven EJBRuntimes..." incorrectly contained information from multiple EJB JAR files with similar names.

Now, the Administration Console only displays MBeans associated with a selected scope.

CR132429

The Administration Console had no option for taking input from a user to remember the last entered user. By default, the last entered user was saved as a cookie which was valid for one week.

Now, the login form on the Administration Console has a checkbox called "Remember my ID on this computer". This checkbox is checked by default. When the checkbox is not checked, WebLogic Server will only remember the user ID for the current session.

CR130110

There was an upload directory problem when the complete path rather than a relative path was specified.

WebLogic Server now checks for relative and absolute path when uploading.

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.

CR172233

While accessing the user/group list from the providers, the list appeared blank on the Administration Console if any of the providers was down.

Now, the Administration Console displays the user/group list for the providers that are accessible and shows an error if any of the providers is down.

CR174734

Re-creating a deleted realm was causing an InstanceAlreadyExistException.

Now, the realm is deleted completely so that the InstanceAlreadyExistException is no longer thrown when a deleted realm is re-created.

CR180635

While uploading an archive file through the Administration Console browser, the archive files were uploaded in the domain directory irrespective of the path specified.

Now, WebLogic Server uses the upload directory property while uploading files onto the server so the files are uploaded into the correct directory.

CR181865

The Administration Console was allowing the addition of members into the JMS distributed destination even if their JMS server was not targeted.

Now, a member cannot be added to the JMS distributed destination if the member's JMS server is not targeted.

CR096998

When the Administration Console is used to edit the CMP EJB deployment descriptor, WebLogic Server no longer throws a NoSuchMethodException.

CR106399

Whenever a method permission was created from the Administration Console in the examples domain and the server was restarted, WebLogic Server was throwing a page not found exception.

Adding MethodPermission.jsp for ejb20 has solved the problem.

CR188452

The Administration Console was unable to display the server log. Instead, an exception was being thrown.

Code fixes have eliminated the problem. Now, the server log can be displayed in the Administration Console.

CR081329

The Refresh function in the Administration Console has been fixed. The Refresh button no longer opens the page that was previously opened, but instead refreshes the page that is currently opened.

CR206741

WebLogic Server was making too many RMI calls to find out the deployment status of a component on a target especially if the target was a cluster or a virtual host. In addition, the component status on the target was not depicting the precise deployment status of the target.

The availability status of a component shows whether it is running on a server or not. It also shows the current availability of a component on all the servers of the targeted cluster or virtual host. The availability status is updated when the targeted servers are shut down either gracefully or forcefully.

Deployment status of a component is now shown in terms of its aggregated deployment status and availability status. The aggregated deployment status of a component could be Available or Not Available when it is deployed on a server and Available, Not Available, or Partially Available when it is deployed on a cluster or virtual host. The Partially Available deployment status implies that the component is available only on some of the servers of the cluster or the virtual host.

These changes have minimized the number of RMI calls needed to retrieve the status report for a cluster deployment and have resulted in improved performance.

CR214994

The Administration Console server monitoring versions page now displays the system property, java.vm.vendor, correctly.

CR178658

The Servlet Extension Case Sensitive attribute has been added to server and cluster configurations. In addition, the Web App Files Case Insensitive attribute has been added to security domain configuration.

These attributes specify whether file lookups for Java Server Pages (JSPs) are case sensitive on all platforms except win32; file lookups from standard win32 file systems are always case-insensitive. On case-insensitive file systems other than win32 (such as NT Samba mounts from UNIX or Mac OS that have been installed in case-insensitive mode), specify case insensitive lookups by setting these attributes to false to prevent the JSP from returning its source code. For example, if a JSP is being served from a Samba mount and you have specified case-insensitive lookups, WebLogic Server converts all file name extensions to lower case before looking up the JSP.

Possible values and usage:

1. OS (the default value): Weblogic Server relies on the operating system for pattern matching.

2. True: Weblogic Server enforces case-insensitivity irrespective of the operating system.

3. False: Weblogic Server enforces case-sensitivity irrespective of the operating system.

CR177776

WebLogic Server encountered distributed dead-locks in a cluster when replicated session http requests landed on a server that acts as neither primary nor secondary for the requests. If multiple such requests landed on servers in a cluster, all the threads in the default thread pool were being exhausted due to this behavior and at some point in time, there were no threads available in default thread pool to receive responses. This lead into distributed dead-lock.

WebLogic Server no longer deadlocks under these conditions.

CR206375

Load balancing http requests in a cluster sometimes caused the following incorrect error message to be reported:

Error while primary becoming secondary,[No old secondary found for roid:<roid>] or [No new primary found for roid:<roid>]

This error message indicates a problem with session stickiness configuration either in the plug-in or in the load balancer.

WebLogic Server now displays a proper message that describes the problem and suggests checking the session stickiness configuration in the load balancer and/or in the plug-in.

CR184893

Classloading from within RAR is no longer slow.

CR108791

When the server state was SHUTDOWN_IN_PROCESS and Runtime.getState was called WebLogic Server was returning the wrong string.

Now, WebLogic Server returns the correct string which depicts the state of the server.

If your applications were dependant on the wrong string constant that was being returned, you may need to change the string constant.

CR125000

CR129560

The cluster service was setting the real uid/gid of the process after binding to the multicast port. As a result, errors occurred when WebLogic Server attempted to switch the user after binding to the listen ports.

Now, WebLogic Server uses the postbind uid/gid during server startup except when binding to ports and only switches to the real uid/gid after listening on all ports.

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.

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.

This problem has been resolved.

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.

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.

CR105444

The server would throw a FileNotFound Exception if a path for a log file was specified but the directory not exist when using the -Dweblogic.Stdout and -Dweblogic.Stderr command-line options.

A code enhancement resolves this issue by creating the directory structure specified by the command-line options when the structure does not exist.

CR099356, CR099005, CR186191

A race condition in JVMSocketManager was causing MuxableSocketDiscriminator.isMessageComplete to throw a NullPointerException which resulted in JVMSocketManager running an infinite loop.

Now, JVMSocketReader initializes the necessary information in static initializer so that initialization happens only once and there is no more infinite loop.

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.

CR174955, CR105257

A call to WLECService.getConnectionPoolCount resulted in a NullPointerException even if the call was made before the IIOP Connection Pool was initialized.

Now, if the IIOPConnection Pool is null, zero is returned. As a result, the NullPointerException is no longer thrown when a call is made to WLECService.getConnectionPoolCount.

CR180426

When WebLogic Server was running in a cluster, a warning message appeared when the DNS name of the cluster was not set. This warning message was degrading the cluster performance.

Now, the cluster address is always read from the clusterMBean if it is not available via the networkchannel. As a result, the warning message no longer causes performance problems for the cluster.

CR180532

Deadlock sometimes occurred when the domain log and server logs were rotated at the same time.

Now, WebLogic Server no longer logs messages while rotating the logs. As a result, deadlock no longer occurs during log rotation.

CR173958, CR185090

Interoperability between 6.1 SP4 and 7.0 SP5 domains using t3 failed 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.

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.

CR179262

During startup, WebLogic Server was experiencing a deadlock between weblogic.jms.common.DistributedDestinationManager and weblogic.cluster.MemberManager.

Synchronization has been reduced in MemberManager and now there is no longer a deadlock.

CR182838

LocalServerRef did not implement the hashCode method which caused multiple entity beans with different PKs to have the same stub.

LocalServerRef now correctly implements the hashCode method.

CR185841

When starting up many Managed Servers concurrently, the Administration Server CPU usage was high.

WebLogic Server now makes fewer remote calls to ServerMbean.getName(). As a result, Managed Server startup time in a large cluser is faster and the CPU usage on the Administration Server is lower.

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.

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.

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.

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.

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.

CR190507

Fixed a problem with oneway calls for ReplicationManager.

CR203523

The following log message has been reinstated to appear as it had in previous WebLogic Server releases.

<Warning> <WebLogicServer> <000333> <Queue usage is greater than QueueLengthThresholdPercent "3%" of the maximum queue size. We'll try to allocate ThreadsIncrease "5" thread(s) to help.>

CR206459

The maximum limit on the number of threads that could be created on the client side was fixed at 50.

Now, the maximum limit on the number of threads that can be created on the client side is set to 65536.

CR183620

The startup script for the Managed Server, startManagedWebLogic.sh or startManagedWebLogic.cmd, that was generated from the domain configuration wizard had the following incorrect line:

cd @USERDOMAIN_HOME

This incorrect line caused the following errors:

C:\bea70sp5\user_projects\mydomain>echo off

The system cannot find the path specified.

To fix the problem, the domain configuration wizard now does string substitution.

CR179645

Now, WebLogic Server unpacks large JAR files much more quickly.

CR183537, CR187458

If no target was specified during the redeployment of an application, weblogic.Deployer was adding the Administration Server as the default target.

Now, if no target is specified, the deployed application is correctly redeployed to all of the current targets. A new application is deployed to the Administration Server by default.

CR192196

A WebLogic Server 8.1 client calling DeployerRuntime.getDeployerRuntime(MBeanHome) was getting an InstanceNotFoundException if invoked against a WebLogic 7.0 Administration Server.

A change was made to the implementation of DeployerRuntime.getDeployerRuntime(MBeanHome). As a result, a WebLogic Server 8.1 client is now able to fetch the DeployerRuntime MBean from the WebLogic 7.0 Administration Server and vice versa without getting any InstanceNotFoundException.

CR124450

If the server is running in development mode and an attempt is made to delete an EAR file deployed on the server using the Microsoft Windows Explorer from within the applications directory, the following error no longer occurs:

Cannot delete abc.ear:there has been a sharing violation, The source or destination file may be in use.

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.

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.

CR127369

An AssertionError was sometimes thrown when more than one bean was based on the same Java class.

This error occurred when the following conditions were satisfied:

1. a bean A had a many-to-one relationship to a bean X (unidirectional relationship)

2. a bean B had a many-to-one relationship to a bean X (unidirectional relationship)

3. beans A and B were two different deployments based on the same java class.

While processing the relationships of beans, WebLogic Server holds the list of cmr-field names, and if the cmr-field name has not been declared, WebLogic Server creates it based on the bean class name. In the above case, while processing relationships of bean X, the cmr-field names of the relation to bean A and the one to bean B will be created. But these class names are the same, so the created cmr-field names are the same. This causes the AssertionError.

Code has been added to make the cmr-field name unique, eliminating the possibility of conflicting names.

CR108169

When an EJB deployment descriptor was edited using the Administration Console, an incorrect method name was introduced.

The correct method name has now been implemented.

CR135410

When the bean is looked up and a business method is called for the first time, the call to EntityContext.getCallerPrincipal() from ejbStore returns the user as "anonymous". After this, when ejbStore is invoked again, it returns the correct username. This problem only occurs with ejbStore and no other method.

This problem has been resolved.

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.

CR189847

Stateful session bean (SFSB) InMemory replication was causing an apparent memory leak.

Although no memory leak was occurring, the heap memory was not being used efficiently. Now, during SFSB InMemory replication, the heap memory is being used more efficiently.

CR196593

Servers were hanging during stateful session bean (SFSB) replication due to lock contention in the NRUCache.

The lock contention in the NRUCache has been reduced to prevent the servers from hanging during SFSB replication.

CR197817

When WebLogic Server executed a finder method on an entity bean, a NullPointerException was being thrown.

To eliminate the NullPointerException, the generated code now expects that the bean could be null and the bean is now handled appropriately.

CR132510

When enabling the relationship caching on an entity bean that is using optimistic concurrency and has cache-between-transaction set to true, WebLogic Server no longer throws an IllegalStateException.

CR205974

When a collection valued CMR field is accessed in a transaction other than the one in which it is created, WebLogic Server no longer throws an IllegalStateException.

As a result, WebLogic Server delivers the correct result set from the finder query regardless of whether caching is turned on or off.

CR203644

Replicated Stateful Session Beans in a cluster with InMemory replicated session no longer throw a NoSuchObjectException or a LeasedRemoteRef error after instances have been passivated or after the cluster instance has been shut down.

CR121040

It was not possible to change the password of a WebLogic Server Windows Service without having to uninstall and re-install the service.

WebLogic Server now has an edit option so that parameters can be edited without having to re-install the service.

Individual or multiple options can be edited simultaneously as follows:

beasvc -edit -svcname:wls_service -javahome:"C:\java\java142_05" -password:"blah" (this command alters the value of "javahome" and "password" parameters)

The options will take effect when the service is restarted.

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.

CR132360

The weblogic.j2eeclient.Main did not work in webstart. The client jar file is an argument loaded by the webstart client and made available in the classpath. But the file was not available in the current directory resulting in an error.

A system property (weblogic.j2ee.client.isWebStart) was added to WebLogic Server to load the client jar file from the system classpath. weblogic.j2eeclient.Main now works in webstart.

CR103309

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-70.00.jsp.

CR186016

While redeploying an application, J2EEApplicationContainer is now redeploying the internal modules such as JDBCModule as it did prior to WebLogic Server 7.0 Service Pack 5.

CR097079

When an application is removed from the Managed Server, the auxiliary jars are now also removed from the staging directory of the server.

CR103506

When deploying an exploded .ear directory that contains a directory whose name contains a period, ".", a NullPointerException is no longer being thrown.

CR185934

COM to Java clients failed when the Microsoft Security Bulletin MS04-011 was applied.

This has now been resolved.

CR199844

When an exception occurred, COM sockets were leaking.

Now, COM sockets are properly closed when an exception occurs.

CR136746

Explicit naming of JDBC driver used in the class VendorId were not possible.

The problem has now been resolved.

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.

This problem has been resolved by a code change in the recovery method that prevents special XA connections from being released to the pool twice.

CR174126

Using multiple different prepared statements in a single transaction invoked a bug in the XA statement cache, which lost the handle to unclosed JDBC statements. This quickly caused all the available cursors in Oracle to be consumed and leaked.

A fix was made to the underlying collection object being used to implement the XA statement cache.

CR177220

In a multi-server domain, a client involved in a global transaction got the following exception:

weblogic.transaction.RollbackException: delist() failed on resource jdbcXAPool

The code was changed so that if the data source is null, then the resource manager is not set. When the data source is initialized, the resource manager is wrapped by VendorXAResource.

CR180097

The JDBC connection pool's "CountOfTestFailuresTillFlush" property neglected to clear statement caches.

The problem was resolved with a code fix.

For detailed information about using the "flush pool" feature, see "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC.

CR184819

WebLogic Server multipools were not failing over when multiple instances of RAC were configured and the first RAC instance was stopped.

Multipool now fails over correctly.

CR182410

Under high load conditions, WebLogic Server slowed significantly.

Removing synchronization in the weblogic.jdbc.common.internal.MultiPool.searchLoadBalance() method eliminated the slowdown under high load conditions.

CR189978

Misconfiguration of the pool or an unresponsive database could have resulted in the creation of a pool that was not activated. If the pool was never activated, WebLogic Server threw a ResourceException. The JDBC MultiPool would not fail over to the next active pool when this exception was thrown.

Now, WebLogic Server throws a ConnectDisabledException with a message indicating that the pool was never activated. The JDBC MultiPool detects and handles this exception and does a retry on a different pool if one is available. As a result, the JDBC MultiPool now fails over to an active pool if any of the pools in the list had never been activated.

CR187604

A getMoreResults and a getResultSet call on a JTS Statement wrapper no longer returns the same and already-closed result set.

CR196738

The MSSQLServer4 driver's Statement.cancel() method was corrupting the JDBC connection. JDBC statements were not being closed within a transaction after the connection was closed.

The MSSQLServer4 driver's Statement.cancel() method was changed so that it is now a no-op and therefore no longer corrupts the connection. This change has no effect on rolling back transactions.

CR197163

The JDBC connection pool's testing of connections was consuming a lot of database resources because each test was creating a new plain statement which requires the DBMS to parse and plan the test SQL every time.

Now, pools will reuse a single prepared statement for a connection's test which results in improved performance. However, if any application DBMS tables or procedures are referred to in the test SQL and if they structurally change at runtime, such as an index being added, this may invalidate the test PreparedStatement's query plan. As a result, the subsequent test will fail and the connection and test statement will be replaced. The test SQL suggested by the Administration Console will typically not include any structurally changing table, so the problem of needlessly recycling a connection is now minimized.

CR203460

When a pool connection was made by the XAConnectionFactory, its seconds-to-trust value was not set, so it remained the default.

Now, the sectonds-to-trust value is set.

CR193357

JDBC refresh was miscounting the number of unreserved connections.

JDBC refresh now correctly counts the unreserved connections and, therefore, is no longer doing any unnecessary work.

CR087241

A JDBC application using XA calls and any Oracle driver, was getting an ORA ORA-01002: fetch out of sequence error while fetching rows if a transaction was suspended and resumed.

The AddOracleFlagToXAResource flag has been added to fix this problem when the XA calls use the Oracle 10g thin driver. To avoid getting the ORA ORA-01002: fetch out of sequence error while using XA calls, you must use the Oracle 10g thin driver and turn on the JDBCConnectionPool flag.

CR142730, CR190124, CR190125

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.

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.

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.

CR099554, CR195519

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.

CR135578

The bytes pending counter for non-durable topics was not getting updated correctly when the consumer exited with outstanding non-durable topic messages still pending Redelivery delay on the topic.

Now, the bytes pending counters for JMS statistics will be appropriately adjusted for non-durable topic messages when the consumer exits and Redelivery parameters have been configured. There is no redelivery attempt on unacknowledged non-durable topic messages when the consumer goes away.

CR134155

JMS messages from topic sessions caused a memory leak when the receiver was created using a transacted session, used AUTO-ACKNOWLEDGE mode, and the message was rolled back.

A code fix resolved this issue.

CR178775

When a JMS client repeatedly opened and closed JMS connections against WebLogic Server, JMSConnection and related objects such as DispatcherWrapper were not being released in both the client and the server side. This caused an OutOfMemoryError which occurred when the client retained one open JMS connection while opening and closing other JMS connections.

A change in the code has fixed the problem.

CR179737

A race condition sometimes prevented JMS from detecting and cleaning up lost connections.

The reconnect logic was tightened to prevent this type of race condition from occurring.

CR173565

JMS messages were delivered twice when an XA transaction failed.

A code fix was made to handle failed transactions, and to log an appropriate error message to notify the user that there is a transaction in an ambiguous state.

Prior to this change, any message involved in a transaction that was in an ambiguous state would still be rolled back and redelivered because the message was in memory. However, the record in the store (if there was one) was not properly updated because the store's handle for that record was invalid, leaving the record (if there was one) in the store. Therefore, when the JMS server was rebooted the message was redelivered, resulting in duplicate message.

Now any message involved in a transaction that is in an ambiguous state will require a JMS server restart before it can be recovered. Any attempts to recover the message without JMS server restart will result in an RMERR.

CR183572

Because the JMS IOThreadPool name was incorrect, all JMS stores on a WebLogic Server were sharing the same two threads. As a result, performance was potentially being degraded when more than two JMS stores were running on the same WebLogic Server.

The JMS IOThreadPool name is now correct which eliminates the potential performance degradation.

CR178405

During a scan for expired messages, a java.util.ConcurrentModificationException was thrown.

The problem was resolved with a code fix.

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.

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.

CR187945

JMS DistributedDestination load balancer was not recognizing pre-existing consumer(s) when a member was added dynamically.

WebLogic Server now checks to see if a member has any consumers when a member is added to a distributed destination so that the load balancer has the information it needs to load balance correctly.

CR190438

A Java-level deadlock was found between objects weblogic.jms.backend.BEQueue and weblogic.jms.backend.BEConsummer.

This problem has been resolved by updating the lock hierarchy to make sure that the destination has been locked down first.

CR197857

JMS was not sustaining the minimum flow rate. The actual minimum flow rate was approximately double the configured value. When using the default flow control settings on a Connection Factory, FlowMinimum=50, JMS was sustaining a flow minimum of approximately 100 messages per second rather than 50 messages per second.

Now, once a JMS destination exceeds its specified bytes or messages threshold and flow control is started for the producer, flow control throttles back until it reaches FlowMinimum (default 50) and it should maintain that minimum flow rate as long as thresholds are exceeded.

This change causes a greater slow down from flow control than previously seen because JMS is now correctly sustaining the minimum flow rate.

To maintain previous flow control behavior (behavior prior to the release of 8.1 sp4), double any FlowMinimum configurations and add a FlowMinimum=100 on ConnectionFactories that were previously assuming default values.

CR187610

Bridge was not using Messaging Bridge Thread Pool for bridge dispatch requests.

Now, Bridge uses the Messaging Bridge Thread Pool if one has been configured. If there are not enough available threads configured in the Messaging Bridge Thread Pool, then the bridge will use the default execute thread pool.

Bridge also logs a warning message if the configured Messaging Bridge Thread Pool size is insufficient and then attempts to obtain a thread from the default execute pool instead.

CR197207

The Java client was hanging if the JNDI lookup was performed from a static block during the response from an EJB call.

To fix the problem, a new system property (-Dweblogic.rjvm.t3.dispatchOnCompleteMessage) has been added. This property needs to be enabled on the client side. When this property is enabled, the t3 request is processed on a thread other than the socket reader thread.

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.

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.

CR174837

WebLogic Server was not allowing custom PageContext implementations.

The unnecessary cast to weblogic.servlet.jsp.PageContextImpl in the generated JSP has been removed. As a result, custom PageContext implementations are now usable.

CR172380, CR198902

A struts-based application failed to pre-compile an EAR file, and throwing the following exception:

<Error> <Deployer> <149205> <The Slave Deployer failed to initialize the application dos due to error weblogic.management.ManagementException: 149233 - with nested exception: [java.lang.ExceptionInInitializerError]. java.lang.ExceptionInInitializerError: java.lang.NullPointerException

A code change resolved the problem by setting the thread class loader before precompiling all the JSPs to the ServletClassLoader() method. This ensures that the same classloader gets used for loading the struts classes and loading any other class that the struts library tries to load afterwards.

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.

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.

CR130073

When an application issued a number of rollbacks from Tuxedo 7.1 through WTC to WebLogic Server, some Oracle XA connections were leaked and not returned to the pool. XA Debug showed that XA End was not called so the connection was not cleaned up.

WebLogic Server now calls XA End, allowing the connections to be returned to the pool and eliminating the out of memory error.

CR125476

When a transaction was in the prepare phase and an XAER_RMERR or an XAER_RMFAIL exception was thrown, the transaction remained pending instead of being rolled back.

Now, under these conditions, the transaction is rolled back.

CR184941

After a manual JTA migration to back up the server, attempts to boot the crashed WebLogic Server were not successful.

Now, after a manual JTA migration to back up the server, if the crashed WebLogic Server is restarted, it boots successfully.

CR202386

Transaction Manager was failing to invoke xa_start() on an object associated with a new resource manager.

To fix this problem, the default registration has been standardized. If the application does not call registerResosource(), the resource is registered with the Transaction Manager as a standard resource.

CR188558

When the WebLogic Server was shut down before the timer thread went off, some resources were not being checkpointed to the TLOG. When the WebLogic Server was brought back up, recovery on those resources would not run and any pending transactions would be left pending.

Now, when the transaction enlists with a resource, if the resource is coordinated locally and if the resource needs to be checkpointed, it is flagged so that at prepare time, if the transaction is two-phase, the resource gets checkpointed to the TLOG.

CR173464

When getting the cached coordinator, the thread no longer goes into an early notification state which was causing the server to hang.

CR211194

Calling the XA call sequence, XA.end (TMSUSPEND), followed by XA.end (TMFAIL), followed by an XA.rollback in the case of an MQSeries resource prevents memory leaks in MQSeries.

CR132228, CR188670

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.

CR135917

The NodeManager native code was sometimes responsible for a segmentation violation if fdopen on stderr failed. This problem has been fixed.

CR076968

NodeManager has been updated to consistently send the process termination signal as SIGKILL instead of SIGTERM when the offline method is invoked.

CR128517

Using the Administration Console, if you configure a machine, but do not configure the NodeManager, and then you inquire about the state of the server, the NodeManager is contacted by default.

If you do not need the NodeManager, set the ListenPort to 0 in the machine configuration. This tells the server that the NodeManager is not configured and it will not try contacting the NodeManager.

CR132947

When the Administration Server was shut down after the Managed Server in the same domain was shut down, the Administration Server was always throwing a java.rmi.ConnectException.

This problem has been fixed.

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.

CR108496

When editing an EJB deployment descriptor from the console, the <global/> tag was being changed to <global>true</global> in the deployed EJB jar file.

An empty tag for getGlobalRole method was added so that validation does not fail after persistence.

CR126191

The DESTROY_POOL command used with the weblogic.Admin tool merely disconnected all the users and suspended the pool. It did not actually delete the pool from the domain configuration as it should.

DESTROY_POOL now deletes the pool configuration. Use DISABLE_POOL or SUSPEND to suspend the pool.

CR134167

EXISTS_POOL did not work as expected. It was looking for runtime mbeans which may or may not exist even if the pool exists. DELETE_POOL, an undocumented command, was the internal implementation to delete a connection pool; however, this feature was documented as DESTROY_POOL externally.

The Help menu also displayed some undocumented commands.

EXISTS_POOL command implementation now looks for configuration mbeans to check whether the pool exists.

DESTROY_POOL command now uses the underlying DELETE_POOL implementation.

All the undocumented commands that appeared in the weblogic.Admin help menu are now disabled. Commands include TEST_POOL, REMOVE_POOL, SUSPEND_POOL, SHUTDOWN_POOL, RESUME_POOL, DELETE_POOL. These will not be supported going forward and will not work in 7.0 SP5.

The Help menu no longer lists these commands.

CR171906, CR179030, CR208205

The Administration Server was not starting when the Managed Servers were running with an operations user.

Now, the operator role allows the user to reboot the Administration Server and recontact the Managed Servers. As a result, the Administration Server can now start when the Managed Servers are running with an operations user.

CR179524, CR203851, CR213673

When the server logs were opened in editors/viewers, while the server was still running, the log froze because the server could not re-open the log file for logging after or during the log rotation.

Retry logic has been implemented in the logger so that WebLogic Server now attempts to rotate to an alternate log file when the first attempt fails and continues to log even if all attempts fail.

CR177510 CR135356

Adding or redeploying a module that was part of a large EAR file (600MB) took a very long time.

A code change to the WebApp module improved performance:

• The WebApp module now considers the update of a module when the delta is for changing the whole module.

• To reduce the startup time for large application deployment, deployment was modified to persist the staged targets attribute for configured applications.

Remote call traffic between the Administration Server and a Managed Server was reduced during application deployment.

CR182686

A ConcurrentModificationException was sometimes thrown while setting System Properties in a startup class or servlet.

WebLogic Server has been modified to synchronize the properties and no longer throws the ConcurrentModificationException when setting System properties.

CR184787

The Administration Console did not display the "replicated_if_clustered" value for PersistentStoreType on the session parameters page of the Deployment Descriptor page. As a result, when the descriptor was persisted, it put in a different value into the descriptor.

The Administration Console now displays the value and it is correctly added to the descriptor.

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.

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.

CR188701

Restarting the Managed Servers when the Administration Server was down caused deployment to fail. When the server was set to stage applications, but the application being deployed did not have its staging mode set, the wrong staging mode was used.

Now, applications that do not have a staging mode set, but are deployed on a server with the staging mode set, are correctly deployed in the right staging mode.

CR190822

JDBC connection pool cloning was not working.

Now, JDBC connection pool cloning works even if the server is targeted.

CR200310

The application manager was being started twice when run in MSI mode.

Now the application manager is only started once when run in MSI mode.

CR135521

When creating or deleting a Commo MBean, WebLogic Server no longer throws an IllegalArgumentException.

Now, WebLogic Server throws an InstanceNotFoundException if the type is null. A client such as wlconfig catches this exception and uses JMX MBean Home to get the attribute value on the MBean.

CR182072

Now, the ConfigurationVersion attribute in the config.xml file changes value after the service pack is upgraded.

During every server bootup, the attribute is now set to be the same as the Administration Server version.

CR100218

Because the value for ExecuteQueueMBean.setThreadPriority() is non-configurable by a user, ExecuteQueueMBean.setThreadPriority() has been excluded from the public javadocs.

CR109591

The Administration Console was not locating a log called 'myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log.

To fix this problem, WebLogic Server now attempts to locate the filename in the following format:

myserver_yyyy_MM_dd_hh_mm.log

instead of the following format:

myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log

If still unable to locate the filename using the myserver_yyyy_MM_dd_hh_mm.log format, WebLogic Server throws a FileNotFoundException.

CR124169

WebLogic Server no longer throws an Assertion error when shutting down or undeploying the MessagingBridge using JMX.

CR202449

When a server instance was created on the Administration Server, its default queue was not getting initialized until the Administration Server was reinitialized.

Now, the default queue is initialized when the server instance is created or cloned.

CR208697

WebLogic Server decremented the notificationID variable when removeNotification() was called to remove some middle elements. WebLogic Server was then throwing an InstanceNotFoundException if access to the last element of

allNotification[] was attempted.

As a result, it was not possible to access the last element because the value of the variable, notificationID, was less than the size of allNotification[].

Code changes have fixed the problem so that now when removeNotification() is called, an ArrayOutOfBoundException is not thrown, and an InstanceNotFoundException is thrown only if the notification instance is not available. The InstanceNotFoundException is no longer thrown if access to the last element of allNotification[] is attempted.

CR211194

Calling the XA call sequence XA.end (TMSUSPEND) followed by XA.rollback no longer causes a memory leak in MQSeries.

CR211815

The locking sequence used during the process of unregistering an MBean has been corrected to avoid deadlock.

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.

CR100070

It was not easy to maintain the WLLogFile for each virtual host in the Apache-WLS plug-in because there was only one global debug flag to enable or disable debugging for all the requests handled by the plugin.

Now, it is possible to specify the debugging option at the top most level and overwrite it within each virtual host and/or location tag.

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.

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.

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.

CR173581, CR173878

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.

CR174431

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

CR175672

The Apache server is hanging when the WebLogic plug-in tries to open the wlproxy log file, even though Debug is OFF.

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

CR175989

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.

CR177707

When using the release 7.0 SP02 plug-in with client certificates, WebLogic Server worked fine. However, after an upgrade to release 7.0 SP05, 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 7.0 SP06 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.

CR179537

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

The problem was resolved with an internal code fix.

CR180236

The previous 7.0 release 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.

CR178792

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

CR180560

The plug-in was not printing the socket information (localhost:localport remotehost:remoteport) to the log file when making a new connection to WebLogic Server.

Log messages with the local hostname and local port number are now added when the plug-in makes a new connection to WebLogic Server.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

CR188811

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.

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.

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

CR189933

The WebLogic Server plug-in was not thread safe. The memory address to SrvrInfo array and its size were being passed around and then could be modified by another thread. If they were then modified by another thread, the first thread could end up accessing invalid memory location which could result in seg fault.

Now, the WebLogic Server plug-in is thread safe. WebLogic Server makes a read-only copy of SrvrInfo array before passing it around.

CR191552

The deprecated property, MaxSkips, was replaced by MaxSkipTime. This new property was not being used throughout the code. As a result, the parameter, MaxSkipTime, defaulted to a value of 10 that could not be changed.

MaxSkipTime is now used throughout the code and therefore its value can now be changed.

CR192875

The iPlanet Server was crashing if readPostDataIntoFile() threw a new exception from its try catch block.

This no longer occurs because readPostDataIntoFile() now returns an exception instead of throwing it if it encounters an error while writing post data to a temp file.

CR193447

The cookie did not contain, |, as the delimiter separating primary and secondary information present. As a result, parseJVMID() always returned the primary server information and ignored the secondary server information.

The cookie is now tokenized to separate primary and secondary information and then call parseJVMID() for both of the extracted values. Now, parseJVMID() returns both the primary server information and the secondary server information.

CR193985

WebLogic Server was logging "creating timer thread in child" messages as [warn] in the log level.

Now, these messages are logged as [info] in the log level which better reflects the nature of the message.

CR194141

The Apache plug-in was decoding the URI before passing the request to WebLogic Server even though getRequestURI states that the returned value should not be decoded.

Now, the Apache plug-in passes the URI to WebLogic Server without decoding it first.

CR194464

A call to internal initJVMID() was not updating the state of the server from GOOD to BAD if the connection was refused. As a result, time was wasted trying to reach a server that was already down.

Now, if the server is already marked BAD, initJVMID() will skip it and try the next server. Also, initJVMID() updates the state of the server if the connection is refused.

CR199045

When multiple object tags were configured for various path values using both SSL and non-SSL configuration, the plug-in was unable to switch correctly between SSL and non-SSL requests.

Replaced a global flag (convertDNSSToIP) with a per request flag (moved inside ConfigInfo structure), so that the plug-in now switches correctly between SSL and non-SSL requests.

CR201736

The WL-Proxy-SSL header is no longer missing when using the ISAPI plug-in.

CR199446

The Apache plug-in did not support regular expressions in the Location and the LocationMatch tags.

Now, the Apache plug-in supports POSIX regular expressions.

The following Location tag is not valid anymore:

<Location */app/*>

...

</Location>

The tag should be changed to:

<Location /app/>

...

</Location>

Following are some commonly used entries in Location tags:

Request matches a certain path:

/app/*

should be changed to:

/app/

Request starts with a certain path:

/app/*

should be changed to:

^/app/

Request matches a particular mime type:

*/*.jsp

should be changed to:

\.jsp

CR199668

Hostname matches were case sensitive, so "HostName" did not match "hostname" when doing a host search.

Now, the host search for iisforward.ini proxy is no longer case sensitive. So, Hostname matches are not case sensitive.

CR202898

When a HEAD request is sent to an Apache plug-in, the headers in the HttpResponse are no longer missing the Content-Length header and the Content-Type header is no longer corrupted.

CR205009

Starting the Apache plug-in (revision 158) with root user no longer results in a core dump.

CR209778

Code was fixed to ensure that custom value is used for ConnectRetrySecs as specified in the configuration file.

Now, ConnectRetrySecs is working correctly with Apache.

CR209383

POST data is no longer getting chunked when FileCaching is set to OFF.

CR207694

Now, when "Expect: continue-100" is found in the request, NSAPI replies with "HTTP/1.1 100 Continue" in the header instead of in the response body.

CR205760

If an INSUFFICIENT_BUFFER error was thrown while reading requests, then new memory was allocated. This memory was being accessed later in the method after it had been freed.

Now, memory is freed at the end of the routine.

CR199080

Now, when the plug-in fails to connect to WebLogic Server, GETLASTERROR is getting logged.

Log messages have also been added to log any errors that occur while the plug-in is connecting to WebLogic Server.

CR128730

When HttpClusterServlet was sending a request to PRIMARY using a recycled connection, it did not determine that there was any failure to connect until it was too late to re-connect. As a result, HttpClusterServlet was never failing over to SECONDARY.

Now, HttpClusterServlet checks to confirm whether the request was successfully sent to PRIMARY. Subsequently, if the request to PRIMARY was not sent successfully and HttpClusterServlet had used a recycled connection, HttpClusterServlet tries to create a new connection to PRIMARY. If the subsequent request also fails with an exception, HttpClusterServlet fails over to SECONDARY.

CR208303

On AIX, the errno variable was not thread safe. To make the errno variable threadsafe, -D_THREAD_SAFE was added to the Makefile.aix.

CR218680

Now for each request, the HTTP status code is set correctly.

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.

CR188748

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.

CR197396

The CPU load on machines no longer increases to 100% while server instances call addIndirection for IIOP Outbound responses to clients calling an EJB with RMI/IIOP.

As a result, performance is now improved.

CR197824

When WebSphere 5.1 tried to make an EJB call to WebLogic server with a HashMap as data, WebLogic Server was throwing an UNMARSHAL exception.

To fix this problem, WebLogic Server now properly handles foreign service contexts.

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.

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.

CR121646

A BAD_CERTIFICATE error was received and the SSL connection was terminated when a client certificate with Extended Key Usage set to critical was sent to WebLogic Server.

The problem was resolved by adding support for EnhancedKeyUsage. WebLogic Server can now accept Certificates with Enhanced Keyusage set to critical.

CR126837

There was a problem getting a list of users through the listGroupMembers implementation used by the iPlanetAuthenticator MBean. Specifically, the listGroupMembers() method returned an empty cursor.

This was resolved by changing the default value of the StaticMemberDNAttribute to "uniquemember".

CR137523

If a user was defined while the File realm was calling the refresh() method, synchronization problems with the user table occurred.

The File realm has been improved so that exceptions are no longer thrown when defining a user while the File realm is performing a refresh.

CR180972

Performance of outbound SSL connections was slowed compared to JSSE because WebLogic Server created a new SSLSocketFactory for each outbound request.

WebLogic Server now caches the SSLSocketFactory when there is no certificate for the request.

CR182860, CR187047, CR194416, CR214190, CR214191, CR214192

When Web browsers sent plain text through the secure port, SSL misunderstood the message header and waited for more data before finishing the message. This delay caused problems with the SSL handshake. The server was using 100%of its CPU usage trying to complete the SSL handshake. This problem was caused by an arithmetic error on the number of bytes read.

This arithmetic problem has been solved. Clients that send plaintext messages to the secure port now receive errors earlier and the server will not hang because of 100% CPU utilization.

CR185438

Connections to external LDAP servers were sometimes dropped if a load balancer or firewall was configured between WebLogic Server and the external LDAP Server.

WebLogic Server now automatically refreshes the connections if they are dropped and user requests complete if the connection is dropped during the request.

CR186916

Two aspects of SubjectUtils.isUserInGroup were problematic.

• Getting only Principals of a specific class required evaluating each Principal while building a set of Principals, then iterating through them to find if any Principal was in the group being searched for. This problem effectively caused two iterations through the Principals when one could b e used to get all Principals of the Subject and then iterating for the group name.

• Getting an AuthenticatedSubject from the javax.security.auth.Subject interface and searching for the Subject in a group could not be done unless the Subject had been authenticated. This problem meant additional cycles to authenticate the Subject and determine to which groups the Subject belonged.

RESOLUTION:

All Principals are now gotten from the Subject and are iterated through once looking for the specified WLSGroup.

A second method has been added with an AuthenticatedSubject as the first parameter. Both public isUserInGroup () methods were changed to call an internal isUserInGroup ()method that works with a s ate of Principals rather than any Subject. This method eliminates the need for conversion from a Subject to an AuthenticatedSubject.

CR136414

WebLogic Server was unable to negotiate an SSL Handshake with an HTTPS URL connection to a site using the VeriSign Certificate.

This problem has been fixed.

CR161839

Synchronization in the TTL cache was not being handled properly thus causing an ArrayIndexOutofbounds exception.

Adding synchronization in the TTL cache resolved the issue.

CR177647

In certain cases, WebLogic Server was using its server certificate as a client certificate for the purpose of establishing two-way SSL communication.

A change in the code has fixed the problem.

CR186439

When a domain with a cluster is started through the Administration Console, the locking mechanism for the LDAP server is now working properly. As a result, Managed Servers are no longer hanging during startup.

CR189238

When ServletAuthentication.weak was used for authentication, WebLogic Server threw a NoSuchElement exception when the username and password were entered.

To resolve the issue, InvalidLogin was modified so that the size is checked before elements are returned.

CR194315

A refresh of the File realm could potentially cause a NullPointer exception.

The code modifications have eliminated this issue. NullPointer exceptions no longer occur when the File realm is refreshed.

CR178854

Some of the demonstration certificates and trusted CA certificates shipped in previous service packs of WebLogic Server 7.0 expired on May 14, 2004, or will not work with the Basic Constraints feature. WebLogic Server 7.0 service pack 2 included updated trusted CA certificates that work with the Basic Constraints feature. The certificates (democert.pem, democert1024.pem ca.pem, ca1024.pem, trusted.crt, demo.crt) are provided as files.

If you are using a previous service pack of WebLogic Server 7.0 that contains expired trusted CA certificates, or demo certificates that do not work with the Basic Constraints feature, please see http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp for more information.

CR189285

When using the iPlanet LDAP Authentication provider, WebLogic Server maintains a pool of connections to the iPlanet LDAP server. These connections are actually connections to Big IP. Big IP is configured to close idle connection at regular intervals.

In some cases, WebLogic Server would issue a query or command to the iPlanet LDAP server on a connection that Big IP closed. However, WebLogic Server did not produce an exception that detailed the problem.

Now, if there are problems with connections to the iPlanet LDAP server, the LDAP server throws an exception that is propagated to the web tier. As a result, WebLogic Server now throws an exception message with the proper information.

CR205373

If a connection in the LDAP connection pool was invalid, an authenticate for the user was failing and a LoginException was being returned.

Now, after a failed login with an existing LDAP connection from the connection pool, WebLogic Server creates a new connection in the pool and uses that connection. As a result, user requests no longer fail due to the LDAP connection timing out.

CR210229

Calling the ServletAuthentication.weak() method no longer results in an EmptyStack exception.

CR194073

Now, WebLogic Server processes the extendedkeyusage extension only when it is marked critical. As a result, WebLogic Server no longer throws a BAD_CERTIFICATE exception on the server side during two-way SSL communication.

CR045135

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-65.00.jsp.

CR125592 CR196597

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-66.00.jsp.

CR127930 CR107359

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

CR128940

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp.

CR157157

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-71.00.jsp.

CR171885

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

CR172187

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-69.00.jsp.

CR175310

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

CR175966

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-72.00.jsp.

CR128940

Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp.

CR120545

While configuring a custom xml parser in weblogic-applicaiton.xml, WebLogic Server no longer throws a Null Pointer Exception.

CR121297

WebLogic Server now forwards the error pages with the proper user.

CR112793

If the client dropped the connection, WebLogic Server was not processing the request any further.

A system property, ProxyForConnectionResets, was added to WebLogic Server. By default it is set to false. When ProxyForConnectionResets is set to true, HttpClusterServlet will continue processing the request even if the client has broken the connection at some time during the processing.

As a result, WebLogic Server processes requests even if the client drops the connection.

CR106348, CR125989

A failure in the listener left the Web Application in an unstable (deployed) state instead of undeploying the Web Application.

When the listener fails (deployment is not completely successful), the Web Application deployment is rolled back.

CR134351

The flag, weblogic.http.client.defaultReadTimeout, has been introduced to set the default readtimeout on WebLogic Server's HttpURLConnection.

When this flag is set, every new HttpURLConnection created on the JVM will have this value set as default. The value can be overridden by setTimeout or setReadTimeout calls on the specific connection. When this flag is not used, the default value is -1. The value should be provided in milliSeconds.

CR132447

If there is a cookie in a header that contains the SESSIONID name as a substring, the SESSIONID was unexpectedly being changed.

This problem was resolved by correcting the logic in parsing SESSIONID from the cookie header.

Due to this new change, no new SESSIONID is created when there is an existing SESSIONID or an existing session.

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.

CR128519, CR132321, CR130021

A ClassCastException occurred when using HttpProxyServlet with a Wrapped Response from a Servlet filter.

A code fix ensures getting the original response in case of a Response Wrapper.

CR175651

A NullPointerException was being thrown when calling the RequestProcessor.getServletContext() method in a Struts-based application.

To fix this problem, a system property, weblogic.http.requestCompletionTimeoutSecs, was added to WebLogic Server in the startup script file. The value given to this flag indicates the number of seconds for the container to wait before finishing all of the inflight work. The default value is 0 seconds, so the container does not wait if the flag is not present.

The servlet container waits for the number of seconds specified in the value of this flag before it deploys or undeploys any web application.

CR184726

Clients that post a request that gets forwarded no longer lose the parameters when weblogic.httpd.inputCharset is set.

CR176941

The GenericProxyServlet.readStatus fails intermittently. This problem occurs if GenericProxyServlet reuses the connection that had already been closed by a backend server.

This was resolved with a code fix to retry the same request when encountering the half-open socket exception and filtering out the connection header.

CR172672

When HttpClusterServlet tried to reuse a recycled connection that WebLogic Server had already closed, it would get a SocketException and mark the WebLogic Server as BAD.

Now, if HttpClusterServlet gets a SocketException when using a recycled connection, it will make another attempt to connect to the same WebLogic Server with a new connection.

CR195698

Replacing the old WAR modules with new ones in the external_stage area was causing a 404 error.

This problem was resolved by staging the actual application in the temp folder.

CR200450

Locale variants passed by the browser were causing unexpected results in validation rules in Weblogic Server. The locale header parsing logic was not considering the variant part of it.

Now, WebLogic Server considers the locale variant while parsing the language header. The language header can be in the following format:

lang-country-variant;q=weight

CR207481

If the incoming JSP request URI was transformed in the filter, the web container was generating duplicate JSPStubs for the same transformed URI, and therefore leaking memory. A code change fixed the problem such that the web container no longer creates duplicate JSPStubs.

CR188237

The issue with using custom output streams in the HttpServletReponse object when using HttpClusterServlet has been fixed. Now, clients can use custom OuputStreams in the HttpServletReponse object.

CR172214

WebLogic Server was undeploying a Web Application from the default HttpServer even if it was not deployed on the default HttpServer.

Now, WebLogic Server undeploys the Web Application from the default HttpServer only if it is deployed on that HttpServer.

CR209387

Now, HTTPURLConnection makes an HTTP call only once (instead of twice) when making the call from a Java Client if the setTimeout() method is used in the Java Client.

CR211410

ChunkUtils.is2chunk is no longer stuck in an infinite loop. WebLogic Server performance has been improved as a result.

CR188953

JSP pages no longer hang when multiple users access a page cached using the weblogic.cache.filter.CacheFilter.

CR129064

Now, when an HTTP request is sent through the iPlanet plug-in, WebLogic Server is no longer incorrectly setting the dynamic server list to WebLogic Cluster 2.

CR109689, CR103678

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.

CR127391

The SOAP HTTP Binding states that when an Exception occurs within a WebService, the server should throw a HTTP 500 "Internal Server Error", with a SOAP Fault response representing the exception.

Many WebService clients use URLConnection in order to make the HttpConnection to the WebService. Weblogic Server overrode the java.net.HttpURLConnection with a different version. WebLogic's version threw an exception from the getInputStream method if the status code was >= 400.

Since the exception was thrown there was no way for the WebService client to retrieve the inputstream, and thus it violated the Http SOAP Binding Specification.

WebLogic Server now retrieves the inputstream upon a 500 error.

CR181695

Autotype was not handling inheritance correctly. The derived type did not extend the base type in the types.xml file.

The inheritance for autotype has been added so that autotype is now handling inheritance correctly.

CR182069

Setting typeMappingFile with autotype did not work as expected.

The problem has been fixed. Autotype now picks up the existing types from typeMappingFile.

CR175471

CR175536

Accessing an external web service via an outbound proxy server (iPlanet Web Proxy Server) returned a SOAP fault. This occurred because using http and https to invoke a remote web service through proxy server with proxy authentication turned on was not allowed.

A code change was made to allow http and https tunneling through a proxy server for a web service client.

CR177611

There was a namespace problem in web-service.xml when servicegen used the type mapping file generated by autotype.

servicegen now recognizes namespaces in the type mapping file generated by autotype.

CR183555

JAX-RPC clients did not maintain session stickiness using the SESSION_MAINTAIN_PROPERTY.

WebLogic Server now supports session stickiness if SESSION_MAINTAIN_PROPERTY is set as follows:

On the Call object:

call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, "true"); or call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, new Boolean("true"));

On the Stub object:

(Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, "true"); or (Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, new Boolean("true"));

CR186319

When the number of contiguous white spaces in an xml file exceeded 32, WebLogic Server required a long time to parse the file.

WebLogic Server now has a larger buffer size and parses xml files more efficiently.

CR197698

As a result of a client-side patch, webservice HTTPS client no longer fails with a java.net.UnknownHostException: null.

CR185173

When calling into a WebLogic Server 7.0.2 web service from a WebLogic Server 6.1.4 dynamic client, running the webserviceclient+ssl.jar file through the VersionMaker utility, and then using the modified jar file in the WebLogic Server 6.1.x environment, WebLogic Server no longer throws a java.lang.NoClassDefFoundError.

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.

CR136608

XA.End needs to be called before sending response to Tuxedo in WTC. WTC was sending a response to Tuxedo for TP/TPA calls before calling XA.End. This resulted in a race condition that could cause an XA.Start on the original thread to begin prior to XA.End being called.

The solution now cleans all success and failure response paths and ensures that XA.end is called before sending any response back to Tuxedo.

CR172581

The following WTC FML methods in WebLogic Server 7.0 offer degraded performance as compared with the same functions executed under WLS 8.1. These functions include:

• TypedFML32._tmpostrecv()

• Fget()

• Foccurs()

• Fadd()

These methods have been backported from WebLogic Server 8.1 to WebLogic Server 7.0 sp6.

CR175113

Thread starvation was causing a decrease in throughput. For an incoming request, WTC spawns a delegate thread that creates an object of type InboundEJBRequest and spawns another thread to execute that object. The threads are executed from the 'default' execute queue. If the EJB application that was executed by the InboundEJBRequest was slow compared to the rate at which input requests were arriving (from the remote Tuxedo domain), thread starvation could occur resulting in a backlog in `default' execute request first and then a loss of input requests.

The slow executing EJB application can now be executed in a dedicated thread pool. WTCService recognizes an execute queue named `weblogic.wtc.applicationQueue' as a dedicated queue for executing WTC applications. If it is not preconfigured and if a system property `weblogic.wtc.applicationQueueSize' is found to be set, this queue is created (during WTC boot period) explicitly.

CR177212

A NullPointerException was thrown for WTC request.

WTC now checks the return value of Utilities.xdr_decode_string before instantiating the StringBuffer.

CR179410

WTC did not clean up the old connection after reconnect. Tuxedo /Domain and WTC are connected with ON_STARTUP connection policy. If the machine on which the Tuxedo domain was running was down, when it is restored, WTC did not clean up the old connection.

Now, when the same remote domain receives a new connection, the old connection is dropped.

CR120545

While configuring a custom xml parser in weblogic-applicaiton.xml, WebLogic Server no longer throws a NullPointerException.

CR135726

When WebLogic Server is unable to handle a given schema construct, it is mapped to SOAPElement.

When this occurred, autotype gave no indication that it had encountered an un-supported schema construct and only examination of the generated classes showed that something had gone wrong.

CR091775

The Dispatch Policy can now be configured from the Administration Console. To configure this attribute, select 'Edit Webapp Descriptor' and the in the new window, select Webapp Ext. The Dispatch Policy attribute appears on the right.

CR126506

Users could not configure a console extension to replace the policy definition pages.

Code was added to enable the CreateResourcesAction to look for an extension before forwarding.

CR132700, CR135127, CR174568

The getParameter() method in GraphApplet is used to get the value of the min/max heap size. WebLogic Server was using Integer.parseInt to convert the string values, and this parsing failed for numbers over 2G, resulting in incorrect values being displayed in the applet-weblogic.management.console.applets.GraphApplet on the Monitoring -> Performance tab.

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

CR100745

The deploy tab of a Web application showed that the application was deployed to the virtual host, which was true, and to the target of the virtual host, which was not true. A code change resolved the problem.

CR128510

The readClassDescriptor() of MsgAbbrevInputStream tried to resolve the class, leading to ClassNotFoundException for unknown classes. Java serialization skipped this ClassNotFoundException if corresponding data was not being read.

The MsgAbbreveInputStream readClassDescriptor() no longer tries to resolve the class, and MsgAbbrevInputStream now implements resolveClass().

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.

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.

The problem was solved with a code fix.

CR107471, CR128979, CR136731

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 plug-in.

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 were killed in that order, the client gave 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 were restarted, the load balancing algorithm switched to round-robin. Analysis revealed that the replica list was 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.

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.

CR125966

A server instance served a replication request while it was being shut down, resulting in a ClassCastException during syncSession, because the Web container was trying to typecast the ReplicatedSessionContext to MemorySessionContext.

Following a code change, a server instance can no longer serve a replication request when it is being shut down.

CR129234

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 this by passing the sessionId instead of ROID.

CR127849

On non-homogeneous unbinds and rebinds on cluster nodes, the server sometimes sent an uninitialized Remote Reference back to the client, resulting in an AssertionError.

The problem was resolved by a code change that ensures that the primary representative is set to null on unbind.

CR112326

A memory leak occurred with weblogic.cluster.BasicServiceOffer during JNDI rebinds of replicable objects. The problem was resolved with a code correction.

CR116954

When HttpClusterServet sent a dummy request "/WLDummyInitJVMIDs" to get a cluster server list in the response header when there was no default Web application deployed, WebLogic Server logged a debug message like the following:

####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <foo> <ms1foo> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1foo) found no context for "/WLDummyInitJVMIDs". This request does not match the context path for any installed web applications and there is no default web application configured.>

A code change has resolved the problem.

CR121113

HttpClusterServlet did not print thread name in error messages, making it difficult to diagnose the problem when an error occurred.

A code change was made to GenericProxyServlet.trace() to include the thread name in logged error messages to aid in troubleshooting.

CR127643, CR129319

When a dynamic proxy that implemented interfaces declared inside a Web application was put into the HttpSession and the session was replicable, WebLogic Server was not able to load the interface classes on the secondary server.

To correctly resolve the dynamic proxy, the secondary server needs the name of the application where the interface resides. An annotateProxyClass was implemented in MsgAbbrevOutputStream to write the applicationName in the stream. On the receiving side, resolveProxyClass uses this application name to load the interface classes from the application.

As a result of this change, dynamic proxies (implementing interfaces stored in the application archive) can be put into the HttpSession and be correctly replicated. There should be no side effects.

CR131745

For Resource Adapters that specify transaction support of LocalTransaction, the transaction state for a connection was not being reset before being released back to the pool of available connections. If another thread picked up the thread immediately and tried to use it, it could result in the connection not being enlisted and shared properly.

Following a code change, the transaction state is now immediately reset when the transaction is complete, which will occur before the connection is returned to the available pool.

CR131692

In 7.0, the shutdown process did not discriminate between application level threads and threads performing work for the WebLogic Server infrastructure. Refusing requests for new connections resulted in unwanted WebLogic Server behavior.

Some examples include: the Node Manager attempted to restart the server being shut down, session replication for current sessions failed, and the console reported that the server was in an unknown state.

Code was added to assist the server in a graceful shutdown.

CR125245

The java.lang.LinkageError: duplicate class definition: error sometimes occurred when multiple threads attempted to load the same class in a Web application while PreferWebInfClasses was enabled. This problem occurred the first time the classes were loaded.

A code change to synchronize the loadClass method of ChangeAwareClassloader resolved this problem.

CR103999

In some WebLogic Server installations the error "Unrecognized property: webservice.client.ssl.strictcertchecking" appeared. This error resulted from the inability of the installation to find the system property passed in its list of properties. The error message did not signify that the property was not taking effect, and as the property has been added to the properties list, the message should no longer appear.

CR103032

The Administration Console was updated to allow the user to edit the 'Allow Remove During Transaction' attribute for stateful session beans.

CR100705

There was an Administration Server dependency in the SecurityConfigurationMBean causing a failure in SecurityConfigurationMBean.findDefaultRealm() if the Administration Server was down.

This was corrected by providing a mechanism to invoke operations on a local MBean server when the Administration Server is unavailable.

CR100373, CR130592

The logic to determine the type of J2EE-module did not use the local or staged copy of the application for Managed Servers. This problem surfaced in the MSI mode as a result of the server's inability to determine the J2EE-module type.

stagingLocation is used to determine the type of J2EE-module if the original path does not exist in the config.xml file of the Managed Server.

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.

CR130352

The WLServer ant task, backported from WebLogic Server 8.1 to 7.0 in Service Pack 4, sometimes created a config.xml file without the specified properties.

Analysis revealed that WLServer never explicitly called saveDomain, which writes MBean changes to config.xml. Instead, it relied on the trigger calling saveDomain. The problem was that WLServer started and shut down a server so quickly that sometimes the trigger did not happen in time.

This problem has been resolved by putting a saveDomain call into the WLServer ant task to force the config.xml to be written out before the server is shut down.

CR129002

WebLogic Server allows the configuration of JMS Distributed Destinations from the Administration Console even if the user does not configure any members for the distributed destinations. The server failed to reboot, however, when this configuration was invalid.

Following a relaxation of legal checks in JMSLegalHelper, if a distributed destination is configured but members are not assigned, the server is no longer made unbootable.

CR128648

The weblogic.deployer WLConfig task was swallowing all IllegalArgumentExceptions, which caused build failures related to the encrypted system password functionality.

The problem was resolved with a code fix.

CR128445

weblogic.Admin set the username and password for the ServerStartMbean each time it was used in a server instance. If a user attempted this it would fail without permissions to WRITE attributes.

The problem was resolved with a code change that caused WRITE attributes not to be set on ServerStart.

CR126280

Rebooting the Administration Server caused a domain administration port exception.

Code was added to the RMI boot service to check the MSI mode. This eliminated the exception.

CR125309

An incorrect return code status was returned from weblogic.Admin SHUTDOWN or FORCESHUTDOWN.

Code was added to correct the return status from weblogic.Admin SHUTDOWN or FORCESHUTDOWN.

Note: Applications relying on the incorrect status code may need to be re-written.

CR125285

FileDistributionServlet should return after calling the sendError()method.

Code was added to return from all methods in FileDistributionServlet after sendError(), if that is not the last thing it does in a method.

CR125018

Certain common proxy operations were not happening on the local server where they should have been executed.

Code was added to ensure that userLockoutManager calls are local by implementing a map of local calls. UserLockoutManager now returns the information for the local server, rather than for the Administration Server.

CR093109

Killing an entire WebLogic Server domain killed the Administration Server, instead of killing only the Managed Servers. This problem was solved with a code fix.

CR094219

Server and domain logging did not work as expected, in the following ways:

The domain log file failed to rotate despite being configured to rotate by time.

The "Limit Log Files" option did not work properly with SimpleDateNamed log files.

A code change has corrected these issues, enforcing the log fileCount restrictions when using SimpleDateFormat to name log files.

CR094410

When DebugHttp was activated in ServerDebugMBean, WebLogic Server reported SocketResetExceptions as errors, rather than as simple debug messages. To address this problem, logMuxableSocketResetException() was added to the message catalog for reporting this debug message.

CR098578

Bootstrap servlet was returning SUCCESS status for the Administration Server when it was not actually fully up or was not in the RUNNING state.

Following a code change, the Bootstrap servlet now attempts to get the ServerRuntime MBean of the Administration Server and checks its status to make sure the server is in RUNNING mode before returning a successful status.

Managed Servers attempting to boot and contact the Administration Server will now return "Booted in MSI mode" if the Administration Server is not in the RUNNING state when the Managed Server is booted.

CR098607, CR136879

In a situation in which Application A is using Application B, while looking up Application B, the J2EE container of Application A creates a DependencyClassLoader by attaching Application B's ClassFinder to it. On redeployment of Application B, Application B encounters a new ClassFinder and its old ClassFinder is no longer valid. On a client request, the server attempts to use the old DependencyClassLoader and throws an exception.

The behavior that caused the exception has been changed: WebLogic Server no longer uses DependencyClassLoader for loading impl class from ReplicaAwareRemoteObject.getPrimaryRepresentative().

CR104269

If you configured a new customer authenticator in the Administration Console, setting the control flag and the default authenticator's control flag both to SUFFICIENT, then restarted the server, then used the set attribute command, and then restarted the server again, you received a security error message and were not allowed to start the server.

The problem has been resolved with a code fix.

CR105338

WebLogic Server stopped logging, on both Administration Server and Managed Servers, when the maximum number of files was reached.

After the following error messages were printed out to the domain log file, the server logging service shut down.

####<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 occurred, all log messages were not printed out to the server log file.

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. Because it assumed that the file that had the latest time stamp was the latest index, it did not check whether a file with the index name 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 resolved with code fixes.

CR105516

In previous WebLogic Server 7.0 service packs, stateful session EJB failover did not work when multiple failovers were required.

The following call sequence with the same browser window led to a java.rmi.ConnectException when only one node of the cluster survived:

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 is successful. After this EJB call again the remote is stored in the HTTP session.

5. Kill node2 .

6. Make a call to node3 and get the EJB remote from HTTP session.

WebLogic Server tried to look up the EJB on node2 and did not try to use node3. The following exception was 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.

CR106957

In earlier service packs of WebLogic Server 7.0, 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 Windows, 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.

CR108727

In previous service packs of WebLogic Server 7.0, 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 the 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.

CR109307

Previously you could not bring up an SP2 Managed Server in an SP3 domain. A code change has brought the different service packs into compatibility and into accord with the WebLogic Server compatibility statement: "Servers within an Administrative domain can be at different Service Pack levels as long as the Administration Server is at the same Service Pack Level or higher than its Managed Servers."

CR109391, CR123398, CR174565

In previous service packs, WebLogic Server attempted to deserialize even nonserializable objects if they were put in the ServletContext, resulting in NotSerializableException.

Non-serializable objects are no longer deserialized in ServletContext.

CR109688, CR135235

Under certain conditions a simple Java client looking up InitialContext would receive a bogus "No version information" error.

The problem was that line breaks in the header buffer were marked by "\n" instead of by the line.separator property. A code change corrected the problem.

CR110233, CR121682

Server instances running in production mode inappropriately checked the \applications folder and created entries in temp files recording such checks. In development mode an application automatically gets undeployed and redeployed in the \applications folder at server start time.

A code fix has resolved the problem.

CR111239

Lost JMS connections were not being cleaned up. The clients (topic subscribers) were running on a different machine than the JMS server. When the customer's network connection between a client and the server was lost, after closure and reestablishment of the subscriber, the session, and the connection the Administration Console showed that the first subscriber was not removed—the console showed two subscribers. When the <MessagesMaximum> value for the Connection Factory is reached, the 'messages pending' value increases with each new message published.

Analysis revealed that due to the network outage the client's peerGone message did not reach reached the server instance. After declaring peergone the client tried to reconnect to the server instance, which replaced the old connection with the new one without declaring a peerGone on the old rjvm, thus causing the JMS objects to remain in memory.

The problem was corrected with a code change that causes the server, when detecting a duplicate connection from the same client for the same protocol, to declare peerGone on the old rjvm and construct a new rjvm and a new ConnectionManager for the new connection.

CR116707

WebLogic Server provided a ReplicaAwareRemoteRef warning log when you used certain Factory/Trader patterns, displaying the following on the client side:

[ReplicaAwareRemoteRef] : WARNING: client-side RA stub didn't find environment on thread

Following a code change, the inappropriate log is no longer printed to the client.

CR116712

In previous service packs, the WLECConnectionRuntime MBeans were not updated when an INVOKE was issued on WLECConnectionPoolRuntime using the 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.

CR120492, CR122551

To improve HTTP tunneling performance, a code change has set the content length for tunneled responses to maintain keep-alive connections, and has also enabled caching HTTP URL connections.

CR121801

The wlconfig tool, introduced in WebLogic Server 8.1, is available in 7.0 starting with Service Pack 5.

CR134971

When <<no stack trace available>> was sent out as part of the exception message field (from the server side), the 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.

CR122112

When calls were made to an EJB using the weblogic.management.timer.Timer class, the following exception was thrown upon lookup of the EJB's home interface:

java.lang.ClassCastException: Cannot narrow remote object to examples.ejb20.timer.SourceDataHome at weblogic.iiop.PortableRemoteObjectDelegateImpl.narrow(PortableRemoteObjectDelegateImpl.java:200) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:132) at examples.ejb20.timer.webapp.TimerServlet.callEjb(TimerServlet.java:61) at examples.ejb20.timer.webapp.TimerServlet.access$000(TimerServlet.java:23) at examples.ejb20.timer.webapp.TimerServlet$MyNotificationListener.handleNotification(TimerServlet.java:81) at weblogic.time.common.internal.TimerListener$1.run(TimerListener.java:48) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:685) at weblogic.time.common.internal.TimerListener.deliverNotification(TimerListener.java:44) at weblogic.management.timer.Timer.deliverNotifications(Timer.java:382) at weblogic.time.common.internal.TimerNotification$1.run(TimerNotification.java:112) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:685) at weblogic.time.common.internal.TimerNotification.execute(TimerNotification.java:109) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)

Analysis revealed that WebLogic Server did not store the ContextClassLoader of the callee inside the Timer class. Therefore, the notification runs in a classloader which is different from the classloader in which the notification was added. This resulted in a ClassCastException.

The problem was solved by a code change to save the ContextClassLoader of the callee when the notification gets added. While delivering the notification event, the saved classloader is set as the contextClassLoader for the delivering ExecuteThread.

CR122361

The Auditing enabled message did not record the USER identity:

<Aug 29, 2003 12:31:25 AM EDT> <Info> <Configuration Audit> <159909> <Configuration Auditing is enabled>

This was inconsistent with the disable message, which did record the USER:

<Aug 29, 2003 12:31:31 AM EDT> <Info> <Configuration Audit> <159910> <USER system, Configuration Auditing is disabled>

Following a code change, both audit messages record the USER identity.

CR122706

A clustered Web application deployed on a cluster that called an EJB on another cluster threw an AssertionError. Analysis revealed that generated code was not using the right method while calculating methods in the interfaces, which resulted in using wrong classloader from the generated stub.

A code change resolved the problem.

CR122878

MBeans were being deleted by KernelID. As a result, no matter who initiated the delete operation, the Auditor recorded that the Kernel had deleted the MBean.

Following a code change, the MBean is deleted by the current Authenticated Subject.

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 and cause exceptions or hanging of 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.

CR129094, CR133591, CR135254, CR135255, CR124861, CR132275

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

CR135488

Previously, any file in the security provider directory (by default /lib/mbeantypes) was treated as a security provider and loaded at server boot time without regard to its file extension.

Beginning with WebLogic Server 7.0 Service Pack 5, only files that end in .jar or .zip are treated as security providers. Security providers that use other extensions will no longer load. If your domain uses alternate file extensions for security providers, change them for Service Pack 5.

CR110897, CR125329, CR129494

If you deployed an application and then unprepared it and then restarted the server, the server would throw the IllegalArgumentException.

Analysis revealed that the J2EE container did not take care of configured but not deployed applications during start up. They were identified as Deployed="false" in the <Application> stanza.

The J2EE container code has been modified to take care of this edge condition.

CR127393

The following memory leaks were identified:

1) A memory leak with EJB Objects. ClientRuntimeDescriptors of EO objects remained on the heap after an application was undeployed.

2) A memory leak with EJBCache in J2EEApplicationContainer. EJBCache objects were not being cleaned up after an application was undeployed.

3) A memory leak with runtime MBean in WebAppServletContext. Runtime MBeans specific to WebAppServletContexts are not being unregistered after undeploying an application.

4) A memory leak with Timer in KeepAliveCache. KeepAliveCache's timer object held an application-specific classloader.

5) A memory leak with ddMap in J2EEApplicationContainerFactory. Descriptor objects were not being unregistered after an application was undeployed.

6 A memory leak due to Introspector cache. Application-specific classes were being held by the Introspector caches after the undeploying of an application that uses Struts.

Code was added to perform the following functions:

1) Unexporting EO objects now removes the ClientRuntimeDescriptor objects associated with the EO objects on undeploying application.

2) Clear EJBCaches on undeploying application.

3) Unregister runtime MBeans specific to WebAppServletContext on undeploying application.

4) KeepAliveCache will initialize the timer before it comes to the context of an application.

5) Clear deployment descriptors on undeploying an application.

6) Flush Introspector caches on undeploying an application.

CR136176

Setting LoadBeforeAppActivation="true" resulted in the StartupClass being invoked twice.

Code was added to make the server ignore cases which are not applicable to PostDeploymentStartupClass

CR102296

A boolean attribute, LoadBeforeAppActivation, was added in StartupClassMBean so that there are three distinct settings for the order in which startup classes are deployed:

Default: After a server instance deploys JMS and JDBC services, EJBs, and applications.

LoadBeforeAppActivation=true: After a server instance deploys JMS and JDBC services and before it deploys EJBs and applications.

LoadBeforeAppDeployment=true: Before a server instance deploys JMS and JDBC services, EJBs, and applications.

CR109645

When an application was configured for the second time after deletion, components within the application did not have the correct targets. Changes to the admin MBean were not being propagated to the config MBeans.

When updating the config MBeans, if the target is a cluster, WebLogic Server now gets the servers in the cluster and for each server builds the objectname for the config MBean based on the server name and then updates it.

CR111065

In certain instances, the delta list of deployment tasks was being created from the SlaveDeployer initialization.

A code fix ensures that the MasterDeployer is always used for creating the deployment task deltas.

CR134122, CR134119

The StatefulEJBObject.remove() call was unexporting an EJB object even if there was no permission for that method.

This problem has been resolved with a code change.

CR128932

The Administration Console reported that an application targeted to a cluster, one of whose Managed Servers was gracefully shut down, was not deployed.

A code change has resolved the problem.

CR127334, CR133975

A memory leak occurred when EOImpl instances of the EJB were not garbage-collected when remove() was called on an already passivated and deleted EJB.

A code change has resolved the issue.

CR132510

A collection valued cmr-field was accessed in a different transaction from the one in which it was created.

Code was added to check if the current transaction is the same as the transaction in which the generated oneToManySet was created (createTx). If it is not, then set the createTx on the oneToManySet to the current transaction.

CR131848

A ClassCastException was thrown at runtime when "cache-between-transactions" is set to true for a BMP bean.java.rmi.RemoteException: EJB.

A check for BMP and CMP20 beans was added to prevent the ClassCastException.

CR103038

When Allow Remove During Transaction was set to "False," and an application attempted to remove a stateful session bean during a transaction, an inaccurate error message appeared.

weblogic.ejb20.locks.LockTimedOutException is not the exception called for in the EJB 2.0 specification, and it has been replaced with the exception required:

javax.ejb.RemoveException

CR132853, CR128980, CR135722

When a Message Driven Bean uses the synchronous message polling scheme and the Sonic JMS server is used, the message-driven bean container's polling optimizations could result in a delay in the message receiving.

To avoid this problem, do not use the optimized poller. As the Sonic message delivery scheme does not work well with this scheme, use a poller that continuously polls the Sonic JMS server.

This new Message Driven Bean behavior is applicable to TIBCO and Sonic JMS providers only.

CR133602

WebLogic Server uses a special handling code for SonicMQ 4.* version, when XAconnections are used. This code was not required for Sonic 5.* version. For this reason, a connection leak occurred.

Avoid the use of special code for Sonic 5.* version inside the WebLogic Server MDB container.

CR133774

The following part of the description for the max-beans-in-cache element in the weblogic-application.xml DTD was incorrect: If 0 is specified, then there is no limit for max-beans-in-cache. A max-beans-in-cache size of 0, would actually set the actual size of the cache to 0, thus causing a CacheFullException.

The above note has been removed from the DTD. Also, a compliance check has been added to not allow a value of 0 to be set for the max-beans-in-cache in the weblogic-application.xml. If you need to set a large size (infinite) for your cache, you can set so by setting the value of the max-beans-in-cache to java.lang.Long.MAX_VALUE in the DDs. This makes it compliant with the behavior of the same element in the weblogic-ejb-jar.xml.

CR126413

A CMP bean threw a ClassCastException while persisting a blob/clob cmp-field to the database when using WebLogic JDriver (type 2).

Code was added to handle casting of LOBs (Blob & Clob) for both Oracle type4 and WebLogic type2 drivers.

CR129185

WebLogic Server loaded optimistic-concurrency beans in a separate transaction, suspending the current transaction, starting a new one, loading the bean and resuming the old transaction for all databases except Oracle, to avoid acquiring locks during the SELECT. Since the default behavior in Sybase is for a a shared-lock to be acquired during the SELECT but released even before the statement has completed the statement, the loading behavior has been changed: When the concurrency-strategy is optimistic, WebLogic Server now suspends and resumes the transaction for databases other than Oracle only if the isolation-level is higher than Read-Uncommitted or Read-Committed.

CR127397

Entity beans use ActivatableServerRef to call activate to get the bean instance. After invoking the bean method, ActivatableServerRef calls deactivate to release the bean to the pool. The problem was that when a EJB was invoked from within the application, deactivate was not called and the bean was not released.

ActivatableServerRef now explicitly calls notifyRemoteCallBegin and notifyRemoteCallEnd.

CR127361

EJBReplacer did not consider remote objects and hence threw a NotSerializableException while passivating a bean that contained a remote object as a member variable.

Following a code change, EJBReplacer replaces the remote object as appropriate if the bean instance contains a remote object member variable.

CR079164

A less than useful deployment error message that the server displayed on an error setting up auto-pk generator table has been replaced with a more detailed one that gives the nested exception message with more clarity and details.

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 recompiled 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 timezone at compile time and using that timezone at deployment time to determine whether recompilation is necessary.

CR106136

In previous WebLogic Server 7.0 service packs, getter methods for an 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 transactions with the 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 until the transaction committed.

ejbStore is now called from postInvoke(), depending on the result of the isModified method in the bean. This has resolved the problem.

CR108084

When a sender posted a JMS message, triggering a message-driven bean, if the MDB never obtained the data in the database it would drop the message. The problem was caused by a known Oracle XA limitation wherein an open resultset is invalidated by a suspended transaction.

A code change resolved the problem.

CR110917

An OutOfMemoryError occurred when the WebLogic Server stateful session bean example (examples.ejb20.basic.statefulSession) ran under heavy load.

The out-of-the-box configuration had been modified to set:

home-is-clusterable = true

replication-type = InMemory

The application archive was deployed to a cluster of two Managed Servers. A Java client performed these steps:

• Look up the home.

• Create an instance of the EJB.

• Call the buy and sell methods.

• Invoke the remove method on the EJB.

Loading the cluster with such requests resulted in the out-of-memory condition. When the client actions were stopped, the server instance did not recover—the console continued to report high heap usage.

Analysis revealed the secondary EJBObjects were not being unexported, resulting in a memory leak.

The problem was solved with a code change to unexport the secondary EJBObjects.

CR111551

In previous service packs of WebLogic Server 7.0, 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 7.0 SP05, server-side JDBC went through the RMI drive, to the pool driver, then on to the DBMS driver.

The problem was solved by correcting the EJBC to generate code that reflects the SP05 and later behavior. Starting in WebLogic Server 7.0 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.

CR111670

After an unsuccessful attempt to create a connectionPool—for instance, using an invalid URL or driver class—it was not possible to create the pool successfully.

This problem occurred because the connectionPool MBean was created before the connectionPool was created, regardless of whether the connectionPool was successfully created. Subsequent attempts to create a pool failed during the attempt to create a second MBean of the same type.

The problem was solved by modifying the JDBCService to delete the associated MBean if an exception creating a connectionPool.

CR112074

When an update call followed by a remove call was performed on a container-managed relationship in a business method, ejbStore was invoked in the middle of the transaction.

The extra ejbStore occurred because the flushModifiedBeans() method was called inside the BaseEntityManager.caseDeleteRemove() method.

The problem was solved with a code change to ensure that the flushModifiedBeans() method is called on for cascade deletes.

CR112558

Failover did not work for a stateful session bean in a cluster with the following exception.

Start server side stack trace:
java.rmi.NoSuchObjectException: Unable to locate EJBHome:
'de.roland24.common.system.session.BackendSessionHome' on
server:
't3://192.168.201.52:0
at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(Home
HandleImpl.java:78)
at
weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.
java:188)
at
weblogic.servlet.internal.session.SessionData.getAttribute(
SessionData.java:426)

A code change solved the problem.

CR112265

The following exception is no longer received when container-managed persistence EJBs are built using EJBGEN tags:

<Jul 17, 2003 2:49:20 PM MDT> <Info> <EJB> <010097> <Exception
during the invocation of EJB "Customer(Application:
classproject, EJBComponent: xpersistence_ejb. jar)" with
primary key "[CustomerPK
guidStr:4E9A50DD-8E1B-F2B5-24E7-860ADE3BE707 ]":
java.lang.NullPointerException at
com.zbc.las.commercial.persistence.test.CustomerPK.hashCode(
CustomerPK.java:24)
at
com.zbc.las.commercial.persistence.test.CustomerPK.equals(
CustomerPK.java:32) at
com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__
WebLogic_CMP_RDBMS_customerOrders_Set.add(CustomerBean_b3dzi6_
_WebLogic_CMP_RDBMS_customerOrders_Set.java:289) at
com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__
WebLogic_CMP_RDBMS_customerOrders_Set.addAll(CustomerBean_
b3dzi6__WebLogic_CMP_RDBMS_customerOrders_Set.java:328) at
com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__
WebLogic_CMP_RDBMS.setCustomerOrders(CustomerBean_b3dzi6__
WebLogic_CMP_RDBMS.java:672) at
com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6_
ELOImpl.setCustomerOrders(CustomerBean_b3dzi6_ELOImpl.java:
268) at java.lang.reflect.Method.invoke(Native Method) at
com.zbc.las.framework.core.persistence.EjbHelper.setRelations(EjbHelper.java:594) at
com.zbc.las.framework.core.persistence.EjbHelper.setRelations(EjbHelper.java:351) at
com.zbc.las.commercial.persistence.test.CustomerBean.
setOrders(CustomerBean.java:302) at ....

CR112703

The JMSConnectionPoller did not know the identity of the user that it required to get the remote username and password. This remote username and password is required for establishing a JMS connection with the remote JMS Server (MQ, WebLogic, and so on).

This fix resolves the problem, but customers need to configure a security identity for an MDB. For instructions on how to do this, see Configuring a Security Identity for Message-Driven Beans in Programming WebLogic Enterprise JavaBeans.

CR112838, CR112225

For BLOBs, in the generated code, WebLogic Server calls ObjectOutputStream.writeObject and ObjectInputStream.readObject to serialize or deserialize the object before writing or 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. These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because WebLogic Server uses readObject to convert the bytes into the appropriate object, which needs the 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.

<serialize-byte-array-to-oracle-blob> has been added to control the persistence behavior. This element is used to specify whether a cmp-field of type byte[] mapped to an OracleBlob should be serialized. The tag has been added to a new compatibility stanza in the weblogic-cmp-rdbms descriptor.

Note that, in versions prior to SP2, the default behavior was to serialize a cmp-field of type byte[] mapped to an OracleBlob. Now, the byte[] is written directly to the OutputStream obtained from the BLOB. To revert to the old behavior, set the value of this tag to true.

CR113161, CR12220, CR110917

A memory leak no longer occurs for a clusterable stateful EJB in the core of the server.

CR116696, CR121886

The setBytes() method on the preparedStatement had issues when the byte[] data was greater than 4K.

This problem was resolved by replacing the setBinaryStream() method with the setBytes() method. As a result, the cmp11 generated code has changed. Customers wanting to take advantage of this fix must rerun ejbc on their EJBs to generate the new code. Otherwise, this change will not have any impact.

CR120450

A java.lang.IndexOutOfBoundsException no longer occurs when a CMP-field and a CMR-field were mapped to the same column.

CR121378

In WebLogic Server 7.0 SP03, when using bean-managed persistence (BMP) EJBs, a ClassCastException occurred when trying to flushModified Beans using BMP beans.

<Aug 25, 2003 9:39:35 AM EDT> <Info> <EJB> <010040> <Exception
in ejbStore: java.lang.ClassCastException:
com.logica.mdch.morse.business.meterpoints.MeterPointXBean_
vm8ya9_Impl java.lang.ClassCastException:
com.logica.mdch.morse.business.meterpoints.MeterPointXBean_
vm8ya9_Impl at
weblogic.ejb20.manager.ExclusiveEntityManager.flushModified(
ExclusiveEntityM anager.java:693) at
weblogic.ejb20.internal.TxManager$TxListener.flushModified
Keys(TxManager.jav a:749) at
weblogic.ejb20.internal.TxManager.flushModifiedBeans(
TxManager.java:329) at
weblogic.ejb20.manager.BaseEntityManager.flushModifiedBeans(
BaseEntityManage r.java:1644) at [...]

Analysis revealed that the exception occurred when a BMP with exclusive concurrency that was involved in a transaction with other EJBs was synchronizing the modified beans with the database prior to before running any finder. ExclusiveEntityManger's flushModified code was not considering the BMP case, and was assuming container-managed persistence as the default.

The problem was resolved to avoid the ClasscastException. As a result of the change, the BMP EJB's ejbStore method may be called more than once in a transaction, when a finder is invoked on any bean with in the TX.

CR122052, CR110440, CR121949, CR132495

For an entity cache timeout with a combined (application level) cache, if the idle-timeout-seconds for one of the beans is set to 0, other beans with idle-timeout-seconds > 0 are also not removed from the cache after timeout.

A code change involving the registration of idle-timeout-seconds has resolved the problem.

CR123213

Stateless session beans were not returned to the free pool if they were invoked from the BMP ejbRemove. As a result, the pool reached maximum size and timed out while waiting to get an instance.

A code change resolved the problem.

CR095485

A COM object that closed during a load could result in sockets being left in a CLOSE_WAIT state.

The sockets now close on endOfStream.

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.

CR127460

For the WebLogic Server jDriver for Oracle versions 817, 901 and 920 with rmi_jndi and rmi_driver tiers, multiple ClassCastExceptions were thrown in connection with the closing of the JDBCHelper class.

A code change has resolved the problem.

CR126511

Oracle OCI NativeXA does not allow a connection to be used by threads other than the thread where it was created.

The WebLogic Server connection pooling algorithm assumed that a connection can be used by any thread. If you used Oracle OCI NativeXA with the previous WebLogic Server connection pooling algorithm, you received an XAException.

A code change backports the PinnedToThread connection pooling algorithm from WebLogic Server 8.1, allowing connections to be pinned to threads so that every thread can have its own connection for every connection pool.

CR108826

Current Multipool does not provide an option to define time based failover. We would like the exact condition under which failover will be triggered to a secondary connection pool. It would go through all the connections in the pool before it decides that it doesn't have any good connection.

In order to avoid network glitches, we'd like have time based option like if all you checks fail for 10 minutes then failover to primary Database. We also need a failback mechanism through which we can failback to the primary once primary is in normal state. For example we have our secondary in remote datacenter, so response time will be more when in running in remote, we can live with when the primary database is down, but not when primary is backup

So in summary, if my primary Database goes down, it needs to wait for xx time before my connection failover to secondary Database.

Once my primary database is available then it should not go back to primary again until I say so. Either we can have an option which says what to do or run time check when these flag is turned on go back to primary or something like that.

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.

CR127949, CR131743

Statement.getResultSet() sometimes generated an unnecessary new ResultSet wrapper.

A code change has resolved the problem.

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.

CR126808

When two applications with an application scoped datasource per application were deployed on the same server and the datasources have the same name, an InstanceAlreadyExistsException was thrown.

Code was added to configure the pool name to be application-specific when necessary.

CR133835

When statements or result sets that are not closed are garbage-collected, their finalize() method closes them if needed. A method that threw a useless exception if the connection had already been closed is no longer thrown.

CR099363

Under load testing, when the connection pool had refresh minutes set to 15 but the test connections on reserve and test connections on release set to false, the JDBC connection pool threw a weblogic.common.ResourceException: No available connections in pool exception. This occurred because when only a few of the connections in the pool are used, all the other connections in the pool were reserved for testing at the expiration of the configured refresh test minutes.

A code change implemented a new algorithm that resolved the situation.

CR103603

When calling DatabaseMetaData meta = dbCon.getMetaData();ResultSet rs = meta.getColumns(null,meta.getUserName(),"dual".toUpperCase(),"%");

in a user transaction or inside a transactional EJB, if the ResultSet was not explicitly closed when the connection is closed, then each subsequent call leaked an Oracle database cursor. The cursors are held until the server shuts down, creating a risk that the database will run out of cursors.

WebLogic Server now explicitly closes a ResultSet when it closes a connection.

CR108478

During a global transaction, when the client put a message into a JMS Queue and a database, the client looped repeatedly and then exited. If after this you restarted WebLogic Server following a crash (kill -9 or System.exit() ), when the client started a global transaction again, the following exception was thrown:

Unknown Exception during dataInsert java.sql.SQLException: XA error: XAER_PROTO

The addition of more robust error-handling code corrected the recovery behavior.

CR108826

In WebLogic Server 7.0SP5, the following enhancements were made to MultiPools:

• Connection request routing enhancements.

• Automatic failback on recovery of a failed connection pool.

• Failover for busy connection pools within a MultiPools.

• Failover and failback callbacks for MultiPools.

See MultiPool Failover Enhancements in Programming WebLogic JDBC for more details.

CR110486

Remote clients can now clear the JDB connection prepare statement cache.

Previously, objects of class weblogic.jdbc.rmi.SerialConnection did not implement WLConnection) so a remote client could not call the clearPrepareStatementCache() method.

This limitation was corrected with a code change.

CR112295

A DataSource for a MultiPool could be deployed to an Administration Server; however, attempts to deploy it to a Managed Server failed, resulting in this ResourceException:

weblogic.common.ResourceException: DataSource(multiDataSource) can't be created with non-existent Pool (connection or multi) (multiPool) at weblogic.jdbc.common.internal.DataSourceManager.createDataSource(DataSourceManager.java:251) at weblogic.jdbc.common.internal.DataSourceManager.createAndStartDataSource(DataSourceManager.java:106) at weblogic.jdbc.common.internal.JDBCService.addDeployment(JDBCService.java:190) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:330) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:590) at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:568) at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:240) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at ...

Analysis revealed that the exception occurred during the DataSourceManager.validateConnectionPool() method. The problem was resolved with a code change.

CR117729

With weblogic.JTAJDBC enabled, WebLogic Server prints out the driver vendor version as in the following:

<Aug 5, 2003 3:22:55 PM PDT> <Debug> <JDBC XA> <000000> < -tx:null- -pool:OracleThinXAPool- Vendor:Oracle 8.1.7 XA>

For Oracle, WebLogic Server printed the version as "Vendor:Oracle8.1.7 XA" regardless of the actual version.

A code change has resolved the problem.

CR120531, CR126189

In previous service packs of WebLogic Server 7.0, 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."

CR120971

The jts.Connection.getVendorConnection() method returned null when the vendor connection was obtained before the JTS connection had been used for a standard JDBC call. All standard calls established the underlying connection, but getVendorConnection() did not.

The problem was corrected with a code fix.

CR127891

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

CR131575, CR132652

WebLogic Server sometimes threw a bogus 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.

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.

CR129220

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

A code change resolved the problem.

CR113462

WebLogic Server 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.

CR135798

The messaging pipeline was not being managed correctly for transacted MDBs. Messages already in the pipeline were not bumped when new messages with higher priority arrived on the queue. Therefore, it was important to keep the message pipeline size to a minimum to get the desired behavior.

The code was modified to decrement the window count on acknowledge from a transacted MDB. The messaging pipeline for transacted MDBs will honor the MessagesMaximum setting.

CR110120

If you migrated a JMS server from one Managed Server to another, sent some messages, and then migrated the JMS server back to the first Managed Server, you saw exceptions like the following:

<Jun 23, 2003 4:18:49 PM EDT> <Error> <JMS> <040366> <JMS Distributed Destination member "S2_BE1_T1" in "DT1" unable to accept connection from remote member "S1_BE1_T1" due to exception weblogic.jms.common.JMSException: Failed to setup system subscription because destination S2_BE1_T1 is not avaiable (shutdown, suspended or deleted). <Jun 23, 2003 4:19:54 PM EDT> <Error> <JMS> <040366> <JMS Distributed Destination member "S1_BE1_T1" in "DT1" unable to accept connection from remote member "S2_BE1_T1" due to exception weblogic.jms.common.JMSException: Consumer already exists

Analysis revealed that while JMS internally binds more multiple WebLogic Server Aggregatable objects on a single server instance, WebLogic Server JNDI expected only one Aggregatable per server and as a result was replacing the first JMS Aggregatable with the second. WebLogic Server JNDI now provides an internal API for JMS to handle this situation so all objects are preserved.

CR132606

Messages Pending counters in console were incorrect for Distributed Topic members that were on the same WebLogic Server instance. Counters were correct for remote distributed topic members.

Code was changed to correctly managed the distributed topic reference count when forwarding to other non-remote distributed topic members.

The customer will no longer see unexpected messages pending for distributed topic members after all messages have been successfully received and acknowledged.

CR128596

Message flows sometimes stalled when messages were being sent over the bridge using distributed destinations from a 7.0 SP2 cluster to 8.1 SP2 cluster when one of the 8.1 SP2 cluster servers was bounced.

A code change resolved the problem.

CR127260

MessagingBridgeRuntime Means was not stopped by the weblogic.Admin utility command:

java weblogic.Admin -url t3://127.0.0.1:7001 -username weblogic -password weblogic INVOKE -type MessagingBridgeRuntime -method stop

The MessagingBridge start and stop methods now throw an informative exception about how to start and stop MessagingBridge at runtime.

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.

CR125693, CR092468

The legal minimum value of the flowMinimum attribute of the JMSConnectionFactoryMBean had been changed to 1 and so, to be consistent, the legal minimum value of the flowMaximum attribute was also changed to 1.

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.

CR103001, CR127436

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.

CR107729, CR113714, CR124985

A problem involving the accumulation of expired messages in a destination with no consumer has been resolved with a code change that adds support for active message expiration. This feature allows expired messages to be removed from a destination that does not have a consumer. To turn on the active message expiration, use the system property -Dweblogic.jms.ExpirationScanIntervalSecs="number of second(s)" between scan. Zero and negative numbers will disable the feature.

CR108665

The JMS server sometimes deleted expired paged-out messages from the persistent store, regardless of whether a queue browser might still have it in the reference list. As a result, enumeration operations sometimes ended due to paging IO exception even when more messages might still be available in the enumeration list.

A code change improved the handling of paging, and solved the problem.

CR111159

If JMS front-end and back-end are not co-located and the front-end FEProducerSendRequest gets a Failure/JMSException, later, when the FEProducerFiniteStateMachine is resumed in a different thread, it does not fail over.

Analysis revealed that if the producer load balancer selects a destination member, but the back-end throws an exception when attempting to add the message to the destination, the front-end did not properly handle the exception and select another distributed destination member for the send.

The problem was resolved by a code change to make sure the front-end producer catches the exception from the back-end and retries, selecting another available distributed destination member. If no other member is available the exception is returned to the sending application.

CR110991, CR117044

The JMSServerRuntimeMBean method getHealthState is no longer a public method.

CR112845

The JMS dispatcher was not able to handle a failover of a JMS send operation when the client and front end (the server where the JMS Connection Factory was targeted) were co-located and the JMS Distributed Destination Member was on a different VM.

A code change has resolved this problem.

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.

CR121011, CR131700

A NullPointerException resulted on restart of JMSServer, when the store contained a message that had a ReplyTo that was a Distributed Destination and was not in the same cluster as the store.

There were two WebLogic Server domains which used the MessagingBridge for inter-domain communication. The sending application set the JMSReplyTo field as a DistributedDestination on domain1, then the message traveled over the bridge and ended up in the JMSStore on domain2. Upon restart of the JMSServer in domain2, JMS attempts to locate the configMBeanName for the Distributed Destination member instance that was written to the store, but it cannot locate this name because it belongs to domain1. This is where the failure occurred. The log contained messages similar to:

####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hwbachp> <managed5_hwbwl98> <main> <kernel identity> <> <040108> <User connection factory "BridgeJMSnnn" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <nnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "Wnnn_JMSConnectionFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <nnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "nnnQueueFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hwbachp> <managed5_hwbwl98> <main> <kernel identity> <> <040108> <User connection factory "WLI_B2B_TopicFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hnnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "RNQueueFactory" is started.>

The problem was resolved with a code modification, so that if JMS cannot locate the configMBeanName, it uses the instance name to create a DestinationImpl (non-DD queue) for the replyTo field. The replyTo Queue is downgraded from a DistributedDestination to a normal destination for this scenario.

CHANGED BEHAVIOR: If the message is in the store on server restart a) which has a ReplyTo and b) this ReplyTo is not in the same cluster to which this store belongs and c) this replyTo is a Distributed Destination, then this replyTo will be plugged in as a normal Destination. Clients using this replyTo will not get LoadBalancing because the replyTo is downgraded from Distributed Destination to a normal destination because the configMBeanName cannot be found (from another cluster).

CR121041

A problem occurred with a Messaging Bridge between two JMS topics running in two Managed Servers in the same domain, running on the same machine. As the Messaging Bridge was being started during WebLogic Server startup, it threw the following warning message. Messages could not be forwarded.

####<Aug 20, 2003 12:49:11 PM MST> <Warning> <MessagingBridge> <slsol4.bea.com> <server2> <ExecuteThread: '10' for queue: 'de fault'> <kernel identity> <> <200026> <Bridge "Test Messaging Bridge" encountered some problems to one of its adapters or und erlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (Exception caught was ja va.lang.Exception: javax.resource.spi.IllegalStateException: Managed connection is closed at weblogic.jms.adapter.JMSManagedConnection.checkIfDestroyed(JMSManagedConnection.java:263) at weblogic.jms.adapter.JMSManagedConnection.sendEvent(JMSManagedConnection.java:231) at weblogic.jms.adapter.JMSBaseConnection.throwResourceException(JMSBaseConnection.java:1266) at ...

Analysis revealed that the bridge failed to create the message listener because it was configured for durable topics and there was no JMS store available. The Bridge encountered an internal error when trying to log the resource exception so the customer was not able to tell why the bridge was failing.

The problem was resolved by a code change to allow the bridge to throw the correct resource exception. Now, the correct exception is logged by the bridge.

<Aug 27, 2003 9:32:35 AM CDT> <Warning> <MessagingBridge> <200026> <Bridge "TopicBridge" encountered some problems to one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (Exception caught was java.lang.Exception: javax.resource.ResourceException: Error setting message listener . . .
. . .
-------------- Linked Exception ------------ javax.resource.ResourceException: Error creating asynchronous consumer or setting message listener . . .
. . .
-------------- Linked Exception 2 ------------ weblogic.jms.common.JMSException: No store for durable consumer . . .

CR121741

Inconsistent behavior occurred when shutting down the MQ-WLS bridge using MBeans. This excerpt is the code used for shutdown:

MessagingBridgeMBean bridge = (MessagingBridgeMBean)mbeanHome. getAdminMBean(bridgeName, "MessagingBridge"); bridge.setStarted(false); for(int i=0;i<serverList.length;i++) { target=(TargetMBean) mbeanHome.getAdminMBean(serverList[i],"Target"); bridge.removeTarget(target);

Sometimes the bridge was untargetted and shut down with the following exception:

<Aug 27, 2003 9:24:08 AM PDT> <Info> <MessagingBridge> <200034> <Bridge "reverseBridge" is shut down.> <Aug 27, 2003 9:24:08 AM PDT> <Error> <Connector> <190008> <Error closing connection instance for XA Transaction Resource Adapter.> javax.resource.spi.IllegalStateException: Managed connection is closed at weblogic.jms.adapter.JMSManagedConnection.checkIfDestroyed (JMSManagedConnection.java:263) at weblogic.jms.adapter.JMSManagedConnection.cleanup(JMSManagedConnection.java:128) at weblogic.connector.common.internal.XATransResourceFactory.cleanUp (XATransResourceFactory.java:325) at ....

Analysis revealed that MessagingBridge.shutdown() called MessagingBridge.cleanup(), which then calls recover() on the source connection. The exception occurred because Recover() is not a valid operation on a transacted session.

A code changes has been implemented to verify that a session is not transacted before calling recover().

CR121760

An InvalidDestinationException was received when using WebLogic Server Messaging Bridge to integrate WebMethods 6.0 JMS with WebLogic Server. When sending messages to WebLogic Server, WebMethods 6.0 requests an ack. The bridge sends ack of type weblogic.jms.DestinationImpl when WebMethods expected type com.wm.broker.jms.Destination. This exception resulted:

javax.jms.InvalidDestinationException: Destination must be of class: com.wm.broker.jms.Destination at com.wm.broker.jms.Message.setJMSDestination(Message.java:896) at weblogic.jms.client.JMSProducer._send(JMSProducer.java:380) at weblogic.jms.client.JMSProducer.send(JMSProducer.java:172) at weblogic.jms.adapter.JMSBaseConnection.sendInternal(JMSBaseConnection.java:5 71) at weblogic.jms.adapter.JMSBaseConnection.send(JMSBaseConnection.java:528) at weblogic.jms.adapter.JMSConnectionHandle.send(JMSConnectionHandle.java:131) at java.lang.reflect.Method.invoke(Native Method) at weblogic.connector.common.internal.ConnectionWrapper.invoke(ConnectionWrappe r.java:101) at $Proxy115.send(Unknown Source) at weblogic.jms.bridge.internal.MessagingBridge.onMessageInternal(MessagingBrid ge.java:1160) at weblogic.jms.bridge.internal.MessagingBridge.onMessage(MessagingBridge.java: 1093) at com.wm.broker.jms.MessageConsumer.deliverMessage(MessageConsumer.java:682) at com.wm.broker.jms.Session$MessageDeliveryThread.run(Session.java:1431)

As WebLogic Server is providing bridge functionality between the two JMS implementations, the request is to convert message acknowledges to the correct type. It seems that this is correctly done for regular messages.

Analysis revealed that the standard WebLogic JMS client was handed a WebMethods message to send, and attempted to call setJMSDestination on the WebMethods message using a WebLogic destination.WebMethods throws an InvalidDestinationException when this occurs.

The problem was resolved by a code change to catch and ignore the InvalidDestinationException.

CR122749

Sorting on a DestinationKey JMSCorrelationID could have resulted in a NullPointerException if not all of the messages in the queue had a JMSCorrelationID set. The same failure could have occurred for DestinationKey JMSType.

Code was modified to check for a null JMSCorrelationID and null JMSTypes before calling compareTo. As a result, sorting will work correctly, without throwing a NullPointerException.

CR123194

In previous WebLogic Server 7.0 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 resolved the problem.

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.

CR128723, CR081630

Because of a timing issue with the consumer load balancer, enabling ServerAffinity caused behavior that could incorrectly select a remote member when a local member would be more appropriate.

In previous service packs, enabling ServerAffinity set this set of preferences:

1) Pick local member without a consumer

2) Pick local member

3) Pick remote member without a consumer

4) Pick remote member

As of Service Pack 5, enabling ServerAffinity sets this set of preferences:

1) Pick local member without consumer

2) Pick any member without consumer

3) Pick local member

4) Pick any member

CR172250

There was no backward compatible property for weblogic.jspc.

Added a new command line flag for weblogic.jspc called backwardcompatible. If it is set to true, then the Web application will be compiled maintaining backward compatibility with WebLogic Server 6.x earlier. With the new "backwardcompatibility" flag, you can compile Web applications as in WebLogic Server 6.x.

CR133760

The server tried to read the Init parameters from the servlet config, using "compilerClass" String instead of "compilerclass" string. The JSP descriptor element is compilerclass and so the JSPServlet was changed accordingly. Code was added to change the method config.getInitParameter("compilerClass") to config.getInitParameter("compilerclass") in JSPServlet code. The JSP descriptor element "compilerclass" is now honored.

CR093625

The server sometimes misdirected output for JSP includes in JSP pages.

Following a code change, isResponseWrapper is reset if all wrappers were removed (if, for example, all of the wrappers were JSP NestedBodyResponse wrappers from JSP body tags, since they are removed on a forward when a wrapper implements weblogic.servlet.internal.RemoveWrapperOnForward).

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.

A code change resolved the problem.

CR126007

When a JSP was forwarded from another JSP, the multi-byte string parameter was lost. This problem occurred only when the parameter encoding was EUC-JP or ISO2022JP and it was sent by the POST method.

Code was added to prevent reparsing the post parameters if the encoding has not changed.

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.

CR093520

When you precompiled JSPs on a machine in one timezone, and then deployed those same JSPs on a server in a different timezone, 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 timezone at compile time and using that timezone at deployment time to determine whether recompilation is necessary.

CR098514

Making a new line during string literal in an attribute of a JSP custom tag caused a compilation error. For example:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core";; %>

<c:if test="${ sessionScope.sessionID == null

or sessionScope.dummy == null }">

There is no Session ID!

</c:if>

Which led to the following error:

unclosed string literal

_c_if0.setTest(weblogic.utils.StringUtils.valueOf("${

sessionScope.sessionID == null //[ /ifTest.jsp; Line: 17]

A code change resolved the problem by allowing the storing of new line characters in the attribute values of a JSP custom tag.

CR104429, CR134313

WebLogic Server was recompiling JSP pages after updated JSP class files were copied to jspWorkingDir.

A new parameter, -Dweblogic.jsp.alwaysCheckDisk, when set to true causes WebLogic Server to check the stale JSP class from disk . This parameter is set to false by default, so default behavior is not changed.

CR111024, CR134046, CR111897

For a JSP with the following fragment using the Cache tag:

<wl:cache name="email_portlet" key="request.email_portlet_key" scope="session" timeout="60"> time=<%= new java.text.SimpleDateFormat("kk:mm:ss.SSS").format(new Date()) %><br> key=<%= key %><br> <% for (int i=0; i<100; i++) { // just a delay try { Thread.sleep(10); } catch (Exception e) { } } refreshed = true;%>

and a concurrent load of ten users, ten threads deadlocked at weblogic.cache.CacheSystem.waitOnLock().

A code change resolved the problem.

CR111423, CR127336

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

CR111655

Previously, it was not possible to use JavaServer Pages Standard Tag Library (JSTL) tags in JSPs that include Japanese characters. When such a JSP is executed, an error starting with the following lines occurred:

java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x82) was found in the CDATA section."

If the pageEncoding attribute was not specified in the page directive, the byte stream, which is used for taglib validation, was constructed using default encoding.

The problem was corrected with a code change to ensure use of the character encoding defined in the contentType attribute if the pageEncoding is not specified.

CR112794

A JSP was refreshed with a copy that did not parse correctly, and this caused a deadlock.

The problem was resolved by a code change that added a check during JSP refresh.

CR117477

For response.sendRedirect, the Content-Type was set to text/plain by default, instead of text/html. As a result, WebLogic Server returned a page with 503 status code for content that required the text/html Content-Type.

Following a code change, text/html is the default type when the Context-Type is not defined yet by the time sendRedirect is activated.

Note that a receiving party who is relying on the text/plain Content-Type will fail after this change.

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.

CR123520, CR106226

In WebLogic Server 7.0 Service Pack 4, if the PageContext.include() or forward() method was used in a JSP body tag, and HttpServletResponse.getOutputStream() was called in the included or forwarded servlet, the following exception occurred:

java.lang.IllegalStateException: Cannot use ServletOutputStream because a Writer is being used. Use getWriter() instead.

This included request was probably nested in a JSP body tag. A code change has resolved the problem.

CR111475

JTARuntime MBean was incrementing statistic counts on non-coordinating servers, as follows:

If you started a transaction, enlisted a resource from a Managed Server (making the Managed Server the coordinator), then enlisted a resource from the Administration Server, and committed the transaction, the JTARuntime MBean from both servers returned TransactionTotalCount as 1.

Following a code change, WebLogic Server only updates statistics on the coordinating server.

CR122842

When registering a new resource under the same name as the old resource, any subsequent XA transaction operations could not go to the new resource. They continued to attempt to reach the original resource.

Code was added to allow the substitution of a second resource with the same name.

CR127412

The application could not get a connection when PinnedToThread was turned on or when using the Oracle OCI NativeXA driver.

The problem was resolved by a code change.

CR113226

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

java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occurred 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.

CR134081

When a resource adapter becomes unregistered, either by calling unregister or by a resource failure, all transaction operations intended for that resource adapter fail.

Starting with Service Pack 5, if a second resource adapter with the same name is registered, all transactions that were intended for the first resource adapter will now operate on the second resource adapter.

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, CR124729

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.

CR127930

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

CR125829

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

CR099488

WebLogic Server was calculating the Administration port URL incorrectly.

A code change ensures that the URL is calculated correctly, based first on the Administration Port (if it is enabled), and then on the Administration channel (if it is enabled).

CR128713

Users sometimes got a beanshell exception when setting the ErrorDestination on a JMSQueue. In certain circumstances the parent was not set on the JMSQueue and caused setting the ErrorDestination to fail because the legal check used the parent.

Code was added to modify the legal checker to pull the parent JMSServer from the name of the JMSQueue for the check.

CR134167

EXISTS_POOL did not work as expected. It was looking for runtime mbeans which may or may not exist even if the pool exists. DELETE_POOL, an undocumented command, was the internal implementation to delete a connection pool; however, this feature was documented as DESTROY_POOL externally.

The Help menu also displayed some undocumented commands.

EXISTS_POOL command implementation now looks for configuration mbeans to check whether the pool exists.

DESTROY_POOL command now uses the underlying DELETE_POOL implementation.

All the undocumented commands that appeared in the weblogic.Admin help menu are now disabled. Commands include TEST_POOL, REMOVE_POOL, SUSPEND_POOL, SHUTDOWN_POOL, RESUME_POOL, DELETE_POOL. These will not be supported going forward and will not work in 7.0 SP5.

The Help menu no longer lists these commands.

CR136210

The code attempted to do a runAs where parameters needed to be passed. Instead of passing the parameters on the stack, however, the code attempted to stash them into object variables. It also tried to use a token scheme to identify which of the log methods to call from runAs(). These object variables were not synchronized. As a result, the same message was sometimes logged multiple times.

The code was changed to use an anonymous inner class which made the code much cleaner and more thread safe. The code in the log handler was synchronized to write to the log file.

CR130441

The security sample providers sample on dev2dev was broken in earlier service packs of 7.0. When you built the sample, started the server, and tried to set up the domain, you received a number of javax.management.MBeanException errors.

A code change was made that enables the server to consider "commotype" as a flag to the administration tool.

CR101109

Upon enabling JDBC logging for a Managed Server in a cluster, the Console showed an error while starting. This error did not effect the JDBC logging and JDBC logging worked correctly.

Code was added to fix the logging server debug messages on Managed Servers.

CR121228

User identity is now being recorded in auditing log messages.

CR121216

The @exclude and @non-configurable tags on the DomainMBean.AdministrationMBeanAuditingEnabled attribute have been removed.

CR132445

weblogic.Admin did not work properly with the default URL. For example:

java weblogic.Admin -username ss -password ss VERSION

returned no results, but adding -url t3://localhost:7001 returned correct results.

Following a code change, weblogic.Admin now checks the input URL for null, because it already has the default URL internally.

CR111199

Restarting the Administration Server, and then starting two Managed Servers simultaneously resulted in heavy CPU consumption. One Managed Server completed initialization, the second started initialization and stopped.

Use of kill -QUIT pid revealed that the main thread was stuck in HashMap.rehash, as shown:

"main" prio=5 tid=0x29240 nid=0x1 runnable
[0xffbec000..0xffbedbd4] at
java.util.HashMap.rehash(HashMap.java:292) at
java.util.HashMap.put(HashMap.java:344) at
weblogic.management.internal.DynamicMBeanImpl$XInfo.get(DynamicMBeanImpl.java:2270) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:195) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:167) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:70) at
weblogic.jms.frontend.FEConsumer.<init>(FEConsumer.java:100)
at weblogic.jms.frontend.FESession$3.run(FESession.java:952)
at ....

A code change increased the size of the default HashMap to accommodate all MBean attributes without resizing, and synchronized thread access to the HashMap.

CR111287

The Convert weblogic.properties utility did does not add DOCTYPE to web.xml and weblogic.xml.

The utility was corrected to add these sentences to the beginning of web.xml and weblogic.xml, respectively.

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd";>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD
Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd";> CONFIGURATION: WebLogic Server 7.0 SP2

CR120987

A Managed Server log was created, incorrectly, in the NodeManager home directory (NODEMGR_HOME) instead of in the RootDirectory specified. The access.log and the tlog files were correctly created under the RootDirectory.

NodeManager had been configured on a machine, to allow remote start of the Managed Server.

In the RemoteStart tab for the Managed Server in the console, the RootDirectory for the Managed Server and the FileName for the log were specified.

config.xml contained this stanza for the Managed Server:

<Server ExpectedToRun="true" ListenAddress="172.23.64.45"
ListenPort="27023" Machine="MyMachine" Name="m1"
ServerVersion="7.0.3.0" StdoutSeverityLevel="64">
<COM Name="m1"/>
<ExecuteQueue Name="default" ThreadCount="15"/> <IIOP Name="m1"/>
<JTAMigratableTarget Cluster="" Name="m1"
UserPreferredServer="m1"/>
<JTARecoveryService Name="m1"/>
<KernelDebug Name="m1"/>
<Log FileName="m1/m1.log" Name="m1"/>
<SSL Name="m1"/> <ServerDebug Name="m1"/> <ServerStartName="m1"
OutputFile="/home/support/BEA/wlserver7.0sp3/user_projects/
jay1/./NodeManagerClientLogs/jay1_m1/startserver_1061321008754.log" Password="{3DES}7v6S0vZT+xUhhbWkLEq23A=="
RootDirectory="/home/support/BEA/wlserver7.0sp3/user_projects
/jay1" Username="system"/>
<WebServer Name="m1"/>
</Server>

The problem was corrected by a code change.

CR121839

DomainMBean instances did not reflect the auditing state when enabled from the command-line.

If MBean auditing is enabled on the command-line via the -Dweblogic.AdministrationMBeanAuditingEnabled switch, neither the Domain nor the DomainConfig MBean instances showed the attribute being set to true. Auditing was on, but the Mbeans did not reflect that fact.

The problem was corrected with a code fix to set the domain mbean attribute from the system property during server startup.

CR121728

Enhancement:

Mbeans for custom authentication providers no longer must be put inside of the WebLogic installation tree in the WL_HOME\server\lib\mbeantypes directory.

WL_HOME\server\lib\mbeantypes is the default directory for installing MBean types. However, if you want WebLogic Server to look for MBean types in additional directories, use the -Dweblogic.alternateTypesDirectory=<dir> command-line flag when starting your server, where <dir> is a comma-separated list of directory names. When you use this flag, WebLogic Server will always load MBean types from WL_HOME\server\lib\mbeantypes first, then will look in the additional directories and load all valid archives present in those directories (regardless of their extension). For example, if -Dweblogic.alternateTypesDirectory = dirX,dirY, WebLogic Server will first load MBean types from WL_HOME\server\lib\mbeantypes, then any valid archives present in dirX and dirY.

Note that you must continue to use the option or your server will be come unbootable (for example, if you used the option and created some users and then decided not to use the alternateTypesDirectory option).

For more information, see "Install the MBean Type Into the WebLogic Server Environment" in Developing Security Providers for WebLogic Server.

CR122204

When a Managed Server with a custom COMMO bean was restarted without restarting its Administration Server, the Managed Server was unable to create an instance of the COMMO bean. This exception occurred:

javax.Management.InstanceAlreadyExistsException is thrown, and the Detailed message in the exception is, The Object name specified 'wlidomain:Name=t,Server=managed1,Type=AppViewRuntime' is not unique across the domain. Please choose an unique Object Name

Analysis revealed that the Mbean was not un-registered on the Administration Server's MBeanServer when it went down. For this reason, upon restart, the Managed Server could not re-create the bean—the Administration Server still had a bean instance with that bean's name in its list of instantiated beans. Mbean names must be unique across a domain.

The problem was resolved by a code change to un-register all of a Managed Server's server-specific beans when it goes down. When a Managed Server goes down, the Administration Server receives a PeerGoneEvent and un-registers all MBeans associated with the Managed Server.

CR136718

The configuration of "Root Directory" is now working when using Node Manager.

CR134413

The Apache plug-in caused a duplicated http header and body for the 302 response. There was no problem between the plug-in 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.

CR113033

In earlier service packs, the ISAPI plug-in did not recognize the WLTempDir flag for the _wl_proxy folder. The code was fixed to use the flag.

CR132699

When the application servers are down the Apache access logs should record a 500 error but instead returned a 200 code:

[Mon Jan 05 12:58:21 2004] [notice] Apache/2.0.44 (Unix) configured -- resuming normal operations

[Mon Jan 05 12:58:25 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

[Mon Jan 05 12:58:27 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

[Mon Jan 05 12:58:29 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

[Mon Jan 05 12:58:31 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

[Mon Jan 05 12:58:33 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

[Mon Jan 05 12:58:35 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115

The problem has been resolved.

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.

A code change resolved the problem.

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

If a connection is grabbed from the pool, but the server instance has already closed the connection, the HALF_OPEN_SOCKET_RETRY exception was thrown, causing the deletion of the previous connection object and the creation of a new one to connect to the same server.

The problem was resolved by the addition of code to handle the HALF_OPEN_SOCKET_RETRY exception properly.

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 was added which marks the server as bad on getting a 503 HTTP status error, gets the next available server and resends the request. All requests will now successfully fail over to next available server.

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.

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 code change has resolved the problem.

CR112503

String comparison for headers was case sensitive for the NSAPI plug-in, and is now case insensitive.

CR123775, CR123120

Using the Post method to forward requests through the Apache plug-in caused the plug-in to set content-length to 0 and wlproxy.log to log this message:

POST and PUT requests *must* contain a Content-Length

This problem has been resolved with a code fix.

CR121726, CR121341

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

CR110991, CR117044, CR120970, CR120978

Requests that received the PROTOCOL_ERROR message from the primary server also received a message similar to the following:

Mon Jun 30 21:52:57 2003 general list: trying connect to '10.84.133.182'/7305/7306 at line 1257 for ..

Indicating that failover was applying to another server in the general list, instead of the secondary server.

The problem has been resolved with a code fix.

CR126982

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:

<Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object>

was proxied to WebLogic Server, and Iplanet failed to serve 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.

CR126568

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.

The problem was corrected by code change to the plug-in to detect and handle HTTP/0.9 responses correctly.

CR126103

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 a problem in the code in proxy.cpp used strdup(), a native system call that 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 the 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 is instructed what space to free.

CR125690

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. Four bytes to mark the end of buffer were getting lost, which resulted in the core dump. The problem was solved with a code fix.

CR125545

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.

CR124464

The plug-in could cause iPlanet to crash shortly after a request received a HALF_OPEN_SOCKET_RETRY, "Unexpected EOF reading HTTP status - request retry" message.

The code was modified to retrieve the exception code from the exception object and then delete the object.

CR124433

If IIS was configured with WlForwardPath=/, the plug-in would try to 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.

CR123925

The plug-in sometimes responded 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.

CR123120

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.

CR122755

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.

CR122754

The plug-in parameter WLExludeByPathOrMimeType did not work when forwarding by mime type. This problem was solved with a code fix.

CR122207

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.

CR121688, CR121943

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.

CR113093

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.

CR111167

In previous service packs of WebLogic Server 7.0, 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.

CR110664

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.

CR109755

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.

CR108092

In previous service packs of WebLogic Server 7.0, 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 plug-in.

CR105123

If you configured a virtual directory, configured a mime type with the wildcard * (proxy everything), and added a DefaultFileName in the iisproxy.ini file, on a request for a directory with no filename the DefaultFileName was not used.

A code change resolved the problem.

CR105173, CR135917

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 TO CLIENT ERROR] was inappropriately logged in the Web server logs.

The server no longer logs a 500 error for this kind of response failure.

CR091910

In earlier WebLogic Server 7.0 service packs, the Apache plug-in did not read PathPrepend when using <IfModule mod_weblogic.c>. The problem occurred with plug-ins for Apache 1.3.x and Apache 2.0.43. This problem appeared only if PathPrepend and MatchExpression properties existed together within the <IfModule mod_weblogic.c> tag. This was also true for PathTrim property.

The problem was solved with a code fix.

CR106764

A thread in the Netscape 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 the Web server appear to hang. This problem was fixed with a code change to the plug-in.

CR087204

Using the PathTrim and PathPrepend parameters in conjunction no longer creates a URL with an unexpected forward slash "/" at the end.

CR124596

An optional enhancement to the BEA ORB forces reconnection when bootstrapping and allows hardware load-balancers to correctly balance connection attempts.

For more information on this feature and its limitations, see Using RMI over IIOP with a Hardware LoadBalancer in Programming WebLogic RMI over IIOP.

CR125261

A fat client application instantiated clients that called a stateless session EJB and experienced a memory leak when using WebLogic Server version 7.0 with Service Pack 3 and Service Pack 4.

This issue was resolved by using the context classloader in the Appmanager. -Dweblogic.LoadStubUsingContextClassLoader option will no longer be available after this change.

CR127333

When an RMI/IIOP client was killed when the server was writing a response, some subsequent client requests failed with a MarshalException. When the initial client connection broke, the indirection map was not cleared when put back into the pool. Subsequent clients which used that particular map from the pool failed with the MarshalException.

A code change ensures that the indirection maps are properly cleared even in cases when the client gets killed.

CR121079

When making an initial request, the WebLogic Server-IIOP runtime would not select the appropriate codeset for wide string transmission.

The appropriate codeset for wide string transmission is now selected for all requests. Interoperability with WebLogic Server will now work correctly.

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.

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.

CR109844, CR113715

Out Of Memory errors due to memory leakage of the DGCServerHelper class during repeated creation and close of InitialContext unnecessarily create a helper object to manage distributed garbage collection.

A code change fixed the problem.

CR106281

In previous WebLogic Server 7.0 service packs, 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.

CR131692

When throwing a derived exception from the ejb method, the iiop layer was adding the Full Value Description for the derived exception but not for the base exception. When the client came back to get information about the base exception the server did not have it and threw an exception.

Code has been added to ensure that when creating a Full Value Description for the derived class, the Full Value description of the base classes is created as well.

CR135710

There was a wait(1000) in the backendstandard that was delaying the some operations such as undeploy.

A code change removed the wait(1000) and introduced tp.wait().

CR172774

The CertificateAttribute needs to be defined to match the binary field that holds the certificate in LDAP, whether it is "userCertificate" or "userCertificate;binary", as described below. Currently it defaults to "userCertificate".

1. userCertificate

If you load the certificate via the ldapbrowser, the attribute userCertificate is created, of type binary, whose value is the data of the certificate.

To be able to access the certificate you must define CertificateAttribute="userCertificate".

2. userCertificate;binary

If you use ldapmodify to add the new attribute, as in:

ldapmodify -p 1155 -D Principal -w Password

dn: cn=support@bea.com,ou=Certs,dc=bea,dc=com

changetype: modify

add: userCertificate

userCertificate;binary:: MIICxDCCAi2gAwIBAgIBIDANBgkqh.....

an attribute named userCertificate;binary is created where the certificate data is loaded. To be able to access this certificate you must define CertificateAttribute="userCertificate;binary".

CR121114, CR134158, CR134159, CR135017, CR130506

The SocketImpl class did not catch an IOException and continued to rethrow it, causing the socket not to close.

This problem was resolved by adding code to close the socket and throw the IOException. As a result of this change, there are no idle sockets.

CR120748

In prior releases, WebLogic Server did not have an LDAP X509Identity Asserter.

Code was added to allow the use of an LDAP X509 Identity Asserter.

CR112147

The existing ServletAuthentication API methods such as weak, strong, authenticate etc, were not propagating the LoginException back to the caller. Two overridden login methods were added, which perform similarly to the weak and authenticate methods. The assertIdentity method, which performs in the same way as the strong method, was added. These new methods will propagate the LoginException to the calling code.

CR124746, CR175051, CR175045

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

CR132503

The Web services client loaded the local identity directly into the Certicom SSL context, but the Web services HttpsURLConnection class didn't associate the connection with that specific Certicom SSL context.

The connection is now associated with the SSL context by the HttpsURLConnection class, which takes an SSL context as a parameter.

CR130355

When adding a duplicate entry, DefaultCredentialMapperLDAPHelper threw an exception without completing the method even though the exception was harmless.

A code change causes DefaultCredentialMapperLDAPHelper to ignore the exception while adding duplicate entries.

CR128002

The connection pool was not being maintained correctly, and the size of the pool was insufficient for the load the request generated. These problems caused a performance problem while authenticating users.

A code change corrected the problems with pool. In addition, an option was added to set the LDAP connection pool size. The option is -Dweblogic.security.providers.authentication.LDAPDelegatePoolSize.

CR127259

The month field in the DefaultAuditRecorder backup file name was reporting an incorrect value.

Code was added to fix the expression. The Month field now reports the correct value.

CR125409

When two Managed Servers were started simultaneously, then same code was executed twice to create an LDAP entry as a part of deploying an application. The lack of synchronization was causing the creation of a duplicate entry in the LDAP.

Code was added to check whether an entry exists in the synchronization before updating the id counter. If a duplicate entry is being created accidentally, WebLogic Server throws an exception, which prevents the creation of the entry.

CR064593, CR121607

The following command-line arguments used to control the SSL time-to-live and cache size are no longer ignored in WebLogic Server 7.0:

-Dweblogic.security.SSL.sessionCache.size=
sessioncachesize

-Dweblogic.security.SSL.sessionCache.ttl=
sessioncachetimetolive

CR097734, CR090472

SSLLayeredSocket was not creating SSLIOContext when proxying requests, causing NullPointerException while tunneling SSL via proxy servers.

A code change that creates SSLIOContext and adds it to context table solved the problem.

CR105933

WebLogic Server was unable to filter connections from LDAP servers because the LDAP protocol was not allowed in the connection filter rules.

LDAP has been added to the list of filterable protocols, so that connections from ldap can be filtered.

CR106192

When you set the security debug flags <ServerDebug DebugSecurityAtn="true" DebugSecurityAtz="true" ...> with StdoutDebugEnabled="true" StdoutSeverityLevel="64", the server logged the user password to stdout in clear text.

This problem has been resolved by removing the password string from the statement that is written to the log file.

CR106294, CR132596, CR120273

Removal of an application was delayed by a configured wait in the processing of embedded LDAP transactions. A code change has resolved the problem.

CR106532

When two-way SSL is turned on, the server invokes IdentityAssertion automatically, which is correct in a client-server scenario but causes problems when the connection is between instances of WebLogic Server. The scenario:

Client hits WebLogic Server Instance1 and is authenticated correctly with two-way SSL. Instance1 then invokes an EJB on Instance2 via two-way SSL, and Instance2 authenticates based on Instance1's certificate. There are two issues:

1. The true user is the client, not Instance1, but Instance2 reads the user as Instance1 based on the DN in Instance1's certificate.

2. Authentication should not be required. You should be able to enforce client certificates for the SSL connection, but turn off the IdentityAssertion check if you want to use a trusted WebLogic Server domain.

A code change has made certificate authentication configurable. If you do not want to treat the certificates submitted as a part of two-way SSL to do IdentityAssertion, use -Dweblogic.security.disableIdentityAssertion=true in the server startup.

CR107363

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

CR108021

A problem that caused loss of information stored with the security subject has been resolved as follows.

A new cache is used when a user logs in via two-way certificates or a token in a header or a cookie, improving the performance of identity assertion. The server receives an RMI call either from a 6.x or earlier instance of WebLogic Server, or when a servlet or EJB with a run-as tag is executed. If a user is deleted, identity assertion will continue to work for the deleted user until the cache TTL is reached. The cache TTL defaults to five minutes and can be adjusted on the command line as follows:

-Dweblogic.security.identityAssertionTTL=N for

N > 0 sets the cache TTL to N seconds

N = 0 sets the cache TTL to infinity

N < 0 disables the cache altogether

CR108624, CR128228

In a performance tuning enhancement, new attributes were added that allow you to limit the depth of a group membership search. You can tune the search according to your membership hierarchy, and eliminate searching that you know will not find group members.

The new attributes are GroupMembershipSearching and MaxGroupMembershipSearchLevel.

CR110242

The LDAPConnection used for the realm.getGroups() call retained the results and prevented their return to the pool, which was also used by an iteration of getGroups(). This caused a proliferation of open LDAP connections.

Following a code change, an LDAP connection is associated with the getGroups() call to the group iterator, and the connection is closed when there are no more elements left in the iterator.

CR110977

Specifying java.lang. Integer.MAX_VALUE for ACLCacheTTLPositive resulted in a java.lang.IllegalArgumentException. The problem occurred after this sequence of events.

1. Start WebLogic Server in CompatibilityRealm mode.

2. Under the Caching realm, enable the ACL cache and specify the value of ACL Cache Positive TTL = java.lang.Integer.MAX_VALUE and save changes.

3. Restart WebLogic Server.

WebLogic Server throws the following exception:

<Jun 25, 2003 4:31:44 PM PDT> <Notice> <Management> <140005> <Loading configuration D:\opt\weblogicapps\ecommerce\.\config.xml> <Jun 25, 2003 4:31:47 PM PDT> <Info> <Logging> <000000> <FileLogger Opened at D:\opt\weblogicapps\ecommerce\.\logs\ecommerce\myserver.log> <Jun 25, 2003 4:31:50 PM PDT> <Critical> <WebLogicServer> <000364> <Server failed during initialization. Exception:java.lang.IllegalArgumentException: ttl<= 0 java.lang.IllegalArgumentException: ttl <= 0 at weblogic.security.acl.TTLCache.<init>(TTLCache.java:195) at weblogic.security.acl.TTLCache.<init>(TTLCache.java:173) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:478) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:375) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:350) at ...

The problem was solved with a change to the ttlcache creation code.

CR111305

The webflowCheckAccess() method now explicitly checks whether a logged in client has access to Web application resources before rendering them.

CR112971, CR104667

The NetScape LDAP API released with earlier service packs of WebLogic Server 7.0 contained a bug that could cause deadlocks when more than one thread called deregister() on LDAPConnThread.

A code change resolved the problem.

CR113459

In previous service packs, removing the Node Manager properties file caused problems. The Node Manager properties file is always created in the <saved logs dir>/NodeManagerInternal directory. Periodically archiving and deleting the contents of NodeManagerInternal removed the Node Manager properties file, so that the certificate password stored in the Node Manager properties file could not be decrypted, and Node Manager did not work correctly.

A code change creates 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.

CR120233

A code change has resolved the problem that caused a java.lang.ArrayStoreException to be thrown when configuring a custom auditor and a custom role mapper with the IPlanet 5.1 Authenticator.

CR120850

weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. Requests from the client, whether one running within WebLogic Server or a standalone Java program, always went through the proxy even if the targeted host was specified in https.nonProxyHosts.

https.nonProxyHosts is detected by SSLParams and an internal list of hosts that should be proxied is constructed. When the SSLSocket is created and initialized, the host is compared against this list. If the host appears on the list, the host is used to open the socket. If the host is not on the list, the proxyHost is used to open the socket. (And, if there is no proxyHost, then this is all moot and the host is used to open the socket).

A code change resolved the problem. A user can now set the following properties:

• http.proxyHost

• http.proxyPort

• http.nonProxyHosts

• https.proxyHost

• https.proxyPort

• https.nonProxyHosts (new property)

For either http or https, one can define a proxyHost upon which the socket will be opened. However, one can also define a list of hosts (nonProxyHosts) to which a client should be connected directly, even if a proxyHost is defined. The change made by this fix is to add https.nonProxyHosts, so that a user can now specify the hosts that the client should always connect to directly using SSL even if https.proxyHost is defined.

CR120852

A MalformedURLException resulted when the dynamic group attribute memberURL contained a string value with a reserved character (such as forward slash '/') in the LDAP search filter portion of the LDAP URL. For example, this URL:

ldap://text replaced:389/dc=text replaced2??sub?(&(|(objectclass=person) objectclass=groupofuniquenames))(uid=*text replaced/2*))

resulted in this exception:

<Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance dyn group entry = LDAPEntry: cn=slashgroup,ou=Groups, dc=text replaced; LDAPAttributeSet: LDAPAttribute {type='cn', values='dynamicgroup001,slashgroup'} LDAPAttribute {type='memberURL', values='ldap:///dc=text replaced??sub?(&(|(objectclass=person)(objectclass=groupofuniquenames))(uid=*htext replaced/2*))'}> <Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance member url = ldap:///dc=text ...

Analysis and investigation revealed that:

• In an LDAP URL, '/' is not illegal, although it is a URL delimiter and must be escaped.

• WebLogic Server used the LDAPUrl object to get the filter, while iterating the dynamic groups. If that url filter part contains special characters like '/' then the LDAPUrl class is not handling them properly.

The problem was resolved with a code change to obtain the filter without using LDAPRealm object.

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. A code change corrected the problem.

CR121043, CR134995

Properties set directly in the JSP were not being captured and set in the HTTP client.

A code change has resolved the problem.

CR121135, CR123865

JDK 1.3.1_08 threw an internal exception that caused two-way SSL communication between two WebLogic Server instances to fail under certain circumstances when LANG was set to univ.utf8.

A code change has resolved the problem.

CR121646

A BAD_CERTIFICATE error was received and the SSL connection was terminated when a client certificate with Extended Key Usage set to critical was sent to WebLogic Server.

Analysis revealed that WebLogic Server did not support Enhanced KeyUsage in SSL.

The problem was resolved by adding support for EnhancedKeyUsage. WebLogic Server can now accept Certificates with Enhanced Key Usage set to critical.

CR122642

After an upgrade from Service Pack 2 to Service Pack 3, an attempt to view the Security->User->Realms->myrealm->Users screen resulted in WebLogic Administration Console hang.

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

CR124164, CR090738,

The entitlement engine previously restricted the number of operands in a role expression to 100. This restriction in turn limited various attribute values. For example, the maximum number of principal-name elements that could be mapped to a role within a security-role-assignment in weblogic-ejb-jar.xml was limited to 50. Having more than principal-name 50 elements resulted in a weblogic.entitlement.data.EnCreateException during the deployment of an application.

A code change resolved the problem by removing the restriction on the number of operands in a role expression.

CR126106, CR090472

On deployment of an application, LDAP entries are written first to Administration and then to Managed Servers. In previous service packs, if writing to the Administration Server failed, the call was returned without writing to the Managed Server, which caused the EJB security layer not to return the correct roles.

A change to the LDAP code has resolved the problem.

CR133655, CR128002

Connection pool code was not behaving properly, causing the LDAP searches to slow down, which caused, for example, slow authentication with a third-party LDAP.

A code change resolved the problem.

CR128624, CR171907

When an application attempted to encode a URL which included an HTML anchor tag, such as this: http://localhost:7001/WebApp/target.jsp#section4, the resulting URL was incorrect: http://localhost:7001/WebApp/target.jsp#section4;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719.

The anchor tag should be at the end of the URL, so it is ignored. The correct URL would be: http://localhost:7001/WebApp/target.jsp;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719#section4.

Code was added to look for an anchor if there is no query string in the original URL, and to append the anchor to the end of the encoded URL.

CR123333

Form-based authentication in a Web application did not allow multi-byte characters for 'j_username' and 'j_password', which prevented request encoding in JSPs. Multi-byte characters caused authentication to fail.

To specify character encoding in the JSPs, you can use 'j_character_encoding' as follows:

<form method="POST" action="j_security_check">

<input type="text" name="j_username">

<input type="password" name="j_password">

<input type="hidden" name="j_character_encoding" value="Shift_JIS" >

</form>

Note: j_character_encoding is not J2EE compliant.

A code change has resolved the problem.

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.

CR129237

A servlet that invoked HttpServletRequest.getServletPath() or HttpServletRequest.getPathInfo() received incorrect values when the ServletMapping was for *.<value> and the URL contained a full stop '.'

Fixing a parsing error resolved the problem.

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 resolved the problem.

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.

CR127708

HttpParsing.unescape() decoded the path /foo/..%c0%../ to /foo/.. because sun.io.ByteToCharUTF8.convert() stops converting the remaining bytes if it encounters bytes that are not valid in UTF8 (for example, 0xc0). This problem did 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, HttpParsing.unescape() decodes the path /foo/..%c0%../ to /foo/..?%..

CR125846

According to the Servlet Specification, an exact pattern should take precedence over a wildcard pattern. But this was not working correctly. For example if you have: "/TestPath/*" maps to "WildcardServlet" and "/TestPath" maps to "ExactMatchServlet", if the incoming relative URI is '/TestPath' then ExactMatchServlet should have been served, not WildcardServlet.

This was fixed by making appropriate changes in the pattern matcher

CR125048

Debugging information from server/bin/fastfile.dll was printed out in the Administration Console.

Rebuilding the binary without any source code change resolved the problem.

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().

CR084455

When WebLogic Server was configured to log all HTTP requests in extended format, at the rotation time, the following error was thrown at approximately one-minute intervals after the rotation was scheduled (one minute being 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 that ensures that the log is not flushed on rotation, and that the log file name is checked for a null value.

CR088785, CR122315

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, CR112910

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

The CGIServlet extracts the CGI scripts in a WAR Web application so that it can execute them. Previously, the servlet called these scripts without setting the current working directory. This meant that subscripts could not be called properly. A code change now ensures that the current working directory is set so that CGI scripts can call subscripts in WAR Web applications.

CR096459

When invoking a flush on 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.

CR103339

Servlet output capitalized the Transfer-Encode type 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 "chunked" in lowercase.

CR103482, CR120943, CR129041

A workaround that solved the problem of an orphaned session in a secondary server by invalidating the session created a race condition that caused a "primary not found" error during load test.

A code change resolved the problem.

CR103925, CR125206

The setAttribute method only checked for hashCode equality. It now also checks the result of the equals method for the old and new objects.

CR104245

Under heavy load, when both the primary and the secondary server in a two-server configuration access the same replicated session, a session replication deadlock results. Both servers try to replicate the same session data; the server in primary role locks the ReplicatedSessionData and tries to update the secondary server. At the same time, the other server does the same and waits for the first server to do the update of its secondary copy. The replication call comes to the first server on its replication thread queue and it cannot finish the update until it can get lock on the session data that is held by another thread in the same server acting as a primary for the same session data. Each server keeps trying to replicate as primary and update the same session as secondary, leading to a mutual deadlock.

As the servers deadlock, all requests involving session access and replication are blocked while the requests keep piling up. As the two servers keep toggling between primary and secondary state, "Got stale replication request" is logged.

A code change that substituted a synchronized object for a synchronized method resolved the problem.

CR108034

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

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.

CR108385

Attempts to post chunkpost data to cluster instances using HttpClusterServlet which was acting as a proxy in front of the WebLogic Server cluster generated the NumberFormatException, while direct requests without proxying from HttpClusterServlet succeeded without any errors.

Taking into account that chunk transfer encoded data is already decoded by the core server, a code change that prevents HttpClusterServlet from making an unnecessary attempt to decode the data again fixed the problem.

CR108577

Module order was not considered during undeployment. This logic is fixed. Now the modules are deactivated and rolled back in the exact reverse order in which they were deployed.

CR108607

WebLogic Server produced errors when applications used XSL with the Formatting Objects Processor 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.

CR109479, CR110838

The JnlpDownloadServlet uses the timestamp on a WAR file to determine whether the client's resources are older than what is available on the Web server. To get the timestamp, JnlpDownloadServlet calls the URLConnection.getLastModified() method. However, the getLastModified() method returned 0.

The code has been modified so that a ZipURLConnection.getLastModified() method returns the modification time of the zip file, and thus the WAR file.

CR109885

Session replication to a failed secondary node caused the primary node to hang. The primary node appeared to be attempting to connect to the secondary node and holding a lock that other threads had to wait on.

A code change has resolved the problem.

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) on 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.

CR110832

WebLogic Server threw a NullPointerException upon deployment of a Web application when DebugEnabled was set to true for the WebAppComponent in config.xml. The problem was resolved with a code change.

CR110910

HttpClusterServlet threw a NumberFormatException 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.

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.

CR111090, CR090886

When -Dweblogic.webservice.transport.http.full-url was set to True, a Web service could not be invoked using the HTTPS protocol.

A code change has resolved the problem.

CR111531

Weblogic Server 7.0 did not handle file names that contained double byte characters when the Sending UTF-8 Only option was turned off. Attempts to access a file with double byte characters in its name resulted in a 404 file not found error.

The problem was corrected with a code fix.

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, which caused a problem when an IOException occurred 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.

CR112910, CR092625

WebLogic Server threw a NullPointerException when HTTP logging was enabled 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.

CR114936

WebLogic Server drained an input stream even if a client cancelled a proceeding request, thus consuming CPU resources.

The code was changed so that connections are thrown away so they do not drain an inputstream. As a result of this change, if an IOException occurs while writing to a client, GenericProxyServer does not recycle this connection and will create a new connection for a subsequent request.

CR116209

If customers added a serializable ServletContext attribute, then overwrote it with a non-serializable value, the original value masked the new value. This problem occurred because the old value was never removed from the attribute's Hashtable.

The code has been modified to remove the value from an attribute's Hashtable, if necessary, when replacing a serializable value with a non-serializable one.

CR120228, CR124369

An exploded Enterprise application that contains exploded EJBs and Web applications and their MANIFEST files, which have shared classes in the classpath, worked on WebLogic Server 7.0 SP2 but not on WebLogic Server 7.0 SP3. The shared classes could not be found.

This problem was resolved by a code change that adds the classpath entry from the MANIFEST file to the classloader for exploded applications.

CR120281

HttpServletRequest.getParameterValues(String) sometimes returned parameter values twice. Analysis revealed that query parameters in forwarded requests were being checked for parsing in a manner that caused properly parsed parameter values to be returned twice.

A code change has resolved the problem.

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 Application are registered for invalidation as necessary by invalidateAll(request).

CR121094, CR129364

Redeploying a Web application that was deployed to both a cluster and a VirtualHost that also mapped to the cluster caused an InstanceNotFoundException. The problem was solved by a code change.

CR121175

HTTPClusterServlet routed requests to a different server instance than the primary instance identified by its JVMID in the session cookie.

HTTPClusterServlet was proxying requests to multiple unclustered Managed Servers. The webapp on the backend server instance consisted an index.jsp and a frameset.jsp. The starting point of the webapp is index.jsp, where a session is created. index.jsp forwards requests using <jsp:forward> to frameset.jsp, which contains a frameset.