Skip navigation.

Release Notes

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Resolved Problems for Service Pack 3

Service Packs are cumulative; Service Pack 3 contains all the fixes made in earlier Service Packs released for WebLogic Server 8.1.

The following sections describe problems that were resolved in WebLogic Server 8.1 Service Pack 3:

Administration Console

Change
Request
Number

Description

Release
Fixed

CR111884
CR182433

In WebLogic Tuxedo Connector, for imported services the combination of the resource name, local domain name, and remote domain name must be unique. However, the Administration Console prevented defining imported services with the same resource name.

The Administration Console now enforces unique naming based on the combination of the resource name, local domain name, and remote domain name.

8.1 SP3

CR125041

A Connection Pool Waiter statistics monitoring area in the Administration Console sometimes showed an incorrect value.

A check was added to ensure that the number of waiters is reported correctly.

8.1 SP3

CR126506

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

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

7.0 SP5

8.1 SP3

CR127617
CR134432

If a user did not have the correct permission to read files under a particular directory, NullPointerExceptions occurred in the console. Because the user did not have the correct permissions, empty arrays were returned.

This problem was fixed by adding suitable checks. WebLogic Server does not display the files for which the user does not have permission.

8.1 SP3

CR132229

Console help was updated to properly identify a comma as the address separator when configuring Jolt and WLEC connection pools.

8.1 SP3

CR132627

When WebLogic Server started with a large heap size (such as "-Xms3069m -Xmx3069m" or "-Xms2500m -Xmx2500m"), the Administration Console displayed incorrect values under server->monitoring->performance. The maximum memory was always 1, and the current heap size was negative.

This problem was corrected with a code fix.

8.1 SP3

CR134434

Symbolic links were resolved during the deployment process and absolute paths were saved in the configuration field (config.xml).

A code change ensures that symbolic links are no longer resolved.

8.1 SP3

CR135294

The console was not able to generate information from custom security MBeans used to create a custom security provider.

A code fix was implemented so the console generated the related pages without any exceptions.

8.1 SP3

CR137213
CR174743

The config.xml was incorrectly updated on UNIX systems when the Administration Console was used to change the load order of Web applications. The leading '/' character in an application's path got lost.

The code was fixed to ensure the attribute values are updated whenever they are changed from the related Console pages and the path attribute is not updated.

8.1 SP3

CR158522

Console help was updated to properly identify the range for polling interval when configuring the String Monitor, Gauge Monitor, or Counter Monitor. The correct range of values is between 1 and 65535 seconds.

8.1 SP3

CR172232
CR178004

When a connection pool using a custom JDBC driver was created, it was not possible to edit the advanced properties tab of the JDBC driver, and the server instance would throw a Java.lang.ClassNotFoundException when the driver was not in the system classpath .

A code fix was implemented to load the JDBC driver even if it is not found in the system classpath. The console displays the Connections-->Advanced page without the XA attributes.

8.1 SP3

CR173345

The Administration Console now includes the following language preference settings:

  • Chinese Simplified/GB18030

  • Chinese Simplified/GB2312

  • Chinese Simplified/GBK

  • Chinese Simplified/UTF-8

  • Chinese Traditional/Big5

  • Chinese Traditional/Big5-HKSCS

  • Chinese Traditional/UTF-8

  • English

  • English/UTF-8

  • Japanese/EUC-JP

  • Japanese/Shift_JIS

  • Japanese/UTF-8

  • Korean/EUC-KR

  • Korean/UTF-8

8.1 SP3

Classloaders

Change
Request
Number

Description

Release
Fixed

CR124348

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

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

6.1 SP6

7.0 SP5

8.1 SP3

CR128510

If a WebLogic Server 8.1 server returned a Calendar object to a WebLogic Server 6.1 or 7.0 client, the client got a ClassNotFoundException. This problem was caused by a change in the Calendar class in JDK 1.4. The readClassDescriptor() of MsgAbbrevInputStream tried to resolve the class, leading to a 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().

7.0 SP5

8.1 SP3

CR137120

The following error was encountered when sequentially starting two Managed Servers in the cluster. The error was not encountered if the two Managed Servers were started simultaneously.

LinkageError : duplicate class definition

The problem was resolved with a code change.

8.1 SP3

CR161884
CR173695

EAR files gave "NoClassDefFoundError" and "IllegalStateException: zip file closed" messages on classes that actually exist in the WAR file.

When multiple threads tried to load a class from a WAR file within an EAR file, is was possible that some JAR files within the WEB-INF/lib directory were not looked into; resulting in NoClassDefFoundError and IllegalStateException.

This problem was resolved with a code change, which added necessary synchronization to ensure that the zips structure within the Finders are not corrupted.

8.1 SP3

Clusters

Change
Request
Number

Description

Release
Fixed

CR111029

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

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

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

8.1 SP3

CR112326

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

7.0 SP5

8.1 SP3

CR112874

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.

8.1 SP3

CR121113

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

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

