Release Notes

 Previous Next Contents View as PDF  

Resolved Problems for Service Packs 1 - 6

The following sections describe problems resolved in previous Service Packs for WebLogic Server 7.0. Service Packs are cumulative; Service Pack 6 contains all the fixes made in earlier Service Packs released for WebLogic Server 7.0. For a description of problems resolved in the most recent Service Pack, see Resolved Problems for Service Pack 7.


WebLogic Server 7.0 Service Pack 6 Solutions

The following sections describe problems that were resolved in WebLogic Server 7.0 Service Pack 6:

Administration Console

Change Request Number



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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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


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.


Change Request Number



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.


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.


Change Request Number



Classloading from within RAR is no longer slow.

Core Server

Change Request Number



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.



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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


Fixed a problem with oneway calls for ReplicationManager.


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


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.


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


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.


Change Request Number



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.


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.


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.


Change Request Number



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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


Change Request Number



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.


Change Request Number



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.


Change Request Number



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.


Please review the security advisory information at


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.


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


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


Change Request Number



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

This has now been resolved.


When an exception occurred, COM sockets were leaking.

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


Change Request Number



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

The problem has now been resolved.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


Change Request Number


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.


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


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.


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.


Change Request Number


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.


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.


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.


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.


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.


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.


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.


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

The problem was resolved with a code fix.


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.


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.


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.


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.


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.


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.


Change Request Number



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.


Change Request Number



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.


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.


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


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.


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.


Change Request Number



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.


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.


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.


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.


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.


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


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.


Change Request Number


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


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

Node Manager

Change Request Number



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


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


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.

Operations, Administration, and Management

Change Request Number



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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


JDBC connection pool cloning was not working.

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


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.


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.


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.


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


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:


instead of the following format:


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


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


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.


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.


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


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


Change Request Number



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.


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.


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.


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.


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.


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


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.


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.


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. Could not parse certificate:

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.


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

The problem was resolved with an internal code fix.


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. Could not parse certificate:

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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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/ were not forwarded.

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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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


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/*>



The tag should be changed to:

<Location /app/>



Following are some commonly used entries in Location tags:

Request matches a certain path:


should be changed to:


Request starts with a certain path:


should be changed to:


Request matches a particular mime type:


should be changed to:



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.


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.


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


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.


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


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.


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.


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.


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.


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


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


Change Request Number



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.


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.


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.


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.


Change Request Number



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.


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.


Change Request Number



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.


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


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.


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.


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.


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


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.


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.


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

Adding synchronization in the TTL cache resolved the issue.


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.


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.


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.


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.


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 for more information.


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.


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.


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


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.


Please review the security advisory information at

CR125592 CR196597

Please review the security advisory information at

CR127930 CR107359

Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Please review the security advisory information at


Change Request Number



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


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


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.


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.


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.


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.


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.


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


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.


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.


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.


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:



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.


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.


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.


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.


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


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


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.

Simple Network Management Protocol (SNMP)

Change Request Number


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.

Web Services

Change Request Number



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


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.


Setting typeMappingFile with autotype did not work as expected.

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



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.


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.


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"));


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.


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


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.


Change Request Number



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.

WebLogic Tuxedo Connector

Change Request Number



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.


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.


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 `' as a dedicated queue for executing WTC applications. If it is not preconfigured and if a system property `' is found to be set, this queue is created (during WTC boot period) explicitly.


A NullPointerException was thrown for WTC request.

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


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.


Change Request Number



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


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.


WebLogic Server 7.0 Service Pack 5 Solutions

The following sections describe problems resolved for the release of WebLogic Server 7.0 Service Pack 5 (SP5). The following list of resolved problems is updated periodically.

Administration Console

Change Request Number



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.


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


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.


Change Request Number



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().


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.


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.


Change Request Number


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 Tunneling result not OK, result: 'DEAD', id: '0' Tunneling result not OK, result: 'DEAD', id: '0'

at weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch(

at weblogic.rjvm.http.HTTPClientJVMConnection.execute(

at weblogic.kernel.ExecuteThread.execute( at> 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.


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.


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.


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.


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.


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.


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


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.


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.


Change Request Number



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.

Core Server

Change Request Number



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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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().


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.


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.


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:[7001,7001,7002,7002 ,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: Connection refused: connect; No available router to destination at weblogic.rjvm.RJVMImpl.getOutputStream( at weblogic.rjvm.RJVMImpl.getRequestStream( at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest( at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(

The problem was solved with a code fix.


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


In previous service packs of WebLogic Server 7.0, an Administration Server started with the command-line options: = 60 = 6 = 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.


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.


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.


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.


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.


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


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.


When calls were made to an EJB using the 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( at javax.rmi.PortableRemoteObject.narrow( at examples.ejb20.timer.webapp.TimerServlet.callEjb( at examples.ejb20.timer.webapp.TimerServlet.access$000( at examples.ejb20.timer.webapp.TimerServlet$MyNotificationListener.handleNotification( at weblogic.time.common.internal.TimerListener$ at at weblogic.time.common.internal.TimerListener.deliverNotification( at at weblogic.time.common.internal.TimerNotification$ at at weblogic.time.common.internal.TimerNotification.execute( at weblogic.kernel.ExecuteThread.execute( at

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.


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.


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.


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.


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.


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.


Change Request Number


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.


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.


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


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.


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.


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.


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.


Change Request Number


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.


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.


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

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


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:


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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
at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(Home

A code change solved the problem.


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.equals( at
WebLogic_CMP_RDBMS_customerOrders_Set.add(CustomerBean_b3dzi6_ at
WebLogic_CMP_RDBMS_customerOrders_Set.addAll(CustomerBean_ at
WebLogic_CMP_RDBMS.setCustomerOrders(CustomerBean_b3dzi6__ at
268) at java.lang.reflect.Method.invoke(Native Method) at
com.zbc.las.framework.core.persistence.EjbHelper.setRelations( at
com.zbc.las.framework.core.persistence.EjbHelper.setRelations( at
setOrders( at


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.


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


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:
vm8ya9_Impl java.lang.ClassCastException:
vm8ya9_Impl at
ExclusiveEntityM at
Keys(TxManager.jav a:749) at
weblogic.ejb20.internal.TxManager.flushModifiedBeans( at
BaseEntityManage 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.


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.


Change Request Number



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.


Change Request Number



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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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( at weblogic.jdbc.common.internal.DataSourceManager.createAndStartDataSource( at weblogic.jdbc.common.internal.JDBCService.addDeployment( at at at at at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at ...

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


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


<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>(



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


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.


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.


Change Request Number



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.


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

A code change resolved the problem.


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.


Change Request Number



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.


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.


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.


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.


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

java weblogic.Admin -url t3:// -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.


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.


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.


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.


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.


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.


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( at weblogic.jms.JMSService.createBackEnd( at weblogic.jms.JMSService.addJMSServer( at weblogic.jms.JMSService.addDeployment( at at 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).


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> <> <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( at weblogic.jms.adapter.JMSManagedConnection.sendEvent( at weblogic.jms.adapter.JMSBaseConnection.throwResourceException( 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 . . .


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 ( at weblogic.jms.adapter.JMSManagedConnection.cleanup( at weblogic.connector.common.internal.XATransResourceFactory.cleanUp ( 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().


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 This exception resulted:

javax.jms.InvalidDestinationException: Destination must be of class: at at weblogic.jms.client.JMSProducer._send( at weblogic.jms.client.JMSProducer.send( at weblogic.jms.adapter.JMSBaseConnection.sendInternal( 71) at weblogic.jms.adapter.JMSBaseConnection.send( at weblogic.jms.adapter.JMSConnectionHandle.send( at java.lang.reflect.Method.invoke(Native Method) at weblogic.connector.common.internal.ConnectionWrapper.invoke(ConnectionWrappe at $Proxy115.send(Unknown Source) at weblogic.jms.bridge.internal.MessagingBridge.onMessageInternal(MessagingBrid at weblogic.jms.bridge.internal.MessagingBridge.onMessage( 1093) at at$

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.


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.


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.


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( at weblogic.jms.common.TextMessageImpl.writeExternal( at at at at at at weblogic.kernel.ExecuteThread.execute( at

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


Change Request Number



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.


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.


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


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.


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.


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.


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.


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="";; %>

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

or sessionScope.dummy == null }">

There is no Session ID!


Which led to the following error:

unclosed string literal


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.


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


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.


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.


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.


Change Request Number



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.


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.


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.


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(

at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(

at weblogic.jdbc.jta.Connection.getXAConn(

at weblogic.jdbc.jta.Connection.prepareStatement( [...]

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.


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.


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 t3://ip_address:port_number: Destination unreachable;

nested exception is: 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.

Node Manager

Change Request Number


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.


Please review the security advisory information at


Please review the security advisory information at

Operations, Administration, and Management

Change Request Number



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


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.


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.


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.


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

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


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.


User identity is now being recorded in auditing log messages.


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


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.


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( at
java.util.HashMap.put( at$XInfo.get( at<init>( at<init>( at<init>( at
at weblogic.jms.frontend.FESession$
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.


The Convert 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"
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD
Web Application 7.0//EN"
"";> CONFIGURATION: WebLogic Server 7.0 SP2


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=""
ListenPort="27023" Machine="MyMachine" Name="m1"
ServerVersion="" StdoutSeverityLevel="64">
<COM Name="m1"/>
<ExecuteQueue Name="default" ThreadCount="15"/> <IIOP Name="m1"/>
<JTAMigratableTarget Cluster="" Name="m1"
<JTARecoveryService Name="m1"/>
<KernelDebug Name="m1"/>
<Log FileName="m1/m1.log" Name="m1"/>
<SSL Name="m1"/> <ServerDebug Name="m1"/> <ServerStartName="m1"
jay1/./NodeManagerClientLogs/jay1_m1/startserver_1061321008754.log" Password="{3DES}7v6S0vZT+xUhhbWkLEq23A=="
/jay1" Username="system"/>
<WebServer Name="m1"/>

The problem was corrected by a code change.


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.



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.


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.


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


Change Request Number



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.


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.


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]: errno = 115

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

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

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

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

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

The problem has been resolved.


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.


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


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.


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.


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.


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.


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.


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


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.


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

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 ''/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.


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: - - [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 ''/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 : 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.


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.


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.


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.


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.


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.


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.


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


    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:

  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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


Change Request Number



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.


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.


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.


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.


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.


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: Serializable readObject method failed error unmarshalling arguments; nested exception is: 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 at javax.rmi.CORBA.Util.mapSystemException( [...]

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.


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.


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.


Change Request Number



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().


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


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.


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.


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


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.


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.


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


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.


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:

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.


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.


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.


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 in the server startup.


Please review the security advisory information at


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


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.


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<init>( at<init>( at<init>( at<init>( at<init>( at ...

The problem was solved with a change to the ttlcache creation code.


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.


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.


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


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.


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.


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.


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


Change Request Number


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.


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


Note: j_character_encoding is not J2EE compliant.

A code change has resolved the problem.


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.


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.


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.


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.


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.


HttpParsing.unescape() decoded the path /foo/..%c0%../ to /foo/.. because 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/..?%..


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


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.


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().


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> Failed to rename log file on attempt to
rotate logs at
weblogic.servlet.logging.LogManagerHttp.rotateLog( at
weblogic.servlet.logging.LogManagerHttp.access$2( at
weblogic.servlet.logging.LogManagerHttp$RotateLogTrigger.trigger( at
weblogic.time.common.internal.ScheduledTrigger.executeLocally( at
weblogic.time.common.internal.ScheduledTrigger.execute( at
weblogic.time.server.ScheduledTrigger.execute( at
weblogic.kernel.ExecuteThread.execute( at
####<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( at
weblogic.servlet.internal.HttpServer.log( at
weblogic.servlet.internal.ServletResponseImpl.send( at
weblogic.servlet.internal.ServletRequestImpl.execute( at
weblogic.kernel.ExecuteThread.execute( at

The problem was solved with a code fix.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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:


This problem was solved with a code fix.


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:

weblogic.servlet.logging.LogManagerHttp.log( at
weblogic.servlet.internal.HttpServer.log( at

The problem was solved with a code fix.


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.


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.


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.


When multiple Web applications were deployed in a Single Sign-On configuration and one application called, 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.


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.

The first time index.jsp is accessed by a proxy server (HTTPClusterServlet), a session is created and a cookie is set in response. When index.jsp forwards to frameset.jsp, new requests (for each JSP in frameset) are sent with the cookie. Intermittently, a cookie is found in the request but the request is sent to a server in server list (other the primary server) and the session is lost. The proxy log has the following entry:

<Thu Aug 21 15:41:15 PDT 2003>: Found cookie: -1339390245
<Thu Aug 21 15:41:15 PDT 2003>: In-bound headers:
<Thu Aug 21 15:41:15 PDT 2003>: Content-Length: 117
<Thu Aug 21 15:41:15 PDT 2003>: #### Trying to connect with server -1189081773!!7201!443

The problem was solved with a change to the logic that updates the server list. When updating a JVMID for the server in the list, now the server is removed from list, updated, and then added back to the list. Simply updating the object did not sort the list.

CR121343, CR133921, CR129538, CR129537, CR174336

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

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


A weblogic.utils.ParsingException occurred when a JSTL end-tag contained a white space between the tag name and the right angle bracket(>). ex. </c:if >:

<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %> Full stack trace:
<Aug 25, 2003 12:46:23 PM EDT> <Error> <HTTP> <101017>
81,name=TempApp,context-path=/TempApp)] Root cause of
ServletException weblogic.utils.ParsingException: Could not
complete parsing, unmatched tags: if otherwise when choose if
forEach if at
weblogic.servlet.jsp.JspLexer.parse( at
weblogic.servlet.jsp.JspParser.doit( at
weblogic.servlet.jsp.JspParser.parse( at
weblogic.servlet.jsp.Jsp2Java.outputs( at
weblogic.utils.compiler.CodeGenerator.generate( ) at
weblogic.servlet.jsp.JspStub.compilePage( at
weblogic.servlet.jsp.JspStub.prepareServlet( at
weblogic.servlet.jsp.JspStub.prepareServlet( at
weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl. java:517) at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm .

The problem was resolved with a code change to allow zero or one occurrence of White Space between an tag's name and '>'.


In previous WebLogic Server 7.0 service packs, it was possible for the server to write standard log entries to a log file before the writing Extended Log Format headers. This situation could occur during a log rotation when multiple threads attempted to write to the new log file at the same time.

The code was fixed to ensure that the thread handling the log rotation has exclusive access to the new log file until after the log headers are written.


The FileServlet returned a response code of 200 instead of 404 when a file was not found. The code was fixed to return 404 when a file is not found.

CR122551, CR122556, CR129248, CR134888

ServletOutputStreamImpl threw the following exception for tunneled requests when the content length was set to -1 and written bytes were 0:

Servlet failed with
Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '-1' bytes.

A code change has resolved the problem.

CR124524, CR127621

The value maxKeepAliveSecs for has been made configurable up to a maximum of 300 seconds.

CR127888, CR111024

A server hung under load while using the cache filter. Analysis revealed that the problem involved unbalanced locked keys with respect to locked scopes.

A code change resolved the problem.


In previous service packs, if you added a serializable servlet request attribute and then overwrote it with a non-serializable value, the original value masked the new one.

A code change has resolved the problem.

Simple Network Management Protocol (SNMP)

Change Request Number



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

A code change has resolved the problem.

Web Applications






During undeployment or redeployment of Web applications, the container was not waiting for inflight Web application requests to be completed. As a result, if a Web application relied on using the context, it encountered an NullPointerException after undeployment, since the context was no longer valid.


As a fix, the -D option (namely, weblogic.http.requestCompletionTimeoutSecs) was introduced in the startup script file. The value given to this flag indicates the number of seconds for the container to wait for finishing inflight work. The default value is 0 seconds; therefore, the container does not wait if this flag is not present.

7.0 SP4

WebLogic Tuxedo Connector

Change Request Number



When CLASSPATH does not include an EJB JAR file, the invocation of a session bean's service method triggers object replication logic which results in a call to TypedFML._tmpresend. If the CARRAY field is null, the _tmpresend records the field length as 0 (instead of FLDID_SIZE + FLDLEN_SIZE). Ultimately, _tmpostrecv is called and assumes the field length is FLDID_SIZE + FLDLEN_SIZE. Because _tmpresend did not record this information, a negative value was read as field length. Currently the check made for field length is to check if it is 0. This is the reason for the NegativeArraySize exception.

Code was added in _tmpostrecv to check the field length and determine whether it is less than or equal to 0.


Multiple tBridge redirects could not be distinguished from each other because there was no Name attribute associated with a redirect.

tBridge redirects now have a configurable Name attribute.


Tuxedo Connector Queuing Bridge wrote debug messages to the WebLogic Server log even when the WebLogic Tuxedo debug option was not set. At intervals specified by the Timeout value in the Administration Console Tuxedo Queuing Bridge Connections tab page, debug messages were logged. For example, when Timeout was set to 60 seconds these debug messages were logged.

####<25-Jun-03 12:49:30 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <59:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0> ####<25-Jun-03 12:50:30 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <60:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0> ####<25-Jun-03 12:51:31 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <61:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0>


The problem was solved by a code change.


The reply message TypedCArray buffer was incorrectly padded with 4-bytes aligned—no padding should occur for a TypedCArray object.

In a test of a tuxedo client making tpcalls to a wtc service using CARRAY message buffer, these results occurred:

  • if wtc service send sback 174 bytes, the tuxedo client receives 176 bytes

  • if wtc service sends back 175 bytes, the tuxedo client receives 176 bytes

  • if wtc service send backs 176 bytes, the tuxedo client receives 176 bytes

  • if wtc service send back s177 bytes, the tuxedo client receives 180 bytes

The problem did not occur when the service was running on another tuxedo domain gateway.

The problem was resolved with a code change.


In the class, while running tpenqueue, the code was checking for null replyQ and replacing it if found with the name of the configured request queue.

This check has been eliminated, and NULL is now a configurable value for replyQ.


The Fchg(FmlKey key, Object value) method in the class did not correctly fill all prior entries with null values as documented.

This problem was resolved with a code fix.

Web Services

Change Request Number



There was no way to create the java.xml.soap.Detail object of the SOAPFaultException exception in version 7.0, as the SOAP Attachments API for Java (SAAJ) was not implemented.

This problem was resolved through a code change which exposed the WebLogic API weblogic.webservice.util.FaultUtil. This code change includes the newDetail() method for creating a Detail object.

Note: the weblogic.webservice.util.FaultUtil API is deprecated in Versions 8.1 and beyond of WebLogic Server. You should use the SAAJ APIs in these versions to create the Detail object.


Custom type mapping file specified by typeMappingFile in clientgen was ignored.

This problem was resolved by setting the custom type mapping file and overriding the default mapping file.


Setting the property in "Setting javax.xml.soap.MessageFactory" in the startWebLogic.cmd script did not work properly for org.xml.sax.driver, org.xml.sax.parser, javax.xml.soap.MessageFactory and javax.xml.rpc.ServiceFactory for JSPs and Servlets.

Following a code change, WebLogic Server checks whether the property is already set before setting it, and sets it to the default value if is not set.


The Apache SOAP client connects correctly to WebLogic Server Web services for methods that take parameters, but for methods without parameters the following error was generated on the server side:

javax.xml.soap.SOAPException: Found SOAPElement ['']. But
was not able to find a Part that is registered with this
Message which corresponds to this SOAPElement

A code change resolved this problem.


Please review the security advisory information at


The class weblogic.xml.schema.binding.FaceUtils was present in webservices.jar but not in webserviceclient.jar. Its absence generated an error when it was declared missing when a client passed complex parameters to a Web server (a list of Java objects, for example).

CR090950, CR172603

Accessing SOAPElement.getElementName() in a client -side handler caused a ClassCastException because the SOAPElement was created with a name class that did not implement javax.xml.soap.Name. The name class is now converted into javax.xml.soap.Name.


The clientgen Ant task was removing the underscore "_" character when it generated Java code from WSDLs. A code change has corrected this problem.


The autotype code generator did not properly handle attributes without types or with anonymous types. A code fix has resolved the problem.


When you start the server with -Dweblogic.webservice.verbose=true, verbose output shows the response XML two times instead of the request and then the response XML. The title of the first output is "Request" even though it shows the response.

Following a code change, the SOAP request and response print correctly to stdout on the server side when Dweblogic.webservice.verbose is turned on.


The WebLogic Server clientgen Ant task was incorrectly allowing hyphens to remain in WSDL files. This caused generated Java code to have class and method names that contained hyphens, which is not legal in java.

A modification to NameUtils now causes clientgen to strip out hyphens. Additionally, for JAXRPC methods and classes, if the resulting string is also a Java keyword, WebLogic Server prepend a _ to it, as per JAXRPC Specifications 1.0 and 1.1


Specifying useServerTypes with multiple services in clientgen did not work properly. If you ran servicegen with multiple service entries to generate a client that specified useServerTypes=true, the type files were not always copied from the Enterprise application for the client, and the generation of the type code removed the "_" from the method names for the getters and setters.

You can now specify more than one service in a servicegen task whose client sets useServerTypes=true. For example, the following will now work:

<target name="ear">





javaClassComponents="com.hp.wsmo.demo.retail.webservice. products.ProductsWS"targetNamespace="http://localhost:70




<client packageName="com.hp.wsmo.demo.retail.client.bea. products" clientJarName="PRODUCTS.jar"

useServerTypes="true" />



javaClassComponents="com.hp.wsmo.demo.retail.webservice. orders.OrdersWS"targetNamespace="http://localhost:7001/ javaclass";




style="rpc"> <client packageName="com.hp.wsmo.demo.retail.client.bea.orders"


useServerTypes="true" />


CR107542, CR136469

In previous 7.0 service packs, only the URL path was used in the Request-Line when writing the request to the socket, and HTTP query and reference parameters in the Web service URI were not being passed to the Web service.

Query and reference parameters, when present, are now appended to the request URI.


When testing a Web service that used Date as an argument, the Web service displayed a security dialog requesting a username and password. The problem did not occur when the argument was changed to a string.

The problem was solved with a code change to eliminate the security dialog and invoke the service correctly when it uses a Date argument.

CR112443, CR109898, CR126134

Passing org.w3c.dom.Document[] as a parameter to a method causes a SOAPException beginning with the following lines:

javax.xml.soap.SOAPException: Found SOAPElement
[<anyType> <this xmlns="mynamespace"> <f:that
xmlns:f="yournamespace"> <or> a lot of random &lt; </or>
<f:the> </f:the> <f:other> foo bar blaz</f:other>
</f:that> </this> </anyType>]. But was not able to find a
Part that is registered with this Message which
corresponds to this SOAPElement ...

A code fix resolved this problem.


In Service Pack 5, WebLogic Server implemented the following previously missing methods for the SOAPHeader class:

  • examineHeaderElements

  • extractHeaderElements

  • examineMustUnderstandHeaderElements

  • examineAllHeaderElements

  • extractAllHeaderElements


A bogus Authorization header in a request caused the Web service engine to try to perform basic authentication even though there were no security constraints defined for the Web application.

A code change has resolved the problem.


In WebLogic Server 7.0 SP02 and SP03, when a user accessed the webservices.basic.statelessSession example Webservice using the client call:

String returnVal = port.sayHello(4, "\n\n <--spaces and

the leading white spaces (new lines and spaces) were stripped off and did not appear on the server side.

The problem was resolved with a code fix.


Problems occurred when char was passed to a Web service operation, whether the client was static, dynamic, or the Web Service Test Home page. Passing char as a parameter resulted in the following assertion error:

     [java] weblogic.utils.AssertionError: *****
ASSERTION FAILED *****[ invalid class: class
java.lang.String ]
     [java] at
     [java] at
weblogic.xml.schema.binding.internal.builtin.JavaCharSerializer.getContentFromObject(      [java] at
weblogic.xml.schema.binding.internal.builtin. XSDSimpleTypeSerializer.writeContentToStream(XSDSimple
     [java] at
     [java] at

The problem was resolved with a code change.

CR121394, CR128988

Calling a method in the Web service through the ISAPI filter caused this exception:

java.lang.IllegalArgumentException: Illegal MimeHeader name or value

A code change has resolved the problem.


Clientgen failed to compile generated classes for an extended type if the base type had a different namespace.

Analysis revealed that the base class from a different package was not being imported. The base class name is now generated with the complete package name, resolving the problem.


WebLogic Server 7.0 Service Pack 4 Solutions

The following sections describe problems resolved for the release of WebLogic Server 7.0 Service Pack 4 (SP4). The following list of resolved problems is updated periodically.

Administration Console

Change Request Number



For a three-node cluster on separate Solaris 2.8 machines, the Administration Server threw an InstanceNotFound exception when accessing the default Execute Queue.

The problem has been resolved.


The Applications Poller sometimes caused high CPU utilization.

The adminMBeanHome.getMBeansByType("Application") now runs only once per poll interval.


Selecting the Details tab in the Security->Realms->CompatibilityRealm->Providers->Adjudicators->RealmAdapterAdjudicator node in the Administration Console while using Compatibility Security caused a

The Details tab was searching for an attribute, RequireUnanimousPermit, which is no longer specified for the RealmAdapterAdjudicator MBean. This problem has been resolved.


WebLogic Server 7.0 previously required specification of the NAME attribute of the MLET element.

To comply with JMX specifications, the NAME attribute is now optional.


In a cluster environment, if the initial context was obtained from a Managed Server to access Mbeans using getMBeansByType, restarting the Administration Server resulted in an exception that began:

java.rmi.ConnectException: This RJVM has already been shutdown

Rebinding JNDI on Managed Server reconnect resolved the problem.


A user belonging only to the Monitor Group was unable to monitor deployments, server states, and clusters. The problem has been resolved.


Change Request Number



Switching from primary server A to secondary server B caused server B to be re-registered as the primary server without re-registering A as secondary. Switching from server A to server B and then back to server A resulted in a stale session.

The primary status of server A is now removed when server B becomes the primary server.


Change Request Number



When a RAR was part of an EAR, redeployment of the EAR failed because the Connector Module code did not handle redeployment properly.

Fixing the redeploy logic in the Connector module resolved the problem.


Change Request Number



ejbc now runs a compliance check that disallows optimistic concurrency for BMP (bean-managed persistence) beans.

Optimistic concurrency is a feature of CMP (container-managed persistence) beans in EJB 2.0. See EJB Concurrency Strategy in The WebLogic Server EJB Container and Supported Services.


The JDBC driver from Microsoft has a limitation whereby for a given result set of rows and columns, the getXXX method can only be called once per row. This limitation applied only if the query columns included a text or image column. WebLogic Server-generated JDBC obtained the key value from a row—for example, using a getLong(1)—and then passed the result set to another routine that read all the column values, including the first, re-executing a getLong(1). This re-execution caused the Microsoft driver to throw an exception.

The problem is resolved by a code fix that avoids parsing the primary key columns in the resultSet twice.


The inclusion of CMR fields in the field-group entry in weblogic-cmp-rdbms-jar.xml caused a compilation failure with the following error:

D:\AA\bea70sp1\weblogic700\samples\server\src\examples\ejb20\relationships\Fathr\EJB_Problem2>java weblogic.ejbc fatherError.jar fathersonError.jar ejbcgen\temp_lr_sahre_jb8\

incompatible types found : <null>

required: int __WL_bean.__WL_isLoaded[null] = true;

1 error

Exec failed .. exiting

The problem has been resolved.


WebLogic Server-generated EJB SQL queries used ">= AND <=" as an operator. IBM DB2 does not handle "<=", and therefore requires "BETWEEN", which is equivalent.

For DB2, generated EJB SQL now uses BETWEEN instead of ">= AND <=", and also handles NOT BETWEEN appropriately.


Change Request Number



The creation of a localDataSource object from information specified in weblogic-application.xml resulted in a NullPointerException.

The method weblogic.jdbc.common.internal.LocalDataSource.defineDriverProps, was not checking for null values for PoolParamsMBean, ConnectionCheckParamsMBean, and XaParamsMBean.

The problem has been resolved.


Change Request Number



The JMS server deleted an expired message from the persistent store when a queue browser still had the message in its reference list, resulting in a paging IO exception.

A code change improved the handling of paging and resolved the problem.


Creating a JMS JDBC store using Microsoft SQLServer 2000 caused an exception if messages were in the queue and you restarted the server.

A change to the order of query and column retrieval resolved the problem.

JSPs and Servlets

Change Request Number



jsp_precompile now works for all kinds of JSPs, including those that extend custom classes.

CR096041, CR108111

WebLogic Server no longer uses redirection (HTTP status code 302) when returning a Welcome file.

WebLogic Server versions prior to 8.1 SP2 and 7.0SP4 were returning a 302 (moved temporary) status code and the location of the Welcome file.

WebLogic Server versions 8.1 SP2, 7.0 SP4 and later return a 200 (OK) status code displaying the content of the Welcome file.

WebLogic Server performance is improved as a result of this change, however the relative URL in the Welcome file may point to a different location which would result in a 404-Not Found error.


JSP code that intended to set double byte characters as a parameter's value—for example:

<jsp:include page="included.jsp">

<jsp:param name="title"

value="<%=\"[double byte characters]\")



—resulted in specified double byte characters being changed to their URL-encoded code. This problem has been resolved.


Change Request Number



The attribute KeepXAConnTillTxComplete, which is required for XA connection pools, now only performs a check if the XA isolation level has changed.

Node Manager

Change Request Number



Node Manager was unable to shut down a Managed Server after the Administration Server restarted.

Node Manager now correctly updates the status of the Managed Server during shutdown.


Change Request Number



Please review the security advisory information at


Please review the security advisory information at


The identity assertion naming convention (WL-PROXY-CLIENT-*) for headers conflicted with WL-PROXY-CLIENT-KEYSIZE, WL-PROXY-SECRET-KEYSIZE and WL-PROXY-CLIENT-IP.

Filtering these headers as identity assertion headers avoided a Client-Cert identity assertion error.


Change Request Number



The weblogic.Admin command did not return the correct exit code when the user and password provided did not authenticate. For example, for a non-existent user:

java weblogic.Admin -username george -password hamilton -url

t3://localhost:7001 lock

This example returned an error message and stack trace indicating that the user did not authenticate, but the exit code indicated success.

This problem has been resolved.

Web Services

Change Request Number



If you used a .NET C# client to access a WebLogic Server Web service and requested two strings returned, the first a result and the second an in/out parameter, the order of the strings returned was incorrect. The second string returned as the result, and the in/out parameter returned as null. A code change ensures that the first accessor returned is the return value.


A client running behind a firewall needed to set properties on a Web service stub.

The problem was resolved by the introduction of two new properties, weblogic.webservice.client.proxyusername and weblogic.webservice.client.proxypassword.


A dynamic client for an SSL-protected Web service did not work when the port number was not included in the endpoint URL.

The default SSL listen port, 443, is now automatically specified.



Some properties set on the stub were not copied into the MessageContext.

After a code change, WebLogic Server now supports the following usecases:

Endpoint can be modified in the following flow:

  • Stub->MessageContext in handleRequest->MessageContext in handleResponse->StubCall->MessageContext in handleRequest->Call

Timeout can be set in the following order:

  • Stub->MessageContext in handleRequest

  • Call->MessageContext in handleRequest


A SOAP response from a document-literal Web service with arrays or user-defined types contained improperly namespace-qualified elements, causing .Net to ignore some data.

The problem was resolved by passing namespace information to those SOAP elements.


Using portable stubs created with the utility caused a NoClassDefFoundError exception.

wsclient70.jar contained the server-side message logger instead of the client-side message logger. An update to wsclient70.jar resolved the problem.


A client created by the clientgen task for a service that returns an array failed when the XML returned from the server did not explicitly indicate the size of the array.

For SOAP arrays of unspecified size, objects are now stored in lists before the array is created.


A missing codecDir in wspackage caused a NullPointerException.

codecDir is not required in wspackage.

The problem has been resolved.


In the weblogic.webservice.binding.soap.HttpResponse class, the method getBodyAsString threw a "String index out of range" error.

A code change causes the method to use the length of the body, instead of the end, resolving the problem.


WebLogic Server 7.0 Service Pack 3 Solutions

The following sections describe problems that were resolved for the release of WebLogic Server 7.0 Service Pack 3.

Administration Console

Change Request Number



You no longer configure the Auto Deployed Enabled attribute on the Domain --> Configuration --> Applications tab in the Administration Console. To control auto deployment behavior, see Auto Deployment in Developing WebLogic Server Applications.


Selecting Server --> Monitoring --> Process Output and selecting any of the view options did not display the output. If you selected the "View Node Manager Output" while the Node Manager was running, the Node Manager would crash.

A code fix resolved the problem.


If you created a Role using the context-sensitive (right-click) menu item "Define Policies and Roles for individual beans..." and added the Role to the Policy (defined using the same context sensitive menu/form sequence) the desired resource could not be used by an external JCom client.

The context-sensitive menu items create a scoped role, and clients outside the scoped role could not use the resource.

Adding a "Define JCom Roles" menu item to the JCom node solved this problem by allowing revision of the scope to include the current client.


Security settings in the Administration Console for Web services did not function properly.

A code change removed the ability to set policy and roles for Web services in the Administration Console.


Realms created by the Administration Console lacked the UserLockoutManager on their RealmMBeans.

The Administration Console now creates a ULMbean when it creates a new realm.


When customers configured a new security realm, the User Lockout tab displayed the message: 'User lockout feature not supported by the configured providers'. This problem resolved by modifying the code to ensure that a User Lockout Manager is created whenever a new security realm is created.


The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close.

Following a code fix, the cursors close.


A new attribute, LogTimeInGMT, was added to the Server -- > Logging --> HTTP console page. This attribute specifies that the time stamp of HTTP log messages is written in Greenwich Mean Time regardless of whether the host computer has specified a different local time zone.


Fixed a problem saving migratable targets for JMS servers where the targets reverted to an earlier setting.


Disabling the SSL Port for a Managed Server from the Administration Console caused an AssertionError that begins:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ ServerIron for server not found ]

Having the validation process check for the configuration MBean on the Managed Server fixed the problem.


The WebLogic Server Administration Console requires you to specify how the WebLogic Security Service should perform security checks. You specify this preference using the fullyDelegateAuthorization flag, a command-line argument that you set when you start WebLogic Server.

When the value of the fullyDelegateAuthorization flag is false, the WebLogic Security Service only performs security checks on URL and EJB resources that have security specified in their associated deployment descriptors (DDs). This is the default setting.

See Understanding the fullyDelegateAuthorization Flag in Securing WebLogic Resources.


The Application tag of config.xml has a LoadOrder attribute that was not settable from the Administration Console.

A code change added the setting to the module pages.


You could not set the LoadOrder attribute in the Application tag in config.xml from the Administration Console.

Adding the LoadOrder attribute to application modules (Application, ConnectorComponent, EJBComponent, WebAppComponent, JDBCPoolComponent) fixed this problem.


In previous Service Packs, when WebLogic Server was installed on NTFS volumes, you could not view the server log in the Administration Console if an alternate log file location was specified. With a log location setting like the following:

<Server Name="myserver" ServerVersion="">

<Log FileName="c:\temp\myserver.log" Name="myserver"/>


the server would throw a

This problem was solved by moving the call for the FileName attribute to a custom getter (breaking a previous dependency on FileStreamHandler), and having the LogFileSearchServlet get the FileName attribute directly from the MBean.


When you tried to clone a new Web application, EJB, or connector on the Examples server, the Administration Console displayed an Unexpected Error page with this message: Path is NULL

The resolution was to remove the Clone icon from ApplicationTable, EJBComponentTable, WebAppComponentTable, ConnectorComponentTable.


You can now configure policies for JMS topics and queues via the Administration Console.


The Administration Console option

Web Application->webapp1->Monitoring->Monitor all Active Web Applications...

was failing for a Web application inside an EAR file.

The problem was resolved with a code fix.


Fixed a problem whereby log messages displayed in the Administration Console were truncating part of the text when using UTF8 encoding.


The Administration Console threw the following AssertionError when you specified 00:00 as the format date for the Rotation Time for the access log:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Could not parse LogRotationTimeBegin: 00:00 because Unparseable date: "00:00" ]

Adding legal validation for the time format in the Log and WebServer MBeans fixed the problem.


Fixed a display problem in the file browser associated with the file converter, in Japanese.


The TransactionLogFileWritePolicy attribute was added in 7.0 SP01, but was never exposed in the Administration Console.

A field for setting this attribute was added to the Server —> Logging —> JTA tab.


After edits to Cookie Max Age Secs using the Administration Console, the value sometimes reverted to the value before the edit.

A code change removing a lower limit to the value fixed the problem.


The waitersTotalCount value was not being decremented, causing the Administration Console to report incorrect values.

Adding a new method, WaiterCurrentCount, resolved the problem.


The Client Cert Proxy Enabled check box was displayed on the Tuning tab for a server, but this attribute is not related to tuning.

The ClientCertProxyEnabled field was relocated to the Configuration —> General tab for a server.


The UserReader MBean did not display users in the Administration Console. An authentication provider can read users in the Console while implementing the UserEditor but with UserReader, the message when trying to display users is "There are no Authentication providers available that support the creation of Users." The same thing was happening for Groups with the GroupEditor and GroupReader interfaces.

The Administration Console was still calling the userEditor.CreateUser method, and never getting to the UserReader.listUsers method.

The MBean has been fixed to look for appropriate provider type.


The WebLogic Server Administration Console was accessible via the Managed Server address and port when the server had been started in MSI (Managed Server Independence) mode.

A code change has restricted this inappropriate access.


The weblogic.Admin utility used the T3 protocol regardless of which protocol you specified. For example, the command "java weblogic.Admin - url http://localhost:7001" used T3 to connect to the server instance listening at localhost:7001.

The utility has been updated to use HTTP or HTTPS if you specify them. Note that you must enable HTTP tunneling if you want to use these protocols. See "Configuring the HTTP Protocol" in the Administration Console Help.


Change Request Number



The Node Manager was writing an unnecessary stack trace on shutdown of a Managed Server running under an Administration Server under certain conditions.

The problem occurred because - HttpUrlConnection.getInputStream doesn't return because the Managed Server waits for a certain period of time before returning the response to a query. This was intentional behavior to provide almost continuous monitoring of the Managed Server. When the Managed Server shut down, however, the delayed servlet response was not sent and the socket was closed. The Node Manager subsequently tried to re-open the connection but failed to connect in openServer call because the server was not there. In response to this, a ConnectException was thrown and logged by openServer.

The Node Manager no longer writes the unnecessary stack trace.


A stack trace resulted from a error looking up a session. A secondary server instance was being shutdown. While making a log entry for a request it served, the HTTP server tried to get the user information from the session. As a result it tried to look up the secondary server even though it was down, resulting in this stack trace.

<Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking
up session for
net!8001!7002 java.rmi.ConnectIOException: Server is being shut
down Start server side stack trace: java.rmi.ConnectIOException:
Server is being shut down at
weblogic.rjvm.RJVMImpl.dispatchRequest( at
weblogic.rjvm.RJVMImpl.dispatch( at...

The primary server correctly selected a new secondary from the available server list, and no session data was lost.

This problem was resolved with a code fix. Now, the server obtains user information from ThreadLocal, instead of the session.


Please review the security advisory information at


The following sequence was causing a ClassCastException: define a server, assign that server to a cluster, create a Unix machine with the same name as the server, assign them to each other, stop and restart the Administration Server, and select the server name from the cluster or from the Servers list. Trying to bring up the Managed Server also caused a ClassCastException.

Fixing a problem in a process that resolves an UnresolvedMBean during startup solved this problem.


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

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


Starting a new Managed Server in a cluster that contained two running Managed Servers caused a ConcurrentModificationException on one of the running servers.

A code change fixed the problem by making the members of a cluster meet synchronization requirements.


If two clusters have between them two distributed queues with the same JNDI name, and a message-driven bean is deployed on both the clusters, messages were being consumed in only one of the clusters.

A message-driven bean now goes through the entire collection of distributed queues in a domain and adds their members appropriately.


An Administration Server and two Managed Servers were in a cluster. Application application1.ear contained EJBs and Web applications. The EJBs were deployed to the cluster. The Web applications were deployed to a VirtualHost, which was in turn targeted to the cluster.

application1.ear contained application1.war, which was configured as DefaultWebApp of the VirtualHost. In addition to this, each cluster node had its own DefaultWebApp.

Deployment succeeded, but attempts to undeploy application1.ear resulted in the exception below, and the application could not be redeployed, even if the entire domain was restarted.

Exception caught for task Unprepare application application1 on
mycluster,application1: Start server side stack trace:
java.lang.reflect.InvocationTargetException: listener:

The Web container was trying to undeploy its DefaultWebApp with the undeployment of every WAR. The first WAR succeeded and the second WAR failed because the DefaultWebApp is already undeployed.

The code was changed so that if no context for the targeted Web application exists on the http server, the default Web application is not undeployed. This resolved the problem.


In a cluster, if you set the value '0' for MulticastTTL, WebLogic Server ignored the setting and took the default value as 1, throwing an error like the following:

"clusterdomain:Name=mycluster,Type=Cluster" is smaller than the
minimum allowed: 1

A code change resolved the problem by allowing the value to be `0'.

CR134233, CR102655

In WebLogic Server 6.1 SP04, session replication stopped working after a failure to replicate a non-serialized object. Invocation of a JSP that tried to set non-serialized data into the session object, resulted in the expected exception:

<Mar 19, 2003 2:58:23 PM PST> <Error> <Cluster> <All session
objects should be serializable to replicate. Please check the
objects in your session. Failed to replicate non serializable

Then, for all subsequent requests, sessions were not replicated, and this exception occurred:

<Mar 19, 2003 2:58:48 PM PST> <Debug> <Cluster> <Unable to create
secondary for -8956818414963087828>

The problem was solved with a code change. Now, when a non-serializable object is encountered, the method returns, instead of trying other secondaries.


To prevent an incorrect port number from being constructed in the HomeHandleImpl class while constructing the URL in NetworkChannel between two Managed Servers, listenPort and sslListenPort are now initialized with default values.


Change Request Number



A configuration exception was thrown when deploying a RAR if max-capacity and initial-capacity are equal.

The check for capacity-increment in .xpi for weblogic-ra.xml was altered so that its value is not considered when max-capacity and initial-capacity are equal. Also, the capacity increment can now be set to zero if max-capacity and initial-capacity are equal.


Unexplainable log messages appeared in the Connector log file, for example: "Unable to locate context: java:/comp/env/WebLogic Server-connector-resref".

The Connector team eliminated voluminous logging messages as an enhancement.


The Weblogic Server embedded LDAP server stopped replicating data to Managed Servers after redeploying the connector RAR file.

A code change causes improved replication behavior.


In versions of WebLogic Server prior to 7.0 SP3, using JCE threw a java.lang.ClassCastException with java.naming.CompositeName was thrown. When using JCA in WebLogic Server 8.1, resource-ref entries (Auth, SharingScope) returned null for Web applications.

This problem occurred because of an internal error, and was resolved with a code fix.


When using JCA in versions of WebLogic Server prior to 7.0 SP3, a java.lang.ClassCastException with java.naming.CompositeName was thrown. When using JCA in WebLogic Server 8.1, resource-ref entries (Auth, SharingScope) returned null for Web applications.

This problem occurred because of an internal error, and was resolved with a code fix.


A client invoked a method on an EJB. When the connection failed between the ManagedConnection (MC) and the EIS while in XA transaction state, the container called XAResource.rollback and ManagedConnection.cleanup every 60 seconds after the transaction had already been rolled back. Subsequent calls made to the EIS resulted in a java.lang.NullPointerException exception:

<Mar 21, 2003 5:50:52 PM PST> <Error> <Connector> <190041> << JCA Resource Adapter for ClearPath MCP_eis/comsRAJNDINAMEBrazil > The returned ManagedConnection instance is null> <Mar 21, 2003 5:50:52 PM PST> <Info> <EJB> <010051> <EJB Exception during invocation from home: drummer.CedarBank.CedarBankBeanBrazil_ris6bf_HomeImpl@12fc36 threw exception: java.lang.NullPointerException java.lang.NullPointerException at drummer.CedarBank.CedarBankBeanBrazil.cedarBank( at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl.cedarBank( at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl_WebLogic Serverkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke( at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke( at weblogic.rmi.internal.BasicServerRef$ at at weblogic.rmi.internal.BasicServerRef.handleRequest( at weblogic.rmi.internal.BasicExecuteRequest.execute( at weblogic.kernel.ExecuteThread.execute( at

WebLogic Server had failed to wait for the transaction to complete before trying to destroy the connection.

A code fix resolved the problem.


During deployment of a RAR that uses the ra-link-ref element, called a 'logical' RAR, the logical RAR deployment was not getting the correct pool name or max-capacity as specified in its weblogic-ra.xml deployment descriptor. This caused unexpected behavior in WebLogic Integration.

The element now functions properly.

Core Server

Change Request Number



JDK1.3.1 introduced the following methods in getInstanceFollowRedirects() and setInstanceFollowRedirects().These methods can be used to disable URL redirects for a specific HttpURLConnection. HttpURLConnection was ignoring the flag set by setInstanceFollowRedirects().

The problem was solved by a code fix to WebLogic Server's HttpURLConnection redirect logic to ensure process redirects in accordance with the setting of InstanceFollowRedirects.


When the security manager in WebLogic Server was enabled and a policy file was set, the path /usr/lib was being prepended to javac during JSP compilation, resulting in a

Executable.resolveExecutable() was searching the wrong path when trying to determine the location of the javac compiler.

The code was changed so that Executable.resolveExecutable() searches the absolute path specified in JavaCompiler before searching java.library.path.


In WebLogic Server 6.1 SP03, stopping a Managed Server after its Administration Server was shut down caused an exception. The problem occurred with this sequence of actions:

  1. Start an Administration Server and a Managed Server.

  2. Shut down the Administration Server.

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

This exception resulted:

Unexpected Exception Start server side stack trace: java.rmi.ConnectException: Unable to get direct or routed connection to: '-19546889165621794S:dwarkamai:[7001,7001,-1,-1,7001,-1,-1]:OAMdomain:adminServer' at weblogic.rmi.internal.BasicOutboundRequest.sendReceive( at weblogic.rmi.internal.BasicRemoteRef.invoke( at...

The shutdown command from weblogic.Admin was successful.

The problem was resolved by catching the exception that occurs when shutting down a Managed Server after the Administration Server is down.


Provided a code fix to allow the NTSockedMuxer to support Windows XP.


Failures occurred due to NoSuchObjectExceptions when attempting to get a connection from a data source on the client. This message was thrown:

Error dropping table: Unexpected Exception java.rmi.NoSuch ObjectException: The object identified by: '275' could not be found. Either it was has not been exported or it has been collected by the distributed garbage collector. at weblogic.rjvm.BasicOutboundRequest.sendReceive( at weblogic.rmi.internal.BasicRemoteRef.
invoke( weblogic.jdbc.common.
internal.RmiDataSource_WebLogic Servertub.getConnection(Unknown Source)
at com.bea.cts.CTSDeployment.executeSQL(CTSDeployment.
java:2445)at com.bea.cts.CTSDeployment.undeploy(CTS at com.sun.cts.harness.Suite
Synchronizer.continueToUndeployApps( at com.sun.cts.harness.SuiteSynchronizer.
undeployApps( at com.sun.cts.
harness.SuiteSynchronizer.doDeployment( at com.sun.cts.harness.CTSGUIHarnessObserver.
starting( at javasoft.sqe.
javatest.TestRunner$Notifier.starting( at javasoft.sqe.javatest.TestRunner$Worker.runTest
( javasoft.sqe.javatest.TestRunner$

Analysis revealed that the data source was garbage collected, although the client still had a reference to it.

The problem was solved by a code fix to garbage collection, to ensure that objects that clients refer to are not garbage collected.


Changes to the Enable Tunneling attribute in the WebLogic console require a server restart for the new value to take effect.

The problems was solved by a code fix that allows the user to enable tunneling without restarting the server.

CR087808, CR095487

On a Sunblade 100 single-CUP Solaris machine, two independent server instances could not look up InitialContext on each other. After one server instance looked up InitialContext, and a second server instance on the same machine tried to look up InitialContext on the same machine this exception resulted:

<2002/10/09 4:23:56:JST> <Debug> <ConnectionManager> <Attempt to sendMsg using a closed connection> javax.naming.CommunicationException. Root exception is java.rmi.ConnectException: Attempt to sendMsg using a closed connection at weblogic.rmi.internal.BasicOutboundRequest.sendReceive( at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke( at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke( at weblogic.rmi.internal.ProxyStub.invoke( at $Proxy45.lookup(Unknown Source) at weblogic.jndi.internal.WLContextImpl.lookup( at javax.naming.InitialContext.lookup( at com.bea.samples.servlet.TestServlet.service( at javax.servlet.http.HttpServlet.service( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.WebAppServletContext.invokeServlet( at weblogic.servlet.internal.ServletRequestImpl.execute( at weblogic.kernel.ExecuteThread.execute( at

The problem was not replicated on Sun Enterprise. The problem did not occur on Sun Blade, if the lookup was done using an IP address instead of localhost.

Analysis indicated that client RJVM tried to close duplicate T3JVMConnections. It issued a CMD_REQUEST_CLOSE to the server and closed the RJVM. However, if the server queued this message, then the RJVM was marked as closed.

A code change prevents RJVM shutdown when detecting duplicate connections, and CMD_REQUEST_CLOSE does not get delivered to server.


The WebLogic Server Administration Console does not provide connection information when starting the Administration Server and Managed Servers via the Node Manager.

A code fix allows the user view the connection information by right clicking the server name in the navigation tree and selecting View Connections.


Users can now throttle incoming traffic by limiting the request queue waiting for execute queue, with the -D flag.


Methods that access COMMO beans via the CommoMBeanServerProxy class from a client virtual machine sometimes triggered a Null Pointer Exception when attempting to ascertain whether an ObjectName was an MBean instance or an MBean Type object name, after the code that set the value for "bean" had already been bypassed by Kernel.isServer().

A code change prevents the premature bypass.


In WebLogic Server 6.1 SP02, hangs occurred frequently because socket reader threads were blocked. The thread that owned the POLL lock was attempting to close an SSL socket, but could not progress because it could not obtain the lock on the output stream required in the sendRecord() method. The following stack trace:

"ExecuteThread: '23' for queue: 'default'" daemon prio=5 tid=0x6d6c40 nid=0x24 waiting for monitor entry [0xe4e81000..0xe4e81a28] at at at at at weblogic.socket.SocketMuxer.closeSocket(

A code fix ensures that SSL sockets do not write data to sockets on close for abortive shutdowns.


Thread dump error occurred with this configuration:

VM: java.version='1.3.1_02''windows 2000'


Thread dumps failed because the JVM_DumpAllStacks symbol had not been globally declared for Hotspot client and Version 1.3.1_x virtual machines.

Thread dumps using weblogic.Admin are now possible with 1.3.1_X hotspot client/server JVMs.


An internal problem with the servlet container caused a source to be returned even if the class could not be loaded. This was discovered while testing a WebLogic Server 7.0SP2 client which got a database connection from a JDBC connection pool on a WebLogic Server 8.1 server. The error prevented the client from getting the database connection.

The problem was resolved with a code fix.


A code fix resolved a problem in which the server was shut down properly while the client sees an error message "Server XYZ failed to shutdown successfully ...".


WebLogic Server native libraries on HPUX were being compiled using cfront, instead of aCC. aCC is the ANSI C compiler which replaced cfront in 1998.

As a result incompatible runtime libraries were loaded(libC.2 from cfront compilation, and libCsup.2 from SUN's Java, compiled with aCC). Incompatible runtime libraries can cause crashes.

The problem was solved by changing WebLogic Server builds to use aCC for hpux11.


A t3 client attempting multiple getInitialContext() calls with different server URLs that refer to the same server. In a normal situation, the client determines that it is a duplicate connection, sends a CLOSE message to the server and shuts its own end of the connection. The server will remove this duplicate connection. In some situations, the CLOSE message gets queued because of an asynchronous IDENTIFY request and the client closes its end of the connection without waiting for the CLOSE message to be delivered. The server detects that this socket has been removed and issues a shutdown on the ConnectionManager which shuts down the otherwise healthy RJVM.

A code fix prevents RJVM shutdown when closing duplicate connections when a CLOSE message does not get delivered.


A system with an Administration Server and two Managed Servers in a cluster has trouble restarting a Managed Server. After rebooting the machine on which one of the Managed Servers is running, the Managed Server is fails to restart and the following exception is thrown:

<Jan 22, 2003 5:27:49 PM EST> <Error> <Deployer> <149204> <The Deployment framework was unable to register with the Data Replication Service. RegisterException due to underlying exception java.rmi.RemoteException: Failed to send message to URL t3://admtest1:7001; nested exception is: myDomain:Location=AdminServer,Name=***servername***,ServerRuntime=AdminServer,Type=DeploymentTaskRuntime

This problem was solved by a code fix to allow the Managed Server to load applications based on the configuration MBeans.


A startup class that calls one EJB business method on doSomethingOnA of BeanA. This method gets the home interface for BeanB and this leads to the following ClassCastException:

<29 janv. 03 13:21:19 CET> <Info> <EJB> <010051> <EJB Exception during invocation from home: test_ccex.a.BeanABean_124zg1_HomeImpl@5c5ca2 threw exception: java.lang.ClassCastException: Cannot narrow remote object to test_ccex.b.BeanBHome java.lang.ClassCastException: Cannot narrow remote object to est_ccex.b.BeanBHo me at weblogic.iiop.PortableRemoteObjectDelegateImpl.narrow(Portabl at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.ja va:132) at test_ccex.a.BeanABean.doSomethingOnA( at test_ccex.a.BeanABean_124zg1_EOImpl.doSomethingOnA(BeanABean_ at java.lang.reflect.Method.invoke(Native Method) at at weblogic.t3.srvr.StartupClassRunner.invokeStartup(StartupClas at weblogic.t3.srvr.StartupClassRunner.invokeClass(StartupClassR at weblogic.t3.srvr.StartupClassRunner.access$0(StartupClassRunn at weblogic.t3.srvr.StartupClassRunner$ java:86) at at va:71) at

A code fix resolved a classloading issue in RemoteObjectReplacer.


When using a custom realm that made many outbound RMI calls, the reader threads became blocked by making outbound calls, leaving no threads for reading the response. This happens from the BootServicesImpl.invoke method from within the RJVM layer on a reader thread.

BootServicesImpl was moved into the RMI layer so that it can dispatch to the default execute queue.







When closing duplicate t3 connections, there was a chance that the threads (the PosixSocketMuxer and RJVM ConnectionManager) could enter a deadlock state because of the order is which locks are acquired.

The FDRecord lock is no longer held during dispatching the requests in the muxer.


A java.lang.ClassCastException was thrown when the home interface was narrowed using PortableRemoteObject after looking it up from the InitialContext.

A code fix correctly narrowed the returned types.


The use of was inconsistent with the way server resources were created in the Administration Console and with the documentation. When used to secure a T3 server, the name of the WebLogic resource was always "T3Srvr." In all other cases, the name of the server being acted upon was used as the name of the WebLogic resource.

This problem was resolved by always using the name of the server being acted upon as the name of the WebLogic resource.


With connection filtering enabled, Connection rejected messages accumulated and filled up the log file.

The new ConnectionLogger property lets users configure whether to log such messages to the log file.


The CoreHealthMonitor was holding the ExecuteThreadManager lock while performing significant work, resulting in deadlocks and Administration Console freezes. The code was changed so that CoreHealthMontor now uses ExecuteThreadRuntimeMBean to get a list of stuck threads and avoids logging from all places in the ExecuteThreadManager if ETM lock is held.


A t3 client would time out while getting an InitialContext from a clustered EJB via a content switch, and the following exception was thrown:

javax.naming.CommunicationException. Root exception is t3:// Bootstrap to:' over: 't3' got an error or timed out at weblogic.rjvm.RJVMFinder.findOrCreate( at weblogic.rjvm.ServerURL.findOrCreateRJVM( at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext( at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext( at weblogic.jndi.WLInitialContextFactory.getInitialContext( at javax.naming.spi.NamingManager.getInitialContext( at javax.naming.InitialContext.getDefaultInitCtx( at javax.naming.InitialContext.init( at javax.naming.InitialContext.<init>( at Test.main(

Including support for t3 clients with load balancers resolved this problem.


Child threads of WebLogic Server execute threads were not inheriting the correct context classloader. This problem was common when a servlet or an EJB created a timer (java.util.Timer).

WebLogic Server execute threads maintain their own context classloader and child thread of these execute threads will not inherit since java.lang.Thread directly assigns the member variable of its own to the child threads.

Setting the same context classloader to java.lang.Thread resolved this problem.


Change Request Number



The weblogic.Deployer utility generated "alternate descriptor" errors when deploying an EAR file. For example:

Module: module_name     Error: Alternative descriptor descriptor_name can't be found.

This problem occurred because WebLogic Server did not look for the descriptor files in the directory where the EAR was extracted.

weblogic.Deployer was fixed to correctly deploy EARs.


All Managed Servers in a domain automatically redeployed EJBs when you restarted the domain's Administration Server.

A code fix ensures that restarting an Administration Server does not redeploy EJBs on the domain's Managed Servers.


WebLogic Server required an incorrect CODEBASE value to access applets deployed as part of an EAR file. For example, an applet packaged inside a Web Application, MyWar.war, and deployed as part of an EAR file, MyEar.ear, required a CODEBASE similar to:

CODEBASE=/bea_WebLogic Server_internal/classes/MyEar@MyWar.war

Where MyWar.war is the name of the WAR file that contains the applet. This was required even if the Web Application explicitly defined a CONTEXT-ROOT of MyWar. This problem occurred because WebLogic Server deployed using the URI of the Web Application, rather than its CONTEXT-ROOT.

The code was fixed to deploy Web Applications using the CONTEXT-ROOT, if one is specified the EAR file's application.xml descriptor. For example, if the above EAR file specified a CONTEXT-ROOT of MyWar for the Web Application, the correct CODEBASE for the applet would be:

CODEBASE=/bea_WebLogic Server_internal/classes/MyEar@MyWar


Refreshing a Web application with weblogic.Deployer (with -activate -upload flags) was not working properly.The web app was deactivated, rolled back and destroyed before being loaded. This was a regression introduced by another fix.

The code was changed to roll back the Web application under the appropriate circumstances.


When the Web container is Tomcat 4.0 and the EJB container is WebLogic Server7.0SP1, and two Web applications which have different names and use different classloaders but the same classes are deployed on Tomcat, the first Web application is able to invoke the EJB, but the second Web application fails to invoke it, with a ClassCastException.

A new -D flag enforces clients to generate stubs on the context classloader. The -D flag is as follows:



Deleting a Web application from a Managed Server that had been stopped resulted in errors similar to the following:

<Warning> <Management> <149311> <Rejecting deployment operations to non-running server, mgd1>

<Warning> <Deployer> <149004> <Failures detected initiating Rejecting deployment operations to non-running server, mgd1 task for application Remove application MyWebApp on mgd1>

The Web application was not deleted.

A code change fixed the problem by eliminating dangling WebAppComponentMBean references from the WebServer and VirtualHost MBeans.


Web applications in an EAR deployed to a VirtualHost did not redeploy on domain restart.

A code change has resolved the problem so that applications that target a Virtual Host restart when the domain restarts.


Please review the security advisory information at

Domain Configuration Wizard

Change Request Number



In WebLogic Server 7.0 SP2, Configuration Wizard templates used in Silent Mode created unusable domains.

A code change to silent.xml fixed the problem.


Change Request Number



CMP entity EJBs did not time out when corresponding rows in the database were locked with a select for update or update statement. The code was changed so that a cancel is sent to any running JDBC Statements before rolling back the transaction. The EJBs now time out when the transaction timeout happens even if the corresponding rows in the database are locked.


The following error was thrown when the EJB Container tried to verify the existence of database tables and columns that did not exist:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[
Table: Cmp_Birthday Full Table Check failed, but table all columns
were found! ] at
TableVe at

The problem was solved with a code fix.


EJB Query Language (EJB-QL) now supports case-insensitive searching with the new Upper and Lower functions.




A Finder method did not find updates made inside a transaction when the concurrency strategy was Optimistic; that is, the include-updates functionality was failing.

The code was changed so that include-updates works with an Optimistic concurrency strategy, for Oracle databases.


A client called a stateless session bean, which in turn called a bean-managed persistence entity bean. The entity bean returned a TreeMap to the session bean. This provoked the following exception under load conditions:

Tue Jul 16 11:46:54 PDT 2002:<E> <Adapter> Exception thrown by rmi
62] java.util.ConcurrentModificationException at
java.util.TreeMap$ at
java.util.TreeMap.writeObject( at
java.lang.reflect.Method.invoke(Native Method) at

Analysis revealed that the entity bean began processing a subsequent call before the current call to TreeMap's WriteObject() method had completed serialization of the object and returned, resulting in the ConcurrentModificationException. This behavior resulted from the bean being locked at the EJB container layer and serialized at the RMI layer.

The problem was resolved by using RMI activation callbacks to return EJBs back to the pool.


A stateless session bean in a cluster with stateless-bean-is-clusterable set to False generated errors such as the following:

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

The JNDI bindings are no longer replicated for the non-clustered stubs.


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


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

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

A code fix ensures that JNDI bindings for non-clustered stubs are not replicated.

CR088156, CR124471

When the PersistenceManagerImpl.releaseResources() method was closed, JDBC statements whose connection was being used in another thread—weblogic.transaction.internal.ServerTransactionImpl.commit()— to commit the transaction, the following deadlock resulted:

FOUND A JAVA LEVEL DEADLOCK: ----------------------------
"ExecuteThread: '180' for queue: 'default'": waiting to lock
monitor 0xcbb28 (object 0xdee1d070, a
oracle.jdbc.driver.OraclePreparedStatement), which is locked by
"ExecuteThread: '73' for queue: 'default'" "ExecuteThread: '73'
for queue: 'default'": waiting to lock monitor 0xcbc78 (object
0xdec416b8, a oracle.jdbc.driver.OracleConnection), which is
locked by "ExecuteThread: '180' for queue: 'default'"

Research revealed that the EJB container was closing statements prematurely. The code was changed so that PersistenceManagerImpl.releaseResources() closes the statements at the appropriate time.


When calling context.getCallerPrincipal() from ejbStore() using UserTransaction context, the following exception was thrown:

<Oct 24, 2002 5:52:24 AM PDT> <Info> <EJB> <Exception from
ejbStore:javax.ejb.EJBException: ejbStore:
nulljavax.ejb.EJBException: ejbStore: null at

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


The -classpath option to weblogic.ejbc, which sets a CLASSPATH used during compilation and overrides the system or shell CLASSPATH, now works. Previously, it was failing with the following errors:

"ERROR: Error from ejbc: Unable to load a class specified in your
ejb-jar.xml: examples.ejb20.basic.statelessSession.TraderBean"

"ERROR: ejbc found errors"


WebLogic Server called ejbload() incorrectly for a clustered container-managed persistence bean deployed to a WebLogic Server cluster; ejbLoad() was called for the bean each time the bean was requested, after the EJB had been modified from another server in the same cluster.

The concurrency strategy was Optimistic and both cache-between-transactions and home-is-clusterable were enabled.

This problem occurred because the bean's state was not correctly updated after the first call to ejbLoad().

The code was fixed to correctly update the bean state.


An EJB specified an isolation level in its descriptor, and got an exception at runtime. WebLogic Server was checking for the wrong vendor workaround; it was checking for supportsTxIsolation instead of supportsTxIsolationUponEnlistment. In addition, different database vendors and drivers have different rules and behaviors when (re)setting the isolation level while the transaction is active. For example, when using the WebLogic Server jDriver/XA for Oracle, the isolation level can only be set when creating the transaction branch, but not when joining or resuming the branch.

Code changes rectified both problems.


When a stateless session bean with max-beans-free-pool set to No LIMIT was copied to the applications directory during deployment, the deployment failed with the following error:

<Nov 5, 2002 4:59:00 PM EST> <Error> <Deployer> <BEA-149201> <The
Slave Deployer failed to complete the deployment task with id 7
for the application _appsdir_BasicStatelessTraderBean_jar. Prepare failed. Task Id
= 7 { Module Name: BasicStatelessTraderBean, Error:
[EJB:011025]The XML parser encountered an error in your deployment
descriptor. Please ensure that your DOCTYPE is correct. You may
wish to compare your deployment descriptors with the WebLogic S
erver examples to ensure the format is correct. The error was:
x-beans-in- free-pool.: [EJB:010136]Param must be an integer.

The problem was with parsing the white space in "NO LIMIT."

The code was fixed so that if max-beans-in-free-pool is specified as NO LIMIT, it is now set to a maximum value of int.


The Administration Console incorrectly reported, in the Waiter Total Count field, the number of clients waiting for access to entity beans with exclusive concurrency and stateful session beans. This count is now correctly decremented when a client acquires the lock or times out.


A stateless session bean attempted to update related beans. After the transaction had been rolled back due to an Oracle constraint violation SQL Exception, an attempt to access the stateless session bean triggered this error:

com.cpships.ecomm.exception.FatalException: EJB Exception: javax.ejb.TransactionRolledbackLocalException: Illegal Reentrant call to RelatedCompanyHomeRemote with primary key: 30: weblogic.ejb20.InternalException: Illegal Reentrant call to RelatedCompanyHomeRemote with primary key: 30

Research determined that after the weblogic.ejb20.manager.DBManager.remove() method was executed, the setBusy flag, which determines whether or not the bean can be used (that is, whether or not the bean is busy), was not correctly reset to False.

This problem was fixed.


ejbc code generation failed for four-level relationship caching, with the following exception:

Found 4 semantic errors compiling
cmr_orders/": 789.
if (__WL_bean__orderLines != null) <-------------------> ***
Error: No entity named "__WL_bean__orderLines" was found in this
environment. 791.
<-------------------> *** Error: "__WL_bean__orderLines" is
either a misplaced package name or a non-existent entity. 1310.
if (__WL_bean__orderLines != null) { <-------------------> ***
Error: No entity named "__WL_bean__orderLines" was found in this
environment. 1312.
<-------------------> *** Error: "__WL_bean__orderLines" is
either a misplaced package name or a non-existent entity.

Analysis revealed that trimmed an extra character when creating the prevCmrFieldName string, if caching was more than three levels.

A fix to solved the problem.


When message-driven beans using external InitialContextFactory() calls for lookups made repeated connection attempts and the JMS
provider was inaccessible, connections and other resources accumulated rapidly, draining server resources.

Further research revealed that JMSConnectionPoller() was not properly closing its InitialContexts. This problem was fixed in the code.


When a container-managed relationship Finder method was executed, WebLogic Server incorrectly attempted to load the state from the database for second accesses to same the entity EJBs, even though the EJBs had cache-between-transactions set to True and were using Optimistic concurrency. This problem was fixed in the code.


BMP entity bean handling was changed to conform to the EJB 2.0 specification. Per the EJB specification, the EJB container now synchronizes the entity bean state—by invoking EJBStore—before running a Finder method. This does not affect the findByPrimaryKey method.


In WebLogic Server 6.1 SP3, read-only EJBs with a many-to-one container-managed relationship caused a LockTimedOutException.

The problem was resolved by modifying the if condition check from rdb.isReadOnly() to READONLY_EXCLUSIVE_CONCURRENCY check.



Two beans with a container-managed relationship of one-to-one were created in the same transaction. A ghost SQL SELECT statement was issued, even though the delay-database-insert-until was set to Commit for both beans. In high-volume situations, the true benefit of batch insert was not realized because of the extra SELECT, resulting in inferior performance.

The code was changed so that the extra SELECT is no longer issued.


If a create was attempted for an entity EJB but then failed, the Pool Beans in Use Count reported in the Administration Console was incremented as if the create operation had succeeded.

This problem has been fixed.


If an EJB contained more than one attribute with a String[], the ejbc compiler would throw the following error:

C:\public\383031>java weblogic.ejbc
__WebLogic_CMP_R byteArray is already defined in
ejbFindByPrimaryKey(java.lang.Str ing) byte[] byteArray =
__WL_rs.getBytes(5); ^
__WebLogic_CMP_R byteArray is already defined in
ejbFindAccount(double) byte[] byteArray = __WL_rs.getBytes(5); ^
__WebLogic_CMP_R byteArray is already defined in
ejbFindBigAccounts(double) byte[] byteArray =
__WL_rs.getBytes(5); ^
__WebLogic_CMP_R byteArray is already defined in
ejbFindNullAccounts() byte[] byteArray = __WL_rs.getBytes(5); ^
__WebLogic_CMP_R byteArray is already defined in
ejbLoad() byte[] byteArray = __WL_rs.getBytes(5); ^ 5 errors Exec
failed .. exiting

This problem occurred only with EJB 1.1.

The code was changed so that unique variables are created for byte arrays in the generated code.


EJB deployment descriptors can be bound and referenced using the token "${APPNAME}" in the JNDI name. But the LocalJNDI Name did not support the "${APPNAME}" token to be resolved at deployment time. Now LocalJNDI name is transformed for the application name token replacement during deployment.


Attempts to deploy a stateful session EJB in WebLogic Server 7.0 SP1 failed with the following ClassCastException:

Unable to deploy EJB: MetaDataBS from
csam_dcf3_server_ejb_depl.jar: java.lang.ClassCastException:
weblogic.ejb20.deployer.SessionBeanInfoImpl at
ptors( at
weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.prepare(Client at
va:1041) at
5) at
weblogic.ejb20.deployer.EJBModule.prepare( at
weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplica at
weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationCo at
weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationCo at
k( at at
weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallba at
weblogic.kernel.ExecuteThread.execute( at

The problem occurred because setMethodDescriptors() was incorrectly identifying session beans as entity beans.

The problem has been fixed.


If, within the same transaction, delay-database-until-insert was set to Commit and ejbRemove() was called, the attempt to remove the bean would fail with a java.rmi.NoSuchObjectException.

The code was changed to check the container cache to remove the bean when delay-database-insert-until is set to Commit.


In a clustered configuration and with an Not Recently Used (NRU) caching strategy, the container was not passivating a stateful session bean correctly when the number of bean instances instantiated exceeded max-beans-in-cache.

In a clustered environment, WebLogic Server uses a ReplicatedStatefulSessionManager to create a new NRUCache.

Research revealed that the Replicated Stateful SessionManager did not register itself with the cache and therefore beans were not moved from the active to the inactive and then to the free queue correctly, resulting in CacheFullExceptions.

A code fix resolved the problem.


The idle-timeout-seconds element determined how long the EJB container waits before passivating stateful session beans, that is, removing them from cache and writing them to disk. The EJB container also used this element to determine how long to wait before removing passivated EJBs from the disk. However, some users wanted stateful session beans to remain on disk longer than idle-timeout-seconds. They wanted to specify how long stateful session beans stay idle in the cache and how long they stay idle on disk using two different elements.

WebLogic Server 7.0 Service Pack 3 introduces the new element session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk.


An application's attempt to update—inside a transaction—an entity EJB with delay-database-insert-until set to Commit and a concurrency strategy of Optimistic failed with a NullPointerException.

The problem was that with a delay-database-insert-until value of Commit, WebLogic Server did not initialize the Optimistic concurrency version column at the time it created the EJB.

The code was changed so that the Optimistic concurrency version column is initialized for bulk inserts.


When attempting to deploy two message-driven beans with the same ejb-name but different JNDI mappings on the same Weblogic Server instance, the first bean was deployed successfully, but the deployment of the second bean failed with this exception: - with nested exception:
ntime=jpserver,Type=EJBMessageDrivenRuntime] at at<init>(RuntimeM at<init>(RuntimeM at<init>(RuntimeM at
weblogic.ejb20.deployer.MessageDrivenRuntimeMBean.<init>(Message at
weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(Message at
1299) at

The problem resulted from non-unique MessageDrivenRuntimeMBean names. The code was changed to create unique names.


A plain Java client created an entity EJB, read the EJB using a Finder method and read-only beans, updated the entity bean, and then read entity EJB again, using a stateless session bean as a facade.

When the transaction-attribute was set to Supports, the client read updated values. However, when transaction-attribute was set to Required or RequiresNew, the client read stale values.

Research revealed that because the cache was set to a timeout of 0,the Finder method was not refreshing the values of timed out beans.

The code was changed so that it refreshes the beans even when the cache timeout is set to 0.


Dynamic EJB-QL incorrectly passed long arguments as MAX_INT to the underlying SQL, resulting in an unsuccessful search. A code fix resolved the problem.


The container was failing to call unsetEntityContext when the entity bean was undeployed. An undeploy method was added to the BaseEntityManager to clean up the pool when an entity bean is undeployed. This resolved the problem.


When WebLogic Server 6.1 throws an EJB exception to an WebLogic Server 7.0 invoker, the invoker receives a serialization error instead accompanied by scary error messages.

This is because WebLogic Server 6.1 shipped with the wrong serial version unique identifier (SVUID) for EJBException.

WebLogic Server 7.0 now identifies when it is communicating with WebLogic Server 6.x and accepts and sends the correct SVUID over such connections. The earlier resolution attempt that shipped with 7.0 was flawed.


In 6.1 SP04, <is-modified-method-name> was not called on CMP 2.0 beans. ejbStore() was called at every bean method invocation and WebLogic Server determined afterwards if the store is to avoid. This caused performance issues in applications that frequently used <is-modified-method-name>.

The problem was solved by implementing the <is-modified-method-name> function for CMP EJB 2.0.


WebLogic Server scheduled multiple JMSPoller triggers at the same time; they all dominated the default JMS queue, provoking a deadlock.

The code was changed to prevent scheduling duplicate triggers.


Combining COUNT and EXISTS in a dynamic EJB-QL request resulted in invalid SQL and this exception:

[java] javax.ejb.FinderException: Exception in dynamicQuery while
preparing or executing statement:
'weblogic.jdbc.rmi.SerialStatement@62b30' [java]
java.sql.SQLException: ORA-00937: not a single-group group
function [java] [java] java.sql.SQLException: ORA-00937: not a
single-group group function

An unnecessary column was being added to the main select list while parsing a subquery. A fix to the parser code solved the problem.


A message-driven bean consumed messages from a JMS queue on another server. That JMS server died. Inside of weblogic.ejb20.internal.MDListener, the UserTransaction.commit method threw an exception. MDListener continued running. Subsequent invocations of the MDB from JMS failed in UserTransaction.begin because there was already a transaction on the thread.

The code was changed so that MDListener suspends the current transaction before starting a new one.


The mdbPoolInfo.start()method was changed so that it is run on every message-driven EJB in a JAR, even if the start failed for the first MDB in the JAR.


The ejbc compiler failed with the following error when a two-dimensional array was specified as an argument:

ERROR: Error from ejbc: Unable to set the method permission for
method "isAuthorized(java.lang.String,[[java.lang.String)". No
matching method could be found. Please verify the method signature
specified in the ejb-jar.xml file matches that of your EJB. ERROR:
ejbc found errors.

The makeMethodParameter() method of the weblogic.ejb20.deployer.mbimpl.MethodDescriptorImpl class was modified to generate the appropriate method parameter signature depending on the dimension of the array passed.


The behavior of clustered message-driven beans has changed to optimize performance. Previously, only standard cluster load-balancing algorithms were used when an MDB connected to JMS, so that JMS connections were balanced across the cluster.

When possible, an MDB steers its JMS connection toward the same JVM that is hosting the messages from which the bean receives connections. This reduces the number of hops made by the MDB when it is accessing the resource.


Column version numbers were not updating correctly with Optimistic concurrency enabled, because blind writes were not checked . The code was changed so that blind writes are checked with Optimistic concurrency.


Automatic table creation was failing intermittently with the following error in WebLogic Server 7.0 SP1:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[
Table: Cmp_Birthday Full Table Check failed, but table all columns
were found! ] at
bleVe at
be(Ta at
LType Map( at
isten at
er.ja va:192) at
.java :168) at
weblogic.ejb20.manager.DBManager.setup( at
ivenB at

Research revealed that preparedStatement was used to fire the query. Because the prepared statement can get deleted from the Oracle database, intermittent assertion errors can occur.

The code was revised to use Statement instead of preparedStatement.


CMP beans leaked JDBC connection pools. The problem occurred when ejbFindByPrimaryKey() called releaseResources().

A change was made to the RDBMSCodeGenerator so that, if ResumeTransaction fails, WebLogic Server releases resources to avoid a potential JDBC connection leak.


The ejbc compiler was failing a JAR file that contained one hundred EJBs.

The problem was fixed by using the @tempfile feature, which is based on the number of files passed independent of the operating system.


In some bean-managed stateful session beans, an IllegalStateException occurred with bean-demarcated transactions when the number of bean instances is greater than max-beans-in-cache when the cache is full and activations and passivations occur.

A code change results in the creation of one replacer per passivation request, so that each thread has its own replacer.


With delay-database-insert-until set to Commit, the Optimistic concurrency version column was not initialized when a "multi-table" bean was created. The code was changed so that RDBMSCodeGenerator.perhapsAssignOptimisticField() now returns generated code that sets the version column for all the tables that the CMP bean is mapped to.


EJBs with Bean-Managed Persistence and with concurrency set to exclusive called ejbFindByPrimaryKey rather than finding the bean in the cache.

A code change resolved the problem so that the EJB finds the bean in the cache.


Change Request Number



When a WebLogic Server 7.0 SP2 client attempted to get the Coordinator remote object from a WebLogic 8.1 server instance, a ClassCastException was thrown while casting the remote stub to the CoordinatorOneway interface. This prevented commit handoff to the 8.1 coordinating server.

A code change that altered classloading functionality fixed this problem.


Change Request Number



In previous releases of WebLogic Server 7.0, JDBC MultiPools with the High Availability algorithm did not fail over when the DBMS for the first connection pool was removed from the network. A code fix solved the problem.


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

The problem was resolved with a code change.


In previous releases of WebLogic Server 7.0, erroneously creating multiple ResultSets that point to a single JDBC object through a JDBC connection pool resulted in an OutOfMemoryError. Each ResultSet resulted in an RMI object. Not all RMI objects were closed when the ResultSet was closed. A code fix solved the problem.


In WebLogic Server 6.1 SP04, with Oracle Thin XA with the from Oracle 9.2, a stateless session bean calling EJB caused XAER_PROTO after "Configuration Changes saved to the repository" message appeared.

START SLEEP 2: After updating thevalue to 1...

DONE SLEEP 2: After updating thevalue to 1...

START SLEEP 2: After updating thevalue to 2...

DONE SLEEP 2: After updating thevalue to 2...

START SLEEP 2: After updating thevalue to 3...

DONE SLEEP 2: After updating thevalue to 3...

START SLEEP 2: After updating thevalue to 4...

DONE SLEEP 2: After updating thevalue to 4...

START SLEEP 2: After updating thevalue to 5...

DONE SLEEP 2: After updating thevalue to 5... Current value is 5 <

Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0

The problem was traced to a known problem in Oracle client 9.2.0.[01], that is solved in A code change to in WebLogic Server was implemented to work-around the 9.2.0.[01] issue.


In WebLogic Server 6.1, it was not possible to use specific Oracle objects (Array, Struct, and others) through a connection pool based on the Oracle Thin Client driver. The objects returned by the Oracle Thin Client driver are not serializable nor remote and therefore cannot be passed over RMI.

In WebLogic Server 7.0 SP3, a new package,, contains proxies for these objects and allows them to be passed through the connection pool.


Starting with WebLogic Server 7.0 SP3, WebLogic Server provides support for Oracle Virtual Private Databases (VPDs). A VPD is an aggregation of server-enforced, application-defined fine-grained access control, combined with a secure application context in the Oracle 9i database server.

For more information, see "Programming with Oracle Virtual Private Databases" in Programming WebLogic JDBC.


The ejb2jsp utility was generating incorrect tag classes for methods that contained parameter types other than String.

The problem was fixed by changing the tag library generator to use getAttribute rather than getAttributeString.


When a non-zero starting index was passed to the getStatementProfiles() method, the traces returned start from the top of the .tsf file, instead of at the specified starting index.

A code fix solved the problem.


The JDBCConnectionPoolRuntimeMBean.getStatementProfiles() method did not filter results by poolName for the MBean instance it was called against. If you called the getStatementProfiles method, the results included statements for all connection pools for which tracing had been activated. This was incorrect because the JDBCConnectionPoolRuntimeMBean instance is specific to a single connection pool.

This problem was resolved by modifying the JDBCConnectionPoolRuntimeMBean.getStatementProfiles() method to correctly filter results by poolName for the MBean instance it is called against.


Rather than returning the actual time a JDBC operation took to execute, JDBCStatementProfile.getTimeTaken() always returned zero, and the start and end time of the operation were always equal.

A code fix to weblogic/jdbc/common/internal/ solved the problem.


Threads trying to replace their JDBC connection were unnecessarily synchronized in the resetThisOne() method of ResourceAllocator, resulting in a waste of resources. The ResourceAllocator code was changed so that threads replace their connections in parallel.


Previous versions of WebLogic Server lacked connection leak profiling and connection leak detection logic in weblogic.jdbc.rmi.internal.ConnectionImpl.

Code changes to and solved this problem.


When the DBMS was not available, makeConnection() in was trying to connect DBMS twice on behalf of the client.

This has been fixed so that only one connection attempt is made.


Under load conditions, when WebLogic Server was calling ResourceAllocator.markBorrowed() and JMX was calling ConnectionPoolRuntimeMBeanImpl.getConnectionDelayTime(), a deadlock condition resulted.

A code fix to solved the problem.


Weblogic Server 6.1 SP04 thin driver, Solaris 8, JDK 1.3.1_04, and Oracle, deadlocks occurred when connection refresh was turned on, with the following stack trace:

"ExecuteThread: '35' for queue: 'default'" daemon prio=5 tid=0x45ac68 nid=0x30 waiting for monitor entry [0xce901000..0xce9019d8] at weblogic.jdbc.common.internal.ConnectionEnv.destroy( at weblogic.common.internal.ResourceAllocator

Both the weblogic.jdbc.common.internal.ConnectionEnv.destroy and weblogic.common.internal.ResourceAllocator.release are synchronized methods.

The problem was solved with a code fix to weblogic/jdbc/common/internal/


In WebLogic Server 6.1 SP04, under load testing, a connection pool with the refresh minutes set to 15, and TestConnsOnReserve and TestConnsOnRelease set to false threw the following exception:

weblogic.common.ResourceException: No available connections in pool ODSConnectionPool

This problem occurred because when only a few of the connections in the pool were used, all the other connections in the pool were reserved for testing at the expiration of the refresh test minutes. At that point, if the client asked for a connection the exception was thrown.

The problem was resolved with a code fix that implements two things:

When used as-is without any other change, refresh only reserves and tests one connection at a time, and releases it immediately. This addresses the locking-all-connections issue.

If the customer adds a driver property to the pool definition, secondsToTrustAnIdlePoolConnection, with a positive integer value, the pool avoids testing pool connections that are known to have successfully connected to the DBMS within that period. This accelerates refresh and testConnsOnReserve.


While closing prepared statement, the cleanUpStatementForReUse() method of called clearBatch(), which is not implemented by MS SQL Driver. This resulted in the following exception:

java.sql.SQLException: This JDBC 2.0 method is not implemented exception.

The code was changed so that the harmless call is permitted and no exception is thrown.


In build-jdbc.xml, RmiDataSource was not built as clusterable. This prevented DataSource failover.

Building DataSources and TXDataSources as clusterable solved the problem.


Attempts to create a connection pool with weblogic.Admin CREATE_POOL resulted in the following exception:

./ No permission to create ConnectionPool Start server side stack trace: weblogic.common.ResourceException: No permission to create ConnectionPool at weblogic.jdbc.common.internal.JDBCService.createPool(Ljava.util.Properties;Lweblogic.secur ity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at weblogic.jdbc.common.internal.ConnectionPool.createPool(Ljava.util.Properties; curity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at weblogic.jdbc.common.internal.ConnectionPool.createPool(Ljava.util.Properties;)V(Unknown S ource) at weblogic.jdbc.common.internal.ConnectionPool_WebLogic Serverkel.invoke(ILweblogic.rmi.spi.InboundReque st;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.spi.OutboundResponse;(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.internal.MethodDescriptor;Lweblo gic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(Unknown Source) at weblogic.rmi.internal.BasicServerRef$;(Unknown Source) at henticatedSubject;; tionAction;)Ljava.lang.Object;(Unknown Source) at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest;)V(Unk nown Source) at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread;)V(Unknown Source) at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(Unknown Source) at Source) at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)

Research revealed that WebLogic Server was requiring aclName—which is deprecated—as an attribute. A code fix resolved the problem.


The XAPreparedStatementCacheSize in the Administration console for JDBC connection pools is now exposed.


An SP2 change allowed the isolation level for drivers that do not allow isolation-level setting. Because the DB2 JDBC driver allows changes to the isolation level the check is not called and thus a change of isolation level is done at an inappropriate time.

This means that EJBs that set the isolation-level in deployment descriptors can throw an exception, even if the isolation level in the deployment descriptor is the same as the default 'READ-COMMITTED'.

A code change fixed this by preventing the isolation level from being set if it is the same as the current level.


A code change resulted in performance improvement in JDBC regarding bubblecaches in JDBCSessionContext and JDBCSessionData.


The getConnectionsTotalCount method from JDBCConnectionPoolRuntimeMBean did not work as expected. It should return the total number of JDBC connections in this JDBCConnectionPoolRuntimeMBean since the pool was instantiated, but instead was returning the maximum number of connections at any point in time, equal to or less than the MaxCapacity.

Code changes to getTotalConnections() in fixed the problem.


PreparedStatement for SQL UPDATE did not work after using CallableStatement on the same connection. getUpdateCount returned zero when nothing has changed on the database. This happened when setting the weblogic.oci.min_bind_size property for the JDBC connection. A code change resolved the problem.


DatabaseMetaData.getDriverVersion() returned an outdated version string. A code fix resolved the problem.


The WebLogic Server jDriver for MS SQLServer can mistakenly accept the jdbc:microsoft:... URL for the Microsoft JDBC driver. If a JVM tries to use both drivers, loading the WebLogic Server driver first will prevent the Microsoft driver from being used.

This jDriver is has been deprecated.


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


Change Request Number



Using a XADataSource on top of jDriver resulted in shrinking heap size until OutOfMemoryError.

In the weblogic.jdbc.oci.Connection class, LOB fields of result sets in a transaction are registered under a connection through the Connection.addLob() method. The registered LOBs are freed (along with the corresponding object in native jDriver library) when one of these conditions occurs:

  • Connection.commit()/Connection.rollback()/Connection.close() is called at the connection level (this Connection is weblogic.jdbc.oci.Connection).

  • An SQL statement is executed and the connection is set to autoCommit mode (i.e., non-TX Data Source or a direct connection from the pool).

  • The return code from an OCI SQL call indicates that a commit/rollback at the database level has occurred.

When an XADataSource is used, none of the above conditions apply. As a result, LOB fields of jDriver in result sets were never released in the JVM heap.

This problem was corrected by a code change in to call closeLob ().


In WebLogic Server 6.1 SP04, jDriver for Oracle 9.2 does not support the AL32UTF8 character set (unicode version 3.1). When NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8, the following error is generated by weblogic.jdbc.oci.Connection.<init>(

java.sql.SQLException: Unsupported Oracle codeset: al32utf8. Set weblogic.codeset in your connection Properties to a valid JDK codeset which is compatible with the Oracle codeset defined in your NLS_LANG setting.

When NLS_LANG=AMERICAN_AMERICA.UTF8, this error occurs: ORA-01461: can bind a LONG value only for insert into a LONG column, indicating a mismatch between the character set on the client and database.

This problem was corrected by a code fix to weblogic/db/oci/OciConnection.


In previous releases of WebLogic Server 7.0, a StringIndexOutOfBoundsException occurred in the WebLogic jDriver for Oracle. The problem occurred occasionally in multiple queries with medium-sized (hundreds of rows) ResultSets. A code fix solved the problem.


In WebLogic Server 6.1 SP03 and SP04, jDriver for Oracle ResultSet.getBigDecimal() method did not return correct value. For example, the value of 9999999999.999999 was rounded to 9999999999.999998.

This problem was solved with a code fix.


The WebLogic jDriver for MS SQL Server that shipped with WebLogic Server 7.0., 7.0 SP1, and 7.0 SP2 threw the following error when used to connect to a MS SQL Server 2000 SP3 database:

java.sql.SQLException: I/O exception while talking to the server, Unable to connect, please check your server's version
and availability.

This problem was solved with a code fix.


The version of the Oracle Thin driver 9.2.0 that was bundled with previous releases of WebLogic Server contained errors that occasionally resulted in data errors. The driver was replaced with a new version from Oracle.


Change Request Number



Long-lived JMS connections lacked a periodic heartbeat check.

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


In WebLogic Server 7.0, the Messaging Bridge did not work properly with a null UserPassword. When a messaging bridge was configured with a non-null UserName and null UserPassword, it failed to start with no clear error messages.

This problem was resolved with a code fix.


In WebLogic Server 6.1 SP03, a JMS server threw a NullPointerException under heavy load conditions:

<Warning> <JTA> <XA resource [JMS_JMSServer1JDBCStore] has not responded in the last 120 second(s).>

<Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

The problem was exhibited in this configuration: 400 execute threads, 200 JMS threads, and 100 connections for the connection pool. Exception occurred under a load test while publishing approximately 10 messages (around 2K) to a durable subscriber every second to the JMS server. There were no distributed transactions and a Sybase driver was used for the connection pool for the JMS JDBC store.

The problem is resolved by a code fix.


In WebLogic Server 6.1 SP02, a JMS exception occurred when attempting to unsubscribe a transacted durable subscriber:

weblogic.jms.common.JMSException: Subscription clientID.vIJAY in use, uncommitted/unacknowledged messages at weblogic.jms.backend.BEConsumer.delete( at weblogic.jms.backend.BEManager.removeSubscription(

Analysis revealed that WebLogic Server was incrementing the unacknowledged message count twice for every message and decrementing it only once. This always left the unacknowledged messagecount > 0 and thus the exception when trying to unsubscribe the durable subscriber.

This problem was solved with a code fix to unacknowledged message counts and pending durable subscribers.


In WebLogic Server 6.1 SP03, the Messaging Bridge connection retry values (minimum, maximum, and increment) did not work correctly. The problem occurred with a Messaging Bridge configured to send messages from one WebLogic JMS server to another, with both JMS servers running on the same WebLogic Server instance. Untargeting one of the JMS servers resulted in this error:

<Error> <Connector> <Error granting connection request.>

Retry attempts should occur at intervals controlled by the Connection Retry parameters. However, with the following startup default values: min=15, max=60, inc=5. The observed behavior was:

    1. A connection is attempted which fails - OK

    2. A second connection is attempted 15 seconds later - OK

    3. The subsequent connection attempts are at an interval of 5 seconds - NOT OK

<Error> <Connector> <Error granting connection request.>
<Error> <Connector> <Error granting connection request.>
<Error> <Connector> <Error granting connection request.>
<Error> <Connector> <Error granting connection request.>
<Error> <Connector> <Error granting connection request.>

After one of the default parameters was changed, the increments were correct. However, the max value was never reached. With the default values, the maximum reached was 55.

A code fix corrected the logic for the retry values.


In WebLogic Server 7.0 SP02, when enqueuing multiple messages in a JMS queue within a JTA transaction, if the transaction was actually rolled back after the enqueuing, then the Administration Console displayed incorrect information.

A code fix adjusted the receivedCounts on transaction rollbacks.


In WebLogic Server 6.1 SP04 only, persistent queue messages received by MDB were not acknowledged properly, causing the Administration Console monitoring function to show "BYTES PENDING". Messages that had been received by the MDB were redelivered when the server was shut down and restarted.

This problem was solved with a code fix to MDB acknowledgments when the EJB transaction descriptor is set to "NotSupported".


In WebLogic Server 6.1 SP02, when a connection pool was created using the Oracle Thin Driver, and a JMS JDBC Store was configured to use this pool (with JDBC logging enabled), produced a Connection has already been closed SQL exception. After this error message, nothing was logged in the JDBC log file.

A code fix prevents the JDBC logging errors.


In WebLogic Server 7.0 SP01, calling a "stop" on a QueueConnection on which there was a ServerSessionPool that was still receiving messages from a JMS queue, caused an endless loop and CPU utilization of 100%.

The problem was resolved by a fix to the code.


In WebLogic Server 7.0 SP01, a JMS connection factory's Flow Control settings were configured to set the FlowMinimum to 2 and the FlowMaximum to 8. After restarting the server, the following configuration exception was thrown:

<Critical> <WebLogic Server> <000364> <Server failed during initialization. invalid value '8' for attribute 'FlowMaximum' of MBean "mydomain:Name=MyJMS Connection Factory,Type=JMSConnectionFactory".

The problem was resolved by removing the legal checks on FlowMinimum and FlowMaximum fields. This is a limitation in the legal checking that can be done in this release.


In WebLogic Server 6.0 SP02 and SP04, when a durable topic subscriber was connected to a JMS server and a message was sent to the topic, WebLogic Server increased the value of Bytes Current Count by message size even though the message had been received and committed by the receiver. The corresponding value of Messages Current Count was not affected.

When the durable topic subscriber was not connected to a JMS server and there was a message sent to the topic, WebLogic Server increases both Messages Current Count and Bytes Current Count. If the durable topic subscriber was connected back to the JMS server, WebLogic Server decreased both Messages Current Count and Bytes Current Count correspondingly. As a result of this inconsistency, the value "Bytes Current Count" cannot be zero even though there is no outstanding message for the durable topic subscriber.

Analysis revealed that in backend/ addMessages(), bytesCurrentCount was updated inappropriately, resulting in display of incorrect statistics in the Administration Console.

The problem was solved with a code fix.


In WebLogic Server 7.0 SP01, analysis of the JMS connection factory's FlowMinimum minimum allowable value of 0 (for Flow Control) was shown to have negative impact on message producers. Although a value of 0 seemed to indicate that a producer could be completely stopped from sending messages, this was not the case as messages would keep trickling through.

The problem was resolved by changing the minimum allowable value for FlowMinimum to 1.


In WebLogic Server 7.0 SP01, the Messaging Bridge Administration Console labels, online help, and log messages conflicted with how the Maximum Idle Time and Incremental Delay attributes were measured. These attributes are measured in "seconds", not "milliseconds".

The problem was resolved by correcting the Administration Console labels, online help, and log messages to reflect that these attributes are measured in "seconds".


In WebLogic Server SP04, after a messaging bridge's Maximum Idle Time setting was reached, messages were logged into the server name log file. If there were numerous messaging bridges configured, then the log file would fill up quickly and possibly grow quite large.

These messages are now only generated when run-time debugging is enabled for the messaging bridge.


In WebLogic Server 7.0 SP02, although the Messaging Bridge documentation stated that a value of -1 for the Messaging Bridge's Execute Thread Pool Size field was valid and that it should be used to disable this thread pool to force all messaging bridges to use the WebLogic Server default thread pool, a value of -1 for this field was not actually allowed.

A code fix allows the Execute Thread Pool Size to be set to "-1".


In WebLogic Server 7.0 SP01, the following security error message was generated when using the Messaging Bridge to interoperate between WebLogic Server domains that did not establish a trusted security relationship:

java.lang.SecurityException: Invalid Subject: principals=[searchuser]

WebLogic Server security now allows synchronous operations between untrusted domains.


In WebLogic Server 7.0, enforced security on physical destinations was not effective when accessed through distributed destinations. For example, if a distributed destination had two physical queue members, SecQ1 and SecQ2, and a user was not given JMS security privilege to "send" messages to either physical queue, the user was still able to send messages successfully through the distributed destination.

The problem was solved by checking security against the physical destination members of the distributed destination.


A user set up a messaging bridge on one server in the cluster and then migrated the bridge to another server in the cluster. Starting up the second server triggered the following exception:

(java.lang.Exception: java.lang.NullPointerException at weblogic.jms.bridge.internal.MessagingBridge.getConnections( at weblogic.jms.bridge.internal.MessagingBridge.execute( at weblogic.kernel.ExecuteThread.execute( at

The messaging bridge skipped one of the initialization steps when it was targeted to a migratable target; therefore, the bridge failed to get the resource adapter information from the configuration. The NullPointerException occurred when the bridge later tried to access a resource adapter.

The problem was resolved by fixing the messaging bridge initialization code for migratable targets.


In WebLogic Server 7.0 SP01, a stateless EJB's topic messages were delivered to a TopicSubscriber client before a connection was started.

A code fix prevents messages from being delivered before a connection is started.


In WebLogic Server 7.0 SP01, the following parsing selector error was produced when the length of the JMS selector attribute was less than 3:

weblogic.jms.common.InvalidSelectorException: Error parsing selector

The problem was resolved by a code fix.


In WebLogic Server 7.0, when a JMS server had an inbound and an outbound queue, and an MDB located on another server consumed messages from the inbound queue and produced messages to the outbound queue in a one-for-one relationship, this was all done within a transaction initiated by the MDB.

The end of the transaction occurred when the MDB enqueued a message on the outbound queue. If the JMS Server was stopped and restarted, messages were lost. Over a load of 10,000 messages, some messages (a small quantity) were lost.

A code fix forces the XASession to perform a CLIENT_ACK acknowledgement.


In WebLogic Server 7.0 SP01, duplicate message IDs could be generated by JMS.

The problem was resolved by a code fix.


In WebLogic Server 7.0 SP01, a message-driven bean would open a XAConnection if it was using an XAConnectionFactory. This meant that for a non-transactional MDB, the container connected using an XASession, and did not realize it was client-acknowledge, so it did not call "acknowledge" and messages did not get acknowledged.

A code fix changed this behavior so that regardless of the type of connection factory returned, the MDB container only creates an XAConnection and a XASession if XA is required.


The session creation method behavior has been changed when using a XAQueueConnection or XATopicConnection object to create a non-XA Session. Prior to this change, the behavior was as follows:

  • XAQueueConnection.createQueueSession creates a XAQueueSession

  • XATopicConnection.createTopicSession creates a XATopicSession

In both cases, the user-specified acknowledge mode and transacted flag were ignored and replaced with the AUTO_ACKNOWLEDGE mode and a transacted setting of false.

Whereas, the new behavior causes the XAQueueConnection.createQueueSession and XATopicConnection.createTopicSession methods to behave exactly the same as the corresponding methods on QueueConnection and TopicConnection, as follows:

  • QueueConnection.createQueueSession creates a QueueSession

  • TopicConnection.createTopicSession creates a TopicSession

  • XAQueueConnection.createQueueSession creates a QueueSession

  • XATopicConnection.createTopicSession creates a TopicSession

Furthermore, the user-specified acknowledge mode and transacted flag settings are honored for each of these four methods.

The four connection methods listed above behave differently if the XAServerEnabled flag is enabled on the connection factory. If this flag is enabled, then all four methods create an XAQueueSession (or XATopicSession) session if invoked on the server, and a non-XA QueueSession or TopicSession session if invoked on the client. The resulting session honors the user-specified acknowledge mode but ignores the transacted flag because the resulting session supports XA.

Note that in previous versions of WebLogic Server 7.0, connection objects that were created from a connection factory with the XAConnectionFactoryEnabled flag enabled behaved as if they were XAQueueConnection or XATopicConnection objects. With the new behavioral change, this behavior is now invisible unless you explicitly cast the connection factory to XAQueueConnectionFactory or XATopicConnectionFactory and called one of the createXA methods.

Prior to this change, if you set the XAConnectionFactoryEnabled flag on your connection factory, you would have noticed different behavior from the createQueueSession and createTopicSession, even if you did not cast the connection factory to one of the XA connection factory classes.


In WebLogic Server 7.0 SP01, on the client and the server side, calling the createSession() method on a XAConnection object resulted in a XASession object.

The behavior was changed so that calling the createSession() on an XASession object results in a non-XA "Session" object.


In WebLogic Server 6.1 SP04, the synchronous receiving of messages on a JMS queue stopped after a garbage collection/transaction timeout.

The problem was resolved by refactoring the JMS dispatcher code to improve thread management.


In WebLogic Server 7.0 SP01, when a message that was being pushed to a consumer arrived at the front-end session, but was destined for a consumer that had already been closed, the messages could have been lost because the list was being inadvertently truncated.

The problem was resolved by a code fix to prevent a potential race condition.


dispatch-policy is now honored for message-driven beans. This means message-driven beans can now be assigned to a user-defined execute queue.


In WebLogic Server 7.0, when a JMS server was migrated from a WebLogic Server instance (server1) to another instance (server2), the JMS server was deactivated on server1 and all its destinations were suspended. However, the in-memory messages lists were not cleaned up when the destinations were suspended. As a result, when the JMS server was migrated back to server1, all the messages that existed on the JMS server before the migration would show up even if they were dequeued from server2. Once the in-memory messages cleaned up on server1 after the JMS server is migrated to server2, there should no be any duplicate messages.

The problem was resolved by cleaning up the in-memory messages lists when a JMS server is migrated to another WebLogic Server instance.


In WebLogic Server 7.0, the run-time MBeans associated with a JMS server (JMSServerRuntimeMBean and JMSDestinationRuntimeMBean) were not unregistered with the Administration Server after the JMS server was suspended. As a result, if the JMS server was targeted to a migratable target, two instances of those MBeans would show up in the Administration Console monitoring pages after the JMS server was migrated from one server to another. One instance was on the original server instance, and another was on the server where the JMS server was migrated.

The unregistration/registration process for run-time MBeans is now handled correctly.


If a long-idle JMS JDBC connection was marked as "bad" (when for example, a firewall's time-to-live expires), JMS attempted to use the bad connection, and failed. The failure would either be immediate or would take upwards of 8-10 minutes to return, depending on tuning parameters.

This problem was resolved by modifying the code so that if JMS is idle, the database is pinged every five minutes to maintain the connection. Five minutes was selected because it is expected to be shorter than any firewall timeout.


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

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


When using JMS with the IIOP protocol, abnormal disconnection by a client was not being properly detected in the server. This causes problems with stateful information associated with the client, like the JMS client identifier.

Abnormal disconnection is now detected and handled appropriately.


Under load conditions, a test JMS application was encountering the following exception:

java.lang.OutOfMemoryError weblogic.jms.common.TransactionRolledBackException: at weblogic.jms.backend.BEConsumer.expireTimeout( at weblogic.jms.backend.BEXATranEntryBlockingConsumer.startRollback( at weblogic.jms.backend.BEXAResource.rollback( at weblogic.transaction.internal.ServerResourceInfo.rollback( at weblogic.transaction.internal.ServerResourceInfo.rollback( at weblogic.transaction.internal.ServerSCInfo.startRollback( at weblogic.transaction.internal.ServerTransactionImpl.localRollback( at weblogic.transaction.internal.ServerTransactionImpl.globalRollback( at weblogic.transaction.internal.TransactionImpl$1.execute( at weblogic.kernel.ExecuteThread.execute( at weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.rollbackAfterRecover( at weblogic.jms.frontend.FESession.recover( at weblogic.jms.frontend.FESession.invoke( at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine( at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran( at weblogic.jms.client.JMSSession.recoverGuts( at weblogic.jms.client.JMSSession.rollback( at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback( at at ----------- Linked Exception ----------- weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.recover( at weblogic.jms.frontend.FESession.invoke( at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine( at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran( at weblogic.jms.client.JMSSession.recoverGuts( at weblogic.jms.client.JMSSession.rollback( at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback( at...

Research revealed that the WebLogic JMS garbage collection functionality was slow to reclaim memory when dealing with long linked lists; the code was changed to break up the lists. This resolved the problem.


A memory leak occurred when creating a QueueReceiver for each message on a Distributed Queue and persisted even after the QueueReceiver had been shut down.

A code change corrected memory leaks in BasicServiceOffer and DistributedDestinationImpl objects.


A memory leak occurred because unused JMS objects remained open.

The problem was resolved by the following fixes:

-Normalized the destination for all the Producers created on the same destination.

-Removed the listener from the correct DispatcherWrapperState when substituting the DispatcherWrapperState for FEProducer

-Removed the listener from the correct DispatcherWrapperState when closing the FEProducer unconditionally

-Removed the leak for Temporary Destinations on FrontEnd when the BackEnd goes down.


Change Request Number



JNDI Context 's list("") method did not return the correct class name.

WebLogic Server now returns the actual class name when using the "list" method.


RMI failover took a long time when kill -STOP was invoked on the server.

A code change reduced the time needed for failover.


JNDI tree was not updated properly on rebind.

JNDI unbind of Clusterable RemoteObjects from one of the cluster nodes caused the objects to still be accessible when the calls landed on the node from which the object was unbound from. This is now fixed and a next available node will be picked to make the remote method invocations.


When a Context.lookup on a composite name was done, a NameNotFoundException was obtained if the name was not resolved, either fully or partially.

When RemainingName is a CompositeName, it should have an enumeration. The remaining name was treated as a single string and WebLogic Server passed '.' as a separator when constructing the CompositeName. Now WebLogic Server properly replaces any '.' separators with '/' to ensure the enumeration is properly created.

CR103148, CR110890

In WebLogic Server 7.0 SP2 a startup class failed to access the local instance MBeanHome with LOCAL_JNDI_NAME ( with LoadBeforeAppDeployments set to true. It failed with the following error message:

Unable to resolve '' Resolved:

'' Unresolved:'home'

Moving the bindings of the other JNDI names into the AdminService so that they are available to startup classes fixed the problem.


Attempting to bind a Dynamic Proxy object into the local JNDI tree caused a ClassNotFoundException.

A code change fixed the problem by implementing resolveProxyClass() and using a thread context classloader to load interfaces from the application.

JSPs and Servlets

Change Request Number



When the content type was set using the page directive, such as <%@ page contentType="text/html;charset=UTF-8" %> then the content type was not set properly and the desired output was not obtained.

This problem was eliminated by a code change.


When "extended format" is selected for the HTTP logging option and the server is restarted, a Null Pointer Exception was thrown.

Adding code to open the access.log file during logManagerHttp's creation time eliminated this problem.


HttpProxyServlet was unable to reach third-party server.

The problem occurred because the server does not send the ContentLength and keeps sending data forever. If there is no content length and it is not chunk transferred, the server reads until the end of stream.

HttpProxyServlet has been changed to read and write byte by byte.


The user-agent was unable to re-establish a WebLogic Server session following a request to a Web application that does not explicitly set CookiePath in weblogic.xml.

WebLogic Server uses the first cookie with a name equal to Cookie Name specified in weblogic.xml, even if a second cookie exists from the same domain and specifies a path that matches the request URL.

In the past, WebLogic Server searched the cookie vector backwards for the JSESSIONID; this search has been changed to run forward.


The redirect-with-absolute-url feature did not work for j_security_check. The Location header in a response was still the absolute path.

The code has been altered so that redirect-with-absolute-url will be honored in FormSecurityModule.


For Network Channels, the getServerPort method returns the value of the FrontendHTTPPort if the FrontendHTTPPort value is set in the WebServer element in config.xml.

When the HOST header contains a port other than the WebLogic Server default listen port (for example when a proxy sits in front of WebLogic Server), the FrontendHTTPPort can be specified to allow getServerPort() to return the WebLogic Server port instead of the one specified in the HOST header. However, this FrontendHTTPPort value was returned for all getServerPort() calls, including those for Network Channels which are running on a different port.

The code has been altered to allow the use of call request.getAttribute("weblogic.servlet.network_channel.port") to return the value of the port on which the request was received.


An incorrect Date header was returned if there was no Host header in the request.

This has been corrected by setting the request invoke time before error messages are sent.


Applying the patch created to fix CR083654 made multi-bytes headers inaccurate.

This has been fixed by adding the UseHeaderEncoding option to WebServer.


For chunked transfer, WebLogic Server was treating the chunk size prepended to data.

setChunking has been moved out of mergePostParams of ServletRequestImpl to MuxableSocketHttp right after request.setInputStream.


When hosting a Web application with user-defined error pages, WebLogic Server returned the following response for 400 error and closed the connection immediately, with no Connection: close header:

HTTP/1.1 400 Bad Request Date: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 463 Content-Type: text/html Last-Modified: Thu, 07 Nov 2002 21:56:52 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html>

The problem was solved with a code fix.


If the Http Header did not have X_WEBLOGIC_CLUSTER_LIST, the ServerList was not created for the code that checks for X_WEBLOGIC_CLUSTER_HASH.

This condition was fixed by enabling the server to store the hash if the list is sent after hash in the response headers.


RequestDispatcher.forward dropped version numbers in the URL header.

This was fixed by setting processPathParameters to false in setRequestURI() when doing forward().


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

Turning off keep-alive on the server made the problem disappear. Increasing Keep-Alive periods still showed the problem with different length of sleep.

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


The servlet container did not pass the login exception to the error page.

Now the error JSP can access the exceptions.


WebLogic Server threw UnsupportedEncodingException for the extra quoted value in charset with JSP tag.

This problem was resolved by adding support for HTTP spec for header attribute values.


In WebLogic Server 6.1 SP03, the JspParser threw an UnsupportedEncodingException for the extra quoted value in charset with JSP tag:

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

resulted in this error:

java.lang.RuntimeException: Unknown/unsupported charset: "Shift_JIS" - Charset: '"Shift_JIS"' not recognized, and there is no alias for it in the WebServerMBean

WebLogic Server did not correctly support the HTTP specification.

The problem was resolved by adding support for quoted strings and comments to Content-Type header charset attribute value.


File servlet GET functionality now supports byte ranges.


WebLogic Server stripped the quotation marks from cookies. This made the cookie values unreadable under certain circumstances. The code has been changed to allow quotation marks to remain in cookies.


When setting:


<description>USE SSL</description> <transport-guarantee>CONFIDENTIAL</transport-guarantee>


in a Web application's web.xml file for a resource and hitting the protected resource with HTTP, the server threw an error saying the user was not authorized to view the resource. The server did not give the user a chance to authenticate and then switch over to HTTPS according to servlet specifications 2.3 page 87.

The container now redirects the client to the HTTPS port if the original request was over HTTP and resources are marked integral or confidential.


WebLogic Server did not accept "," as a character in Netscape cookies.

A comma is now allowed for Netscape cookies because commas can be used as delimiter only for RFC2109 cookie.


If a request is issued through the proxy, and then the same request is issued again without letting the first finish, an exception occurred.

The proxy now drains the inputstream from IIS even when it has failed to write to the client (connection was closed by the browser).


In WebLogic Server 6.1 SP04, JISAutoDetect encoding for HttpRequest resulted in this UnsupportedEncodingException: JISAutoDetect at at at at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding( ...

This problem did not occur with WebLogic Server 6.1 SP03.

The problem occurred because used the CharToByteConverter class instead of CharToByteConverter is the one for input converter. CharToByte is for output converter. JISAutoDetect is only available for input stream.

The problem was corrected with a code fix.


Java comments spanning multiple scriptlets caused jspc to fail.

Adding code that causes the ScriptletScopeLexer to skip an entire Java comment solved the problem.


If a JSP with a line such as <%@ include file="./" %> and contains a line such as <%@ taglib uri="/c.tld" prefix="c" %> and c.tld has a validator, a JSP Compiler error with <%@ include file="./"%> and using tag lib was returned.

This problem was fixed by adding a reference to the currentURI of the JSP page being translated into XML format. This allows the implementation to calculate the location of the included JSP relative to the application root.


When using the HTTPClusterServlet to access a secure Web application on a backend cluster, Internet Explorer will 'hang' for 30 seconds after the username and password has been entered.

WebLogic Server now closes the connection between the client and the proxy server if a Connection: Close Header request has been proxied to the browser.


A NullPointerException was thrown from WebLogic Server when a Web application was accessed (after successful deployment) which had a property set to java protocol in its application.

The code now checks for null value of source.getURL().


A new installation of WebLogic Server 6.1 SP04 threw a null pointer exception when a successfully deployed web app that has a property set to java protocol is accessed. The browser returned Error 500--Internal Server Error. The problem did not occur with an upgrade installation.

<Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP>

<[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with



at weblogic.servlet.JSPServlet.service(

at javax.servlet.http.HttpServlet.service(









at weblogic.kernel.ExecuteThread.execute(


Analysis revealed an error in ZipSource.getURL(). The problem was resolved by adding logic to check for null value of source.getURL().


The server misdirected output for JSP includes in JSP pages.

The problem was solved with changes to the servlet engine to unify handling of includes, forwards, wrapped-responses, and JSP BodyTags.


A new parameter, Weblogic Plug-In Enabled, was added to WebLogic Server. A call to getRemoteAddr returned the IP address of HttpClusterServlet, and not the IP address of the client, because HttpClusterServlet did not set the proprietary header, "WL-Proxy-Client-IP" and therefore used the socket's IP address.

This has been corrected in the code.


Innocuous warning message removed from code.

context.log.error("Warning: One of the getParameter family of methods called after reading from the ServletInputStream(), can't mix these two!"); was turned off


According to the JVM specification, the size limit for a method size is 64K. In WebLogic Server 6.1 SP03, a customer has JSPs with many body tags for which the generated java code exceeded the 64K limit for the __jspService method.

The problem was solved by a code change. Now, when an empty BodyTag of the form <my:tag ... /> is encountered, the generated code that would normally set up scope for the body is replaced by a single call to a static method in that tricks the BodyTag into thinking it is being invoked as usual from the JSP source.


In earlier versions of WebLogic Server 7.0, WebLogic Server precompiled all JSPs, even those that had not been updated.

A code change now prevents the temp directory from being overwritten when an instance of WebLogic Server is restarted.


A new capability was added to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:

<WebServer Name="myserver" AuthCookieEnabled="true"/>

This causes an new secure cookie to be sent to the browser when authenticating via an HTTPS connection. Once set, the session can access other security-constrained HTTPS resources only if the cookie is sent from the browser.

Note: If authenticating via plain HTTP, the secure cookie is not set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie is not verified (since it will not have been sent from the browser). This behavior allows the browser to access non-protected HTTPs resources without the user logging in.


When running a load test with a 3 server cluster and using IIS proxy plugin, then shutting down one of the servers in the cluster, the IIS proxy threw a 500 error.

This was due to both a parsing error and a server affinity problem.

These problems have been fixed in the code.


Unix platforms (Solaris, Linux) showed loss of replicated sessions on secondary servers.

The session-config element in web.xml (j2ee descriptor) is not deprecated. The value is in minutes. The weblogic.xml (BEA-specific descriptor) element takes a value in seconds and takes precedence over the value defined in web.xml.


JSP compilation errors were handled improperly. The filter communicated with OutputStream instead of with HttpServletResponseWrapper getWriter, with this result:

java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream() at weblogic.servlet.internal.ServletResponseImpl.getWriter( at weblogic.servlet.internal.ServletRequestImpl.reportJSPFailure( at weblogic.servlet.internal.ServletRequestImpl.reportJSPCompilationFailure( at weblogic.servlet.jsp.JspStub.reportCompilationFailure( at weblogic.servlet.jsp.JspStub.compilePage( at weblogic.servlet.jsp.JspStub.prepareServlet( at weblogic.servlet.jsp.JspStub.prepareServlet( at weblogic.servlet.internal.ServletStubImpl.getServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.TailFilter.doFilter( at weblogic.servlet.internal.FilterChainImpl.doFilter( at WebLogic ServerBugFilter.doFilter(WebLogic at weblogic.servlet.internal.FilterChainImpl.doFilter( at weblogic.servlet.internal.WebAppServletContext$ at at weblogic.servlet.internal.WebAppServletContext.invokeServlet( at weblogic.servlet.internal.ServletRequestImpl.execute( at weblogic.kernel.ExecuteThread.execute( at

WebLogic ServerBugFilter.doFilter after

The problem was fixed by the implementation of a wrapper-aware RequestCallback.


In WebLogic Server SP02, SP03, and SP04, when getting certain POST requests from WAP devices, a Web application encountered a java.util.ConcurrentModificationException

<29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$ at weblogic.utils.enumerations.IteratorEnumerator.nextElement( at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML( at ...

Analysis revealed that when a charset is associated with the request's content-type, the code read the data again using the encoding, and reset the query parameters, in the application. The application already has the enumeration object and iterates it (request.getParameterNames), and then tries to get the value of the parameter (request.getParameterValues(k)). At that point, the query parameters are wiped out and getParameterValues method tries to set it, resulting in the exception.

The problem was resolved with a code change to set query parameters after they are wiped, so that the data can be read again when a charset is associated with the request's content-type.


Right after server startup some server requests were rejected because the MBean did not update server state before the listening thread started receiving requests.

This problem has been resolved by using Boolean flags inside the Web container to update the server state for the listening thread.


The following EJB/Web application setup was causing a class cast exception:

Servlet Filter1 --> WebApp1 -- forward to WebApp2 ctx --> Servlet

Filter2(WebApp2) --> Ejb Lookup (fails)

This problem has been fixed by locating the EJB lookup in the Servlet instead of a Servlet Filter when doing a forward between two Web applications.


When multiple chunked requests are posted to a servlet a number of the requests fail with a NumberFormationException. Mostly of the time alternate requests are fulfilled and the next request fails. It seemed to be occurring when the requests were being made on the same connection. The exception stack trace was:

<ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException: at java.lang.Integer.parseInt( at weblogic.utils.http.HttpChunkInputStream.readChunkSize( at weblogic.utils.http.HttpChunkInputStream.initChunk(

Analysis revealed two problems in PostInputStream:

  • It did not reset control variable readAllChunks when recycling PostInputStream

  • isChunkComplete did not detect the end of chunk correctly

The problem was resolved by a code fix to read until end of stream in PostInputStream and correctly detect end of chunk in HttpChunkInputStream.


A Web service using a filter servlet that, in turn, used HTTPRequest wrapper classes on top of an HTTPServletRequest resulted in a ClassCastException error, as WebLogic Server was expecting that request to be of the type weblogic.servlet.internal.ServletRequestImpl.

A code fix resolved the problem.


When a request with an incorrect URI was received from a from plug-in, WebLogic Server threw the following stack trace:

<Mar 8, 2003 3:27:20 PM PST> <Error> <Socket> <BEA-000421> <Uncaught Throwable i n processSockets java.lang.NullPointerException. java.lang.NullPointerException...

This problem was solved with a code fix.


WebLogic Server 6.1 SP04 misdirected output for JSP includes in JSP pages.

The problem was corrected with a code fix.


The first access to deleted JSP pages was causing a JspFileNotFoundException instead of 404 File Not Fount. Further access to this page correctly returned 404.

The problem is fixed so that deleted JSP pages always return 404.


In previous versions of WebLogic Server 7.0, if you invoked a JSP from a Web application running on an Admin Server so that the JSP registered a ModelMBean on the Admin Server MBeanServer, and then stopped and restarted a Managed Server, the server would fail with the following message:

<Critical> <WebLogicServer> <000364> <Server failed during initialization. - with nested exception:


java.lang.ClassCastException: at at at at


at weblogic.t3.srvr.T3Srvr.initialize1(

at weblogic.t3.srvr.T3Srvr.initialize(


at weblogic.Server.main(

Code changes in resolved the problem.


The following JSP code:

<jsp:plugin type="applet" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/" height="800" width="500" type="applet" jreversion="1.3.1_06" nspluginurl=""; iepluginurl=",1,3,0" >

generated this HTML:

<embed type="application/x-java-applet;version=1.3.1_06" pluginspage=""; height="800" width="500" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/">

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

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

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


If a taglib is imported once via the taglib directive in a page that includes a second page, and that second page also imports that same taglib, then invalid XML results in the following browser output:

Error 500--Internal Server Error From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.

And the following log file output:

<[ServletContext(id=287644,name=jspVal.war,context-path=/jspVal)] Servlet

failed withIOException javax.servlet.jsp.JspException: The taglib validator

rejected the page: "Exception TestValidator XML parsing: org.xml.sax.SAXParseException:

Attribute "xmlns:valtest" was already specified for element "jsp:root". -- stack trace written to stderr., "...

Because of a code change to weblogic.servlet.jsp.jsp2xml.Jsp2XmlOutputter, duplicate tag prefixes are ignored in the generation of the XML views of the JSPs.


Forwarding a request from a servlet or JSP to another JSP page did not log queryString in the access.log. Additionally, access.log logged the forwarded request, but not the original request.

A code change to RequestDispatcherImpl fixed the problem.


The HttpClusterServlet was not correctly parsing the session id from post data.

If you sent a request through HttpClusterServlet to a cluster, establishing a session, and then sent a second request without a cookie but with the session id in the post parameters, the servlet did not recognize the session.

The servlet is now able to extract the session id from the post data.


Performance improvements were made to the command-line compilation of jspc; One compiler process is now forked for each JSP, rather than multiple compiler processes. In addition, a TLD used for multiple JSPs is now parsed just once for all JSPs, rather than once each.


If a JSP called Security.getCurrentUser() with no user logged in, the following exception resulted:

java.lang.NullPointerException at

The code was changed to tolerate wlrealm null settings without throwing an exception.


Change Request Number



In previous releases of WebLogic Server 7.0, an unexpected exception was thrown while committing or rolling back a server-initiated transaction when the coordinating server was not the initiating server. The subordinate initiating server that was waiting for commit/rollback processing to complete was interrupted by an unexpected exception, often a PeerGoneException resulting from a restart of the coordinating server, and the transaction status was changed to "unknown." When the coordinating server restarted, it was not able to resolve the transaction correctly.

A code change allows the coordinating server to resolve the transaction correctly after restart.


The javax.transaction.xa.XAResource interface defines a method, setTransactionTimeout(), which allows the Transaction Manager to set the transaction timeout in the resource manager for operations associated with the XAResource instance. The WebLogic Server Transaction Manager did not invoke this method when a resource manager is accessed by an application in a global transaction.

The following properties were added to the JDBCConnectionPool object in the config.xml file:

  • XASetTransactionTimeout—Determines whether the Transaction Manager will call XAResource.setTransactionTimeout before the call to XAResource.start. Possible values are true and false. When set to true, the Transaction Manager passes the global transaction timeout in seconds to Oracle as the Session Timeout. When set to false, the Transaction Manager does not call XAResource.setTransactionTimeout. The default value for this parameter is false.

  • XATransactionTimeout—When XASetTransactionTimeout is set to true, the XATransactionTimeout value is sent to Oracle as the Session Timeout (same as setting the SesTm in an OpenString). When this parameter is set to 0 the Session Timeout is set to the global transaction timeout in seconds. The default value for this parameter is 0.

These parameters are valid for connection pools that use an XA JDBC driver to create database connections. They are ignored for connection pool that use a non-XA JDBC driver. These parameters are not available in the Administration Console.


In previous releases of WebLogic Server 7.0, a problem can occur when a transaction spans multiple WebLogic Server instances. With some configurations it is possible that transactions can accumulate redundant state resulting in increased completion times and possibly leading to transaction time outs. This problem was fixed by a code change.


In previous releases of WebLogic Server 7.0, a problem could occur with the recovery migration service with clustered Managed Servers when an exception was not caught. This could cause Managed Server boot failures when other members of the cluster were not yet running. This problem was fixed by a code change.

CR092301, CR107866

In previous releases of WebLogic Server 7.0, a NullPointerException exception can occur during transaction coordination for some configurations. This problem was fixed by a code change.


In WebLogic Server 7.0, transaction recovery processing on server restart was delayed for newly discovered resources. In WebLogic Server 7.0 SP3, WebLogic Server begins transaction recovery processing on a resource as soon as it is discovered by a server.


A subcoordinator server was not recovering in-doubt transactions automatically after server down, requiring manual rollback or commitment by the DBA.

Research revealed that the subcoordinator code was losing track of remote participants after server restart. A checkpoint was added to the code to properly track remote participants.


In WebLogic Server 7.0, stale entries in the transaction log sometimes caused unnecessary recovery overhead when a server is restarted. This problem was solved with a code fix.


In WebLogic Server WebLogic Server 7.0 SP1, a stale transaction state can become associated with dedicated communication threads which can then erroneously infect remote servers with a transaction, resulting in java.lang.IllegalStateException exceptions being generated. This problem was fixed by a code change.


In WebLogic Server 7.0 SP1, under certain circumstances when a server with JMS messages in a pending state is shut down or crashes, pending messages are not recovered when the server is restarted. The problem was resolved with a code fix.


JTA Migration sometimes failed with a NullPointerException or ConnectException after a transaction was propagated among two servers in cluster.

NullPointerException <Feb 28, 2003 6:38:44 PM JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [serverB] fails. java.lang.NullPointerException at...

ConnectException <2003/02/27 13:11:20:JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [server1] fails.> java.rmi.ConnectException: Destination unreachable; nested exception is: Connection refused: connect; No available router to destination at...

Research revealed that the code created a race condition between the notification of when the server was dead and when the information for that server was cleaned from the cache. If the notification that the server was dead came after the cache was cleared, the remaining Managed Server would get a NULLPointer Exception when it tried to look for the location of the tlog of the dead Managed Server.

A code fix resolved the problem.


If a transaction was rolled back, and a server participant had no resource participants, it was possible that the transaction would never be completed. The transaction continued to exist on the coordinating server and continually retried notifying the server with no resources to roll back. Eventually, the transaction was abandoned. Although all resource participants were informed of the rollback, it was possible that after completion callbacks would not be processed on the coordinating server.

This problem was resolved by logic changes in rollback asynchronous reply processing to accommodate servers with no resources and to immediately set state to rolled back when all servers and resources are accounted for.


As part of transaction timeout processing, for each transaction that had been prepared and for which the current server is a subordinate participant in the transaction, the Transaction Manager will send a one-way RMI message to the coordinator to determine the status of the transaction. If the coordinator was restarted, it is possible for this status request to be dispatched before the JTA subsystem finishes reading the commit records from the transaction log.

In this case, the status request was dispatched and checked to see if the transaction IDs being queried exist in the Transaction Manager's map of known transactions. Because the tlog had not yet been processed, the TM responded with a rollback decision to the subordinate, even if the transaction had passed the commit point prior to the coordinator restart.

This scenario resulted in a mixed transaction outcome where the resources on the subordinate making the status request are rolled back while other resources in the transaction are committed.

The code was changed so that it does not process checkStatus() requests before the JTA subsystem has initialized. This prevents a mixed transaction outcome.


The Transaction Manager was unnecessarily writing a commit record when all but one participating resource in a transaction respond to the prepare command with the XA_RDONLY flag.

A code change resolved this problem. Now, before writing a log record, the server checks to see how many participating resources require second phase. If the number is one, the transaction does not generate a commit record.


If all but one participating resources in a transaction respond to prepare with the XA_RDONLY flag, the transaction manager should issue a one-phase commit to the pending participant. However, the Transaction Manager was unnecessarily writing a commit record for this scenario.

The code was changed so that, before writing a log record, the Transaction Manager checks to see how many participants require second phase; if one does, the write is skipped. This resolved the problem.


While processing remote beforeCompletion callbacks, the Transaction Manager resumed the transaction context before invoking the registered objects. Statically registered resources were not enlisted when the transaction was resumed on the thread, which prevented beforeCompletion logic to perform additional updates as part of the transaction.

The Transaction Manager now allows enlistment of statically registered resources.


While processing remote beforeCompletion callbacks, the TM resumes the transaction context prior to invoking the registered objects. However, statically registered resources are not enlisted when the transaction is resumed on the thread.

The code was changed so that Enlistment is performed on such resources to allow beforeCompletion logic to perform additional updates as part of the transaction. This resolved the problem.

Operations, Administration, and Management

Change Request Number



LogManager's use of synchronization was causing a deadlock in the threads.

Eliminating some synchronization in LogManager fixed the problem. There is no more deadlock.


Change Request Number



The iPlanet server no longer crashes after an application (including a load testing application) makes multiple attempts to connect.


The NSAPI plug-in did not read the SESSIONID from post data.

Analysis revealed a problem in getPreferredServersFromCookie(). When session.getId() was kept as post data, getId() included an extra string: |time.

The problem was solved by a code fix.


When the Apache plug-in received a new dynamic server list from the backend server it reset the keepAliveSecs to 0. This resulted in the timer removing all the connections from the pool. So effectively connection pooling was broken.

A code fix eliminated this problem.


Dynamic server list was being parsed incorrectly with a cluster, by the Apache plug-in.

This problem was resolved and the server list is now being parsed correctly for versions going back to 5.1.


ISAPI plugin was not failing over on a HTTP 503 response from the backend WebLogic Server.

A code fix caused the plug-in to fail over when it receives a HTTP 503 response from WebLogic Server.


PathTrim value was case sensitive, and needed to be made case insensitive, for the ISAPI plug-in.

A code fix provides case insensitivity to the PathTrim value.


When using a long URI and a weblogiccluster instead of weblogichost, the Apache plug-in was shutting down unexpectedly.

A code fix increased the buffer size to the limit of the URI length, which resolves this problem.


Parsing post for cookies was not implemented correctly in the ISAPI plug-in.

The ISAPI plug-in now parses the post only if the content-type is application/x-www-form-urlencoded.


The X_WEBLOGIC_FORCE_JVMID header was sent to a server instance in a cluster, by the Apache plug-in.

X_WEBLOGIC_FORCE_JVMID should only be sent when the server list is non-clustered and the current server does not have a jvmid yet.

This problem was solved by a code fix.


Apache plug-ins needed to be created for Linux-IA64.

The binary files and libraries have been created, and the new plug-in is available.



A customer needed to determine a browser's cipher strength on the WebLogic side, in a configuration that included a plug-in with 128-bit step up certs between WebLogic Server and the browser. The browser had 40-bit or 128-bit strength. The customer used the following code to obtain the browser's cipher strength:


However, the value returned was always 128 (although the browser was set to use a cipher size less than 128-bit).

This problem occurred because HTTPS_KEYSIZE determines the strength of the connection that is made. Because 128-bit certs were used on the plug-in, 128 was returned, regardless of the strength used by the browser. When the request was directed to WebLogic Server, 40 or 128 was returned, depending on the browser strength. The plug-in does not modify the HTTPS_KEYSIZE or HTTPS_SECRETKEYSIZE headers.

To meet this need, two new headers were implemented: WL-Proxy-Client-Keysize and WL-Proxy-Client-Secretkeysize. Both headers values can be obtained using request.getHeader().


The following new exception types were added for the NSAPI plug-in: READ_ERROR_FROM_CLIENT, READ_ERROR_FROM_SERVER, READ_ERROR_FROM_FILE, WRITE_ERROR_TO_FILE


With the ISAPI plug-in, when requests contained multiple cookies, cookies not named JSESSIONID but that immediately followed the JSESSIONID cookie were stripped off and not delivered to WebLogic Server.

The problem was solved with a code change.


In the ssl_certchain_verify_callback method, SSLNoErr was returned as the error condition for some failure cases of certification validation. This included cases where the CA certificate had basic constraints that were not marked as critical and the strict setting was enabled (instead of the default "strong" setting), and if the certificate was not marked as being a CA.

This problem was resolved by returning X509CertChainInvalidErr for these failure cases (instead of SSLNoErr).


The NSAPI plug-in now supports dynamic DNS lookups on a DNS name when the name returns a list of IP addresses from the DNS server and the plug-in is configured with WebLogicHost = 'DNS name'.


Change Request Number



Some accessors did not map properly in the ejbc-generated IDL (Interface-Definition-Language). The problem has been resolved.


When setting principal and credentials in a client that then contacts a server that contacts another server, the server-to-server credential propagation of principals was not correct.

A code fix provides correct credential propagation.


WebLogic failed to get an ROID from a server and return it to a client, and threw the following exception:

java.rmi.UnmarshalException: failed to unmarshal class weblogic.cluster.replication.ROID; nested exception is: java.rmi.UnmarshalException: null; nested exception is: org.omg.CORBA.MARSHAL vmcid: 0x0 minor code: 0 completed: No

A code fix properly marshals the class.


The clustered reference used by CosNaming contains a single concrete reference, causing IIOP failover handling to malfunction at the JNDI level.

The reference was not being bound into JNDI. A code fix resolved this problem.


A code fix improved replacement for clusterable objects.


A fat client connects to a stateless EJB and then invokes a method that returns a class that extends Vector. The class extending Vector uses its own serialization to improve optimization of the serialization. The fat client displays the contents of this Vector class. If RMI-IIOP is used as the protocol, then the Vector is empty.

Analysis revealed that the call to writeReplace was too late. The repository ID had already been written so that WebLogic Server read the actual class rather than the class that should be resolved.

A code fix invokes writeReplace properly for externalizable classes.


The MBean property Server.IIOP.IdleConnectionTimeout configures how long the server lets a connection be idle before closing it. WebLogic Server did not have a similar client-side property.

A code fix implemented an idle timeout and a pending timeout. The pending timeout is controlled by the DGC period length and number.

To set the idle timeout to 100s (default is 240 s):


To set the pending timeout to 5 minutes (default is 60 s):


To set the period length:

-Dweblogic.PeriodLength=120000 (for 120 s)

A connection is be timed out if the connection idle period has not elapsed. It is assumed that the pending timeout is always greater than the idle timeout. The pending timeout is used for outbound connections that are still awaiting responses.


WebLogic Server does not support outbound chunking of IIOP valuetypes, which meant it did not support change to externalizable classes.

A code fix implemented support for outbound chunking.


In 7.0 (G.A., SP01, and SP02), a client accessing WebLogic Server through a firewall using the t3 protocol received an error because the server expected to route a message over a connection that was not initialized.

The server's ExternalDNSName was specified. Upon initial connection, the client addressed the request to the server instance's ExternalDNSName. The JVMID in the response from the server instance requires the server's internal IP address and internal DNS name. Subsequent requests from the client were not recognized.

A code fix resolved the problem.


A code fix correctly maintains IIOP client context IDs (including the thin-client) for multiple threads doing competing authentications.


When the client was on a server in one cluster and was using a replica-aware stub for a server in another cluster, the local server could not be in the replica list, and therefore, the preferred host was ignored.

This problem was resolved by modifying the code to check for local affinity (which will never be obtained when calling a remote cluster). If the local affinity cannot be obtained, then the preferred host is compared against the replica list. If and only if there is no match in the replica list will a host be chosen from the list using the load-balancing algorithm.


A bug prevented exception interoperability working over IIOP. Specifically an exception thrown by a server running on JDK 1.4.x (i.e 8.1) could not be understood by a 7.0.x server running on JDK 1.3.1. This manifested itself as a MARSHAL exception. There were two bugs, one in the handling of sequences and the other in the way classes with described by FVDs (FullValueDescriptions). Exception interoperability now works over IIOP.


WebLogic Server RMI now supports arrays of primitives.


Over CORBA and IIOP, client-server access generated marshalling and indirection errors.

Code changes fixed the generation of hashCodes during indirection, and also equals for IndirectionWrapper.


Change Request Number


CR080488, CR091569

A sample custom Authentication provider that supports the user/group management Security Service Programming Interfaces (SSPIs) was included in the sample security providers code example on dev2dev. In addition, a custom Auditing provider was added to the code example.

For more information, see http://dev2dev/codelibrary/code/security_prov81.jsp.


Within two trusted domains, a Java client calls stateless session bean1 on server1 in domain1. This bean calls stateless session bean2 on server2 in domain2. The user calling the first server is user system in group Administrators with Role Admin (default).

If the call from bean 1 to bean 2 used the t3 protocol, the principal was propagated properly.

If the call from bean 1 to bean 2 was an IIOP call and there was a security role assignment in the weblogic-ejb-jar.xml that mapped the role Admin to user system, the principal was propagated properly.

However, if the call from bean 1 to bean 2 was an IIOP call and the security role assignment mapped role Admin to group Administrators, an org.omg.CORBA.NO_PERMISSION error occurred.

The principal propagation now works properly in all situations.


After creating a domain with one Administration Server and one Managed Server, enabling the for the two servers returned a error reported in the AdminServer log for <Error> <EmbeddedLDAP> <000000> <Error parsing Entry #19: access denied ( .\myserver\ldap\ldapfiles\ read)>.

This problem was resolved by updates to the weblogic.policy file, to which was added information about granting permissions to user applications, and examples of grant statements. The weblogic.policy works for Weblogic Server Examples, Pet Store, and Workshop. It needs to be modified to be used for user configurations; instructions are in the comments at the top of the file.


WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority. This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA thus ensuring all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected. If WebLogic Server is booted with a certificate chain that won't pass the certificate validation, an information message is logged noting that clients could reject it.

For more information, see SSL Certificate Validation.


When using the Active Directory LDAP Authentication provider, the user search filter did not support the use of backslashes in a user name. The LDAPv3 Attribute Syntax Definition specification supports the use of backslashes in the user search filter. The code for the user search filter has been updated to support the use of backslashes.


The methods getCurrentUser and getCurrentSubject are supposed to return the user ID of the user associated with the current thread. In previous Service Packs of WebLogic Server 7.0, if you forwarded from one servlet to another using RequestDispatcher.forward, these methods would return null (or an empty string).

A code fix resolved this issue so that requests forwarded from one JSP or servlet to another will carry the authenticated user in the session.


In previous releases of WebLogic Server, the SSL license check required both the 128 bit and the IP address using the license. The original intent of the license check was:

  • To ensure customers could not use the Certicom SSL runtime except when running WebLogic Server. This was a requirement of BEA System's agreement with Certicom.

  • To determine what strength SSL could be used (domestic or export). This was a government regulation.

BEA recommended that Java clients not running on a server copy the license from the server to the Java client machine. However, the implementation of the license check in the SSL code asked for an IP validation. Therefore, the server SSL license could not be used on the client machine. The IP validation in the license check has been removed. The license can now be copied from the server to the Java client machine.


When using the Active Directory LDAP Authentication provider, the user search filter did not support the use of nature language characters in a user name. The LDAPv3 Attribute Syntax Definition specification supports the use of natural language characters in the user search filter. The code for the user search filter is updated to support the use of nature language characters.


The Realm Adapter Authentication provider in the Compatibility realm used the authenticated user name in the User object instead of creating a User object with a unique ID. This problem broke backward compatibility with custom security realms that perform simple authentication (username/password).

The Realm Adapter Authentication provider code has been modified to create a User object with a unique ID.


The password used to access the encrypted private key in the Node Manager key file, weblogic.nodemanager.keyPassword, was in plain text and accessible.

The problem was resolved by the creation of the Node Manager properties file,


The hierarchy caching optimization has been removed from the resource engine within the WebLogic security framework. The resource cache has been updated to use Resource as a key. The cache now runs resource.equals() on every cache hit to make sure there is not a hash code collision. The resource string representation and parent are cached in the resource, so after the hierarchy is in cache only one cache lookup is required to get the resource name path. This change improves the performance of WebLogic Server.


A call to username password always raised an exception. This problem has been resolved.


In earlier versions of WebLogic Server 7.0, groups in LDAP had to be explicitly added to one another for WebLogic Server to recognize that the two groups were nested. Implicit nesting, by adding a group under another group in an LDAP tree, was not recognized.

This problem has been resolved by a modification to the LDAP provider that makes it perform group membership checking by hierarchy. Set the property as follows:"true"


When two-way SSL and the method were used, an exception occurred. The import in the authentication portion of the servlet code used instead of as defined by the servlet specification. The servlet code now uses


The LDAP Realm v2 had poor performance when handling groups with a large number of users. This problem could cause the WebLogic Portal server to hang and time out. The problem was related to the calls to:


Specifically, the calls hung if there were many groups in the groupDN were searched by the LDAPRealm v2 and the Group.isMember method was called in succession for all of these groups. Generally, the server would hang after several hundred calls in a row.

The code for the LDAP Realm v2 was updated to resolve this problem and improve performance when handling groups with large numbers.


The default value for backup minutes is now correctly calculated and reported under domain > Domain Wide Security Settings -> Embedded LDAP in the Administration Console.


When using a 6.1 security configuration that uses the RDBMS security realm, the server (and therefore Compatibility security) would not start.

    1. The RDBMS Realm config.xml entry needs to explicitly state the RealmClassName, Database Driver and Database URL attributes. When using the RDBMS security realm in 6.x, these values assumed the RDBMS code example and the examples database were used.

    2. The HimselfAAA code must be recompiled to work with WebLogic Server version 7.0. In WebLogic Server 6.x, a private Admin API was exposed in the RDBMS code example. This is a known issue. For more information, see Upgrading Security.

    3. The Weblogic Server code which loads the security realms did not properly defend against cases where the RealmClassName attribute would be empty. This code has been updated and an exception which clearly states that a Realm Class Name must be supplied is thrown.

CR096589 was failing with a class cast exception.

Research revealed that the wrong certification class was being imported. A code fix resolved the problem.


Construction of an AuthenticationProvider was not recognizing errors, because WebLogicBeanMaker was not seeing exceptions thrown by the AuthenticationMBI class constructor.

The problem was resolved by a code change ensuring the propagation of errors.


In past releases of WebLogic Server, the WebLogic Credential Mapping gave no notification when it received passwords that it could not validate. This problem has been resolved. The WebLogic Credential Mapping provider now throws an exception when it receives encrypted passwords that cannot be validated.


In past releases of WebLogic Server, the passwords stored in the embedded LDAP server by the WebLogic Credential Mapping provider were in clear text. The WebLogic Credential Mapping provider now encrypts passwords when storing them in the embedded LDAP server.


Node Manager allowed unauthorized starting of Managed Servers, because it supplied a cleared user name and password regardless of the authorization level of the user.

Node Manager now performs a security check on the user.


The Bouncy Castle JCE provider was not tested prior to 7.0 SP3, and requires special case code to get it to work with SSL. In this release, code was added to SSL to detect when the BouncyCastle provider JCE is plugged in, and fall back to use internal cryptography instead. Customers that want to use the BouncyCastle JCE provider in their server side applications can do that now without provoking an exception. SSL will not use that provider if it is plugged in, but the exception will not occur.


When a user account in one of the supported LDAP servers became disabled (for example, if the account was disabled for a long period time or locked because of a failure), any attempt to use that account (username/password) from an LDAP security realm resulted in the need to restart the server. The following exception was throw:

<[WebAppServletContext(2052089,WebCM-Outages,/Webbed-Outages)] Servlet failed with Exception netscape.ldap.LDAPException

This problem has been resolved.


In previous releases of WebLogic Server, the code that unloaded the SunJCE provider at runtime was still being used. This problem did not allow the use of the Sun JCE provider with WebLogic Server when the SSL protocol was enabled on the server instance.

This problem has been resolved.

Customers who are using JDK 1.4 clients with Sun JCE may experience a performance degradation due to a performance issue in the JDK 1.4 JCE implementation. If the client does not require the Sun JCE provider, you should comment out the Syncs provider from the JDK/re/lib/security/ file as follows:


The default connection filter in WebLogic Server was not handling the HTTPS protocol properly. This problem has been resolved.


In previous releases of WebLogic Server, it was not possible to make a secure connection to a third-party XML server because the XML server did not support the SSL protocol.

The following workaround is provided:

    1. Create a WebLogic client (a Java Server page (JSP) deployed in WebLogic Server).

    2. Create an Java authenticator class according to the Java specification. This authenticator should obtain a surname and password for the used to connect to the XML server.

    3. Specify Net Permission for the Java authenticator class in the weblogic.policy file. The Net Permission is granted to all users of that Java VM. Note this presents a possible security weakness and should therefore be used carefully.

    4. Use to establish a connection to the XML server.

    5. Specify -DUseSunHttpHandler as a command-line argument when starting WebLogic Server.


Eracom and Entrust third-party security providers have been certified for this release.


7.0 SP2 enabled JCE providers to be used for SSL cryptography operations. Unfortunately, all JCE providers do not behave the same way; each requires special handling and foreknowledge. The ERACOM/Entrust JCE providers require special case code to work with SSL.

Code added to SSL causes it to detect when the ERACOM/Entrust providers are plugged in, and to use internal cryptography. ERACOM/Entrust JCE providers work in server-side applications now.


Please review the security advisory information at


Please review the security advisory information at


When multiple authorization providers were installed, you could not define policy on Web applications.

This problem has been fixed.

System Administration

Change Request Number



When multiple elements in WebLogic Server's config.xml had the same objectnames, later elements overwrite configurations for preceding elements. This used to happen silently. Now, WebLogic Server throws an error message (ID=150012) to standard output.


In Unix, newly deployed files did not display in file or directory listings unless you changed to the root directory and then changed back to the newly deployed file's parent directory.

This problem was resolved by code changes to file_chooser.jsp.


The WebLogic Server SNMP MIB had a duplicate OID ( for applicationRuntimeIndex and cacheMonitorRuntimeIndex. cacheMonitorRuntime now uses a unique OID:


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


The ServerLifecycleRuntimeMBean and the ServerConfigMBeans for a deleted Managed Server continued to exist until the Administration Server restarted.

Deleting their Managed Server now deletes these MBeans.


Fixed a bug that caused the following exception when starting the Administration Server and using SNMP: java.lang.ClassNotFoundException:


Fixed a problem that displayed an unnecessary error message if both weblogic.Domain and weblogic.apache.xerces.maxentityrefs are set when starting WebLogic Server.


Fixed a problem causing a NPE when using dynamic MBeans.


Fixed a problem when restarting an Administration Server that caused the following exception when using the domain-wide Administration Port. This exception does not occur when the domain-wide Administration Port is not used, nor is the exception thrown when the domain is initially booted:

<Emergency> <Configuration Management> <150009>

<Errors detected attempting to connect to admin server ...


Fixed a problem that causes application deployment to fail after restarting an Administration Server while Managed Servers are running.


On HP-UX, migration to 7.0 from earlier versions of WebLogic Server sometimes failed with an OutOfMemory error.

The problem was caused by a hard-coded reference to a JDK in an Ant script.

Replacing the reference with a variable fixed the problem.


Fixed a problem that caused a NPE when invoking MBeanHome.deleteMBean().


Fixed SUID incompatibilities in the System Administration subsystem.


Binding is newly implemented for the T3S protocol.


The getAttributes() in RequiredModelMBean should return a, which should contain objects, but in the WebLogic Server 7.0 JMX implementation the AttributeList returned by RequiredModelMBean contained the value of the MBean attribute directly and not as a object, causing the following exception:

java.lang.ClassCastException: java.lang.String at at Serverkel.invoke(Unknown Source)

at weblogic.rmi.internal.BasicServerRef.invoke( at weblogic.rmi.internal.BasicServerRef$ at at weblogic.rmi.internal.BasicServerRef.handleRequest( at weblogic.rmi.internal.BasicExecuteRequest.execute( at weblogic.kernel.ExecuteThread.execute( at server side stack trace

at com.adventnet.beasupport.client.JMXConverter.convertInvocationTargetException( at com.adventnet.beasupport.client.ProxyMBeanServer.getAttributes( at com.adventnet.beasupport.client.WebLogicClient.getAttributes( at com.adventnet.beasupport.client.WebLogicClient.cmdline( at com.adventnet.beasupport.client.WebLogicClient.access$000( at com.adventnet.beasupport.client.WebLogicClient$

The GetAttributes method now returns an Attribute object.


Setting a JMSServer's Store property via the weblogic.Admin utility:

java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -mbean examples:Name=examplesJMSServer,Type=JMSServer -property Store examples:Name=examplesJMSFileStore,Type=JMSStore

resulted in the following exception:

<Mar 10, 2003 3:32:15 PM EST> <Error> <Management> <141033> <Error importing MBean examples:Name=examplesJMSFileStore,Type=JMSStore to server examples:Name=examplesJMSFileStore,Type=JMSStore

This problem was partially fixed by checking when setting an attribute that is a WebLogicObjectName on a configuration MBean. The code checks to see if the bean is a valid one and will throw an InvalidAttributeValueException. This is logged on the Adminstration Server and the JMSServer remains usable but does not have the file store set.


A Managed Server failed with the following stack trace:

java.rmi.ConnectException: This RJVM has already been shutdown -1425673232662082784S:WebLogic ServerDEBUG1:[53101,53101,53102,53102,53101,53102,-1]:WebLogic Servere1:ADMIN Start server side stack trace: java.rmi.ConnectException: This RJVM has already been shutdown -1425673232662082784S:WebLogic ServerDEBUG1:[53101,53101,53102,53102,53101,53102,-1]:WebLogic Servere1:ADMIN at weblogic.rjvm.RJVMImpl.getOutputStream( Code)) at weblogic.rjvm.RJVMImpl.getRequestStream( Code)) at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest( Code)) at weblogic.rmi.internal.BasicRemoteRef.invoke( Code)) at Servertub.getMBean(Unknown Source) at Code)) at Code)) at at at weblogic.drs.internal.SlaveCallbackHandler$2.execute( at weblogic.kernel.ExecuteThread.execute( Code)) at..

Research revealed that the application slave deployer, which runs on the Managed Server, was looking up, caching and using the Administration Server's Admin MBeanHome when it was initialized, that is, when the slave deployer was initialized.

The code was changed so that the Administration Server's Admin MBeanHome is looked up when necessary instead of being cached when the slave deployer is initialized. This resolved the problem.


A cluster contained an Administration Server and two Managed Servers. Application1.ear contained EJBs and Web applications; the EJBs were deployed to the cluster and the webApps were deployed to a VirtualHost, which is in turn was targeted to the cluster. Application1.ear contained Application1.war, which was configured as the DefaultWebApp of the VirtualHost. In addition to this, each cluster node had its own DefaultWebApp.

Undeploying Application1.ear resulted in the following exception:

deactivating application application1 on server2 deactivating application application1 on server1 deactivated application application1 on server2 unpreparing application application1 on server2 deactivated application application1 on server1 unpreparing application application1 on server1 failed application application1 on server2 failed application application1 on server1 Exception caught for task Unprepare application application1 on mycluster,application1: Start server side stack trace: java.lang.reflect.UndeclaredThrowableException: java.lang.reflect.InvocationTargetException: listener: ServletContext(id=559103557,name=DefaultWebApp,context-path=)

The application could not be redeployed, even if the entire domain was restarted.

Research revealed that the Application Mbean unstageTargets() method used an incorrect indexing for unstaging virtualHosts.

A code fix resolved the problem.


A WebLogic Server instance gave an OutOfMemoryError when receiving 21,000 persisted messages synchronously in a transacted session on Solaris.

The garbage collector was slow at reclaiming long lists that are freed. Breaking up the linked lists fixed the problem.


Some load-balancing applications such as Cisco Loadbalancer became unable to use session stickiness because of a change to the SessionID format in 7.0.

A new server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true , retains the information that the load-balancing application needs for session stickiness.


Exception propagation was not working properly because RemoteException was not being treated as a valuetype for rapid caching.

Caching only real valuetypes fixed the problem.


An exploded Web application was allowed to load classes from the docroot.

This inappropriate classloading behavior has been disallowed.


On GroupReaderMBean, isMember was failing when member name contained a comma.

A code change resolved this problem so that member names containing commas are now accepted.


Links on the Examples server point to local files, which does not work if users are accessing them from remote browsers.

The problem was fixed by adding virtual-mapping to weblogic.xml of examplesWebApp so that remote users may browse example documentation.

To activate, properly configure virtual-mapping in weblogic.xml, replacing the <local-path> value of <virtual-directory-mapping> with your samples installation location (for example, d:/bea/weblogic/samples/server/src).


When a t3 connection was established with WebLogic Server with weblogic.jar in the bootclasspath, the following exception occurred:

java.lang.NullPointerException at weblogic.rmi.internal.StubGenerator.getStubClass( at weblogic.rmi.internal.StubGenerator.generateStub( at weblogic.rmi.internal.StubGenerator.generateStub( at weblogic.rmi.extensions.StubFactory.getStub( at weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub( at weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext( at weblogic.jndi.WLInitialContextFactoryDelegate.newContext( at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext( at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext( at weblogic.jndi.WLInitialContextFactory.getInitialContext( at javax.naming.spi.NamingManager.getInitialContext( at javax.naming.InitialContext.getDefaultInitCtx( at javax.naming.InitialContext.init(

A code change that specifies using an augmentable classloader to generate stubs fixed the problem.


Change Request Number



In the WebLogic Builder WebLogic Settings panel, when a RAR's "Capacity increment" was larger than the difference between "Maximum capacity" and "Initial capacity", WebLogic Builder failed to load the RAR, and printed a SAXProcessorException beginning: weblogic.xml.process.: capacity-increment should be less than or equal to ( max_capacity-initial_capacity)

A code change resolved the problem.


Relations listed in the EJB Relations panel are now sorted alphabetically by name.


Method name and transaction attributes are now required information for creating a new method.


Methods from the bean class are no longer listed in the Method name selection list in the Add method dialog. Home, local home, remote interface, and local interface methods are still listed.


The deployment dialog no longer needs to be refreshed before it displays accurately the status of a failed deployment.


In the Advanced panel of an entity bean, the selection list was not displaying all of the read-only entity beans that can be invalidated when the container-managed persistence entity bean has been modified. The list now displays all such beans.


When you open a project without compiling the classes referenced in the deployment descriptors, Builder used to throw a spurious AssertionError. It now warns the user that the classes cannot be found.


WebLogic Builder no longer incorrectly allows JNDI names to be assigned to beans that have no local interface.


WebLogic Builder's validation utility detects updated class files in exploded modules, but not in archived modules. Builder detects updated class files in both archived and exploded modules when you close and re-open the project


If you remove all CMP fields from a project, Builder may corrupt weblogic-rdbms-cmp-jar.xml. A warning appears if you try to remove all CMP fields from a project.


It is now possible to abort or cancel creation of a relationship in Builder's Add Relation, Add Finder, and Add CMP wizards.


Builder now displays a warning when invalid CMP nodes are activated.


Before this release, adding a row in a bean's CMP Fields node and then deleting it in the table view would cause an AssertionError to be thrown. This problem, which was caused by an incompletely defined property in Builder's user interface, has been fixed.


An advanced panel now exists for BMP beans, similar to the panel for CMP beans.


A new deployment descriptor element called <allow-remove-during-transaction> was added to the weblogic-ejb-jar.xml deployment descriptor. This tag was added for stateful session beans and is the child of the <stateful-session-descriptor> tag. However, the tag was not surfaced in WebLogic Builder.

This problem was resolved by adding the 'Allow remove during transaction' check box to the Advanced Pane of a Session in WebLogic Builder.


Using weblogic.Deployer to deploy an application to a cluster with a user in the Deployers group deployed the application, but also caused the following exception: Access not allowed for subject: principals=[velvet, Deployers], on ResourceType: Cluster Action: execute, Target: addDeployment


Adding ACLs for cluster deployment fixed the problem.


Calling getLogFileName on the VirtualHostMBean was returning an incorrect path.


Redeploying to a Managed Server using weblogic.Deployer without specifying the server was deploying the application to the Administration Server.

The problem has been resolved by a change to the weblogic.Deployer utility.


weblogic.Admin was not handling invalid URL arguments properly. For instance:

java weblogic.Admin https://hostname:8888

when there is no server running there should result in a "Failed to connect" error message, but sometimes resulted in the command exiting without explanation, or hanging.

The problem was fixed. An exception that was being thrown by is now caught, and an appropriate error message is displayed.


Creating a relation with the same name as another relation in the same project is no longer allowed in WebLogic Builder.


The cache table in the Tuning panel of an entity bean is now disabled if no cache references are available. Clicking on elements of a cache table when no cache references were available was causing an error.


WebLogic Builder did not expose pool settings for entity beans.

This problem was resolved by adding a Pool Panel for entity beans to the Tuning sub-node.


In 6.1 SP04, <is-modified-method-name> was not called on CMP 2.0 beans. ejbStore() was called at every bean method invocation and WebLogic Server determined afterwards if the store is to avoid. This caused performance issues in applications that frequently used <is-modified-method-name>.

The problem was solved by implementing the <is-modified-method-name> function for CMP EJB 2.0.


weblogic.Admin prompted for a password, and then threw an exception before you could type it.

A code change resolved this problem.

CR098709 Tools

While performing a SET operation, the client was constructing WebLogicObjectname corresponding to the MBean. However, other members such as parent, were not set correctly. This made the WebLogicObjectname inconsistent.

Sanitizing all attributes whose values belong to WebLogicObjectname fixed the problem.


The setWebLogic script sometimes failed to source the script.

The problem was a relative address of the script that did not work in all system shells.

Replacing the reference with a universally readable relative address fixed the problem.


You can now rename existing relations in the Add relations wizard. The name field of an existing relation was previously read-only.


Previously, resetting default transaction attributes in a bean was causing transaction attributes in other beans in the project to reset also. Multiple methods containing multiple transaction attributes were sometimes redefined as a single method with a single transaction attribute. This behavior no longer occurs.


Previously, some beans with bean-managed persistence were timing out at periods inconsistent with the transaction timeout settings in their deployment descriptor files. BMP beans now behave as CMP beans do, in accordance with the deployment descriptors.


In previous versions of WebLogic Builder, some controls were inappropriately available. For instance, you could fill out the name value for an Oracle sequence even if automatic key generation was not enabled for the application. An effort has been made to disable and enable controls appropriately throughout the WebLogic Builder interface.


The automatic key generation frame in WebLogic Builder did not enable/disable all fields consistently. For example, if you opened a JAR that did not have an <automatic-key-generation> tag and loaded the Automatic Key Generation tab, the check box would be unchecked, but you could still enter a value.

This problem was resolved by modifying the code so that the fields are uniformly disabled.


The setting for caching between transactions was not being persisted, so that you could go to a bean's Tuning panel and select a concurrency strategy and check "Cache between transactions," and when you re-opened the project the setting had reverted to "False." This setting is now persisted.


Updates to finder methods were sometimes not being persisted. The autocommit setting was to blame, and it has been fixed.


The Server was sometimes unusable until restart after a bad Type setting had been used when setting JMSFileStore with weblogic.Admin.

A bad Type setting now results in a InvalidAttributeValueException being logged on the Admin server.


Debug flags in the command-line to start a server were persisting to the domain configuration file, so that a server started in debugging mode remained in debugging mode until the debug flags were taken out of config.xml.

Following a code fix, command-line flags no longer write to config.xml.


java weblogic.marathon.ddinit.WebInit stageDir failed to generate servlet components in weblogic.xml and web.xml.

A regression in the codeline cause the problem. This was fixed and the problem was resolved.

Web Services

Change Request Number



In client code with weblogic.jar in the classpath returned 200, while running in the container for the same url returned 404. The cause of the 404 message was that, using HttpURLConnection from within WebLogic Server, the EJB code received an instance of setRequestProperty() ignored any headers with empty value strings. SOAPAction header was required by the Apache server hosting

You can specify which protocol Handler you want to use, which allows you to use the Sun implementation in your code. The following simple servlet illustrates this:

package test;


import java.util.*;

import javax.servlet.*;

import javax.servlet.http.*;


public class ProtocolHandlerTest extends HttpServlet {

public void service(HttpServletRequest request, HttpServletResponse response) { try { URL testUrl_1 = new URL(null, "";, new;

URLConnection huc_1 = testUrl_1.openConnection();

URL testUrl_2 = new URL(null, "";);

URLConnection huc_2 = testUrl_2.openConnection();

System.out.println("huc_1 = "+huc_1.getClass().getName());

System.out.println("huc_2 = "+huc_2.getClass().getName());

} catch ( mue) {

} catch ( ioe) { } }}


The WebLogic Web Services runtime environment, when generating the WSDL for a deployed Web Service, now correctly maps any exceptions thrown by the EJB method that implements an operation to a <soap:fault> element in the WSDL. Previously, these Web Service-specific exceptions were being incorrectly mapped to <soap:body> elements.


The clientgen Ant task now correctly accepts a <classpath> child element in the build.xml file that contains the call to clientgen.


The Javadoc for the weblogic.uddi.client.service.Inquiry.findService method of the UDDI Client API has been updated to specify that, in addition to the service name, you must also include the business key when using the method.


The implementation of the weblogic.webservice.client.WebLogic ServerSLAdapter interface no longer fails to propagate user certificates to the SSL connections it opens. Previously, it was not possible to perform authentication on Web Service invocations using client-side certificates over SSL.


The WebLogic Web Services runtime no longer alters the javax.xml.rpc.soap.SOAPFaultException exception when thrown from a stateless session EJB that implements a WebLogic Web Service. Previously, the exception would be incorrectly wrapped in an EJBException.


The Web Services runtime now correctly propagates the HTTP 500 "Internal Server Error" exception to a client if the Web service being invoked throws an exception. The actual exception is correctly contained in the SOAP Fault.


When processing the following WSDL file, the clientgen ant task created invalid classes:

wsdl:message name="UploadCBProfileRequest"> <wsdl:part name="body" element="tns:TRAMSDATA"/> <wsdl:part name="authHeader" element="tns:AuthenticationHeader"/> </wsdl:message> <wsdl:portType name="RelMgrPortType"> <wsdl:operation name="uploadCBProfile"> <wsdl:input message="tns:UploadCBProfileRequest"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RelMgrSOAPBinding" type="tns:RelMgrPortType"> <soap:binding style="document" transport="";/> <wsdl:operation name="uploadCBProfile"> <soap:operation soapAction="" style="document"/> <wsdl:input> <soap:body parts="body" use="literal"/> <soap:header wsdl:required="true" message="tns:UploadCBProfileRequest" part="authHeader" use="literal" xmlns:wsdl="";> </soap:header> </wsdl:input> </wsdl:operation> </wsdl:binding>

The resultant generated task contained duplicate uploadCBProfile() arguments.

Research revealed that the code was adding header parts to message even if that part was already there. A code fix resolved the problem.


In WebLogic Server 6.1SP03, the client for the sample Web service at samples\examples\webservices\rpc\weatherEJB was built by wsgen and deployed using only the client.jar (no weblogic.jar). When the non-SSL web service was invoked by the Java client, the following exception was thrown:

<< Missing class files in servicegen client.jar. Getting Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/net/http/HttpsURLConnection at weblogic.soap.http.SoapContext.lookup( at javax.naming.InitialContext.lookup( at com.verizon.client.client.main( >>

Analysis revealed that the class is necessary for minimal out-of-the-box functionality and should be included in the client.jar.

The problem was resolved by adding to client.txt.


You can now successfully use the UDDIExplorer to publish a Web Service to a private UDDI registry when using the JRockit JVM with WebLogic Server. Previously, publishing a service to the private registry would return the UDDIExplorer error "E_fatalError(10500): a serious technical error has occurred while processing the request." The same publish operation has always worked correctly with the default Sun JVM.


The Web Service Ant tasks that generate the non-built-in data type components (such as the serialization class, Java class, and so on) now correctly convert the unsupported XML Schema data type xsd:union to the default Java class for unsupported XML Schema types: SOAPElement. Previously the Ant tasks would fail with an error.


The WebLogic Web Services runtime now wraps the details of exceptions it gets from WebLogic Server in CDATA, correcting a previous problem in which the details of a SOAP fault might contain invalid XML. An example of invalid XML is a WebLogic Server message such as <no stracktrace available> is placed within <> resulting in the invalid <<no stacktrace available>>.


Unless verbose mode is explicitly enabled, the following warning is no longer outputted to the command window from which you started WebLogic Server when deploying a Web Service that has a handler-implemented operation:

WARNINIG: Unable to find a javaType for the xmlType:datatype. Make sure that you have registered this xml type in the type mapping Using SOAPElement instead.

The Web Services runtime is checking for typemapping information which is not needed in this case, so the warning is confusing and misleading.


The servicegen Ant task no longer returns an error when used with the typeMappingFile attribute, and the specified types.xml file contains a class name for a non-built-in Java data type that does not follow the JAX-RPC naming conventions. If you are creating your own serialization class, non-built-in Java data types, and so on, you can name the Java data type anything you want.


The WebLogic Web Services runtime now correctly handles the time part of xsd:dateTime values. Previously, due to incorrectly handling of timezone offsets, the time would change depending on the timezone.


The WebLogic Web Services runtime now correctly handles xsd:dateTime data types. Previously, the "+" character was omitted from the time zone offset part of the dateTime value when the timezone was positive.


On abort of an SSL connection, the CLOSE_WAIT might remain for some time, keeping the socket open.

A code change fixed the socket leak.


Implementing a Web service with the following signature:

public void echoDom(Document doc)

resulted in a compile error.

This problem was resolved by disallowing void to be added to type-mapping for document style at build or runtime, preventing the writing of void part for document style, and avoiding using the wrapper element in the Document serializer for document style.


clientgen was not creating serializer and deserializer classes for complex types.

clientgen now handles complex types that contain single references to model groups.


Running with invocation-style="one-way" results in the WSDL containing an <output> in the <binding> section for that operation as can be seen from the snippet below.

<portType name="MyServicePort">

<operation name="sayNothing">

<input message="tns:sayNothing" />



<binding name="MyServicePortSoapBinding" type="tns:MyServicePort">

<soap:binding style="document"

transport=""; />

<operation name="sayNothing">

<soap:operation soapAction="" style="document" />


<soap:body use="literal" namespace=""; />



<soap:body use="literal" namespace=""; />




This behavior was exhibited in both "rpc" and "document" style web services. Running with Microsoft's WSDL.EXE against this WSDL resulted in an unsuccessful validation and consequently in a failure to generate the .Net client proxy or stubs.

A code change stopped the generation of output messages in one-way bindings, resolving the problem.


Because Hewlett-Packard ceased to support the HP Apache-based Web Server version 1.3.x, WebLogic Server removed the Apache 1.3 plug-in for HP.


When using a thin client (wlclient.jar), customers may have encountered a marshalling exception that indicated an IIOP stream corruption. This problem occurred when IIOP or T3 was specified as the protocol in multiple minor versions of J2SE 1.4, but not when weblogic.jar was in the client classpath.

This problem occurred because of issues with the encoding and decoding of custom marshaled valuetypes and in the way WebLogic Server kept track of indirections when marshaling valuetypes.

These issues have been resolved.

WebLogic Tuxedo Connector

Change Request Number



When creating large Field Manipulation Language (FML) tables (on the order of 4K entries), mkfldclass[32] generated a method to instantiate each entry into a hash table. For large FML tables, this single method exceeds the size limitation in the JVM.

This problem was resolved by implementing a dynamic load field table mechanism. For more information, see Using the DynRdHdr Property for mkfldclass32 Class.


viewj and viewj32 methods can create huge java classes (exceeding 65535 byte codes in the constructor method) when compiling view files that contain a large number of fields.

Analysis of the problem revealed that majority of the code in the constructor involved assigning null values to fields and array elements and could be removed.

This problem was resolved by providing a code fix that suppresses redundant code when compiling view files.


Using WTC to access Tuxedo 8 Corba objects resulted ia n JavaIDL Reader thread leak. Running a simple example application resulted in a build-up of JavaIDL Reader threads in the JVM running WebLogic Server. The threads were not destroyed until the server was shut down.

Analysis revealed the finalize() was not called at the correct time. A code fix to add a call to ORB.destroy() was implemented to resolve the problem.


Change Request Number



The built-in XML parser (based on Apache's Xerces) no longer throws a java.lang.ArrayIndexOutOfBoundsException exception when parsing an XML file that contains Japanese characters.


The built-in XML transformer (based on Apache's Xalan) now correctly adds a closing </META> tag when transforming an XML file into an HTML file using an XSL stylesheet. Previously, the closing </META> tag was not generated in the output HTML file, causing the XML to be invalid, although the HTML file rendered correctly in a browser.


Previously, certain types of XML files caused a decay in the response times of parsing them as the iterations increased. This is no longer true.


There was a conflict using JSTL tags in JSP with Japanese characters under these conditions:

1. Page encoding of JSP is defined by Shift_JIS. <%@ page pageEncoding="Shift_JIS" %>

2. Using multibyte characters (Japanese) in JSP.

3. Using JSTL tags.

The following errors occurred when executing the JSP: 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., " at weblogic.servlet.jsp.Jsp2Java.outputs( at weblogic.utils.compiler.CodeGenerator.generate( at weblogic.servlet.jsp.JspStub.compilePage( at weblogic.servlet.jsp.JspStub.prepareServlet( at weblogic.servlet.jsp.JspStub.prepareServlet( at weblogic.servlet.internal.ServletStubImpl.getServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.ServletStubImpl.invokeServlet( at weblogic.servlet.internal.WebAppServletContext$ at at weblogic.servlet.internal.WebAppServletContext.invokeServlet( at weblogic.servlet.internal.ServletRequestImpl.execute( at weblogic.kernel.ExecuteThread.execute( at

Research revealed that the encoding for makeXMLStream was incorrect. Changing the encoding to UTF-8 resolved the problem.


WebLogic Server 7.0 Service Pack 2 Solutions

The following sections describe problems that were resolved for the release of WebLogic Server 7.0 Service Pack 2.

Administration Console

Change Request Number



Making changes to an EJB descriptor value via the Deployment Descriptor Editor provoked a

This problem has been resolved.


The Administration Console Deployment Descriptor Editor now replaces "&" with "&amp;" when writing to memory/disk, because "&" is a special character which must be escaped as "&amp;" in xml files or deployment can fail.


When you upgrade a domain created under version 6.x of WebLogic Server, the user "system" now explicitly grants access to the Administration Console.


Translated online help was not visible; now it is visible.


Web applications that are targeted to the source server now show up as targeted to the cloned server.


Machine deletion no longer fails when one or more servers are configured on it.


There are no longer empty monitoring pages for EJBs with the Netscape 4.7 browser.


In WebLogic, the Console threw an NPE when JDBC driver was not in $CLASSPATH. This problem has been fixed in this release.


Changing a user password and then clicking Continue no longer throws a NullPointerException.


Users can now reboot a server when a Realm Adapter ATN provider is added to a 7.x security realm.


Users can now target a multipool to a cluster in the Console.


Clicking on Server --> Services --> Bridge --> Monitor all Messaging Bridge Runtimes no longer causes a 404 error.


There is now a Console configuration option to for specifying that the log be timestamped in Greenwich Mean Time (GMT).


Attempting to edit the EJB Deployment descriptors of Pipeline EJB shipped with the sample WebLogic Portal Server no longer fails with MBean exceptions, such as


"Security" -> "Users" -> "Unlock Users" is no longer garbled in a Japanese environment.


EJB methods can now define policies correctly via the Console.


The console now uses the global Admin/Operator/Monitor/Deployer roles.


Editing EJB deployment descriptors no longer provokes a NullPointerException.


Browser warning pages no longer display in the Administration Console when a browser is not supported.


An Administration Server no longer throws an OutOfMemory exception when the Administration Console is set to monitor thread pools.


Change Request Number



Two different .war files within an .ear file each instantiated their own instance of a singleton, resulting in incorrect results when the application was run.

This problem has been fixed.


Loading classes via the context class loader at deployment time no longer fails and causes ClassNotFound exceptions.


Multiple entries were being added to the ClassFinder. As a result, ClassLoader.getResources returned an Enumeration with duplicate entries.

The problem has been fixed.


A client class can now successfully create an InitialContext when the java command line specifies weblogic.jar using the -Xbootclasspath argument.


Change Request Number



Under WebLogic Server 6.1, running on any platform, when the Cluster Address was specified as a list of comma separated IP addresses, for example:

IPaddress1, IPaddress2


IPaddress1:7011, IPaddress2:7011

and error message was issued when the Managed Servers in the cluster started up:

<main> <system> <> <000101> <Cannot resolve ClusterAddress: IPaddress1:7011, IPaddress2:7011

The cluster started correctly. The comma delimited could not be resolved.

A code change was implemented to support ClusterAddress in format of a list of comma separated IP addresses, when the domain is set to Development mode. This format is not supported for projection mode operation. EJB handles may not be managed properly, resulting in problems with failover when this format is used.

In Production mode, the cluster address must be specified as a DNS name that maps to the Managed Servers in the cluster.


Timing issues related to creation of the cluster-wide JNDI tree and deployment of MDBs resulted in a NameNotFoundException. during startup. The ejbCreate method of the MDB called a service on an EJB that was pinned to a single node in the cluster. For reasons related to application requirements, this node is started first. When a secondary node started, and the MDBs deployed with an initial-beans-in-pool setting greater than 0 the beans threw the NameNotFoundException. This occurred because the home interface for the pinned EJB had not been bound to the JNDI tree yet. When the MDBs were deployed with an initial pool setting of 0 the node started correctly and the beans work properly when the first message is queued because JNDI has had a chance to catch up.

This problem was solved by implementing a MemberWarmupTimeoutSeconds attribute in ClusterMBean. The default value is 0 which means no cluster warmup. By default, the cluster startup sequence remains unchanged. If a value > 0 is set, cluster member's wait for that period of time to synchronize with other members during startup. All MDBs are deployed after the warmup time.


A six node cluster hosting a Web application ran for seven hours, then hung repeatedly. The configuration was: F5/Big IP Load Balancer directing requests to cluster of three servers running WebLogic Server 6.1 SP2, IIS and ISAPI plug-in, in turn proxying to a cluster of six WebLogic Server 6.1 SP2 servers. Host machines were Solaris 8 dual CPU servers running JDK 1.3.1.

The plug-in directed requests to a server instance other than primary or secondary, and WebLogic Server looked up and made calls on remote ROIDImpl.

The problem was solved by a fix that fabricates a local stub for ROIDLookup and Replication Manager RMI objects, thus avoiding JNDI lookups for the stub. In addition, calls to ROIDLookup now use the replication threads to ensure execution even when the default execute threads are unavailable, avoiding a possible hang.


A Web application was deployed on a cluster. HttpClusterServlet did not fail-over during the graceful shutdown of a Managed Server under WebLogic Server6.1 Sp2. The Web application was undeployed and could not find a match for the context when request was received during the shutdown sequence. Instead of transparent failover, a page not found error was displayed in the browser. This problem did not occur in the case of a a server crash, only during a graceful shutdown.

This problem was fixed by implementing a check for server state, and logic to return a SERVICE_UNAVAILABLE (503) when context is null, allowing plug-ins to fail-over instead of returning 404 (NOT FOUND) to the client.


On an NT multi-homed system, an Administration Server in Managed Server discovery mode did not restart if the URL host was the same as the host name, and the host name resolved to multiple IP addresses. When the host name resolved to multiple addresses, the Administration Server cannot reliably determine which Managed Servers it was managing, prior to failure, hence restart of the Administration Server did not complete.

A check was added to to determine, when user specifies a dotted IP address for the Administration Server when starting a Managed Server, if the address is multihomed - in which case this message is displayed: 'The admin server url "http://qa700:9001"; cannot be used with managed-server-discovery-mode because the hostname resolves to multiple ip addresses. Please turn off discovery mode or set just one ip address for this host.'


Fixed a problem in which shutting down an Administration Server, with a timeout option, resulted in this error message: Expected RemoteException, RuntimeException, or Error but received: 'class weblogic.rjvm.PeerGoneException.'

Error has been corrected. Now, when shutting down with a timeout option, the following message is output: The shutdown sequence has been initiated.


The debug flag for clusters could not be turned off, resulting in large log files. The problem occurred because, in, the flag controlling whether or not debug messages are logged was set to true, and could not be changed.

The problem was solved by providing the ability to configure the flag using a tag in config.xml:

<ServerDebug DebugCluster="true" Name="myserver"/>


Null Pointer Exception at ReplicaAwareRemoteRef.getCurrentReplica resulted in termination of shutdown process before the shutdown was complete.

This error was corrected.


Change Request Number



Deploying a RAR without a weblogic-ra.xml descriptor file no longer provokes a NullPointerException.


Fixed a problem in which the JCA Connection Factory would try to obtain a new connection instead of using the available connections.


During shutdown of WebLogic Server, Messaging Bridge Adapter undeployment no longer throws a NullPointerException.


WebLogic Server no longer persists deprecated default weblogic-ra.xml elements.

Core Server

Change Request Number



Emergency messages are no longer issued during a deliberate server shutdown.


The alt-dd deployment descriptor element is now handled correctly for EJBs and Web applications.


Socket reads are no longer blocked, causing a server to hang with JDK version 1.3.1.


weblogic.admin no longer succeeds at HTTP tunneling when tunneling is disabled in the Server Mbean.


You can now re-boot with the last known good COMMO configuration, by booting the server with the -Dweblogic.safeCommoBoot=true flag.


A server launched from a non-default directory can now see its applications.


Using MAX_BACKOFF_BETWEEN_FAILURES on weblogic.t3.srvr.ListenThread, users can now configure the time period in which the server listen thread will send a "Failed to listen on port" message if it is still trying to accept a socket connection. Please refer to the weblogic.t3.srvr.ListenThread javadoc getMaxBackoffBetweenFailures() and setMaxBackoffBetweenFailures() for more information.


When the AppletArchiver utility is used to generate a client jar file and the applet in question uses the javax.swing.JApplet class in its code, an error is no longer thrown.


InvalidClientIDException and NameAlreadyBound exceptions no longer occur when creating Durable subscribers to JMS servers in a clustered environment.


Various multiplexor (muxer) problems were resolved.


The getState and getStateVal properties in the ServerLifeCycleRuntimeBean now behave similarly.


JavaSocketMuxer no longer creates a new thread every time WebLogic Server registers a socket on client.


Shutting down wlidomain via WebLogic Server console no longer causes a java.lang.ThreadDeath.


In earlier versions/service packs,(6.1SP3) some debug messages from ChangeAwareClassLoader were inappropriately written to the stdout. This bug has been fixed in this release.


The performance of WebLogic Server 6.1SP3 is somewhat affected during continuous requests from Microsoft WAS Tool. Performance is improved with fix for JSPs and servlets that use a multibyte charset as content-type in the response.


The "root" identity no longer retains control of .wlnotdelete after server startup.


Invoking weblogic.Server.stop() from NT Service to shut down a WebLogic Server instance no longer throws a NullPointerException.


The synchronized code in the RJVM no longer restricts EJB failover during machine disconnection.


On HPUX, SAP JCO no longer causes Java Virtual Machine (JVM) crashes.


WebLogic Server 6.1SP3 has a performance regression in ListenThread as it consumes more CPU time when compared with WebLogic Server 7.0 SP2. The server throttling was causing performance degradation by caching information about the active sockets.

This problem has been fixed.

CR086425, CR84172

Large Message Transmission Units (MTUs) no longer cause performance degradation.

CR086552 is no longer thrown (in WebLogic Server 7.0SP1) during Java serialization.


In an application with a web tier and an EJB tier, the web tier communicating with the EJB tier no longer hangs and throws exception similar to the one shown below when the EJB tier closes the ConnectionManager.

<Sep 24, 2002 8:43:58 AM PDT> <Info> <RJVM> <Failure in heartbeat trigger for RJVM: '7831636024374910916S:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@3bedf2 - id: '7831636024374910916S:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' connect time: 'Tue Sep 24 06:15:16 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream( at ...


A connection from a Managed Server to an Administration Server no longer terminates prematurely before shutdown of Managed Server is complete. An exception similar to the following used to be thrown in 7.0SP01.

<Oct 1, 2002 3:22:42 PM PDT> <Warning> <rmi> <080006> <Failed to associate the transaction context with the response while marshalling an exception: java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@7d37fa - id: '2847122412264039151S:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver' connect time: 'Tue Oct 01 15:18:40 PDT 2002'' has already been shut down java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@7d37fa - id: '2847122412264039151S:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver' connect time: 'Tue Oct 01 15:18:40 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream( at


An IIOP performance regression was resolved.


Build dates are now embedded in multiplexor (muxer) libraries.


Setting ulimit -n to unlimited no longer causes server crashes on AIX.


Accessing a simple stateless session bean in a cluster no longer provokes IllegalArgumentException: port out of range.


Deployment of EJBs with a custom CallRouter no longer fails with an IllegalArgumentException.


The PosixMuxer no longer throws Interrupted System Call exceptions.


Manually doing a lookup and then persisting and caching the handle did not work when the methods were conversational. This is fixed with changes to serialization and deserialization of EJBHandle object.


Change Request Number



When installing an application through the console or dropping an application in the applications directory in development mode, the components now deploy in the order defined in applications.xml.


Hot-deploying or manually deploying a Web application intermittently no longer results in a NoSuchObjectException: Bean is already undeployed exception.

CR080537, CR084907

Fixed a problem in which a startup class marked to be deployed before applications—because the LoadBeforeAppDeployments was set to True—nonetheless were loaded after applications were deployed, on server startup.


weblogic.refresh now works for files whose names are specified using wildcard characters.


A SaxParseException on the DTD now has a severity of Warn, rather than Info.


There is no longer a cross-platform path incompatibility in weblogic.deploy. weblogic.deploy now successfully updates the webapp (.war file) from a Windows 2000 machine to a cluster running on Solaris.


When web.xml and weblogic.xml are out of sync with respect to the resource-ref and resource-description elements, the error message now names the ResourceReference in question, rather than giving generic information.


Applications are now deployed once at startup, instead of twice.


An application targeted to a Managed Server now correctly deploys even if the Managed Server is not running.


MBeanHome.getAllMBeans() no longer throws a java.lang.IllegalArgumentException when a custom MBean is defined.


Applications targeted to Managed Server(s), are now correctly reported as deployed even after an Administration Server shutdown and restart from the Administration Console.


This problem has been resolved:

A Web application targeted to a Virtual Host while the Virtual host is targeted to a Managed Server.

Changes are made to the JSP in the Web application.

An undeploy followed by a redeploy fails, in that changes made in the Web application cannot subsequently be seen in the browser when a new request is made.


Change Request Number



Fixed a small performance regression introduced in 7.0 with Stateful Session Beans, with tx-attributes of Required and NotSupported.


Spaces are no longer required around an equals sign (`=') in an EJB QL query.


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



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


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


WebLogic Server EJB now supports finder methods on a byte-cmp field.


Automatic primary key generation is now supported for java.lang.Long.


Error reporting is now improved for hot-deployed EJBs.


A subquery without a WHERE clause no longer generates incorrect SQL.


ejbc now performs deployment correctly when another .xml file is included in weblogic-ejb-jar.xml.


An is-modified-method-name tag in weblogic-ejb-jar.xml no longer results in an java.lang.NoSuchMethodException, when updating an EJB 1.1 bean to EJB 2.0.


EJBCacheRuntime statistics no longer report negative numbers for values.


If an in-memory replication license is not detected, the EJB container now handles the situation gracefully, rather than throwing an error.


The dispatchPolicy option is now a public option for both ejbc and rmic.


Repeated attempts to deploy and undeploy a bean no longer cause the server to run out of memory.


When home-is-clusterable was set to False the server no longer attempts to send announcements to the rest of the nodes in a cluster.


There is now a bean-level option to set the dispatchPolicy in the weblogic-ejb-jar.xml file.


Source files in the ejbc output directory are no longer unintentionally deleted when running ejbc.


In 6.1 SP3 a problem caused the EJB Handle Size to increase dramatically. The problem has been resolved


Third-party jars are now loaded properly in situations in which the JMS Provider is not WebLogic-specific.


Per-bean pessimistic concurrency is now supported with Microsoft SQLServer. Pessimistic locking can be done with the use of use-select-for-update tag in the DD. This doesn't work with MSSQL Server. The equivalent SQL for it would be of the form:


Adds support to generate 'WITH(UPDLOCK)' in all SELECT queries if database-type tag in DD is SQL Server.


In earlier versions making TX_SUPPORTS for 'create()' and 'remove()' methods breaks the basic functionality of locking and unlocking stateful session beans. This problem is resolved by restricting 'create()' and 'remove()' to be run in Unspecified tx context.


In WebLogic Server 6.1SP#, When calling context.getCallerPrincipal() from ejbRemove(), an exception similar to the following exception is thrown:

<Jul 31, 2002 4:52:17 PM EDT> <Error> <HTTP> <[WebAppServletContext(4292442,test,/test)] Servlet failed with Exception weblogic.ejb20.interfaces.PrincipalNotFoundException: Error. Method SecurityHelper.getCallerPrincipal returned a NULL Principal. The CallerPrincipal Stack has been corrupted. One cause of corruption might be: A Bean has Created its own Threads. Note that this would be in violation of EJB2.0 Final Spec Chapter: Runtime Management 24.1.2 at weblogic.ejb20.internal.EJBRuntimeUtils.getCallerPrincipal( at ...

This is fixed in this release.


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


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


Container-managed persistence automatic key generation now works with SQLServer.


In some earlier versions, ExclusiveEntityManager is not returning beans to pool correctly. When beans exited the cache, they were not returned to the free pool as they should be from the ExclusiveEntityManager. This is fixed in this release.


Users can now configure the read-timeout-seconds for a read-only bean using an application-scoped cache.


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


The "Idle Beans Count" value in the Administration Console is no longer constantly increasing.


ejbRemove() is now called correctly during undeployment of a message-driven bean.


A problem with the serialization of bean-managed-persistence stateful session beans during passivation has been resolved.


In WebLogic Server 6.1 SP3, the EJB container breaks EJB2.0 contract: "Tx not set to rollback when using BMT and exception is thrown". In this release, The container logs the exception (works fine earlier) delete the bean instance (works fine earlier), and mark the transaction for rollback (doesn't work earlier). Also the transaction is disassociated with the thread.


Fixed a problem in which the EJB container was parsing security role information incorrectly.


ejbc no longer generates syntactically incorrect code when a column is defined as LongString in weblogic-cmp-rdbms-jar.xml.


Change Request Number



The login.jsp file for the webapp security sample now allows for URL encoding when a user logs in.


Fixed a problem in JdbcTable.jsp example. It no longer sets the database connection properties for username and password to the literals of the variable names; it now correctly uses the variables content.


Fixed a problem in which the package-summary.html file of the r3client Web services example was incomplete. The file now contains all of the necessary information.


Change Request Number



The Configuration Wizard no longer creates a misconfigured JMSJDBCStore in the PetStore domain.


The Configuration Wizard no longer generates an incorrect SSL port when creating Managed Servers in console mode.


Change Request Number



Administration Console help no longer displays 404s or displays in English instead of displaying Japanese translation.


Change Request Number



A com2java.exe problem in which generated classes would not compile without manual intervention has been resolved.


Change Request Number



Prepared statement code no longer provokes a null pointer exception. The problem was that the prepared statement object was being set to null.


Prepared statement caching is now off by default, that is, the default statement cache size is now 0.


Creating connection pools with the weblogic.admin command-line interface no longer results in this authentication error:



WebLogic Server JDBC now supports the NLS_LANG parameter WE8MSWIN1252.


When a user transaction failed to roll back due to the Oracle being down, the JDBC connections used in the transaction were released. As a result, no connections were available in the pool. This problem has been resolved.


WebLogic Server can now create a JDBC store configured for a JMSServer using Oracle 9.0.1 version.


Previously, prepared statement cache functionality did not include support for calling setInt() for statement columns that were first used with setLong(), setFloat(), or setDouble(). In addition, calling setInt() on a column that had originally been bound with setNull(i, BIGINT) caused a "Re-Parse Cursor" SQLException.

The missing functionality was supplied by the exposure of a new XA Prepared Statement Cache in the JDBC Connection Pool MBean, which is turned on by default with a default value of 5, and by other code changes.

The default value for Prepared Statement Cache Size was also increased from 0 to 5, which enables the feature by default. See "Increasing Performance with the Prepared Statement Cache" for more details, including usage restrictions.


Transaction isolation can now be set when using jDriver/Oracle XA and Oracle Thin XA. Previously, attempting to set it resulted in this error:

get exception: java.sql.SQLException: Due to vendor limitations, setting transaction isolation for "Weblogic OCI XA" JDBC XA driver is not supported


Running continuous Selects through a JDBC connection pool no longer provokes OutOfMemory errors.

In previous releases of WebLogic Server, if application code created JDBC objects that were abandoned without being closed, the objects would be lost but would still hold memory or open cursors, even after being garbage collected. If too many such objects were created, the server would eventually run out of memory and the database may run out of cursors.

In WebLogic Server 7.0SP2, the code was changed so that abandoned JDBC objects are closed before being garbage collected.

Note: If you immediately create a JDBC object that is identical to an abandoned object, WebLogic Server creates a clone of the original JDBC object. However, when the original leaked object is closed, the clone will also be affected.

You can avoid abandoning JDBC objects by following the best practices described in "Closing JDBC Objects" in Programming WebLogic JDBC.


Change Request Number



The statement.cancel method is now working with WebLogic jDriver for Oracle.


ResultSet.getCharacterStream() now works for Oracle LONG type.


When using a PreparedStatement via weblogic.jdbc.pool.Driver with the Oracle jDriver, its parameters were not cleared properly and jDriver inserted conjunct data (new data of parameter and previous data of parameter) into the database.


On the HP platform, attempts to connect to connect an Oracle database using weblogic.jdbc.connectionPool.oraclePool no longer result in a SIGSEGV 11 HP error.


The JDriver for Oracle no longer raises an ArrayIndexOutOfBoundsException if there are more than 511 parameters in a prepared statement. Limit is now 1024 instead of 512.


Change Request Number



Message-driven beans were not acknowledging object messages; messages are now queueing correctly to the message list.


For the null string user property— setStringProperty(propertyName, null)—the property name is now reflected in Message.propertyExists().


Using a serverSession pool no longer causes Message.getJMSDestination() to return null.


In earlier versions the JMSSession.commit method threw exceptions similar to the following stack trace, when both client and server were colocated (server-side tests) in the cluster environment. (HP AS and Sol MS)

EXCEPTION: java.lang.Error: transaction suspended twice Start server side stack trace: java.lang.Error: transaction suspended twice at weblogic.jms.dispatcher.Request.forceSuspendTransaction( at weblogic.jms.dispatcher.Request.sleepTillNotified( at ...

The problem is fixed in this release.


The JMSDispatcher thread no longer has a problem with the security context when dispatching messages to a remote server.


The handling of JMS Queue browsers has been modified so that associated memory is cleaned up when the browser is closed, even if the entire enumeration of messages has not been traversed.


In WebLogic Server 6.1SP2, MessageListener is not receiving messages after TransactedSession Roll back. The message listener appears to stall after processing a certain block of messages and performing a certain amount of rollback() calls.

This stalling appears to occur on the second batch fetch from the JMS Queue. In other words, if the Messages Maximum parameter equals 10, the first 10 messages will be processed correctly, however the message listener will stall on the 11th or 12th message. If Message Maximum equals 1, the stall is on the second message and sometimes 3rd message. This is fixed in the current release by properly maintaining the internal data structures with Queue commits.


Redelivery of JMS messages for a durable topic subscriber is no longer restricted to batches of 10 and is now configurable.


Creating a connection pool using jDriver with Oracle 8.1.7., then configuring a JDBCStore for JMS using this pool, and enabling JDBC no longer throws a "java.sql.SQLException: Connection has already been closed" error.


Durable subscriptions are no longer erroneously unsubscribed when a JMS Messaging Bridge is stopped, undeployed or shut down.

CR083196, CR088255

A JMS Messaging Bridge no longer drops messages if the destination server hosting the messaging queue is shut down.


Recovery of a server in a cluster has been improved to handle cross-server notifications appropriately. Changes were made at the networking level, at the RMI level, and in JMS.


Sending messages to a Topic whose ServerAffinity property is set to False no longer causes a NullPointerException.


For a certain class of applications, WebLogic JMS can now significantly optimize topic subscriber selectors by indexing them. These applications have messages that contain one or more unique identifiers and thousands of subscribers that filter based on these identifiers.

A typical example is an instant messaging application where each subscriber corresponds to a different user, and each message contains a list of one or more target users.


Messages are no longer lost if the WebLogic Server instance is killed and restarted while the MessagingBridge is processing the messages.


Setting a MessageListener or an ExceptionListener to Null no longer throws a NullPointerException.


The error message that displays when a Messaging Bridge fails to establish an initial context with a server no longer includes the Bridge's password as part of the message.


Closing a JDBC store no longer causes outstanding JMS I/O requests to be dropped.


Calling recover followed by ClearProperties no longer causes message properties to be dropped.


JMS security policies are now checked for message queue browsing; anonymous users can no longer browse a message queue.


The selectors code has been optimized, resulting in up to a 30 percent performance improvement when there are high number of subscribers, each with a unique simple selector.


Distributed destination messages no longer contain incorrect birth or expire times.


JMSServer undeployment ("remove deployment") no longer throws an InstanceNotFound exception.


JDBC store creation now succeeds on an AS400 configuration running DB2.


Redelivered flag is no longer set to True when it should be set to False.


Pending counts for JMS DurableSubscriber are no longer set to negative values.


When a JMS client program is disconnected abnormally, associated resources are now completely cleaned up on the server side.


createTopic("BackendName/TopicName") is now working correctly.


Messages no longer erroneously stay on the queue when a message has its replyTo set to a distributed destination.


Change Request Number



WebLogic Server 7.0 has a slight performance regression with JNDI lookups and use of EJBs. This has been fixed by allowing pre-generated JNDI-related stubs. ejbc has a new flag— disableHotCodeGen— which generates stubs and skeletons during compilation time.


In WebLogic Server 6.1 SP3 JNDI lookup failover is taking a long time when the network plug is pulled. This has been fixed in this release.


Change Request Number



Fixed a problem in which after a transaction timeout using XA driver + SSB, the XAConnection became unusable until a server restart.


Setting the JTA transaction timeout value to 20,000,000 or larger no longer provokes an exception (javax.transaction.SystemException: start() failed).


Calling a connection from the XA connection pool after the transaction has timed out no longer throws an XA-PROTO error.


Fixed a deadlock issue with Oracle XA thin driver.


The "direct-write" file I/O option for JTA and JMS is now available on HP.


Change Request Number



DBAs no longer have to resolve distributed in-doubt transactions manually; WebLogic Server now resolves them automatically.


Change Request Number



When using access.log in Extended Log File Format all times are now specified in GMT instead of in local time.


Network connections for performing server life cycle operations between an Administration Server and a node manager are now closed after task completion.


The node manager no longer throws an OutputHandler error when trying to start a remote server.


MBeans are no longer accessible with HTTP despite HttpdEnabled being set to false and TunnelingEnabled being set to false.


A server no longer fails to launch from a non-default directory

CR079110, CR083257

When a WTCServer run-time MBean was deleted using the weblogic.Admin DELETE command, the command was not UNDEPLOYING the WTC before deleting it. This problem has been resolved.


A deployment failure caused a ConfigurationError resulting in the server process dying. This problem has been resolved.


Fixed a problem in which starting in an Administration Server provoked a java.lang.reflect.UndeclaredThrowableException if the application targeted a virtual host to the Managed Server but not the Administration Server.


WebLogicMBean.setParent() is now exposed as a public method in Javadoc.


A graceful shutdown feature is added for NT Services. There is now a -stopclass option for beasvc. When this option is set, the stop() method on this class is invoked to perform the shutdown.


The SERVERLOG command line utility no longer fails when the secure T3 protocol is in use.

Previously, this command:\server\lib\cacerts weblogic.Admin -url t3s://localhost:7502 -username system -password password SERVERLOG "2002/07/17 13.00" "2002/07/17 14.00"

Resulted in this message: Unable to get log file:unknown protocol: https


When registering custom MBeans are registered within an EAR, an attempt to use JMX/MBeans to remove a JDBC connection pool no longer fails with java.lang.ClassNotFoundException.


Attempts to instantiate a new COMMO MBean no longer throw a on the client side.


Managed Server startup no longer fails with a stack overflow exception when the secureT3 protocol is in use.


JMS topics and queues are now being created properly at runtime, in a cluster. Previously, it appeared that the topic had been created, but clicking on the Destination Link under JMS Server resulted in these exceptions:



On AIX 4.3, booting a Managed Server, with the Administration Server running, no longer causes the WebLogic Server process to exit with a NullPointerException.


SNMP requests no longer time out after a Managed Server is dropped.


In a Web Logic Platform domain, WebLogic Server no longer fails to recognize the following three properties during startup:





WebLogic Server no longer fails to recognize the following properties during startup:





The file descriptor count for the WebLogic java process no longer grows out of control to the point where the server process dies.


Domain log rotation by time no longer fails when the server is rebooted.

Node Manager

Change Request Number



The Node Manager no longer tries to detect Managed Server failures by trying to initiate an HTTP connection. If Node Manager receives a connection failure, the connection exception can now be observed in the Node Manager output.


After completing the task, an Administration Server now correctly closes the connection it established with the Node Manager. Previously, it failed to, resulting in the server running out of file descriptors.


The NodeManager now parses weblogic.policy correctly; it no longer adds an equals sign when copying the property to the command line of the child process.


A race condition no longer occurs when the Node Manager kills a cluster. This problem had been resulting in Connection refused: connect errors.


Change Request Number



All plug-ins now parse folded headers properly as per the HTTP 1.1 specification. Previously, folded headers provoked "malformed header" error messages.


The Apache plug-in is now correctly parsing the primary jvmid from the session cookie.

CR089033, CR088914


Fixed plug-in vulnerability to cert chain attacks, a security risk.


Failover is now correctly prevented when Idempotent is set to Off, for NSAPI.

Core dumps no longer occur as a result of setting ConnectTimeoutSecs to 0.


IPlanet no longer core dumps when all WebLogic Server instances are shut down.


"error page is unavailable" messages no longer appear when page is actually available.


The proxy plug-in made spurious extra calls to the application server under heavy load. Now, if a call comes into iPlanet, only one call goes to the application server.



Failover is now correctly prevented when Idempotent is set to Off, for ISAPI.


Previously, when the ISAPI plug-in received an error while reading data from the client, it tried to send the incomplete data (request) to the backend WebLogic Server. This situation occurred if, for example, the end user pressed the browser stop button while the plug-in was reading the HTTP POST request

Because the data being sent did not meet the expected number of bytes, the plug-in received an error in the sendRequest phase.

This no longer occurs.


IPlanet now has the WLExcludePathOrMimeType flag, allowing proxying by path but excluding certain images from that proxy.


If the URLRewriting property is used for session tracking instead of cookies, stickiness is now maintained. Previously, session would not be tracked properly even when URLRewriting was set.


There is no longer a performance problem in NSAPI in which netbuf_getc() was very slow and was not able to distinguish between '\0' and 0 in the postdata.


The KeepAlive feature is now enabled by default for ISAPI and NSAPI plug-ins.


In NSAPI netbuf_getbytes() no longer fails with a Java client with iWS4.x.


Fixed a problem in IPlanet in which, if performing a redirect using a URL that contained both a query string and an anchor, the anchor was incorrectly considered part of the value portion of the last query string member.


Session caching and KeepAlive functionality are now enabled for secure sessions.


Change Request Number



Attempts to store RMI objects in a database no longer fail due to a problem with serializing dynamic proxy objects.


Fixed a problem with replica lists that occurred when calling into a cluster and was manifesting as an AssertionError.


The runtime descriptor for CSIv2 support in the IOR for an RMI object now defaults to Supported. Previously, it defaulted to None.


Fixed an IIOP initialization deadlock that was causing servers to hang on restart under heavy load conditions.


Fixed a memory leak in stub generation that was resulting in IncompatibleClassChange errors.


Fixed a problem in which WebLogic Server could not unmarshal Any's using indirect typecodes. This was resulting in interoperability problems with IBM.


Fixed a series of problems that were preventing using WebLogic Server to coordinate a transaction with Orbix 2000 2.0.


Requests no longer close prematurely when an Exception response occurs.


The domain name field—in which WebLogic Server places the server name—is now set correctly in the replica list in a service context.


Fixed a problem in which generated IDL was corrupt when the exception class name terminated in a capital I (`I').


Circular references are now handled correctly in IDL generation. Previously, if classes contained circular references, attempts to compile them with the -iiop -idl options failed.


Using indirection within TopLink no longer throws Assertion failures.


Fixed a problem in which weblogic.ejbc was generating an incorrect IDL module declaration for multi-dimensional arrays.


Change Request Number



Please review the security advisory information at


Problems corrected in sslclient example:

  • Package-Summary.html no longer contains blank classes.

  • WebLogic Server_home replaced with Samples_home.

  • MyListener class is now in the kit.


Fixed a problem in which certificate data was not appearing in the Administration Console.


SSL is now working properly in applets.


The TLS_RSA_WITH_DES_CBC_SHA cipher suite is now exportable.


The location of the log files for the WebLogic Auditing provider has changed. Auditing is configured for the security realm, but each server instance writes to its own log file located in the server directory. The new location is WL_HOME\mydomain\myserver\


In previous releases, WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority. This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA, thus ensuring all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected.

For more information, see SSL Certificate Validation.


Defining security policies in the weblogic.xml or weblogic-ejb-jar.xml files required creating a \lib directory in the domain and then granting permissions to the \lib directory in the weblogic.policy file.

This known problem is fixed in this release.

For information about defining security policies, see Securing WebLogic Resources.


WebLogic Integration no longer experiences problems resuming the SSL session when interacting with WebLogic Server.


The code example for the custom Authorization provider did not work because the web.xml file in the code example was incorrect. The file used a url-pattern of * to protect its pages when it should have used */.