7.0 SP5

8.1 SP3

CR122924

When cluster address was specified as

t3://127.0.0.11:8001,127.0.0.12:9001

WebLogic Server incorrectly appended the port number when generating the home handles.

WebLogic Server now confirms whether the port number is already specified by the user and uses that information to properly create the URL used by the home handle.

8.1 SP3

CR126406

The cluster service set the real uid/gid of the process after binding to the multicast port, which caused errors when binding the server to listen ports.

A code change was made to ensure that the server only uses privileged uid/gid when binding to listen ports. For the rest of the server startup, the unprivileged uid/gid is used.

8.1 SP3

CR127375

In a single node cluster using a weight-based load balancing algorithm, a remote method invocation on an EJB from an external client resulted in an ArrayIndexOutOfBoundsException.

When there is a single node cluster, WebLogic Server will not have any replicas for requests to fail over or load balance. Adding a check for this condition resolves the problem.

8.1 SP3

CR127616
CR133899

A NullPointerException sometimes occurred in the BasicReplicaHandler during 70->81 interop if cluster affinity is set.

A null check was added to all affinity handlers.

8.1 SP3

CR130407

A client attempted to fail over even when there was only one server in the cluster.

This was resolved with a code fix so that failover happens only when there is more than one server in the cluster.

8.1 SP3

CR130507

Session replication caused server nodes to hang in a cluster because batch updates were performed for the lastAccessedtime of the sessions, which were all stored in a hashtable for all sessions. While doing batched updates, this hashtable was locked until all the updates were done (all the updates were remote calls), thus preventing other threads from updating the hashtable and resulting in poor performance.

The code was fixed so that a new hashtable (local variable) is created inside the trigger method of BatchedLATUpdater, which is a clone of the original hashtable. The new hashtable is used to access the lastAccesstime for the sessions; the old hashtable is synchronized only while it is being cloned. Therefore, it can be used by other threads while the remote calls are being made.

8.1 SP3

CR177367

An NPE was thrown when running a cluster under a heavy load or when the session stickiness was not maintained. When the load was high on the cluster nodes the plug-in was getting a connection refused from the node and hence failing over the requests to the other nodes in the cluster. Either condition was causing the session to change/get created randomly on any node in the cluster, and in certain scenarios it was possible that the primary was removed and a secondary was created for the session on the same node. Any thread trying to get the secondary information was failing with an NPE because finding the secondary information requires the primary. While the primary was removed first before creating secondary, the secondaryURL was being computed to null.

A code fix ensure that WebLogic Server now checks for null secondaryURL. In addition, a warning message is now logged to inform users of the problem, so they can configure the cluster for the expected load. This also ensures that the situation can be debugged if the session stickiness is broken in the load balancer configuration or the plug-in.

8.1 SP3

Compilers

Change
Request
Number

Description

Release
Fixed

CR136199

EjbObject.idl generated by ejbc -idl was not compliant with CORBA3.0.

From CORBA 2.6: "3.2.3.1 Escaped Identifiers. As IDL evolves, new keywords that are added to the IDL language may inadvertently collide with identifiers used in existing IDL and programs that use that IDL. Fixing these collisions will require not only the IDL to be modified, but programming language code that depends upon that IDL will have to change as well. The language mapping rules for the renamed IDL identifiers will cause the mapped identifier names (e.g., method names) to be changed. To minimize the amount of work, users may lexically "escape" identifiers by prepending an underscore (_) to an identifier. This is a purely lexical convention that ONLY turns off keyword checking. The resulting identifier follows all the other rules for identifier processing. For example, the identifier _AnIdentifier is treated as if it were AnIdentifier."

The problem was resolved by a code change that adds an underscore (_) to known IDL reserved words.

8.1 SP3

Configuration Wizard

Change
Request
Number

Description

Release
Fixed

CR128745

When using the Domain Configuration Wizard in silent mode to create a domain configuration, the Administration Console showed a user assigned to same group more than once.

The code was modified so that it does not add an entry if the corresponding assignment is already done.

8.1 SP3

CR130268

When the Domain Configuration Wizard encountered a problem that resulted in a failure it was returning a zero.

The code was modified to return a non-zero when user script files are not found.

8.1 SP3

CR130536

On the AIX 5.1 platform running WebLogic Server 8.1, Service Pack 1 with the Posix Performance Pack, a SIGSEGV 11 (*) segmentation violation occurred from the IBM JVM.

To recreate this error:

    1. Create a new WebLogic domain using the Configuration Wizard.

    2. Set the file descriptor limit to unlimited (ulimit -n) in the shell.

    3. Run the startWebLogic.sh script.

This issue was resolved with a code fix that ensures that the resetFd() method is called in the commEnv.sh script, which automatically resets the unlimited setting to 1025.

8.1 SP3

CR132234

Silent-mode script can now be used to create and edit the log child element of a Server element.