Updated code examples are available from the following URL:


The method did not delete the principal and credential information from the subject of a LoginContext. Therefore, the user was not logged out.

This known problem is fixed in this release.


Protected JNDI resources can no longer be accessed by unauthorized users.


WebLogic resources with hierarchies (for example, JMS, JDBC, Server) now handle actions correctly from the getParentResource() method.


Calling a stateful session bean from a JSP caused the following security violation:

java.rmi.AccessException:Security Violation: user username has insufficient permission to access EJB

This error occurred because an established security context was not closed properly. Use ServletAuthentication.runAs(Subject subject, HTTPServletRequest request) at the end of the JSP so that the user will be added to the HTTPServletRequest if the initial security context is not closed.


WebLogic Server rejects digital certificates that have the KeyUsage constraint set as a critical, but do not have the KeyEncipherment constraint set.

Older versions of WebLogic Server which use SSL V3.0 did not reject certificates under this circumstance. However, this release of WebLogic Server which uses TLS V1.0 will reject certificates under this circumstance.

Workaround: Apply patch CR089059_70sp1.jar.


The ServerIron monitoring product sends a request to the SSL port during a server health check. During this health check, the SSLIOConect and related SSL objects were not released, causing an out-of-memory error.

This known problem is fixed in this release.


The users group no longer includes unauthenticated users.

This known problem is fixed in this release.


Dynamic groups now works properly with the IPlanet Authentication provider.


The servlet container in WebLogic Server did not pass login exceptions to the error page as specified by the J2EE specification.

This known problem is fixed in this release.

CR092167, CR085441

Please review the security advisory information at


Fixed a problem in which, when adding users to replicated LDAP databases in cluster, it took an unacceptably long time for users to be replicated on Managed Servers.

Servlets and JSPs

Change Request Number



Fixed a problem in which tag libraries failed when the type option was specified and the type was an array; the type was erroneously treated as a string.


Fixed a problem in which method_releaseTags() was not called as part of jsp:forward, in generated code. Tags are now released when a forward occurs within the body of a JSP.


Fixed a problem in which, when a servlet sent messages to an applet in HTTP/1.1, the applet would hang until all the messages were sent. That is, the applet did not receive the messages in parallel as the servlet sent them.


URLs containing a "%" now load correctly.

CR044926, CR075799

Java code can now be generated from JSP files that include a '}', on 2Byte platforms.


When using jsp:usebean, jspc no longer generates class files with a deprecated method.


jspc now works correctly when JSPs are located in directories other than the root directory and expressed in relative pathnames.


When jsp:include refers to a non-existent JSP, a FileNotFoundException is now thrown.