Silent-mode configuration can be used to create and edit any valid configuration object and its child elements, except custom security objects. For more information about valid configuration objects, see the WebLogic Server Configuration Reference. For more information about silent-mode script configuration, see "Creating a Script for Silent-Mode Configuration" in Creating WebLogic Configurations Using the Configuration Wizard.

8.1 SP3

CR132608

While attempting to create a domain using WebLogic Server Template Builder on Solaris 2.9 and creating a MySQL JDBC connection pool, the JDBC URL failed.

This problem was fixed with a code fix.

8.1 SP3

CR135642

When running the Configuration Wizard in silent mode, the wizard incorrectly converted the JDBC connection pool URL for the Oracle OCI driver (jdbc:oracle:oci:@<DBName>) to the URL for the Oracle Thin driver (jdbc:oracle:thin:@<DBHost:port:DBName>). This problem prevented deployment of JDBC connection pools with the Oracle OCI driver when the server was started.

The Configuration Wizard now accepts the URL for either Oracle JDBC driver.

8.1 SP3

Connector

Change
Request
Number

Description

Release
Fixed

CR124102

When the process of enlisting an adapter's connection with a transaction threw an exception, the state of the connection was not properly reset, which meant the connection could never be cleaned up by the shrinker.

Also, the connection could not be used by incoming application requests. Eventually, this resulted in exhaustion of the connection pool.

The server code has been repaired to properly reset the state of the connection when the enlistment fails. The connection can be cleaned up by the shrinker, and can also be used by future application requests.

7.0 SP5

8.1 SP3

CR125399

For adapters that failed the connection proxy test, connection idle detection should have be disabled even if inactive-connection-timeout-seconds is specified in the weblogic-ra.xml descriptor. Prior to this release, the server tried to perform idle cleanup using such an adapter, which would result in a NullPointerException.

Now idle-detection is properly disabled for an adapter that fails the proxy test. As a result, the NullPointerException will no longer occurs.

8.1 SP3

CR126184
CR135205

In some Resource Adapters, the Connector container sometimes reported false connection leaks. The problem occurred for adapters which implement the ManagedConnection.getConnection() method in a way that the same handle could be returned in subsequent calls.

The problem occurred because of the way it created proxies around the connection handles. When a proxy was finalized, and there was a handle with the same hashCode value still open, the container behaved as if there was a leak.

The Connector container now keeps track of a count associated with handles that have the same hashCode. The count is incremented when opening and decremented when the proxy is finalized. In this way, the container will only report a leak if all the proxies associated with a handle are finalized, and no false leaks will be reported.

8.1 SP3

CR129392
CR133572
CR177908

A WebLogic Server instance hosting a Messaging Bridge had to be restarted when the MQSeries 5.3 Queue Manager was stopped and restarted. This was because the call into MQSeries would fail when the Messaging Bridge attempted to close an XASession object. This resulted in resources not being cleaned up with regards to the MQSeries Queue Manager after shutting it down. Also, the Queue Manager would not restart because it detected that there were still objects in use by the WebLogic Server process.

Application of the IBM upgrade CSD06 to MQSeries 5.3 resolves this issue. As a result, the Queue Manager can be shutdown and restarted without error, and without having to shutdown the WLS server process.

8.1 SP3

CR174339

Some internally cached objects were not cleaned up properly when connections were permanently removed from the pool, which could then result in the cache growing arbitrarily large.

A code change ensures that cached objects are cleaned up when a connection is permanently removed from the pool.

8.1 SP3

CR175301

Under a heavy load with the jRockit JVM, the ConnectionRuntimeMBeanImpl() API for WebLogic Connector sometimes throws an InstanceAlreadyExists exception. This is because the ConnectionInfo#hashCode() method is not always unique for different objects.

In previous service packs, the hashcode of the connection was used to generate the MBean name. The code was improved so that it now uses a synchronized counter to generate the name. As a result, all runtime MBeans used for monitoring resource adapter connections are generated with unique names.

8.1 SP3

CR176940

When deploying an adapter on multiple servers in a cluster, the connections created on each server got an XAResource, and the server used the same name for resource registration. This caused the Transaction Manager to try to invoke calls on the wrong XAResource for some operations.

The name used for resource registration is now qualified by the server and domain name, thus ensuring that an adapter deployed on different servers in a cluster will use different names for the resource registration.

8.1 SP3

Core WebLogic Server

Change
Request
Number

Description

Release
Fixed

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

7.0 SP5

8.1 SP3

CR105257
CR174955

If a call to WLECService.getConnectionPoolCount was made before the IIOP Connection Pool was initialized it resulted in a NPE.

Code was added to return a 0 if the IIOPConnection Pool was null.

8.1 SP3


CR105444

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

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

8.1 SP3

CR108993
CR133901

On HPUX11, the CPU usage was high when using the native posix muxer.

A new muxer was designed, based on /dev/poll. This muxer can be enabled by setting the MuxerClass property as follows -

<Server ... MuxerClass="weblogic.socket.DevPollSocketMuxer" ...>