javax.servlet.jsp.PageContext.out attribute now cleaned up correctly for body content tags; output is now sent correctly to the browser.


JSPs with a page contentType directive can now be deleted and overwritten in an exploded web archive (WAR).


If a JSP file contains a jsp:setProperty, and the bean this tag refers to contains a multidimensional array as attribute String [][], jspc now generates compilable code.


Content type is now set correctly when the page contentType directive is used.


WebLogic Server now allows the user to reset the buffer size as long as the response is not committed to the client. In 7.0 and 7.0 SP1, the server would throw an illegalStateException setBufferSize was called after some ServletOutputStream.write()'s, even if the buffer had not been committed. This caused problems with Servlets/Filters which that depended on calling setBufferSize before flushing the buffers.


Japanese characters in a JSP are no longer corrupted when including content from another JSP.


A JSP now correctly detects that contentType is set to an illegal character set.


Line numbers for JSP compile errors now correctly match up to the error message.


jspc parsing error messages made more specific to help users quickly locate malformed descriptors.


jspc execution time is now more efficient, due to how jspc calls multiple JSPs that use identical tag libraries.


Fixed a problem in which deployed resources of multiple virtual hosts conflicted due to sharing a common temporary directory. This was resolved by including the server name in the temporary directory path.

A side-effect is that compile-on-startup JSP classes are not deployed to Managed Servers from an Administration Server. However, this was never intentionally supported, and the correct procedure is to precompile these classes before server startup using weblogic.jspc and deploying to the WEB-INF/classes directory.