The following message should appear when the server starts up. This message confirms that the /dev/poll has been enabled.

<Sep 9, 2003 5:29:28 PM PDT> <Info> <Socket> <BEA-000406> <DevPollSocketMuxer was built on Sep 8 2003 15:34:11>

If the /dev/poll device is not available, it will fail to load. Currently it is available for:

  • Solaris 7 with a patch and on Solaris 8 and above

  • HP-UX 11.0 with PHKL_24064 patch required

  • HP-UX 11i with PHKL_25468 patch required

8.1 SP3

CR109180

Transactions started on one server that used another server as the transaction coordinator would fail during the commit if the two servers have not previously exchanged transaction contexts. This occurred because the channel being passed to the JTA interceptor contained information on the local server, not the remote peer.

A code fix was used to pass correct channel to the JTA interceptor.

8.1 SP3

CR109307

Previously you could not bring up a WebLogic Server 8.1 SP2 Managed Server in an 8.1 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."

7.0 SP5

8.1 SP3

CR109688
CR133876
CR133877
CR135235
CR176217

Under certain conditions a simple Java client looking up InitialContext would receive an incorrect "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.

7.0 SP5

8.1 SP3

CR116707

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

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

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

7.0 SP5

8.1 SP3

CR116712

In WebLogic Server 6.1 SP04, the WLECConnectionRuntime MBeans were not updated when an INVOKE was issued on WLECConnectionPoolRuntime using Admin tool.

Analysis revealed that when resetConnectionPool() was invoked on the WLECConnectionPoolRuntime MBean, the pool was not reset. Old connections were not removed.

The problem was solved with a code change. Now, the mbeans that correspond to old connections are unregistered before the resetConnectionPool() invocation.

6.1 SP6

8.1 SP3

CR120492 CR122551

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

7.0 SP5

8.1 SP3

CR120492
CR122551
CR171857

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.

7.0 SP5

8.1 SP3

CR120811

When using the WebLogic thin client with an applet, concurrentModificationExceptions and JMSExceptions were thrown. Investigation showed that there were two problems:

  • There was a problem with the Sun ORB implementation. An applet's virtual machine released AppletContext upon a browser refresh and stopped all threads in the applet context's thread group. When an ORB was initialized as part of an applet context, the reader threads were created in the applet context's thread group. When the browser was refreshed, the ORB reader threads were also stopped.

  • The WebLogic thin client created two threads in the applet context group: a HeartbeatMonitor thread and a RequestTimer thread. When the browser was refreshed, these threads were stopped with others in the applet context group.

The problems were solved with the following changes:

  • The Sun ORB implementation changed in JDK 1.4.2_04 so that it creates the reader threads on a child thread group of the system thread group but not to the applet's context thread group. This change ensures the reader thread stays alive as long as the orb is alive or applet's JVM is alive.

  • The WebLogic thin client TunnelResponse and HeartbeatMonitor threads are now created on a child thread group of the system thread group but not to the applet's context thread group. This change ensures these threads stay alive as long as applet's JVM is alive. The fix is provided only for signed applets.

8.1 SP3

CR121311

Server shutdown failed because of in-use resources. This was due to application problems: either an application leaked pooled resources, such as JDBC connections and JMS sessions, or an application was holding a reference to pooled resources after server shutdown had commenced.

By default, pools are now shut down even if resources are in use.

For JDBC connections, to revert to the previous behavior, set ignoreInUseConnections="false" on the JDBCConnectionPoolMBean.

8.1 SP3

CR122361

The Auditing enabled message did not record the USER identity:

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

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

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

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

7.0 SP5

8.1 SP3

CR122706

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

A code change resolved the problem.

7.0 SP5

8.1 SP3

CR122878

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

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

7.0 SP5

8.1 SP3

CR123509

Performance degradation occurred when tunneling the t3s protocol through IPlanet for HTTP/1.0 requests because of an IPlanet change related to the Keep-Alive functionality. This problem was resolved by a code change that now specifies HTTP/1.1 for tunneling requests.

7.0 SP5

8.1 SP3

CR123571
CR128843
CR183237

When starting several T3 clients on the same machine simultaneously, there was a possibility that two or more of the clients could obtain the same JVMID, cause exceptions or hanging on the clients. The problem occurred only when starting multiple T3 clients on the same machine at the same time. This problem was solved by modifying the code used to generate JVMIDs.

6.1 SP6

8.1 SP3

CR125245

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

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

7.0 SP5

8.1 SP3

CR125285

WebLogic Server was masking certain exceptions during application deployment because of an unhandled internal exception. With the code fix which handles this exception, the original exceptions are rethrown, which makes it easier to debug the original issue.

7.0 SP5

8.1 SP3

CR125440

WebLogic Server cached the EndPoints based on ConnectionKey for iiop requests. The ConnectionKey was based on host, port and type information on which the connection was established. Because of the way the ConnectionKey was established, tunneling requests used the wrong Connection object. Some clients from the same host never got responses back under load test because they were going to different EndPoints.

WebLogic Server now creates unique IDs for a Connection object so that tunneling requests use the correct Connection object.

8.1 SP3

CR126374

WebLogic Server was not calling the setPriority method on an ExecuteThread even when a priority was set for a particular execute queue.

Code was added to call setPriority when an ExecuteThread gets created.

8.1 SP3

CR126613

When onMessage for an MDB was invoked on a thread, the following exception was thrown because the transaction previously associated with the thread was not cleaned up properly:

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Left-over JTA transaction found on MDB listener thread ]

A stale transaction on the thread is now cleaned up before the thread is used to call the onMessage method on an MDB.

8.1 SP3

CR127394

When weblogic.jar was added as a ClassPathElement inside the ant task , ant used AntClassLoader to load classes from the weblogic.jar. This process worked, but ant did not properly set the contextclassloader on the thread. The context classloader on the thread was still the system classloader. This resulted in classloading issues while generating the stub.

This problem has been fixed in the WLDeploy ant task that WebLogic Server creates. In the implementation of the WLDeploy task the correct context classloader is set.

8.1 SP3

CR127455

The Administration Server uses a trigger to send a heartbeat to each Managed Server to verify that the Managed Server is running. When a Managed Server is restarted, the trigger for the old Managed Server needs to be cancelled. In some situations, the trigger for the old Managed Server was not cancelled properly.

The code was fixed to ensure the trigger is correctly cancelled.

8.1 SP3

CR128417
CR134918
CR172274

Sometimes server-side sockets remained in an IDLE state when a client issued a reset on the socket before the server could set the TCP_NODELAY option. Therefore, these IDLE sockets were not getting cleaned up properly.

A code change ensures the clean up of server-side sockets when an exception occurs when setting the TCP_NODELAY option on the socket.

8.1 SP3

CR128445

The weblogic.Admin command line utility set the username and password for the ServerStartMbean each time it was used to start a server instance. If a user attempted to start a server with weblogic.Admin, it would fail without permissions to WRITE attributes.

A code change ensures that WRITE attributes not set on ServerStart.

7.0 SP5

8.1 SP3

CR128496

Attempted interoperability between WebLogic Server 6.1 SP5 and 8.1 SP1 domains caused an InvalidClassException. This is because 6.1 SP5 was released with the pre-EJB 2.0 specification, while release 7.0 and later were released with the final EJB 2.0 specification, which changed the class javax.ejb.TransactionRolledbackLocalException in the final release. Therefore, if a release 6.1 SP5 domain sends this exception to an 8.1 domain, then the 8.1 domain fails to read the exception while deserializing this exception object with InvalidClassException because the SVUID of the local class and incoming response class are different.

The code has been modified to load the local class and stamp the SVUID to the incoming class when the other peer is a release 6.1 domain.

8.1 SP3

CR128646

When running a servlet, the generic class loader could not find the WebLogic JDBC class.

This was resolved by adding a check to the generic class loader to see if the JDBC class is set to null in weblogic.utils.wrapper.WrapperFactory.java. If it is set to null, then the current classLoader(this.getClass().getClassLoader()) is loaded.

8.1 SP3

CR129094

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

7.0 SP5

8.1 SP3

CR130376
CR133631
CR174605
CR175607
CR172366

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

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

8.1 SP3

CR130409
CR178422

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.

8.1 SP3

CR132704

When using the MBean.forceShutdown from a servlet's Init method and using load-on-startup, the server did not successfully shut down and the "Start this Server" button in the Control tab is greyed out and stays in this state for quite some time. After several minutes, the link is enabled.

The problem was resolved with a code change. The forceShutdown call now ensures the server is shut down without hanging the server lifecycle thread. Because the server state is properly changed, the console properly activates the links as soon as the server is down.

8.1 SP3

CR132994

Due to a Sun plug-in bug, a lookup for an EJB was failing. However, a WebLogic Server bug was exposed because of this issue. There was only one server in the cluster and yet the system was trying to fail over to another server even when the replica list was empty.

This problem was resolved with a code change; failover only occurs if the replica list is not empty.

8.1 SP3

CR135122

When an application in a WebLogic server instance made an RMI call to another application within the same server instance, it uses the Call By Value (CBV) Wrapper implementation. The CBV wrapper implementation cloned the values for all the object instances except primitive datatypes and Date instances. If application specific code derived the Date and provided it's own implementation for the Date class, cloning the user defined class created an object instance on the other server's classloader. A ClassCastException occurs when the other server assigned the instance to the caller's application.

The problem was resolved with a code change.

8.1 SP3

CR135255

When a request comes over a network channel, the server (instead of writing the default channel information as part of JVMID) writes the address information of the network channel. This information from streams is used to detect if the request came over a default channel or a network channel. In this case, the ChunkedObjectOutputStream did not implement the EndPointStream interface because the server was unable to make a distinction between the default and network channel.

This problem caused a degradation in performance.