Fixed a problem in which an included resource ("Resource A") was not sent to the servlet output stream when dispatched from another resource ("Resource B") that had been forward dispatched inside a JSP BodyTag.


jsp:include now carries jsp:param properly if the value is "/////"


Fixed a problem in which, when a Web application had a JSP file with a multibyte name, WebLogic Server did not compile it and returned the directory contents.


Fixed a classpath problem such that .jar files are found successfully when compiling JSPs.


When an URL is specified as a JSP name/value parameter to an included JSP, the URL is no longer truncated when a different encoding scheme is specified.


WebLogic Server now specifies the cache-control appropriately to prevent caching proxies from caching a cookie.


Fixed a problem in which, when a proxy with ppath and pathtrim was used between a client and WebLogic Server and form based-authentication was used, the client would not get redirected to the proceed resource.


WebLogic Server is now cleaning up and requeuing properly after dispatching a servlet request, thereby preventing memory leaks.


The access.log file now correctly rotates according to size.


The lifetime of HTTP persistent connections is now configurable on the client side, via the new setTimeout() method, which is demonstrated in this code snippet:

URL u = new URL(url);
HttpURLConnection hu = new HttpURLConnection(u);
BufferedReader in =
new BufferedReader(new InputStreamReader(hu.getInputStream()));