A code fix ensures that the ChunkedObjectOutputStream implements the EndPointStream interface so that the JVMID class can determine on which channel the request came.

8.1 SP3

CR135256

The server wrote the address information of the default channel rather than the network channel information as part of JVMID. This caused the client to throw a java.rmi.ConnectException because the default channel was not visible to the client.

A code fix ensures the server writes the address information correctly.

8.1 SP3

CR136076

EJB network channel issue; unable to connect to the business channel. When the connection request was received on the network channel, the server correctly translated the JVMID by writing the network channel information in it. However the server was also translating the rawAddress and calculating it based on the network channel address. The rawAddress must be calculated based on the defaultChannel address so that JVMID equality is maintained.

A code fix was implemented to always write the rawAddress based on the defaultChannel address, even if the request is received on a network channel.

8.1 SP3

CR136250

When a request was retried for proxy authentication, the original headers and post data were not sent by HttpURLConnection, which caused Proxy Authentication to fail.

A code fix ensures that any headers and data from the original request are re-sent during a retry.

8.1 SP3

CR136756

A client threw a java.net.UnknownHostException exception when it tried to connect to a server. The exception was thrown because the client had previously connected to a server that had a private network channel. The client threw the exception when it was unable to determine if a connection existed before attempting to open a new connection.

A code fix was used to resolve this issue.

8.1 SP3

CR172105
CR177136

Calling the setTimeout method of weblogic.net.http.HttpURLConnection no longer takes twice the amount of time specified.

8.1 SP3

CR172366

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

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

8.1 SP3

CR173345

When trying to determine if a client was an applet, WebLogic Server tried to read a system property, and if it threw a security exception the client was assumed to be an applet. For signed applets a security exception was never thrown and it was incorrectly assumed to be a Java client when it was actually an applet. Therefore, WebLogic Server could not distinguish between a Java client and a signed applet.

A code change ensures that in addition to determining whether a client is a signed applet, WebLogic Server also reads additional properties that are only set for an applet.

8.1 SP3

CR173958

Interoperability between 6.1 SP4 and 8.1 SP2 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.

8.1 SP3

CR174605

The beasvc service was generating thread dumps when it received the SERVICE_CONTROL_INTERROGATE control code. This could cause unintended thread dumps when beasvc was interrogated by other tools.

A code fix ensures that thread dumps are generated only when a custom control code is received.

8.1 SP3

CR175607

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

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

8.1 SP3

Deployment

Change
Request
Number

Description

Release
Fixed

CR127393

A number of memory leaks were identified with this problem:

  • ClientRuntimeDescriptors of EO objects remained on the heap after undeploying application.

  • EJBCache objects were not cleaned up after undeploying of the application.

  • Runtime mbeans specific to WebAppServletContexts were not unregistered after undeploying an application.

  • KeepAliveCache's timer object held an application-specific classloader.

  • Descriptor objects were not unregistered after undeploying an application.

  • Application-specific classes were held by the Introspector caches after undeploying an application that uses struts.

Code has been added to WebLogic Server that fixes these problems.

8.1 SP3

CR128537

The weblogic.deployer utility exited after 60 minutes with the following exception, even if the Timeout parameter was set to a higher value:

<Error> <Deployer> <lcaix17.bea.com> <myserver> <ExecuteThread: '0' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149014> <Target myserver is not defined - error null>

The code was fixed to use the default timeout only if it is not provided in the Deployer options. This way deployment will not fail at the default 60 minutes, when the timeout is provided. Instead, it will wait for the timeout to expire.

8.1 SP3

CR130062

When the weblogic.Deployer command was used from a wrapper class, deployment to multiple domains could have produced deployment failures. This was due to RMI calls that were made without a properly authenticated subject on the thread.

A code fix was made to keep the subject properly authenticated until the deployment activity is complete.

8.1 SP3

CR130592
CR133154
CR135864

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

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

8.1 SP3

CR132685

An EJBModule maintains a Map that maps the implementation class with the list of all EJB names whose implementation classes are derived from the keyed implementation class. This map is used during redeployment.

There were two bugs in this implementation where:

  • There was an unnecessary map maintained in EJBModules.

  • The same EJB name was added repeatedly to the list in the map.

These issues lead the EJB container to consume more memory and caused the server to run out of memory.

The unnecessary map was removed and the EJB container only adds EJB names to the list which are not already added.

8.1 SP3

CR133764

An application was successfully deployed as an exploded ear and the META-INF directory contains a weblogic-application.xml file where a listener-class is defined and a listener class was located in APP-INF directory. After an extension template was created using config_builder.cmd, the META-INF and APP-INF directories were missing from the created .jar file and the application could not be deployed.

A code fix was used to resolve this issue.

8.1 SP3

CR133864

When wlconfig and wldeploy ant commands were used to deploy applications, the deployment tasks were hanging.

A code fix ensures that the RMI queue threads no longer poll for task completion while deployment is running.

8.1 SP3

CR134856

The administration console did not correctly display the current status of a Web application deployed on a cluster after clicking Stop on the Deploy tab.

A code fix was used to resolve this issue.

8.1 SP3

CR134938
CR137390

There was a classloader issue when undeploying applications. A J2EE container maintains an application-specific classloader and classloader tree, which are used for loading application classes and module-specific classes. When the undeploy command was issued on the application, it closed the classloader and classloader tree before rolling back the modules in it, and therefore got a NoClassDefFoundError errors for the classes that were referred from the destroy() method of the servlet for the first time, because servlet destroy() is called from the rollback() of that specific module.

A code fix ensures that the container will not close the classloader tree before rolling back the modules in it.

8.1 SP3

CR135145

During deployment, an application that contains a Web application targeted to virtual hosts tries to search for an existing application on the default Web server even though it is not targeted to the default Web server. Hence it fails to deploy the component on the virtual host if there is another application deployed on the default Web server with the same context-path.

The application no longer searches for the existing application on the default Web server when it is not targeted to default Web server.

8.1 SP3

CR136885

During server startup, all applications were staged. This included applications that were not needed by the current server. This was observed from the entries in the StagedTargets property in the Application stanza of the config.xml file and the stage directory had all available applications staged.

A code change was used to resolve this issue. Only the necessary applications needed on the current server are staged.

8.1 SP3

CR175858

Staged directories were not removed when an application was removed using the Administration Console.

A code fix ensures that the staged directories are removed after an application is removed.

8.1 SP3

EJB

Change
Request
Number

Description

Release
Fixed

CR090405
CR091204

WebLogic Server newly supports java.net.URL resource connection factory, so that an EJB can obtain a obtain an HTTP connection to a Web server external to the WebLogic Server environment using the java.net.URL resource connection factory.

WebLogic Server will support this in the following ways:

If the Bean provider provides a direct URL for the res-type java.net.URL, WebLogic Server will create a URL object with the jndi-name provided and bind the object to the java:comp/env. The bean provider declares the jndi-name as follows in that case in the weblogic-ejb-jar.xml:

<resource-description>

<res-ref-name>url/MyURL</res-ref-name>

<jndi-name>http://www.rediff.com/<;;/jndi-name>

</resource-description>

If the bean provider provides a string that is not a valid URL, Weblogic Server treats it as an object that maps to a URL and is already bound in the JNDI tree. In that case, WebLogic Server binds a LinkRef with that jndi-name.

<resource-description>

<res-ref-name>url/MyURL1</res-ref-name>

<jndi-name>firstName</jndi-name>

</resource-description>

The URL can then be accessed as follows inside the Bean code:

URL url = (URL) context.lookup("java:comp/env/url/MyURL");

connection = (HttpURLConnection)url.openConnection();

7.0 SP6

8.1 SP3

CR103038

When the <allow-remove-during-transaction> element in the weblogic-ejb-jar.xml was set to "False", and an application attempted to remove a stateful session bean involved in a transaction, an inaccurate exception was thrown.

weblogic.ejb20.locks.LockTimedOutException is not the exception called for in the EJB 2.0 specification, and it was replaced with the exception required: javax.ejb.RemoveException.

8.1 SP3

CR108169

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

The correct method name has now been implemented.

8.1 SP3

CR109267

When using entity EJBs with container-managed persistence and automatic key generation, the following error was thrown when using some XA JDBC drivers:

XAER_RMERR : A resource manager error has occurred in the transaction branch

A change to the automatic key generation code resolved the problem.

8.1SP3

CR110440

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

7.0 SP5

8.1 SP3

CR122524

An incorrect string was passed to retrieve the tableName from the DatabaseMetaData if the schemaName was not specified with the tableName.

Code was added to pass the correct string to retrieve the tableName from the DatabaseMetaData when the schemaName is not specified with the tableName.

8.1 SP3

CR123213

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

A code change resolved the problem.

8.1 SP3

CR125501

WebLogic Server was throwing an Illegal Reentrant call error in some situations when a client removed an EJB and then created a new EJB with the same primary key.

A code fix was implemented resolve this issue.

8.1 SP3

CR127187

A CacheFullException was thrown for cmp11 beans because of back door database deletes.

For EJB creates, WebLogic Server now checks if the bean exists in the cache before inserting it into the cache. This eliminates the possibility that the cache state will get out of sync with the database due to back door database updates.

The cache is now remains consistent even after back door database updates.

8.1 SP3

CR127397
CR131629

This problem was there for Remote Objects using ActivatableServerRef.

Entity beans use ActivatableServerRef.

ActivatableServerRef called activate to get the bean instance. after invoking the bean method it called deactivate. In deactivate we were releasing the bean to the pool.In some cases only activate was being called. Because deactivate was not being called WebLogic Server was not releasing the bean.

WebLogic Server no longer relies on activate and deactivate calls. The ActivatableServer ref now explicitly calls notifyRemoteCallBegin and notifyRemoteCallEnd.