Temporary files stored in the applications/.wlnotdelete file are now deleted when they are no longer needed—when an application is redeployed or removed.


If defined, FrontendHTTPPort, FrontEndHTTPSPort, and FrontEndHost now take precedence over a HOST header when constructing a redirected URL.


Fixed a problem in which HttpClusterServlet stopped forwarding requests to a server if a malformed status line was detected in one request.


Fixed a problem in which commas in a quoted value in a cookie would not parse correctly.


Fixed a problem in which, if an application threw a customized exceptions that extended
ServletException, the wrong message would appear.


An HTTP request containing absolutURI now executes with the correct context path, request URI and request URL.


Fixed a problem in which Web applications were being extracted twice during deployment.


Malformed processes now exit gracefully, rather than throwing a NullPointerException.


The server now correctly parses HTTP requests with TransferEncoding set to Chunked.


The PrintNulls option is no longer missing from weblogic700-web-jar.dtd.


Session attributes are no longer lost when using HttpSessionListener with PersistentStoreType set to replicated.


CGI output now correctly displays when calling a CGI script from a JSP in an .ear or .war file.


isRequestedSessionIdValid() always returned the value, true, which means that the request session ID is valid, even if you changed the session ID in the URL.

Invalid sessions are now correctly detected and reported as invalid.


When accessing a URL, HTTP POST parameters are now correctly preserved when a form-based authentication is invoked and authentication is successful.


Fixed a problem in which the Console displayed invalid values for servlet execution times.


CGIServlet now work when <url-pattern> is an exact match.


HttpClusterServlet now correctly proxies a request to SSL when SecuryProxy is set.


An HTTP 1.0 request now correctly returns an HTTP 1.1 response in the header.


Fixed a problem in which JDBC session persistence was failing when using Oracle Thin Driver


204 HTTP responses no longer include a message body, as mandated by specification.

CR084076, CR086280

Fixed a problem in which while accessing a servlet over a Keepalive connection created a malformed request.


HTTP session tracking is now maintained when PersistentStoreType is set to jdbc.


Delegating a JSP's output to another JSP by including or forwarding no longer provokes an IllegalStateException when using a response wrapper.


WebLogic's CGI server now provides the SERVER_URL, HTTP_COOKIE, and QUERY_STRING environment variables to scripts running within it.


GenericProxyServlet now handles wrapped responses.


The HttpURLConnection handler now implements getErrorStream(), thus making it possible to read custom response from the 'error' page.


Fixed a problem in which JSESSSIONID was encoded in the URL even when URLRewritingEnabled was set to false, resulting in a 404 error.


ejb-local-ref now works for Web applications.


CacheSessionCookie now defaults to true, preventing display problems on the first displaying attempt.


Outbound (from WebLogic Server) HTTPS connections no longer require a trailing slash '/' to work.


A NullPointerException bug resulting from change of behavior of between Java 1.3.1 and Java 1.4.0 has been fixed.


A servlet engine no longer throws a SocketWriteError when trying to load a console page.


A Web application's attempt to upload a file no longer provokes an ArrayIndexOutOfBounds exception; the code has been rewritten to handle buffer overflows and other scenarios in which a buffer is only partially read.

CR086677, CR087573,


Fixed a problem with JDBC persistence in which subsequent requests were allowed before session persistence had completed, resulting in data loss.


HttpURLConnection now times out correctly.


Fixed a problem in which invoking ServletContextListener before HttpSessionListener caused unexpected results during server shutdown.


Server now more robust at detecting missing XML close tags, thereby avoiding exceptions.



The MaxSkips feature has been deprecated in WebLogic Server plug-ins for clustered servers and replaced with MaxSkipTime.

MaxSkipTime sets the amount of time after which the plug-in will retry the server marked as "bad," where "bad" denotes a server that failed previously.


Fixed a problem that was causing 10% performance regression in HttpClusterServlet calls.


Fixed a problem in which jspc was unable to create a file in the current directory.


A servlet filter no longer needs to call flushBuffer() explicitly on the response wrappers after having called chain.doFilter(), in order to send a response to a client.


response.sendRedirect() now correctly redirects to a relative URL instead of an absolute URL.


Undeploying a Web application no longer provokes an IndexOutOfBoundsException.


Fixed a problem in which JISAutoDetect encoding for HttpRequest was provoking exceptions.


Cookie parsing is now fixed in iisproxy: when a client sends multiple cookies the proxy now correctly sticks to the primary server.


Turning on session monitoring no longer results in increased traffic and Administration Server hangs each time a new session is created.


Change Request Number



WebLogic Builder now supports entering a value for both Servlet name and URL pattern in Servlet/Filter Mappings->Filter Mappings->Add.


If a .jar file contains more than one container-managed persistence (CMP) descriptor file, WebLogic Builder now displays all of the descriptor files; previously, Builder displayed only the first one it found.


When WebLogic Builder creates a container-managed persistence entity bean, it now defaults the <trans-attribute> value to Required.


WebLogic Builder now correctly displays enable-call-by-reference default value as True.


WebLogic Builder now provides a feature to export deployment descriptors to a user-specified destination.


Adding a new finder/select works properly now when setting resultTypeMapping in WebLogic Builder.


Fixed a problem in which WebLogic Builder failed to preserve timestamps when originally opening up an archive. In some cases this problem caused the EJB container to erroneously pre-compile all JSPs.


Fixed a problem in WebLogic Builder in which adding a finder with the same method name as that contained in an existing finder updated the tree but not the table.


WebLogic Builder now reloads classes before validating them.


WebLogic Builder now validates classes before deploying them.

CR074634, CR074955, CR074972

Using WebLogic Builder's Relations wizard to edit the relations of a CMP with multiple relations already configured no longer results in an exception.


When you edit a Finder method name using WebLogic Builder's editing panel, the change now correctly propagates to XML. When you edit using the Finder pop-up dialog, the change now correctly propagates to XML and to the editing panel.


WebLogic Builder now saves and properly propagates server connectivity information in the Options dialog.

Previously the values in the Options dialog had no correlation to the value that would appear in the "server connect" dialog. With this fix, that information is now kept in sync with the values entered in the Options screen.


Specifying an invalid drive when opening a component (type bogusDrive in the text box, press enter and select open) in WebLogic Builder no longer causes a NullPointerException.


WebLogic Builder now properly constructs one-to-many relations.


WebLogic Builder now correctly parses and edits the weblogic-cmp-rdbms-jar.xml file.


Fixed a DDInit problem that was resulting in a NullPointerException. Issuing this command:

java weblogic.marathon.ddinit.EJBInit project.jar

where project.jar is a well-formed ejb jar no longer provokes this error:

Exception in thread "main" java.lang.NullPointerException


WebLogic Builder now defaults the concurrency strategy to Read if there is no value set for verify-column, thereby preventing an error.


WebLogic Builder now supports use-select-for-update.


Command-line DDInit now works for EAR files.


DDInit now creates weblogic-application.xml as well as application.xml for EAR files.


EJBGen now has a global-role tag.


If a server dialog is cancelled, WebLogic Builder no longer erroneously displays an error message.


DDInit now correctly determines that two relations that should be equal are in fact equal.


WebLogic Builder now supports LongString and SybaseBinary types for dbms-column-type.

WebLogic Tuxedo Connector

Change Request Number



Fixed a problem in which WTC transactions were rolling back unexpectedly, due to incorrect handling of TPEV_SENDONLY.


The processing of messages by the WTC/tBridge with a connection that pulls messages from Tuxedo /Q no longer stops pulling messages after some time.


A tpcall with the TPNOBLOCK flag set no longer fails.


Fixed a problems that occurred in failover and failback situations when the connection policy was set to ON_DEMAND or ON_STARTUP.


The WebLogic Tuxedo Connector simpappcns example now supports a multi-platform environment.

Web Services

Change Request Number



Non-standard mappings of datatypes are no longer ignored.


WebLogic Web services no longer adds extra non-CDATA characters when generating a SOAP fault.


Users can now specify a portTypeName via a deployment descriptor element.


Fixed a problem with an xml node's parsing of white-space strings.


Fixed incorrect content-type setting that was resulting in NullPointerExceptions when Java clients accessed Web services.


Selecting "Define policies and roles for individual service" in the Administration Console no longer throws a NullPointerException.


Added a Web services example that handles SOAP with attachments without the use of handlers.


Introduced more efficiency into serialization resulting in a performance improvement.


HttpsURLConnection now correctly picks up identities from SSLContext.


Corrected a problem that resulted in JAX-RPC client-stub generation not operating properly.


Custom SoapfaultException is now correctly embedding the detail field.


JavaBean array types are now handled correctly.


XML data binding no longer fails on inherited types with duplicate elements.


WSDL generation now handles recursive types.


A WebLogic dynamic client can now invoke a style style="document" WebService.


Fixed handling of month and day formats in serialization and deserialization.


Fixed a problem in which passing dates as parameters resulted in a java.Lang.IllegalArgumentException.


XSD enumerations are now recognized in WSDL generation.