8.1 SP3

CR127872
CR135787

A java.sql.BatchUpdateException: ORA-01006 or java.lang.ArrayIndexOutOfBoundsException is thrown when enable-batch-operations is set to true for an EJB that uses Optimistic Concurrency and a batch of queries arrive such that a parameter is null in the predicated clause of one query and not null in the predicated clause of another query.

A code fix provides a check to verify whether the queries are fit for batching. If they are not, batching is turned off and the queries are executed using multiple update statements. The following warning message is sent to the server log:

<Apr 27, 2004 11:25:12 AM PDT> <Warning> <EJB> <BEA-011078> <The CMP EJB UserSession has enable-batch-operations set to true, however the update queries are not suitable for batching. Batched operations are turned off for this batch and the queries shall be executed with mutliple update statements.>

8.1 SP3

CR128063

When an MDB suspended a transaction, if the transaction was later resumed, it was committed or rolled back using a different thread. This caused problems for some XA implementations.

The MDB container now ensures that the transaction is started and committed using the same thread.

8.1 SP3

CR128956
CR133894
CR154779

When the domain had two JMS targets with the same JNDI name, MDB deployment was trying to create two MDB pools with the same name. As as a result of this, it was trying to create two MessageDrivenEJBRuntimeMBeanImpl objects with same name, which was causing an Instance Already Exists exception.

This was resolved by a code fix so that when the <provider-url> stanza is mentioned in the MDB descriptor, it is treated as any foreign JMS provider. Also, when performing the Distributed and/or Migratable destination optimizations, consideration is given only to the JMS target that is related to the current server or current cluster. No consideration is given to the JMS targets of other clusters.

This way, MDB deployment will not fail when the JNDI name is reused for different JMS destinations across the domain in different clusters. Also, the <provider-url> stanza should not be mentioned in the MDB descriptors to have the Distributed and/or Migratable destination optimizations, as documented in the "MDB Deployment Options" section of Programming WebLogic Enterprise Java Beans".

8.1 SP3

CR128980
CR135722

When an MDB used the synchronous message polling scheme, it had issues when a TIBCO JMS server was used. Specifically, the MDB container's polling optimizations could result as a delay in messages being received.

The code was fixed so that the optimized poller is not used. Since the TIBCO message delivery scheme does not work well with this scheme, MDBs now use a poller that continuously polls the TIBCO JMS server. And since these pollers need an exclusive thread, when a dispatch-policy is specified with an MDB, the fix ensures there are enough threads for polling. Otherwise, the user can also tune the max beans count in the MDB descriptors.

Note: This fix only applies to TIBCO JMS, so other foreign JMS servers still use the existing mechanism. Therefore, there will not be any change in the behavior for MDBs using foreign JMS servers other than TIBCO.

8.1 SP3

CR129035
CR132804

For a CMP20 bean using automatic key generation with the MS SQL Server database, and the delay-db-insert-until element set to ejbPostCreate, an entity local object that did not have the correct identity set got cached in the relationship set. This unidentified, entity local object, was returned when a getter method was called for the CMR field, thereby causing a ClassCast exception.

This was resolved by associating a dummyPK to the entity object\entity local object before calling a create on the bean and replacing it with the correct identity when the PK is known.

8.1 SP3

CR129185

WebLogic Server loaded optimistic-concurrency beans in a separate transaction, suspending the current transaction, starting a new one, loading the bean and resuming the old transaction for all databases except Oracle, to avoid acquiring locks during the SELECT. Because 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.

7.0 SP5

8.1 SP3

CR129223

CMP20 EJBs using Optimistic concurrency and cache-between-transaction failed for many-to-many relationships.

With the cache-between-transactions element set to true, the bean along with the generated many-to-many set was cached, which caused the new transaction to use the cached bean and hence the cached set. The previously cached values in the set were not cleared and hence at the end of the transaction when the M2NJoinTable inserts are done, it failed with a ORA-00001: unique constraint violated error. This indicated that an attempt was made to insert a record with a duplicate (unique) key.

The problem was resolved by clearing the cached many-to-many set for the new transaction since the many-to-many set is maintained per transaction.

8.1 SP3

CR129379
CR136730

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.

7.0 SP5

8.1 SP3

CR131848

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

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

7.0 SP5

8.1 SP3

CR133602

WebLogic Server used a special handling code for SonicMQ 4.* version, when XAconnections were used. This code was not required for Sonic 5.* version and caused a connection leak when used with it.

A code fix eliminated the connection leak.

7.0 SP5,

8.1 SP3

CR133774

The following part of the description for the max-beans-in-cache element in the weblogic-application.xml DTD was incorrect: If 0 is specified, then there is no limit for max-beans-in-cache. A max-beans-in-cache size of 0 would 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 prohibit a value of 0 for the max-beans-in-cache in weblogic-application.xml. If you need to set a large size (infinite) for your cache, set 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 weblogic-ejb-jar.xml.

8.1 SP3

CR134082