Skip navigation.
Downloads | Product Documentation | Support

Release Notes

# Resolved Problems for Service Pack 1

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

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

- Administration Console
- Classloader
- Cluster
- Connector
- CORE
- Deployment
- EJB
- Installation
- Internationalization
- J2EE
- JDBC
- JMS
- JNDI
- JTA
- JVM
- Localization
- Node Manager
- Plug-Ins
- RMI/RMI-IIOP
- Security
- Servlets & JSPs
- System Administration
- Tools
- Utilities
- WebLogic Workshop
- Web Services
- XML

## Administration Console

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR094513 | For Connectors that had not yet been used, the Connector monitoring table displayed the last used time as "`Wed Dec 31 19:00:00 EST 1969`." It now displays the text: "`Never`." | 8.1 SP1
CR095863 | Custom attributes defined in the MBean Definition Files (MDFs) for several WebLogic security providers were displayed on the General tab for that provider, rather than on the Details tab. These attributes were as follows: RequireUnanimousPermit for the WebLogic Adjudication provider Severity for the WebLogic Auditing provider MinimumPasswordLength of the WebLogic Authentication provider PolicyDeploymentEnabled for the WebLogic Authorization provider CredentialMappingDeploymentEnabled for the WebLogic Credential Mapping provider RoleDeploymentEnabled for the WebLogic Role Mapping provider These attributes are now on the Details tabs for these WebLogic security providers. | 8.1 SP1
CR097818 | No online help was available for the View Idle Connections or View Leaked Connections pages. Online help for these pages is now available. | 8.1 SP1
CR098353 | The TransactionLogFileWritePolicy attribute was added in 7.0 SP01, but was never exposed in the Administration Console. A field for setting this attribute is now available on the Server —> Logging —> JTA tab. | 7.0 SP3 8.1 SP1
CR099541 | The Delete button at the bottom of the Policy Editor page did not delete the highlighted security policy. It also did not delete the default security policy. However, the Remove button would delete the default security policy. This action occurred because of a problem in the JavaScript code. The JavaScript code was modified so that the buttons on the Policy Editor page now work properly. | 8.1 SP1
CR099771 | The JDBC Assistant did not allow users to enable "Advanced Options" when creating data sources. The particular option of interest was `Emulate Two Phase Commit for non XA Driver' . The `Emulate Two Phase Commit for non XA Driver' option is now available in the JDBC Assistant. | 8.1 SP1
CR099866 | If the administration port is enabled, the Administration Console must use it. However, console extension Web applications do not use the administration port, so the links in the navigation tree that pointed to the console extension Web application did not work. This problem occurred because console extension Web applications were not labeled internal (which is required to access the administration port), and thus the servlet container rejected the request. Console extension Web applications are now labeled as internal. | 8.1 SP1
CR100224 | Exceptions were not correctly handled when viewing the JNDI tree for a Managed Server. The exceptions showed up in the log, but there was no indication in the Administration Console that an exception had occurred or that anything out of the ordinary had happened. The JSP code has been modified so that when an exception in the JNDI tree occurs, an "Access Denied" entry for the node in question is made in the navigation tree. The exception is also printed to the log. | 8.1 SP1
CR100460 | When an attempt was made to clone a server that is a target of an existing JMS distributed queue/topic, a `javax.management.InvalidAttributeValueException` was displayed in the Administration Console. This exception stated that the server was an `"Illegal target"` and that `"A JMSDistributedQueue/JMSDistributedTopic, if it has members, should be deployed to a cluster or a single server that is not in a cluster."` While the newly created/clone server was created, it did not show up in the navigation tree, but did show in the summary server view. Code has been modified so that the cloning of a server would not cause existing JMS distributed queues/topics to be added as targets, since these have already been targeted to a cluster. Additionally, the newly created/clone server now shows up in the navigation tree. | 8.1 SP1
CR100638 | Clicking the Distributed Topic Members or Distributed Queue Members links in the banner of the page for a specific Distributed Topic/Queue Member resulted in a 404 error. This problem was resolved by removing the links from the banner, since they duplicated the functionality of the links for the specific Distributed Topic/Queue Member. | 8.1 SP1
CR100731 | After the apparently successful deletion of a Web application, clicking the Continue link caused a `javax.management.InstanceNotFoundException` to be displayed. This problem was resolved with a code fix. | 8.1 SP1
CR100974 | When configuring a new Network Channel for a server, the Administration Console required that a Listen Address be specified, when this field is not required. This problem was resolved by removing validation on the Listen Address field so that it is not required by the Administration Console. | 8.1 SP1
CR101247 | If you were logged in to the Administration Console as a user who was granted a non-Admin security role and clicked the Services —> JCOM node in the navigation tree, the Domain Configuration page was displayed. This problem was resolved by removing the Services —> JCOM node from the navigation tree when users do not have permission to modify security settings (that is, for all users granted a non-Admin security role). | 8.1 SP1
CR101317 | When using the Administration Console with Internet Explorer 5.5, you may have seen the following JavaScript error message: "Object does not support this property or method". Upgrading to Internet Explorer 6.0 corrects this problem. This error appeared only occasionally on some computers where unspecified Internet Explorer patches have been applied. This problem was resolved by adding a JavaScript workaround for the bug in this version of Internet Explorer. | 8.1 SP1
CR101770 | The SSL Login Timeout field was unintentionally dropped from the WebLogic Server Administration Console. This problem was resolved by adding this field to the Configuration —> Tuning tab, under the Login Timeout field. | 8.1 SP1
CR102441 | There was no help text displayed on the pages that allow you to select which configured Authentication provider, Authorization provider, Role Mapping provider, or Credential Mapping provider should store a new user, group, security policy, or security role that was being defined (respectively). This problem was resolved by adding and displaying help text for these pages. | 8.1 SP1
CR102561 | When a JMS file store was assigned to a single JMS Server, and a distributed topic was created with the Enable Store box checked (that is, set to true), errors similar to the following may have been displayed: `StoreEnabled set to 'true' for destination 'MyJMS Topic' but no Store configured for server 'TendrilJMSServer'.` `Can not set Enable Store to True if the JMS Server does not have a store defined.` This problem occurred because the Enable Store setting is non-dynamic and the JMS Server was being auto-targeted too early in the process. This problem was resolved by removing the auto-targeting of JMS Servers. | 8.1 SP1
CR102846 | The Administration Console displayed a Channel Weight field in the Server —> Protocol —> Channels —> Network Channel tab's Advanced Options pane, when this field was obsolete. This problem was resolved by removing the Channel Weight field from the Administration Console. | 8.1 SP1
CR102982 | The Client Cert Proxy Enabled check box was displayed on the Tuning tab for a server, but this attribute is not related to tuning. This problem was resolved by relocating the ClientCertProxyEnabled field to the Configuration —> General tab for a server. | 7.0 SP3 8.1 SP1
CR103328 | When attempting to view server log message details using the Administration Console, the following exception may have occurred: `java.lang.IllegalArgumentException: Cannot format given Object as a Number` This problem occurred because messages with number arguments were not being handled properly. This problem was resolved by modifying the code so that messages with number arguments were handled properly. In addition, unexpected exceptions that may have occurred while they were being formatted were also fixed. A localized message will now be presented to users as happens elsewhere in the Administration Console. | 8.1 SP1
CR103536 | When multiple JMS Servers were configured and new distributed topics/queues were created with the Enable Store box unchecked (that is, set to false) and then later checked (that is, set to true), an error similar to the following was displayed: `Can not set Enable Store to True if the JMS Server does not have a store defined.` This error also occurred if the Enable Store box was checked, a new topic/queue was prepared, and the Apply button was clicked after the topic/queue was created (by clicking the Create button). This problem was resolved by correcting the verification logic. | 8.1 SP1
CR105226 | When attempting to view global roles without use of the navigation tree (by clicking Realms —> myrealm —> User Management —> Manage Role within this Security Realm), the resulting page displayed all security roles, not just the global roles. This may have resulted in seemingly duplicate security roles, when in fact a global role and scoped role with the same name may have been listed. This problem was resolved by modifying the page so that the navigation path shown above displays only global roles. | 8.1 SP1
CR105262 | Attempting to view scoped roles for a Web application deployed as part of an enterprise application (EAR) resulted in the following error: `There are no appropriate RoleEditor providers configured.` This problem was resolved by modifying the code so that it locates a Role Mapping provider that supports the editing, deploying, and so on of security roles by implementing the `RoleEditor` optional SSPI. | 8.1 SP1
CR108134 | The JDBC Assistant listed a number of JDBC drivers, but only a subset of those drivers are actually certified for WebLogic Server JDBC. The drivers that are certified for WebLogic Server JDBC are now marked as such in the JDBC Assistant. | 8.1 SP1

## Classloader

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR102530 | When WebLogic Server executes external processes that require CLASSPATH information, a String representation is generated based on the classpath of the current classloader. This representation includes information from any MANIFEST classpath entries and could have caused duplicate elements in the generated path. In some cases, this might have led to an OutOfMemoryError. The algorithm that generates the classpath has been modified to filter duplicate entries in order to prevent this problem. | 8.1 SP1

## Cluster

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR102526 | When an HTTP network channel was defined on a server (using the Administration Console's Protocols —> Channels tab for that server), session replication did not work. This problem occurred because there was a problem in the remote channel selection code. This problem was resolved by modifying the remote channel selection code so that it does not try to use invalid channels for t3. | 8.1 SP1

## Connector

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR100269 | JDBC Resource Adapter using Oracle Thin Client driver failed during completion of client-controlled transactions. This problem occurred when using a transaction started from a client application. The client started a transaction and then accessed a bean or Web application that used the resource adapter. When the client application attempted to commit or roll back the transaction, the server threw an exception of type `javax.transaction.xa.XAException`. This problem occurred because the Oracle Thin Client driver did not properly handle a call to `XAResource.end` with a `TMSUSPEND` flag. This problem was resolved by having the connection intercept the calls to the `XAResource`. | 8.1 SP1
CR100707 CR101761 | 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. | 7.0 SP3 8.1 SP1
CR101906 | 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(CedarBankBeanBrazil.java:130) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl.cedarBank(CedarBankBeanBrazil_ris6bf_EOImpl.java:46) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:785) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)` Research revealed that WebLogic Server failed to wait for the transaction to complete before trying to destroy the connection. A code fix resolved the problem. | 7.0 SP3 8.1 SP1
CR101924 | When there is more than one matching credential, creating a new credential mapping resulted in an exception that began with the following lines: `java.lang.IllegalStateException: Subject is read-only at javax.security.auth.Subject$SecureSet.add(Subject.java:1046) at weblogic.connector.common.internal.SecurityContext$1.run(SecurityContext.java:250) at java.security.AccessController.doPrivileged(Native Method) at weblogic.connector.common.internal.SecurityContext.initSubject(SecurityContext.java:244) ...` This problem occurred because WebLogic Server called the `setReadOnly` method on the Subject as it added each credential in the list to the Subject. Therefore, only the first credential added to the Subject would not throw the above exception. This problem was resolved by modifying the code so that the setReadOnly method was called only once, after all the credentials were added to the Subject. | 8.1 SP1
CR102220 | A messaging bridge could not reconnect to the source/target destinations when the source Weblogic Server instance was killed and then restarted. This problem occurred because the `ConnectionPool` code was synchronized on the connection pool for the entire duration of releasing a resource or destroying a connection. This resulted in a deadlock of two threads, with the first thread releasing the resource and obtaining a lock, and then waiting on a second thread that was trying to destroy a resource that was waiting to get a lock on the connection pool. The problem was resolved by modifying the `ConnectionPool` code to obtain a lock only when it is required to remove any potential lock contention issues. | 8.1 SP1
CR104642 | When an error occurred in a `ManagedConnection`, it was removed from the connection pool, but the count of available connections in the pool was not being decremented. As a result, the maximum connection limit may have been reached sooner than expected, and an error message similar to the following may have been encountered when clients requested a new connection: `<Reached maximum capacity of pool "Archiv_eis/ArchivAdapter", making "0" new resource instances instead of "1".>` This problem was resolved by modifying the code to properly decrement the number of available connections in the pool following an error in the `ManagedConnection`. | 8.1 SP1
CR105085 CR105712 | After doing a proxy test, the connection was not being closed. This problem was resolved by modifying the code to call the `close()` method on the opened connection returned by `getConnection`. The connector container now introspects the connection handle to find the `close()` method and invokes it. If the `close()` method is not found, the container will log an error message stating that it did not find the `close()` method, and that it is required by the revised J2EE Connector Architecture Specification. | 8.1 SP1
CR112051 | In some cases with transactions involving connections to a resource adapter, if one thread was in the middle of beginning a transaction, and another thread was completing a transaction, a deadlock situation may have occurred causing both threads to hang. The deadlock occurred because both the JTA and Connector subsystems were performing synchronization on the same object in a conflicting way. The internal synchronization mechanisms have been repaired so that the conflict will no longer occur. As a result, the server will no longer hang in cases where one thread is starting a transaction while at the same time another thread is completing a transaction. | 8.1 SP1

## CORE

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR071415 | When the WebLogic Server security manager starts and sets the policy file, the path `/usr/lib` was prepended to `javac` during JSP compilation, causing a `java.security.AccessControlException`. The problem was solved with a code fix. | 6.1 SP6 8.1 SP1
CR087808 CR095487 | When multiple initial context lookups were attempted from a client with different server URLs simultaneously, there was a possibility that WebLogic Server would shut down the healthy RJVM when detecting duplicate connections. This problem has been resolved. | 6.1 SP5 7.0 SP3 8.1 SP1
CR092155 | If remote calls are made to a stale stub (that is, a stub obtained from a previous incarnation of the server that can no longer be used to make remote calls), network resources may be depleted. This problem was resolved by modifying the code so that the communication layers detects this occurrence and throws a ConnectException without actually connecting to the server. | 8.1 SP1
CR097077 | 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. This problem was resolved by moving `BootServicesImpl` into the RMI layer so that it can dispatch to the default execute queue. | 7.0 SP3 8.1 SP1
CR098865 | When SSL sockets were closed, they wrote data by sending a CLOSE alert to the peer. This caused threads to hang when clients became unresponsive or when the connection was very slow. This problem was resolved by ensuring that after t3s RJVM timeout, the socket will be forcibly closed. | 8.1 SP1
CR100177 | The use of `weblogic.security.service.ServerResource` 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. | 7.0 SP3 8.1 SP1
CR101103 | WebLogic Server experienced a performance regression when running SPECjAppServer with IIOP. This problem occurred because the JDK IIOP serialization code queried the system class loader for two classes for every request, and because loadClass is synchronized. This made the lock highly contended across the whole VM. This problem was resolved by caching these two classes in GenericClassLoader. | 8.1 SP1
CR101720 | With connection filtering enabled, `Connection rejected` messages would accumulate in the log file, resulting in the log filling up. This was resolved with the new ConnectionLogger property, which lets users configure whether to log such messages to the log file. | 7.0 SP3 8.1 SP1
CR101946 CR101808 | If you used the Java socket reader implementation, extended use of JMS sometimes led to an Out of Memory error. This problem occurred because of a memory leak in the Java socket muxer, which happened when socket read errors occurred. The problem was resolved by modifying the code to ensure that data structures related to the sockets were freed properly when the socket read errors occurred. | 8.1 SP1
CR102196 | In some rare error conditions, there was a memory leak in the NTSocketMuxer when the initiation of an NT asynchronous read failed. This problem was resolved by modifying the `NTSocketMuxer` to set a "read complete" status correctly after a `SocketException` occurred. | 8.1 SP1
CR102848 | 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. | 7.0 SP3 8.1 SP1
CR102874 CR103973 | By default, network channel tunneling was on, which may have posed a security risk if you had explicitly configured network channels for a WebLogic Server instance. This problem is resolved by disabling network channel tunneling by default. | 8.1 SP1
CR103203 | The `AcceptBacklog` server attribute was erroneously marked as dynamically configurable. This was wrong because the accept backlog for a server socket can only be changed at creation time. WebLogic Server has no dynamic means of recreating server sockets on demand, and so the accept backlog can only be configured statically. This problem was resolved by ensuring that the accept backlog is only statically configurable. | 8.1 SP1
CR103721 | Attempts by a Java client to obtain an initial context over t3 using the address of a load balancer as the Provider_URL failed with a connection refused or connection timeout. A software change now allows a Java client to obtain an initial context over t3, with the Provider_URL set to the IP address of the load balancer. This is only possible when there is not already an established socket connection between the Java client and a server instance in the cluster. Only requests from the Java client that can be addressed to the load balancer are initial context requests. When using a default channel and t3, it is not necessary to set ExternalDNSName to traverse a NAT firewall. (Initial context requests described above will fail if ExternalDNSName is set.) | 7.0 SP3 8.1 SP1
CR103853 | If a start-up class or a start-up servlet attempted to set some system properties, a `java.util.ConcurrentModificationException` was thrown, which would prevent WebLogic Server from starting up. The problem was resolved by working on a clone of system properties when attempting to log the system properties during startup. | 8.1 SP1
CR103967 | Child threads of WebLogic Server execute threads did not inherit the correct context classloader. This common problem occurred when a servlet or an EJB created a timer (`java.util.Timer`). Analysis revealed that WebLogic Server execute threads maintained their own context classloader and child threads of these execute threads did not inherit the context because `java.lang.Thread` directly assigned the member variable of its own to the child threads. The problem was solved with a code fix. | 6.1 SP6 8.1 SP1
CR104030 | If an EJB that was not compiled with `ejbc` or `appc`, WebLogic Server will automatically compile it at deployment time. The compiler will be picked up from the PATH environment variable. However the `commEnv.sh` did not export the PATH variable which was causing a wrong compiler to be picked up. This is now resolved. | 8.1 SP1
CR104373 | When a Java client attempted to invoke the `create` method on the home stub of a stateless session bean using just the `wlclient.jar`, a `ClassCastException` would sometimes occur. This is because the client was unable to retrieve a suitable IIOP stub for the object from the server. This problem was resolved by modifying the stub generator to generate stubs with names that precisely reflect the IIOP Repository IDs used for remote objects. | 8.1 SP1
CR107950 | Idle RJVMs that lasted for more than 4 minutes were shutdown in the WebLogic Server 8.1 GA version, which was a regression from WebLogic Server 7.0. In WebLogic Server 8.1 SP1, idle RJVMs are not timed out. | 8.1 SP1

## Deployment

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR083731 | All system-created temporary files are now removed when an auto-deployed application is removed while the Administration Server is down. The corresponding configuration and files are cleaned up the next time the Administration Server is started. | 8.1 SP1
CR091897 | Deployment failed for a Web application with a short name, such as `ab.war` or `i.war`. This error occurred: `java.lang.IllegalArgumentException: Prefix string too short at java.io.File.createTempFile(File.java:1232 at weblogic.j2ee.Component.retrieveComponent(Component.java:296 at weblogic.j2ee.Component.<init>(Component.java:188)at weblogic.j2ee.WebAppComponent.<init>(WebAppComponent.java:45 at weblogic.j2ee.Application.addComponent(Application.java:149) at weblogic.j2ee.J2EEService.addDeployment (J2EEService.java:117)...` The bug was corrected. | 6.1 SP5 8.1 SP1
CR099405 | Duplicate state transition messages were being logged during deployment operations. This problem was resolved with a code fix. | 8.1 SP1
CR101836 | A request to deactivate (undeploy) a non-existent JSP using `weblogic.Deployer` returned a message indicating the operation was successful, rather than returning an error. This problem was resolved by modifying the code so that an error message containing information about how to undeploy a single JSP is returned. | 8.1 SP1
CR104230 | Javadoc for the `weblogic.management.deploy.DeployerRuntime` class was modified to remove documentation for extraneous methods. | 8.1 SP1
CR104231 | Javadoc for the `DeployerRuntimeMBean` class did not mark deprecated methods. The following methods are now marked as deprecated: activate deactivate remove unprepare lookupActiveTargetsForComponent lookupActiveVirtualHostsFor lookupActiveServers | 8.1 SP1
CR104258 | If security constraints on a Web application were modified and the Redeploy button for that Web application (in the Administration Console) was clicked, old security constraints were not removed. Note: This problem did not occur when the Stop and Deploy buttons were clicked instead of the Redeploy button. This problem was resolved by ensuring that the appropriate methods are called to notify the WebLogic Security Service any time the deployment descriptors are read and security might change. | 8.1 SP1
CR108934 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. | 7.0 SP3 8.1 SP1

## EJB

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR069896 | Inside of a CMP deployment descriptor, if a weblogic-rdbms-relation contained two weblogic-relationship-roles with the same relationship-role-name, a NullPointerException could result when the EJB compiler was run. This problem was resolved by adding a compliance check to ensure that the relationship-role-names are unique within a weblogic-rdbms-relation. | 8.1 SP1
CR084768 | ejbc now logs a warning message when a field group or relationship cache was declared, but not associated with a finder (that is, never used). | 8.1 SP1
CR090104 | EJBs that specify an isolation level in their descriptor got an exception at runtime. There were two problems. One, WebLogic Server was checking for the wrong vendor workaround; it was checking for `supportsTxIsolation` instead of `supportsTxIsolationUponEnlistment`. Two, different database vendors and drivers have different rules/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/resuming the branch. Code changes rectified both the problems. | 7.0 SP3 8.1 SP1
CR091352 | `ejbc` code generation was failing for 4-level relationship caching, with the following exception: `Found 4 semantic errors compiling "D:/labs/cluster70/src/com/bea/ps/cmr_orders/ejbcgen/com/bea/ps/cmr_orders/CustomerBean_1q1rpd__WebLogic_CMP_RDBMS.java": 789. if (__WL_bean__orderLines != null) <-------------------> *** Error: No entity named "__WL_bean__orderLines" was found in this environment. 791. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** 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. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** Error: "__WL_bean__orderLines" is either a misplaced package name or a non-existent entity.` Analysis revealed that `RDBMSCodeGenerator.java` was trimming an extra character when creating the `prevCmrFieldName` string, when caching was more than 3 levels. A fix to `RDBMSCodeGenerator.java` solved the problem. | 7.0 SP3 8.1 SP1
CR092202 | WebLogic Server did not check that an Oracle sequence existed when a bean was deployed. This problem was resolved by adding the following behaviors: The create/alter feature works in non-production mode only. The container never drops a sequence. If the container creates a sequence, it leaves an indication that the sequence has been created. (The indicator has the format: `<sequence-name>_created_by_webLogic`). The container may only alter a sequence that has an indicator in the database. When deploying in development mode, the container looks for `<sequence-name>` and if found, uses that sequence. Otherwise, the container looks for `<sequence-name>_created_by_weblogic` indicator. | 8.1 SP1
CR094629 CR098386 | With a CMR one-to-one (created in the same transaction), a database `SELECT` is issued to ensure the database consistence. This database `SELECT` can be avoided in some cases, if the proper constraints are set on the database. This database `SELECT` is now avoided by modifying the code so that `__WL_CMR_isLoaded_` is set to true. This causes the database round-trip to be skipped when the bean state is `STATE_EJB_POSTCREATE`. Because this resolution causes the database check to be skipped, customers must be sure to create the database with the proper constraints. This resolution is limited to the case where a bean that has a 1 to 1 relationship with the current bean is being created in one of the bean's `ejbPostCreate` methods, and the CMR field in a bean's create method is implicitly set using a CMP field that is mapped to the same CMR field. For example, a parent's primary key is embedded as part of child's CMR field. If the CMR field setter is used, the container will still do the database `SELECT`. | 7.0 SP3 8.1 SP1
CR094871 | `O_ITEM table (ItemEnt)` caused a deadlock in SPECjAppServer. This deadlock only occurred with deployment descriptors that would be used for a single-server configuration, not for a multiple-server configuration. This deadlock was caused by different orderings of the primary keys in two different transactions for the SQL statement that was used for read verification (for the verify-rows feature). This problem was resolved with a code fix. | 8.1 SP1
CR095141 | 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. | 7.0 SP3 8.1 SP1
CR095173 | The `idle-timeout-seconds` element determines 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 to use 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`. In other words, they want 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 introduced the new element `session-timeout-seconds`, which specifies how long the EJB container waits before removing an idle stateful session bean from disk. This element is also available in WebLogic Server 8.1 Service Pack 1. | 7.0 SP3 8.1 SP1
CR096800 | When WebLogic Server 6.1 throws an EJB exception to a WebLogic Server 8.1 invoker, the invoker received a serialization error. This is because WebLogic Server 6.1 shipped with the wrong serial version unique identifier (SVUID) for `EJBException`. WebLogic Server 8.1 SP1 identifies when it is communicating with WebLogic Server 6.x and accepts and sends the incorrect SVUID over such connections. The earlier resolution attempt along these lines that shipped with 8.1 was flawed. | 7.0 SP3 8.1 SP1
CR097155 | There were several issues with the `default-dbms-tables-ddl` feature: It did not create the `ddl` file when the EJBCompiler was run It was not clear where the `ddl` file was placed once it was created If the `ddl` file already existed, it was modified These problems were resolved by modifying the code so that the `ddl` file is now created at compile time. A message indicates the location of the `ddl` file when it is written, and if the `ddl` file already exists, it is overwritten. | 8.1 SP1
CR098343 | JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute `KeepXAConnTillTxComplete` was set to `true`. This sequence of events led to the problem: 1. Start a user transaction on one server instance 1. 2. Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2. 3. Update an EJB on server instance 2. 4. Commit the transaction. No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the EJB connection pool. After repeating the sequence of steps several times, the connection pool ran out of connections. The problem did not occur if the actions were executed on a single server instance, or if the JMS message was placed in the queue outside the transaction scope. The problem was solved with a code change to release the connection in the `aftercompletion` callback. | 6.1 SP6 8.1 SP1
CR098548 | A compliance warning has been added indicating that corruption of a Blob Clob may occur if a bean is using optimistic concurrency, has any fields that are mapped to Blob/Clob DBMS columns, and no timestamp or version column has been specified. This warning also recommends the addition of a timestamp or version column. | 8.1 SP1
CR098798 | When the EJB compiler was unable find a method specified in a transaction attribute setting, isolation level setting, method permission setting or an idempotent method setting, the error message produced did not contain the particular EJB on which the method could not be found. The error message was augmented to contain this information. | 8.1 SP1
CR100010 | An expired `license.bea` file resulted in a `NullPointerException` when attempting to deploy an EJB, rather than an exception indicating a problem with the license. This problem was resolved by modifying the code so that no deployments can be attempted after failing the license check, and a message indicates a problem with the license. | 8.1 SP1
CR100719 | `Appc` previously did not take `alt-dd` descriptors into account when invoking the underlying module compilers. The module compilers now use `alt-dd` descriptors if they are defined in the `application.xml` descriptor of the EAR. Command-line options were also added to `appc` to support application-level `alt-dds`. | 8.1 SP1
CR100822 | 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. This has been augmented so that, 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. | 7.0 SP3 8.1 SP1
CR100890 | ejbc now recognizes EJB QL identifiers with acceptable UNICODE names. ejbc warns if any non-standard characters are used in an identifier but allows them to be used. Continued use of non-standard characters in an identifier may result in non-portable applications across J2EE containers. | 8.1 SP1
CR101248 | CMP beans were leaking JDBC connection pools. The problem was occurring 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. This resolved the problem. | 7.0 SP3 8.1 SP1
CR101446 | In some cases, the EJB compiler was generating an interface that illegally declared methods as final. This problem was resolved by modifying the code generator to not declare interface methods with a final modifier. | 8.1 SP1
CR102308 | The Administration Console reported incorrect values for waiters for entity beans. The problem was solved by adding a `waiterCurrentCount` attribute that is incremented when a client starts waiting for a lock, and decremented when the lock acquired or the client times out. | 6.1 SP6 8.1 SP1
CR102565 | An incorrect `javac` CLASSPATH may have caused compiler errors in `appc`. This problem was particularly likely if one version of an EJB class existed in the system CLASSPATH and a different version existed in the JAR file. This problem may also have affected compilers other than `appc`. This problem occurred because of an incorrect ordering of the JAR file in the system CLASSPATH for the `appc` invocation. This problem was resolved by modifying the code so that the CLASSPATH passed to `javac` lists the system CLASSPATH before the PATH to the JAR file being compiled. | 8.1 SP1
CR103108 | EJB runtime counts that were of type `long` were not being synchronized, resulting in corrupt and/or incorrect count results. This problem was resolved with a code fix. | 8.1 SP1
CR103226 | Relationship caching for CMP is now supported for SQLServer 2000. Using nested relationship caching in SPECjAppServer 2002 using SQL Server 2000 used to cause the following SQL Server 2002 error: `java.sql.SQLException: [BEA][SQLServer JDBC Driver][SQLServer]Query contains an outer-join request that is not permitted.` This problem was resolved by modifying the outer join syntax to handle multiple database types, and by adding a `<database-type`> tag to the `weblogic-rdbms-jar` file. This tag indicates the database type of the underlying DBMS. For SQL Server 2000, specify the `<database-type>` as SQLServer2000. Note: SQL Server 7 should be specified in the `<database-type>` tag as SQLServer. | 8.1 SP1
CR103393 | A bug in the CMP code generator sometimes resulted in generated code that would not compile when a CMP field was also a CMR field. In particular, an array was being accessed with an invalid index (the index was `null`). This problem was rare and only showed up when the EJB compiler was invoked. This problem was resolved by ensuring that the code generator always used a valid array index. | 8.1 SP1
CR103341 | New convenience functionality for CMP beans using Oracle sequences was added. The tag `<create-default-dbms-tables>` will now operate on Oracle sequences on systems that are being used in development mode. | 8.1 SP1
CR104046 | With `delay-database-insert-until` set to `Commit`, the Optimistic concurrency version column was not being 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. |
CR104256 | CMP Bean creation failed if any of the primary key field values were Java primitives and if any of these primitive key field values were set to a value equal to the default value for that field type. For example, if a bean had a primary key field of type Java primitive '`int`' and the value of the primary key field was '`0`', then CMP bean creation would fail. The CMP container now allows the setting of Java primitive default values for primary key fields to be recognized and for EJB creation to proceed. This fixes a bug in the container. No other side effects are expected. | 8.1 SP1
CR104610 | By default, `appc` would fork a new process for compiling. In some cases (large EARs, for example), this process required customers to allocate a lot of memory to the JVM heap to successfully compile, and sometimes a `java.lang.OutOfMemoryError` would occur anyway. This problem was resolved by adding an explicit `-J` option to the `wlappc` ant task's `runtimeFlags` option. Customers can now pass a memory size to the new process, such as `runtimeFlags="-J-ms64m -J-mx256m"`. Additionally, the default for `appc` was changed to "inline compilation". Therefore, `appc` will no longer fork a new process for compiling by default. For example, in WebLogic Server 8.1 GA: `<wlappc forceGeneration="true" compiler="javac" runtimeFlags="-ms64m" lineNumbers="true" verbose="true" debug="true" keepgenerated="true" source="${dist-dir}/ejb_${name}.jar"> <classpath refid="ejbc-classpath"/> </wlappc>` In 8.1 SP1: `<wlappc forceGeneration="true" compiler="javac" runtimeFlags="-J-ms64m" lineNumbers="true" verbose="true" debug="true" keepgenerated="true" source="${dist-dir}/ejb_${name}.jar"> <classpath refid="ejbc-classpath"/> </wlappc>` | 8.1 SP1
CR104979 | This change affects the following EJB callback methods on the following bean types: `ejbCreate`, `ejbRemove`—for stateless session beans and message driven beans. `ejbPassivate`—for stateful session beans when ejbPassivate is called due to a cache timeout. The security principal that is active when these methods are called will be `anonymous` except if any of the following are done: 1. For those beans which have a `run-as` role specified, a `run-as` principal has been designated according to the rules for designating a `run-as` principal. In these cases the `run-as` principal will be active. 2. If the bean is new for this service pack: `<create-as-principal-name>` or `<remove-as-principal-name>` or `<passivate-as-principal-name>` are specified for the corresponding EJB callback methods, then the specified principal is active during the EJB callback method. Note that principals specified using this method will take precedence over the more general `run-as` role principal assignment that is specified using (1) above. If any operations performed as part of these EJB callbacks require more permissions than `anonymous` would have, then an appropriate principal must be set using one of the methods (1) or (2) above. | 8.1 SP1
CR107455 | When read-only beans were used, `OutOfMemoryErrors` occurred. This problem occurred because multiple duplicate entries were being created for the same bean in the `lastLoadMap`. The duplicate entries were being created by an unnecessary call to `initLastLoad()` during `getBeanFromRS()`, even though `lastLoadMap` was already initialized by the call to `cache.get()`. This problem was resolved by removing the unnecessary call to `initLastLoad()`. | 8.1 SP1

## Installation

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR098373 | The WebLogic Server installer did not provide users with the ability to exit the installer when it was determined that the available space was not adequate for product installation. Instead, the installer only provided users with an option to specify another directory. This problem was resolved by providing an option for users to exit the installer when it was determined that the available space was not adequate for product installation. | 8.1 SP1
CR101452 | The name of the JDK directory was hardcoded in the `config.cmd` and `config.sh` scripts. This problem was resolved by replacing the hardcoded JDK directories to `%JAVA_HOME%\bin\java` and `%JAVA_HOME%\bin\javaw`. | 8.1 SP1

## Internationalization

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR099768 | If the catalogs listed on the command line do not have any translations, `l10ngen` exits abruptly but does not provide an error message indicating the reason. This problem was resolved by modifying the code so that if none of the catalogs have translations, a warning is issued. If any catalogs have translations, then the translations are processed, but no warnings are issued for those that do not have translations. | 8.1 SP1
CR102646 | When attempting to convert I18N message files to WebLogic Server message catalogs, the use of the `Loggable` class caused an error like the following to be written to the server log (rather than the appropriate message): `<Apr 1, 2003 1:31:35 PM PST> <Error> <Unknown> <000000> <Unable to access undefined message, id=900017>` This problem occurred because the `Loggable` class attempted to look up the message catalog class name based on the message ID, which would not work properly if there were issues with the classloader. This problem was resolved by modifying the code so that the message catalog class name is now passed into the constructor of the `Loggable` class. | 8.1 SP1
CR107052 | Internationalization characters in the InternalRequestDispatcher's response were garbled because the String content was created without the charset. This problem was resolved by creating the String with the appropriate charset, thus ensuring that the String appears in the correct encoding. The change should cause no side-effects. | 8.1 SP1

## J2EE

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR091939 | In `weblogic.Deployer`, an application would always use the deployment descriptor with which it was originally deployed. In other words, you could not change the deployment descriptor when the application was redeployed using the `-redeploy` flag. (You could only change the deployment descriptor if you first used the `-undeploy` flag.) This problem was resolved by modifying the code to allow the switching of deployment descriptors at update time. The behavior of the `-redeploy` flag now works the same way as an `-undeploy` followed by a `-redeploy`. | 8.1 SP1
CR096215 | Any war file containing a `WEB-INF/web-services.xml` deployment descriptor will now have its associated Web Services compliance checked when compiled by `appc`. This additional checking was added to help identify application errors more quickly during development. | 8.1 SP1
CR098671 | A split-directory EAR could not be deployed with a module-level `alt-dd` deployment descriptor. This problem was resolved by a code fix. For more information about using module-level alt-dd deployment descriptor, see the "Module" table under Application Deployment Descriptor Elements in Developing WebLogic Server Applications. | 8.1 SP1
CR101002 | When an EAR was deployed security roles defined in the `application.xml` file but with no corresponding `security-role-assignment` entries in `weblogic-application.xml`, these security roles were not visible from the WebLogic Server Administration Console when right-clicking the deployed enterprise application and selecting "Define Scoped Role...". This problem was resolved by modifying the code so that all security roles defined in `application.xml` are viewable in the Administration Console (even those without assignments in `weblogic-application.xml`). | 8.1 SP1
CR102293 | `wlcompile` supports a nested `javac` element that you can use to specify flags on `javac`. For example, you can specify deprecation warnings on `javac` as follows: `<wlcompile srcdir="${srcdir}" destdir="${destdir}">` `<javac deprecation="true" />` `</wlcompile>` | 8.1 SP1
CR102306 | The `wldeploy` command did not support application-level `alt-dd` deployer arguments. Attempts to use such arguments would result in a build failure. This problem was resolved by adding support to wldeploy for application-level `alt-dd` deployer arguments. This means that split-directory EARs can now be deployed with application-level `alt-dds`. | 8.1 SP1
CR105317 | When specifying preprocessor names on the command line as shown below, any spaces before or after the classname were interpreted as part of the classname, and therefore, an otherwise legitimate class would not be found. `-Dweblogic.classloader.preprocessor="com.dirig.preprocessor.DirigBEAClassProcessor, ppclass.MyPP1 ,ppclass.MyPP2 "` This problem was resolved by ensuring that any such spaces are not interpreted as part of the classname. | 8.1 SP1

## JDBC

####

Change Request Number | Description | Released Fixed
--- | --- | ---
CR090255 | Version 9.2.0.2 of the Oracle Thin driver, which shipped with the product, produced a `NullPointerException` when the `addBatch` and `setNull` methods required data conversions. This problem was resolved by updating the Oracle Thin driver to version 9.0.2.3. | 8.1 SP1
CR090365 CR090366 | Version 9.2 of the Oracle Thin driver, which shipped with the product, did not allow a BLOB and a long raw to coexist in the same table. The following exception would be encountered: `java.sql.SQLException: Protocol violation` This problem was resolved by updating the Oracle Thin driver to version 9.0.2.3. | 8.1 SP1
CR092453 | In WebLogic Server 6.1 SP04, with Oracle Thin XA with the `CLASSES12.zip` from Oracle 9.2, a stateless session bean calling EJB caused `XAER_PROTO` after "Configuration Changes saved to the repository" message appeared. `START SLEEP 2: After updating the value to 1... DONE SLEEP 2: After updating the value to 1... START SLEEP 2: After updating the value to 2... DONE SLEEP 2: After updating the value to 2... START SLEEP 2: After updating the value to 3... DONE SLEEP 2: After updating the value to 3... START SLEEP 2: After updating the value to 4... DONE SLEEP 2: After updating the value to 4... START SLEEP 2: After updating the value to 5... DONE SLEEP 2: After updating the value to 5... Current value is 5 <``Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0` The problem caused by a known problem in Oracle client 9.2.0.[01], that is solved in 9.2.0.2. WebLogic Server implemented a code change to work around the 9.2.0.[01] issue. | 6.1 SP5 8.1 SP1
CR094729 | 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. | 7.0 SP3 8.1 SP1
CR099872 | The message for the `Exception during commit of transaction` stack trace exception contained the connection pool name, but not the data source name. `<Exception during commit of transaction Xid=39:74a54046e2c2bb30(5962554),Status=Rolled back. [Reason=ja vax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the EnableTwoPhaseCommit property on the corresponding JDBCTxDataSource property, to true. Pool = CatPhase1] ...` The stack trace content was enhanced to include the name of the data source. | 6.1 SP6 8.1 SP1
CR100877 | The JTS driver attempted to create remote connections in single-server `SpecJAppServer` runs. This problem occurred only if a connection to the database for the transaction had already been opened, and the `getConnection` method was called again when the transaction timed out and was rolled back. In addition, this problem: Occurred infrequently. Resulted in no impact to the behavior of the application. Occurred as a result of a rollback race condition. Could have negatively impacted performance. This problem was resolved by modifying the code so that the transaction status is checked before a remote connection is made. | 8.1 SP1
CR101419 | Fail-over for DataSources and TxDataSources in a cluster was not working. This problem occurred because the DataSources and TxDataSources were not built as clusterable, and was resolved by building them as clusterable. | 8.1 SP1
CR101709 | DB vendors (such as Oracle) execute SQL DDL operations within a new local transaction. However, if the `AutoCommit` flag for the connection was set to false (as is the case when a connection is obtained from a WebLogic Server TxDataSource), the local transaction was not committed, and remained active on the connection. When running with the Oracle 9.2.0 Thin driver, subsequent XA operations performed on this connection failed with an XAER_PROTO, due to the currently active local transaction. This is because starting with this version, Oracle Thin driver started checking for active local transactions when asked to perform XA operations on connection objects. WebLogic Server can now circumvent this problem by rolling back any active local transactions on a connection when it is being returned back to the WebLogic Server JDBC connection pool. This defensive behavior can be enabled by setting the new WebLogic Server JDBC connection pool attribute `RollbackLocalTxUponConnClose` to true. | 8.1 SP1
CR101822 | Setting the isolation level to Connection.TRANSACTION_READ_COMMITTED for Oracle Thin Driver failed, with an exception indicating that the Isolation Level "2" could not be mapped. This isolation level is now properly recognized and passed to the Oracle driver. | 8.1 SP1
CR102364 | Clicking the Test Pool button on the Testing tab in the Administration Console after creating an Informix JDBC connection pool might have resulted in the following errors: `<Error> <JDBC> <BEA-001112> <Test "select count(*) from ITEMS" set up for pool "informixPool" failed with exception: "java.sql.SQLException: Database not selected yet.".>` `<Error> <JDBC> <BEA-001111> <Unable to verify the test "select count(*) from ITEMS" set up for pool "informixPool". Connections will not be tested.>` Note: This problem only occurred for some Informix configurations. This problem was resolved by modifying the code so that the configuration works properly for Informix JDBC connection pools. | 8.1 SP1
CR102698 | Attempts to create a connection pool with `weblogic.Admin CREATE_POOL` resulted in the following exception: `./wlg-create-pool.sh 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;Lweblogic.se curity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at ...` Research revealed that WebLogic Server was requiring `aclName`—which is deprecated—as an attribute. A code fix resolved the problem. | 7.0 SP3 8.1 SP1
CR103321 | The `getConnectionsTotalCount()` method of `JDBCConnectionPoolRuntimeMBean` did not behave as expected. Instead of returning the total number of JDBC connections in the pool since instantiation, it returned the maximum number of connections since instantiation. The problem was resolved with a code fix in the method. | 8.1 SP1
CR104103 | RowSets failed to serialize a CLOB column to XML, resulting in an exception similar to the following: `java.io.IOException: No XML Schema type mapping found for JDBC type: 2005` This problem was resolved by modifying the code so that a CLOB is appropriately mapped to an XML schema type. | 8.1 SP1
CR104522 | The `CachedRow.containsKey(Object)` method always returned an inverted value. This problem was resolved with a code fix. | 8.1 SP1
CR104523 | `DatabaseMetaData.getDriverVersion()` was returning an outdated version string. A code fix resolved the problem. | 7.0 SP3 8.1 SP1
CR107609 | If a RowSet had to look up the DataSource itself (instead of it being set from outside), an application was forced to set the username and password. This was due to a problem in the cleanup processing for RowSets. The security check that occurs when JNDI credentials are used reduced performance by about 40% in some cases. This problem was resolved by fixing the problem in the cleanup processing. | 8.1 SP1
CR108006 | When multiple transactional (JTS) JDBC connections were used in a remote application during a single transaction, a `NullPointerException` could be seen on the remote client if any of the connections were closed and any other connections were used after that. This problem occurred because, while all RMI connections in the same JTS transaction must actually represent the same underlying JTS connection, a mistaken optimization was added, which supplied the same RMI connection for multiple connection requests within a transaction. Closing any one of these would also close what the application thought was any other, supposedly independent one. The solution was to remove the optimization, and to always return distinct RMI connections to separate remote connection requests within a given JTS transaction. | 8.1 SP1

## JMS

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR097038 CR102656 | When a source JMS bridge destination was not running in the same WebLogic Server 8.1 domain as the Message Bridge, then a trusted security relationship must have be established between the domains. Otherwise, the Messaging Bridge must have been configured to work in synchronous mode (Asynchronous Mode Enabled = No). This problem has been resolved so that non-trusted domains also work when using asynchronous mode communications. | 7.0 SP3 8.1 SP1
CR098280 | 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 will be 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 will 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 will honor the user-specified acknowledge mode, but it will ignore the transacted flag since the resulting session supports XA. Note that in previous versions of WebLogic Server, 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. | 7.0 SP3 8.1 SP1
CR098975 | WebLogic Server sometimes failed to boot after you undeployed a distributed destination. This occurred when you deleted the distributed members and the distributed destination itself, but did not delete the underlying physical destinations. The following sequence of Administration Console actions caused this problem: 1. In the Configuration -> Members tab of a distributed destination, click the trash can icon to remove a member. 2. When prompted, do not delete the member's underlying physical destination. 3. Click Remove to delete the member. 4. If necessary, continue deleting all the members of the distributed destination. 5. Delete the distributed destination. If you had shut down the server at this point, you would not be able to reboot it. The problem was resolved by creating a JMS template for distributed destinations at the domain level. This prevents the template from being deleted when a user deletes a distributed destination member but does not delete the underlying physical destination represented by the member. This way, when WebLogic Server boots, the JMS template that the physical destination is referencing still exists so the boot does not fail. | 8.1 SP1
CR100663 | A new debug flag "`DebugJMSMessagePath`" was added to trace the JMS message in the server and more debugging messages were added. When the new `DebugJMSMessagePath` flag is turned on, the JMS message inside the server is tracked and a debug message is logged informing the message's path along with the `JMSMessageID`, if available. This flag can be turned in two ways as shown below: In the config.xml: `<ServerDebug Server="name of the server" DebugJMSMessagePath="true" />` In the server startup command-line as: `-Dweblogic.Debug.DebugJMSMessagePath=true` | 8.1 SP1
CR101076 | The messaging bridge was enhanced to log all JMS header attributes when `-Dweblogic.Debug.DebugMessagingBridgeRuntime` is set to true. | 8.1 SP1
CR101298 | If a long idle JMS JDBC connection was marked as "bad" (when for example, if a firewall time-to-live expires) JMS attempted to use the now bad connection, and would fail. 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 5 minutes to maintain the connection. | 7.0 SP3 8.1 SP1
CR101585 | A JMS Client Session that was never committed or acknowledged would result in a memory leak. This problem was resolved by properly handling rollback and recovery when unacknowledged messages exist. | 8.1 SP1
CR101594 | When the WebLogic Server licence file did not include a license for JMS and a JMS Server was configured and targeted to a WebLogic Server instance, the server booted without the JMS Server, but did not indicate the reason for the JMS Server's failure to start in the server log file. This problem was resolved by logging an error in this case. | 8.1 SP1
CR101804 | When undeploying a JMS server by setting the JMS server's target to "none" in the Administration Console, redeploying the JMS server by setting its target back to the original WebLogic server instance resulted in a `NullPointerException`, and the redeploy failed. This problem was more likely to have occurred when JMS templates were used. This problem was resolved. | 8.1 SP1
CR102234 | ASSERTION FAILED messages were printed to the bridge server log when a server was killed. This problem occurred because the bridge adapter code closed both the source connection and the target connection, when one of these connections may already have been destroyed and removed from the pool. This problem was resolved by modifying the bridge adapter code so that it does not attempt to close a bad connection. | 8.1 SP1
CR102284 | The performance of the JMSHelper extension methods was improved. | 8.1 SP1
CR102649 | Errors [J2EE:160054] and [J2EE:160062] frequently occurred in the case that an application was using JMS connection pooling, where the session was opened in `ejbCreate()` and closed in `ejbRemove()`. This problem occurred because the EJB was returned to the pool before the transaction was complete, and the JMS session was still associated with the old transaction. This problem was resolved. | 8.1 SP1
CR102656 | Using a messaging bridge for asynchronous messages between non-trusted domains resulted in security error messages. The code was changed to handle message passing between the domains with allowable security credentials in this case. | 8.1 SP1
CR102749 | JMS JDBC stores may have deleted durable subscriptions over time. If a durable subscription record was accidentally deleted, its associated messages were also deleted on the next reboot of WebLogic Server. This problem was fixed by keeping track of handles for durable subscriptions so that wrapping handle values would not re-use an existing handle. | 8.1 SP1
CR103375 | Shutting down a server resulted in the following exception: `weblogic.jms.common.JMSException: Failed to remove temporary destination because JMSServer is shutdown or suspended ...` This problem occurred because attempts to remove temporary destinations are made while the server is in the shutting down state, and therefore these attempts cannot be completed. This problem was resolved by modifying the code so that a `JMSException` is not thrown when attempts to remove a temporary destination are made during a server shutdown, and the temporary destinations are successfully removed. | 8.1 SP1
CR105337 | 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(BEConsumer.java:1620) at weblogic.jms.backend.BEXATranEntryBlockingConsumer.startRollback(BEXATranEntryBlockingConsumer.java:72) at weblogic.jms.backend.BEXAResource.rollback(BEXAResource.java:1205) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:1400) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:664) at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:365) at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.java:1521) at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.java:2142) at weblogic.transaction.internal.TransactionImpl$1.execute(TransactionImpl.java:1656) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:211) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:198) weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.rollbackAfterRecover(FESession.java:1773) at weblogic.jms.frontend.FESession.recover(FESession.java:1373) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) at com.ncr.crm.framework.jms.DemoMessageConsumer.run(JmsMemoryLeakDemo.java:163) at java.lang.Thread.run(Thread.java:479) ----------- Linked Exception ----------- weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.recover(FESession.java:1219) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) 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. | 7.0 SP3 8.1 SP1
CR105403 | When trying to deploy an MDB on a stand-alone server, deployment fails if the license does not have the "Clustered JMS" component. License checking has been corrected. | 8.1 SP1

## JNDI

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR091837 | Some customers had problems with the amount of time RMI stubs took to failover, if the destination server became unavailable. This amount of time varied with the operating system and the operating system version. This problem occurred because the socket creation from a client was taking too long to fail. This problem was resolved by providing the `-Dweblogic.client.socket.ConnectTimeout` flag, which sets the `Socket.connect()` method timeout in seconds. | 8.1 SP1
CR101433 | A deadlock occurred in the serialization of JNDI results. This problem occurred because the hashtable containing environment arguments (which is used to create the initial context) was being shared by different threads. This problem was resolved by using a workaround for a Sun bug, which involved cloning the hashtable containing environment arguments so that the hashtable is not shared by different threads. | 8.1 SP1
CR103711 | When one-phase deployment was used for an application, all `ejb-ref` lookups from within that application were resulting in a JNDI lookup. To improve performance, the `ejb-ref` values are now cached. | 8.1 SP1
CR105462 | When obtaining a new initial context via WLInitialContextFactory and then closing it repeatedly, a memory leak occurred in the JNDI client, and an Out of Memory exception was thrown. This problem occurred because the `TransactionHelper` class has a stack of `TransactionHelperImpl` objects. Objects were pushed into the stack when creating new contexts, but were not popped when the context was closed. This problem was resolved by modifying the code to pop the objects from the `TransactionHelper` when a context is closed. | 8.1 SP1

## JTA

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR097013 | 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. | 7.0 SP3 8.1 SP1
CR099830 | 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: java.net.ConnectException: 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 has been cleared, then 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. | 7.0 SP3 8.1 SP1
CR102358 | The following debug message was printed continuously every 5 seconds when JTARecovery debug was turned on: `<Mar 29, 2003 1:09:15 PM EST> <Debug> <JTA> <BEA-110027> <ResourceDescriptor[JMSConnectionPool]: checkRecovery: >` This message is no longer printed. | 8.1 SP1
CR102400 | The transaction manager could generate a `NullPointerException` when trying to contact a remote server that is unavailable. This problem was resolved by a code change. | 8.1 SP1
CR102738 | An internal API, which was causing a ServerMBean lookup to fail, was changed. This change caused the Transaction recovery process to not recognize changes in a server's listen address. This problem was fixed. Additionally, code was added to ensure that asynchronous retries are attempted until new server information is obtained from the Administration Server. This ensures that the Transaction recovery process completes when the sub-coordinator server comes back up, without having to restart the coordinating server. | 7.0 SP3 8.1 SP1
CR103556 | When a `jndi.properties` file existed in the classpath that had a server URL pointing to a different server than the server being booted, a `javax.naming.NameAlreadyBoundException` was thrown when the transaction manager attempted to bind its `TransactionManager` object into the local JNDI tree. The exception was thrown because the bind operation was performed on the remote server's JNDI context in which a `TransactionManager` object already existed. This problem was resolved by a code change to ignore the `jndi.properties` file while binding objects into the local JNDI tree. | 8.1 SP1
CR103601 | If an object passed in the "equals" method of `weblogic.transaction.internal.XidImpl` was not an instance of `XidImpl` (for instance, it was of type `String`), then this exception is thrown: `java.lang.ClassCastException: java.lang.String at weblogic.transaction.internal.XidImpl.equals(XidImpl.java:114) at test.main(test.java:9)` The problem was solved with a code fix to check and report type mismatches. | 6.1 SP6 8.1 SP1
CR106174 | 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 TM was unnecessarily writing a commit record for this scenario. The code was changed so that, before writing a log record, it checks to see how many participants require 2nd phase; if one does, the write is skipped. This resolved the problem. | 7.0 SP3 8.1 SP1
CR106177 | 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. | 7.0 SP3 8.1 SP1

## JVM

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR101608 | The JVM has a bug whereby it is possible for it to crash while reading an FVD-described class under IIOP. This problem was made worse by a bug in WebLogic Server, whereby it was possible to trivially provoke the problem. This CR refers to the WebLogic bug so that it is no longer trivially possible to cause this crash. However, the bug in the JVM still exists and is only fixed in J2SE 1.4.1_03 (and 1.3.1_09). BEA recommends upgrading to 1.4.1_03 when it becomes available. | 8.1
CR105703 | Starting in WebLogic Server 8.1, jDriver makes a new JDK 1.4 feature, `ByteBuffer`, to improve performance. `java.nio.charset.CharsetDecoder` is also used to decode the bytes in `ByteBuffer` that are returned from an Oracle server. Unfortunately, `CharsetDecoder` does not properly decode single byte data. This problem was resolved by adding more international codesets to work around this JDK bug. The codesets include: `Shift_JIS, SJIS, windows-31j, MS932, EUC_JP, EUC-JP, ISO-2022-JP, ISO2022JP, EUC_KR, EUC-KR, windows-949, MS949, EUC_CN, EUC-CN, windows-936 MS936, GBK, Big5, windows-950, MS950, Big5_HKSCS, Big5-HKSCS` These names are based on JDK 1.4 internationalization. | 8.1 SP1

## Localization

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR108583 | The `messageid="DefaultMigratableSuffix"` of `ja/JP/ManagementText.xml` was translated to a Japanese String, resulting in an inability for customers to delete a server that was created with the Configuration Wizard. This problem occurred because this String, which is used in a String comparison, should not have been translated in the catalog. This problem was resolved by removing the Japanese translation of the String. | 8.1 SP1

## Node Manager

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR093664 | The comment at the beginning of `nodemanager.properties` that documents the syntax of this file only included SSL configuration information. It now includes descriptions for other commonly used properties. | 8.1 SP1

## Plug-Ins

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR096625 | The Apache plug-in sent a `X_WEBLOGIC_FORCE_JVMID` header to a WebLogic Server instance in a cluster. However, `X_WEBLOGIC_FORCE_JVMID` should only be sent when the server list is non-clustered and the current server does not yet have a JVM ID. This problem was resolved by modifying the code so that `X_WEBLOGIC_FORCE_JVMID` is only sent when the server list is non-clustered and the current server does not yet have a JVM ID. | 7.0 SP3 8.1 SP1
CR097202 CR103161 | 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: (Integer)httpRequest.getAttribute("javax.servlet. request.key-size") 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(). | 6.1 SP5 8.1 SP1
CR100361 | The `READ_ERROR` exception did not differentiate between reading from a client and reading from a back-end server. (In contrast, there were two different `WRITE_ERROR` exceptions: `WRITE_ERROR_TO_CLIENT` and `WRITE_ERROR_TO_SERVER`.) This problem was resolved by introducing the following new exception types: `READ_ERROR_FROM_CLIENT—`error when reading data from client `READ_ERROR_FROM_SERVER—`error when reading data from backend server `READ_ERROR_FROM_FILE—`error when reading from temporary file which stores post data `WRITE_ERROR_TO_FILE—`error when writing post data to the temporary file | 6.1 SP5 8.1 SP1
CR101222 | After fail-over from a primary server to a secondary server for NSAPI and Apache did not recover the failed primary server after the time specified in `MaxSkipTime` had elapsed. This problem occurred because the bad primary server had not been reset. This problem was resolved by resetting the primary server after the `MaxSkipTime` had elapsed. | 8.1 SP1
CR101596 | 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`). | 6.1 SP5 8.1 SP1
CR102616 | 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'. | 7.0 SP3 8.1 SP1

## RMI/RMI-IIOP

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR095810 | You could not use callbacks through a firewall when using the thin client `.jar` files (`wlclient.jar` and `wljmsclient.jar`) and IIOP or IIOPS. Callbacks did work when using tunneling. Since Bi-Directional IIOP was already supported in the thin-client when tunneling was used, this problem was resolved by generalizing the code so that BiDir could be used with standard IIOP as well as over HTTP. | 8.1 SP1
CR097787 | Although thin-client IIOP implemented an asynchronous "PeerGone" mechanism, this mechanism did not wakeup pending requests with an exception when a network partition occurred. This problem was resolved by modifying the code so that when BiDir is used, the "PeerGone" mechanism signals an exception on the socket. | 8.1 SP1
CR101776 | There were no dynamic debug flags for thin clients. This problem was resolved by adding the following debug flags for thin clients: `-Dweblogic.debug.client.iiop=true` `-Dweblogic.debug.client.startup=true` `-Dweblogic.debug.client.http=true` `-Dweblogic.debug.client.security=true` `-Dweblogic.debug.client.ots=true` `-Dweblogic.debug.client.cluster=true` `-Dweblogic.debug.client.ssl=true` `-Dweblogic.debug.client.dgc=true` | 8.1 SP1
CR102875 | When attempting to deploy from ant (`wldeploy`) on a WebLogic Server instance using the IIOP protocol, the server produced a `NullPointerException` in `weblogic.corba.utils.MarshaledString`. This problem occurred because WebLogic was erroneously returning null when retrieving a repository ID from a stub that had been cached by a previous lookup. This problem was resolved by initializing the type ID to the result of the `info.getRepositoryId` method in cases where the type ID is null. | 8.1 SP1
CR103388 | WebLogic RMI now supports arrays of primitives. | 7.0 SP3 8.1 SP1
CR105892 | 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. | 8.1 SP1
CR106521 | Customer could not pass Any's containing enums to or from CORBA servers. This problem was resolved by fixing the marshaling of enums inside Any's. | 8.1 SP1
CR106750 | Client-server applications with clients connecting to WebLogic Server over IIOP and invoking server-side logic through EJBs may have experienced intermittent IIOP errors. Specifically, these were CORBA/IIOP MARSHAL and indirection errors in the `read_value()` method during thin client access. This problem was resolved with a code fix. | 8.1 SP1
CR108332 | When using a thin client (`wlclient.jar`), customers may have encountered a marshalling exception that indicated there had been 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. | 8.1 SP1
CR109032 | Accessors with checked exceptions were not mapped properly in the IDL, resulting in the wrong IDL being generated. This problem was resolved by modifying the IIOP name mangling code so that it now checks whether accessors (`getFoo()`) and mutators (`setFoo()`) throw checked exceptions. If they do, then they are not mangled to IDL attributes (that is, just treated as standard functions). | 8.1 SP1

## Security

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR097038 CR102656 | When using the Messaging Bridge, non-trusted domains only worked when using synchronous mode communications. This problem has been resolved so that non-trusted domains also work when using asynchronous mode communications. | 7.0 SP3 8.1 SP1
CR098843 | The `weblogic.management.runtime.ExecuteThread.getUser` method always returned `null`. This problem occurred because there was no way to obtain the current user for a given thread, and was resolved by adding code that does this. | 8.1 SP1
CR100783 | The ImportPrivateKey utility produced the following message when the wrong private key password was entered: `ASN.1: Lengths longer than 32 bits are not supported`. That is, rather than indicating a problem with the password, the error message described a problem with the key length. This problem was resolved by modifying the error message to be more appropriate. | 8.1 SP1
CR101531 | The memory usage of the Embedded LDAP server was reduced by decreasing the size of a buffer used for logging. This reduced the total memory usage by 1.8 million bytes. | 8.1 SP1
CR101770 | The SSL Login Timeout attribute was unintentionally dropped from the WebLogic Server Administration Console. Support for the attribute was added back into the Administration Console. | 8.1 SP1
CR101785 | A `UsernamePasswordLoginModule` LoginModule was added for use by the IIOP thin-client. This class has the same API as that of the `weblogic.security.auth.login.UsernamePasswordLoginModule` class, but in this implementation, there is a new property called `authOnLogin`. When true, this property forces the `login` method to perform authentication (rather than on the first invocation). The default for this new property is false. | 8.1 SP1
CR102164 | The MBean implementations for the WebLogic Authentication provider and LDAP Authentication providers threw a `weblogic.management.utils.InvalidPasswordException` if the password was not valid. This behavior was inconsistent with the `weblogic.management.security.authentication.UserPasswordEditor`'s `changeUserPassword` and `resetUserPassword` methods, which do not declare a `InvalidPasswordException` exception. This problem was resolved by removing the `weblogic.management.utils.InvalidPasswordException` and changing the Authentication providers' MBean implementations to throw a `weblogic.management.InvalidParameterException` when a password is not valid. | 8.1 SP1
CR102221 | The SSL `closeWriteHandler` method produced an `IOException` when the output stream had already been closed by an application. This problem occurred because the `closeWriteHandler` method did not check whether the `WriteHandler` was already closed, and attempted to write an alert to the output stream. This problem was resolved by adding this check. | 8.1 SP1
CR102251 | In 6.x, the t3 protocol sends authenticated user object between clients and servers. In 7.x and higher, the t3 protocol sends authenticated subject object (which extends the authenticated user object) between clients and servers. When a 7.x server communicates with a 6.x client, it converts any authenticated subjects back to authenticated users before sending them to a client. If the client was communicating with both 8.1 servers and 6.1 servers, it received an authenticated user when it created a context to a 6.x server. When it created a context to a 8.x server, it received an authenticated subject. Depending upon which context was created last, an authenticated subject or authenticated user would be sent to the client. If the context to the 8.1 server was created last, then the client identity was an authenticated subject, which would be passed to both the 6.1 and 8.1 servers. When the authenticated subject was passed to the 6.x server, the 8.1 client attempted to convert it into an authenticated user. The code to do this was only intended to be used on the server-side, so it was failing with an exception that eventually caused an assertion failure. When run with a 6.1 client, things worked correctly, as the client always received an authenticated user. This problem was resolved by modifying the code so that conversions from an authenticated subject to an authenticated user can be called on the client side. | 8.1 SP1
CR102443 | Attempts to use one Weblogic Server instance as a LDAP server to another WebLogic Server instance that had a LDAP Authentication provider configured failed. The server acting as the LDAP server threw a `NullPointerException`, while the server configured to use external LDAP hung. This problem was occurred because user and group DNs did not match the hierarchy in the embedded LDAP server for the other domain. This problem was resolved by modifying the code so that an informative error is returned when the credentials supplied are invalid. | 8.1 SP1
CR104191 | `URLResource` converted the context path to lowercase on Windows systems, causing a case mismatch between the context path used by Web applications and the WebLogic Security Framework when re-deploying a Web application with security constraints. As a result, security constraints that were removed from the Administration Server were not be propagated to the Managed Servers in the domain. This problem was resolved by adding a verification to ensure that the case of both context paths match. | 8.1 SP1
CR104502 | `utils.der2pem` wrote out an extra new line if the number of characters was an exact multiple of the line width, resulting in an invalid `.pem` file. This problem has been resolved. | 8.1 SP1
CR104713 | When a WebLogic Server instance was configured for two-way SSL and a WebLogic Identity Assertion provider was configured with the `AuthenticatedUser X.509` token type, a `ClassCastException` was thrown while the server was authenticating the client connecting over SSL. This exception indicated that there was a problem with `DefaultIdentityAsserterProviderImpl` (the Weblogic Identity Assertion provider). This problem occurred because a token of the wrong type was being passed to the WebLogic Identity Assertion provider. This problem was resolved by ensuring that an array of certificates is passed to the WebLogic Identity Assertion provider. | 8.1 SP1
CR105809 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-33.jsp. | 7.0 SP3 8.1 SP1
CR106027 | When logging into the Administration Console as a `Monitor`, a user could still have access to the 'Configure new Application' screen. This constituted a security hole, because it allowed a monitor to upload a file to any place the WebLogic server can see. The problem was resolved with a code fix. | 7.0 SP3 8.1 SP1
CR108958 | Currently WebLogic Server allows a JCE provider to be configured and used for SSL unless it is determined that the JCE provider is not working with Certicom. If the latter is the case, WebLogic Server adds it to the list of JCE providers known to cause problems. When Certicom discovers that the installed JCE provider is in this list, it ignores it and uses the Jsafe implementation instead. The IBM JCE provider has been added to this list, so it is now ignored by the Certicom SSL implementation, but is still available for other applications. | 8.1 SP1

## Servlets & JSPs

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR088670 | When returning a license error, WebLogic Server produces a 403 page that explains the problem. However, this message has a content-type of `x-weblogic/internal`, when it should have a content-type of `text/html`. This caused an "open with application or download file" prompt on Mozilla. This problem was resolved by modifying the content-type to be `text/html`. | 8.1 SP1
CR092778 | When using JISAutoDetect encoding (which is used to accept Shift-JIS, EUC-JP and ISO-2022-JP for input streams without code/configuration modification) with an HTTP request, an `UnsupportedEncodingException` was thrown, starting with the following lines: `java.io.UnsupportedEncodingException: JISAutoDetect at sun.io.Converters.getConverterClass(Converters.java:102) at sun.io.Converters.newConverter(Converters.java:133) at sun.io.CharToByteConverter.getConverter(CharToByteConverter.java:62) at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding(ServletRequestImpl.java:344)` `...` This problem occurred when a JSP/servlet called `request.setCharacterEncoding("JISAutoDetect")`. This problem was caused because `ServletRequestImpl.java` used `sun.io.CharToByteConverter`, instead of `sun.io.ByteToCharConverter`. `CharToByteConverter` is for an output converter, while JISAutoDetect is only available for an input stream. This problem was resolved by changing to `ByteToCharConverter`, which accepts JISAutoDetect. | 6.1 SP5 8.1 SP1
CR093209 | A new installation of WebLogic Server threw a `NullPointerException` when a successfully deployed Web application with a property set to java protocol was accessed. The browser returned `Error 500--Internal Server Error`. The problem did not occur with an upgrade installation. `<Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP> <[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with Exception java.lang.NullPointerException at weblogic.servlet.JSPServlet.service(JSPServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCon ext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:235) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)>` Analysis revealed an error in `ZipSource.getURL()`. The problem was resolved by adding logic to check for a null value of `source.getURL()`. | 6.1 SP5 8.1 SP1
CR093625 | In WebLogic Server 6.1 SP3 and SP4, servers misdirected output for JSP includes in JSP pages. The problem was resolved with changes to the servlet engine to unify handling of includes, forwards, wrapped-responses, and JSP BodyTags. | 6.1 SP5 8.1 SP1
CR094190 | According to the JVM specification, the size limit for a method is 64K. Some WebLogic Server customers have 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 `StandardTagLib.java`. This tricks the `BodyTag` into thinking it is being invoked as usual from the JSP source. | 6.1 SP5 8.1 SP1
CR094488 | A new capability was added to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add `AuthCookieEnabled="true"` to the `WebServer` element in `config.xml`: `<WebServer Name="myserver" AuthCookieEnabled="true"/>` This will cause an new secure cookie to be sent to the browser when authenticating via an HTTPS connection. Once set, the session can access other security-constrained HTTPS resources only if the cookie is sent from the browser. Note: If authenticating via plain HTTP, the secure cookie will not be set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie will not be verified (since it will not have been sent from the browser). This allows the browser to access non-protected HTTPs resources without the user logging in. | 6.1 SP5 8.1 SP1
CR095981 | `<charset-mapping>` in `weblogic.xml` was ignored when compiling JSP files with `precompile=true`. As a result, some of double byte characters were garbled because of the mismatch between the character's encoding specified in `<charset-mapping>` and in the compiled classes. Analysis revealed an error in the precompiler. The problem was solved with a code fix. | 6.1 SP6 8.1 SP1
CR097719 | In WebLogic Server SP02, SP03, and SP04, when getting certain POST requests from WAP devices, a Web application encountered a `java.util.ConcurrentModificationException`: `<29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at weblogic.utils.enumerations.IteratorEnumerator.nextElement(IteratorEnumerator.java:25) at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML(XMLSwitch.java:347) at ...` Analysis revealed that when a charset is associated with the request's `content-type`, the code read the data again using the encoding, and reset the query parameters, in the application. The application already has the enumeration object and iterates it (`request.getParameterNames`), and then tries to get the value of the parameter (`request.getParameterValues(k)`). At that point, the query parameters are wiped out and `getParameterValues` method tries to set it, resulting in the exception. The problem was resolved by a code change to set query parameters after they are wiped, so that the data can be read again when a charset is associated with the request's content-type. | 8.1 SP1 6.1 SP5
CR097759 | There was no timestamp associated with VM thread dumps. This problem was resolved by modifying the code so that a message of the following format is printed before a VM thread dump (applies only to thread dumps taken with the `weblogic.Admin` thread dump command): `THREAD DUMP from JVM taken at 'Mon Mar 24 16:26:13 2003'` | 8.1 SP1
CR098955 | If `logRotationBeginTime` was a past date and the interval between `logRotationBeginTime` and today's date was large, calculation of the rotation time was flawed, due to improper casts of long to int. This has now been resolved. | 5.1 SP14 8.1 SP1
CR100068 CR110324 | You could not use JSTL tags in JSPs that included Japanese characters. When the JSP was executed, an error starting with the following lines would occur: `java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x82) was found in the CDATA section."` ... This problem occurred because of the following, conflicting conditions: 1. The page encoding of JSPs is defined by `Shift_JIS,` as in: `<%@ page pageEncoding="Shift_JIS" %>` 2. Using multibyte characters (Japanese) in JSPs. 3. Using JSTL tags. This problem was resolved by modifying the encoding of the byte stream returned from the `weblogic.servlet.jsp.StandardTagLib.makeXMLStream` method to UTF-8. | 7.0 SP3 8.1 SP1
CR100172 | When multiple chunked requests were posted to a servlet, a number of the requests failed with a `NumberFormationException`, starting with the following lines: `<ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException:` `...` This problem occurred because the code incorrectly attempted to detect the end of the chunk at the wrong place. This problem was resolved by modifying the code so that it reads until the end of the stream, and detects the end of the chunk correctly. | 7.0 SP3 8.1 SP1
CR100188 | The `AuthCookie` feature did not work for certificate authentication. (`AuthCookie` is a secure cookie used to make HTTP to HTTPS transitions secure.) This capability was added in WebLogic Server 6.1 SP5 to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. This problem was resolved with a code fix. | 8.1 SP1
CR100260 | When an HTTP request was proxied by a WebLogic proxy to a cluster using the non-default network channel, the cluster list returned was with respect to the default channel. Thereafter, the plug-in started proxying to the default channel, instead of the original network channel, which may not have been reachable. This problem was resolved by modifying the code so that the dynamic server list is aware of non-default network channels. | 8.1 SP1
CR100570 | While saving changes for `weblogic.xml` from WebLogic Builder, it created extraneous entries in the `weblogic.xml` file for the deployment descriptor MBeans. The extra entries were defaults and did not need to be added to the `weblogic.xml` file. This problem was resolved by modifying the code so that the entries are only written to the `weblogic.xml` file if the default values have been changed. | 8.1 SP1
CR101996 | Use of `xmlx` tags with request and response wrappers resulted in `ClassCastExceptions` since the tags internally cast to the internal request and response implementations. This problem was resolved by unwrapping the request and response instances to the original internal representation. Use of the `xmlx` tag may have also produced an `IllegalStateException` indicating that an attempt was made to use `getWriter` after `getOutputStream`. This problem was resolved by modifying the code to appropriately reset the output state prior to calling `getOutputStream`. | 8.1 SP1
CR102057 | Including a static resource in a request with no buffer size (for example, `response.setBufferSize(0)`) could lead to an infinite loop. This problem was resolved by guarding against this case. | 8.1 SP1
CR102062 | The `ServletContext.getResourcePaths` method returned incorrect results when called in a WAR file, and in the case of split-directory deployments, the `Set` returned by this method only contained the results from the `srcdir` (it did not contain the results from the `outputdir`). This problem was resolved by a code fix. | 8.1 SP1
CR102077 | `weblogic.servlets.internal.InternalRequestDispatcher` throws a `StringIndexOutOfBoundsException` if given a URI whose length is 0 (for example, an empty HTML file). This problem was resolved by guarding against this condition. | 8.1 SP1
CR102499 | If an attribute was added to the request using the Web application classloader and if the request gets delegated to a child classloader of the Web application's classloader, upon `request.getAttribute()`, the Web application container was trying to deserialize the attribute in order to avoid a `ClassCastException`. This was resulting in Serialization errors. The Web application container code will now be able to detect that the class was loaded by a parent classloader. If true, it will not deserialize. However, if the child places attributes into the request using `setAttribute()`, this will not work if the class or references within are child scoped only, or the class or references within are not serializable. You can workaround the second problem by pushing and popping the Web application classloader temporarily for `setAttributes()` in the child classloader. | 8.1 SP1
CR102667 | A `NullPointerException` was thrown by a Web application module if the context with the same name was previously deployed using the old deployment model (6.x deployment model). This problem was resolved by ensuring that if present, the old deployment model is handled correctly. | 8.1 SP1
CR102763 | ExternalDNSName is deprecated for Network Channels (not servers). Customers should make use of the new Public Address for channels, when a firewall is between a proxy Web server and a cluster. Additionally, customers should use paired channels for HTTP and HTTPS. More information is available in the Firewall Between Proxy Layer and Cluster section of Using WebLogic Server Clusters. | 8.1 SP1
CR103059 | A `<url-pattern>` value with a single character in a `<servlet-mapping>` element was not honored in a web.xml deployment descriptor. For example, `<url-pattern>*.f</url-pattern>` produced a 404 File Not Found error when attempting to access `welcome.f` , but `<url-pattern>*.oop</url-pattern>` worked properly when attempting to access `welcome.oop`. This problem has been resolved so that single character `<url-patterns>` now work as expected. | 8.1 SP1
CR103095 | When the authentication method associated with a Web application module was invalid and the Web application module was being deployed, no error message was produced, and the authentication method was defaulted to BASIC authentication without notification. This problem was resolved by modifying the code so that a Web application module with an invalid authentication method will not be deployed, and a message indicating the problem will be displayed in the server log file, as well the Administration Console or stdout (depending on how the Web application module is deployed). | 8.1 SP1
CR103192 | If clients did not have session cookies enabled, users were not able to log in to secured Web sites over HTTPS. It was possible to workaround this problem by manually disabling the `AuthCookie`, which up until WebLogic Server 8.1, had been disabled by default. This problem was resolved by automatically disabling the `AuthCookie` check when the Web application has session cookies disabled. | 8.1 SP1
CR103247 | WebLogic Server could not locate implicit TLDs when using the split directory feature. This problem occurred because the `resourceFinders` were being updated after the implicit TLDs were loaded. (The updating of `resourceFinders` is responsible for adding the srcdir and the destination (outputdir) directories.) This problem was resolved by updating the `resourceFinders` before the extraction process. | 8.1 SP1
CR103925 | The `setAttribute` method only checked for `hashCode` equality. It now also checks the result of the `equals` method for the old and new objects. | 8.1 SP1
CR104410 | When PersistentStoreType was set to "replicated," customers who had successfully deployed an application received an "Internal Server error" message when attempting to access the application from a browser. In addition, the following exception was logged on the server: `weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ServletSessionRuntime Action: register, Target: null` This problem was resolved by modifying the code so that a session with session monitoring enabled could be successfully created. | 8.1 SP1
CR104469 | The `fastfile.dll` file, which is required for native IO for the `FileServlet` on Windows, was not working with the JRockit JVM. This problem has been resolved. | 8.1 SP1
CR105171 | 'load-on-startup' JSP files were being compiled by `weblogic.jspc`, even when the `<jspServlet>` element in `weblogic.xml` indicated that `weblogic.servlet.WlwJSPServlet` should be used. This problem was resolved so that the specified compiler will be used. | 8.1 SP1
CR106172 | The deployment of a Web application with the `precompile` option set to `true` in `weblogic.xml` failed, with a JSLT tag validator error of `org.xml.sax.SAXParseException`. This problem occurred because when `precompile` was set to `true`, the JSP file was not being passed to the method that performs validation. This problem was resolved by modifying the code to properly pass the JSP file to the method that performs validation. | 8.1 SP1

## System Administration

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR080353 | Converting the `weblogic.properties` file using the domain convertor does not produce any entry for `weblogic.password.guest=<guestpassword>`. Although the conversion is successful, an error similar to the following may be encountered: `java.lang.SecurityException: Authentication for user guest denied in realm weblogic` This problem was resolved by modifying the code so that a warning indicating how to obtain the old behavior is displayed: `<Apr 12, 2003 10:29:30 AM EDT> <Warning> <Management> <BEA-141186> <User Guest has been disabled by default. If you would like to enable Guest, you should do it manually.>` | 8.1 SP1
CR098920 | Improvements were made to message catalog Detail/Cause/Action information, based upon BEA Support's review of existing System Administration catalog messages. | 8.1 SP1
CR099404 | When using the Security Service Provider Interfaces (SSPIs) to create MBeans to manage your custom security providers, if you attempted to use the same `ObjectName` for more than one MBean, WebLogic Server wrapped the underlying JMX exception, `InstanceAlreadyExistsException`, inside a generic `MBeanException`. In SP1, the true exception is thrown. | 8.1 SP1
CR100331 | When starting up a server in an empty directory using the following command, the warning message transposed the Domain Name and Server Name: `. /bea/wls810/curr2weeks/weblogic/server/bin/setWLSEnv.sh /bea/wls810/curr2weeks/jdk141_02/bin/java -Dweblogic.management.GenerateDefaultConfig=true -Dweblogic.ListenAddress=172.18.136.38 -Dweblogic.ListenPort=7101 -Dweblogic.Domain=rmiiiopStressCluster -Dweblogic.Name=adminServer -Dweblogic.management.password=weblogic -Dweblogic.management.username=weblogic weblogic.Server` The incorrect warning message was similar to: `<Mar 6, 2003 9:17:24 AM EST> <Warning> <Management> <BEA-140012> <Creating default domain` adminServer `with default server` rmiiiopStressCluster`.>` This problem was resolved by correcting the warning to: `<Mar 6, 2003 9:17:24 AM EST> <Warning> <Management> <BEA-140012> <Creating default domain` rmiiiopStressCluster `with default server` adminServer`.>` | 8.1 SP1
CR101002 | Security roles for an EAR that were only defined in `application.xml` (that is, not also defined in `weblogic-application.xml`) were not made available to the WebLogic Security Service, and therefore were not visible in the Administration Console. This problem was resolved with a code fix, and these resources now appear in the Administration Console as expected. | 8.1 SP1
CR101144 | When attempting to log into UDDI after a server reboot, the following exception was thrown: `<Mar 25, 2003 11:23:05 AM CST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=1 4133705,name=uddi,context-path=/uddi)] Root cause of ServletException. weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: EmbeddedLDAPConfig Action: read, Target: Credential at weblogic.management.internal.SecurityHelper$IsAccessAllowedPrivilegeA ction.wlsRun(SecurityHelper.java:492)` The exact steps to reproduce this problem are as follows: 1. In an empty directory, create and start a WebLogic Server instance. 2. Load `http://localhost:7001/uddiexplorer/index.jsp`. 3. Navigate to Search Private Registry and click SEARCH. 4. Stop the server, then restart it. 5. Repeat steps 2 and 3 above, and the error will occur. This problem is due to a change to ensure that access to protected attributes is not allowed unless users are granted the `Admin` security role. This problem was resolved by modifying the UDDI code to run as an identity that has administrative privileges. This way, it can obtain access to the embedded LDAP password attribute it requires. | 8.1 SP1
CR101246 | For any action that requires reading an encrypted password field (such as attempting to deploy a JDBC connection pool), users of the Administration Console who are granted the `Deployer` security role received an exception similar to the following: `Access not allowed for subject: principals=[DeployerUser, Deployers], on ResourceType: JDBCConnectionPool Action: read, Target: Password` This problem was resolved by modifying the code so that users granted the `Deployer` security role have read access on all the `DeploymentMBeans`. This means that users granted the `Deployer` security role will also have read access to encrypted attributes on `DeploymentMBeans`. The `password` attribute on the `JDBCConnectionPoolMBean` was also affected by this change. | 8.1 SP1
CR102149 | 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. | 7.0 SP3 8.1 SP1
CR102706 | In a cluster, a Managed Server attempting to update an Administration Server may have encountered a `java.lang.NullPointerException`. This problem occurred because of an issue with the registering of `NotificationListener`s. This problem was resolved by correcting the processing for registration/unregistration of `NotificationListeners` to protect against the possibility of a `NullPointerException` when attempting to unregister a `NotificationListener`, when no `NotificationListener` had been previously registered. | 8.1 SP1
CR102805 | The `weblogic.webservice.client.BaseWLSSLAdapter.addIdentity(java.security.cert.X509Certificate[] chain, java.security.PrivateKey privateKey)` method is no longer mistakenly marked as deprecated. The other two versions of this method are still correctly deprecated. | 8.1 SP1
CR102807 | A warning and a `java.lang.NullPointerException` may have occurred if a server name was not specified when first booting an Administration Server from a newly-created directory. This problem was resolved by modifying the code so that a management error is reported if a server name is not specified when booting an Administration Server. | 8.1 SP1
CR102849 | Domain log messages file resulted in a synchronous network IO, creating the possibility for deadlocks or other issues to arise. This problem was resolved by modifying the code so that messages are now broadcast to the domain log asynchronously. | 8.1 SP1
CR103117 | Customers who attempted to upgrade Web Service clients from WebLogic Server 7.1 to 8.1 may have experienced `ClassNotFoundExceptions` when the client was invoked using the `webserviceclient.jar`. This problem occurred because the `weblogic/webservice/PartFilter.class` and `weblogic/webservice/core/FaultMessage.class` files were missing from the `webserviceclient.jar`. They have now been added. | 8.1 SP1
CR103831 | A deadlock condition occurred when the server and domain logs were being rotated at the same instant on the Administration Server. (See also CR102849.) This problem was resolved by modifying the code so that messages are now broadcast to the domain log asynchronously. | 8.1 SP1
CR103935 | After the error messages were printed to the domain log file, the server logging service was shut down. If the problem occurred, not all log messages were printed to the server log file. This problem occurred on both the Administration Server and the Managed Server(s). This problem occurred because in selecting the log file to rotate to, a log file that already existed on the file system would be chosen. Therefore, any attempt to rotate would result in a failure. When log files are rotating at a fast rate, it is possible that the file handle is still not released. As such, this problem was resolved by determining the oldest and latest files based on last modified timestamps, and offsetting the rotation size if any failure is encountered. | 8.1 SP1
CR104008 | The `weblogic.Admin` SHUTDOWN and FORCESHUTDOWN commands can now retrieve user credentials from a boot identity file. This enables you to invoke these commands from a script without storing unencrypted user credentials in the script. For more information, refer to SHUTDOWN and FORCESHUTDOWN in the WebLogic Server Command Reference. | 8.1 SP1
CR104966 CR105251 CR105252 | The HTTP log rotation time format was not consistent with the format indicated in the online help. If the format specified in the online help was used, a parse error would be seen the next time the WebLogic Server instance was started, and it would not start. If the expected date format (`MM-dd-yyyy-k:mm:ss)` is not specified, the Administration Console now indicates the problem. The online help has been corrected to indicate this format. | 8.1 SP1
CR105198 | The following exception was displayed during startup of cluster instances after an Open LDAP Authentication provider was added to a default (active) security realm: `com.rsa.jsafe.JSAFE_PaddingException: Could not perform unpadding: invalid pad byte` This problem was resolved by having the Managed Server obtain the Administration Server's Encrypted Service and perform the proper Encryption. | 8.1 SP1
CR105777 | 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. | 7.0 SP3 8.1 SP1
CR120295 | Some logging methods were inadvertently publicized. In the WebLogic Server 8.1 API Reference (Javadoc) for the `weblogic.logging.WLLogRecord MBean`, the setter methods should not have been made public. The attribute values in this MBean are precomputed and set internally; they should not be modified. In addition, in the API documentation for the `weblogic.logging.WLLevel` MBean, the constructor should not have been made public. The WebLogic logging services support a fixed set of levels, so creating your own `WLLevel` is not supported. You can extend the `java.util.logging.Level` class which is handled after appropriate mapping to `WLLevel` by the WebLogic logging service. | 8.1 SP1

## Tools

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR069568 | The EJB 2.0 DTD allows for multiple roles and multiple methods to be defined inside one method-permission element. While WebLogic Builder allowed users to define multiple roles, it only allowed one method. This problem was resolved by modifying WebLogic Builder so that users can specify both multiple roles and multiple methods in one method-permission element. | 8.1 SP1
CR093246 | A new tag 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. | 7.0 SP3 8.1 SP1
CR096719 | 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. | 7.0 SP3 8.1 SP1
CR099865 | Setting a default transaction value (`default-tx`) on a single bean using the `<container-transaction>` tag would result in the default transaction value being set the same way for all the beans in the same JAR. This problem was resolved by modifying the code so that setting the default transaction value on a single bean did not affect the same setting for other beans in the JAR. | 7.0 SP3 8.1 SP1
CR099913 | 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. | 7.0 SP3 8.1 SP1
CR102990 | WebLogic Builder no longer allows users to delete a role if it is being used in a method permission. | 8.1 SP1
CR103200 | If a Java source file that did not end in the `.java` extension was provided to `source2wsdd`, it would fail with the following error: `[source2wsdd] source2wsdd: Illegal package name` This was problematic since the convention for EJBGen source code files that are in split directories is for the suffix to be `.ejb`. This problem was resolved by modifying `source2wsdd` so that it would accept either a `.java` or `.ejb` suffix. | 8.1 SP1
CR105436 | `java weblogic.marathon.ddinit.WebInit stageDir` was failing 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. | 7.0 SP3 8.1 SP1
CR108254 | `wlcompile` failed when calling EJBGen if the classpath contained spaces. This problem occurred because when `wlcompile` forked EJBGen, it did not quote the classpath. As a result, if the classpath contained spaces, some of the elements were misinterpreted. This problem was resolved by making sure the classpath is treated correctly. | 8.1 SP1

## Utilities

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR101046 | `weblogic.BuildXMLGen` overwrote an existing `build.xml` file without warning. This problem was resolved by adding the following warning message: `weblogic.utils.compiler.ToolFailureException: Build File already exists, use -file to specify alternative build file name.` | 8.1 SP1

## WebLogic Workshop

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR102094 | The script used to start the WebLogic Workshop sample server, WL_HOME`\samples\workshop\startWebLogic.cmd` was not installed in the WebLogic Server 8.1 release. Therefore, you could use the Windows Start Menu selection to start the sample server because it referred to this missing file. This problem has been fixed. | 8.1 SP1

## Web Services

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR085000 | A `StackOverFlowError` occurred during the serialization of a `java.lang.Object`. This problem was resolved by using `Object.toString()` for instances of the class `java.lang.Object`. | 8.1 SP1
CR087303 | 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="http://schemas.xmlsoap.org/soap/http";/> <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="http://schemas.xmlsoap.org/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. | 7.0 SP3 8.1 SP1
CR094458 | It is now possible to configure Web Service security requirements on a per operation basis for both requests and responses. | 8.1 SP1
CR096558 | This version of WebLogic Server uses a newer version of SOAP 1.2 specification (W3C Candidate Recommendation 19 December 2002). | 8.1 SP1
CR097887 | Web Service deployment descriptors and WDSL did not support all XML encodings. This may have resulted in the following error when using servicegen: `[servicegen] java.io.CharConversionException: Unconvertible UTF-8 character` This problem was resolved by using the `weblogic.webservice.i18n.charset` property to support encodings for Web Service deployment descriptors and WSDL. | 8.1 SP1
CR098050 | When deserializing a `xsd:string` to a `java.lang.String`, certain characters, for example '/', were causing the resulting String to be truncated. This problem was resolved by modifying the String deserializer to handle multiple character data events. | 8.1 SP1
CR099028 | A soap header with a simple type used the wrong namespace (schema namespace). This problem was resolved by fixing the soap header to use the target namespace of the Web Service. | 8.1 SP1
CR099030 | A one-way call to a WebLogic Server instance used to wait until the end component invoke was complete. Now the client returns after sending the request. | 8.1 SP1
CR100386 | `javax.xml.rpc.Call.SESSION_MAINTAIN_PROPERTY` was not supported. In other words, nothing was done with this property if it was set on the client, which violated section 13.7 (Session Management) of the JAX-RPC 1.1 specification. This problem was resolved by adding support for this property. | 8.1 SP1
CR100528 | If you defined two Web Services using the same serviceNames and serviceURIs, as in: `service serviceName="SessionFoo" serviceURI="ejb20test" service serviceName="SessionFoo" serviceURI="ejb20test"` both nodes would be merged into one Web Service (with a merged offering of operations). However, if you defined two Web Services using different serviceNames and the same serviceURIs, as in: `service serviceName="SessionFoo" serviceURI="ejb20test" service serviceName="SessionBar" serviceURI="ejb20test"` only one of the Web Service's operations would show up under `./ejb20test`. This problem was resolved by adding a check in servicegen to be sure that the same serviceURI is not used in more than one Web Service. If it is, you will now get a build error. | 8.1 SP1
CR100807 | The default method for Web Service back end components was not being called, therefore, the server-side dispatcher was not working properly. This problem was resolved with a code fix. | 8.1 SP1
CR100932 | Default type mappings are now able to load the `types.xml` file from the classpath. | 8.1 SP1
CR101149 | When JMS transport was enabled and a browser was used to test a Web Service with multiple operations using different transports, the test page would display all operations in one section and did not distinguish between them. This problem was resolved by fixing the test page so that it is now possible to distinguish between operations using different transports. | 8.1 SP1
CR101160 | In WSDL, it is possible to describe SOAP faults than contain complex types. This was not supported in the WebLogic container. This problem was resolved by implementing sections 5.5.5 and 4.3.6 of the JAX-RPC specification. | 8.1 SP1
CR101369 | The `SOAPFaultException` `faultactor` and `faultstring` are no longer reversed. | 8.1 SP1
CR101416 | `Javax.xml.rpc.Service.getProxy( <stub-class> )` did not work correctly when one XML type was mapped to many Java types. This is fixed by using both Java and XML types to lookup for codecs. | 8.1 SP1
CR102139 | Web Services security now includes timestamps on signed messages. The security portion of the Web Service deployment descriptor has been extended to allow timestamp processing to be configured. | 8.1 SP1
CR102328 | A `ClassNotFoundException` was thrown while attempting to build a Web Service. While building the Web Service using the servicegen utility, an error starting with the following lines would occur: `java.lang.ClassNotFoundException: weblogic.management.descriptors.WebElementMBean at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) at java.lang.ClassLoader.loadClass(ClassLoader.java:250)` `...` This problem occurred because WebLogic Server was not able to locate the `weblogic.jar` and `webservices.jar` files when they were not added to the system's CLASSPATH. This problem was resolved by modifying the code so that WebLogic Server always loads classes from the thread's context classloader. | 8.1 SP1
CR102686 | The asynchronous Web Service client failed and printed the following debug information when only the `webserviceclient.jar` was in the client's classpath: `java.lang.ClassNotFoundException: weblogic.kernel.Kernel` Note: This problem was not encountered if `weblogic.jar` was also in the classpath. This problem was resolved by preventing the debug information from being printed, and by including `weblogic.kernel.Kernel` in the `webserviceclient.jar`. | 8.1 SP1
CR102772 | Adding a SOAP Header block with child elements, in a client-side handler without using a namespace prefix: (via `SOAPEnvelope.createName(String localName)` and `SOAPHeaderElement.addNamespaceDeclaration("","http://identifier.company.com/Context/v1";)` ) caused the `SOAPHeader.getChildElements(javax.xml.soap.Name)` method to return an empty `Iterator` against that SOAP Header block inside a server-side handler. This problem was resolved so that you can now add default namespaces by using `SOAPHeaderElement.addNamespaceDeclaration("","http://foo.bar/" )`. | 8.1 SP1
CR102745 | The `weblogic.webservice.binding.jms.ConnectionPool.getInstance().close()` method, which is required only for light clients using JMS transport because of a bug in the SDK, has been added to the Javadocs. | 8.1 SP1
CR102985 | If a reliable request was made to a Web Service that did not exist, a SOAP fault exception was returned. The behavior of the sender was not deterministic in this case. This problem was resolved by modifying the code so that 1. 1. If there is a SOAP fault, a delivery failure is reported. 2. If there are no reliability headers in the response, the request is retried. 3. If the status is DUP or OK, the message is removed from the queue. | 8.1 SP1
CR103111 | A SOAP message was always treated as platform default encoding when it was encrypted and decrypted. This problem was resolved by allowing SOAP messages to have a specified encoding in the handler of the secure message. Web Service applications and clients that use WS-Security can now exchange non-ascii characters by specifying an encoding. The method of specifying an encoding is the same as for a non-secure SOAP message, except the `setAcceptCharset()` method in `weblogic.webservice.binding.BindingInfo` is ignored. If no encoding specified, UTF-8 is used. | 8.1 SP1
CR103394 | Optional parameters could not be set to `null` from a Java client using the stub generated from WebLogic Workshop. The optional parameters were always sent with default values. This problem was resolved by modifying the code so that optional parameters are not written or sent in the SOAP request from the client to the Web Service unless the value of the optional parameter(s) in the client is set in the client that uses the generated stub. | 8.1 SP1
CR103791 | `java weblogic.webservice.autotype` did not handle arrays of user types as a Java type. For example, the first statement shown below would work, but the second would not: `java weblogic.webservice.autotype -destDir /tmp/z88 -javaTypes 'foo.bar.tests.SomeBean'` `java weblogic.webservice.autotype -destDir /tmp/z88 -javaTypes '[Lfoo.bar.tests.SomeBean;'` This problem was fixed by correctly loading Array classes. | 8.1 SP1
CR104187 | A serialization problem occurred when sending a SOAP message to a Web Service generated using `wsdl2service` from `GenericDataService.wsdl`. This problem was resolved by modifying the code so that nested model types with `maxOccurs` set to a value greater than 1 work properly. | 8.1 SP1
CR104719 | 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. | 7.0 SP3 8.1 SP1
CR104989 | `java weblogic.webservice.autotype` failed to generate serialization/deserialization classes for complex types that contained only references to named model groups. This problem was resolved so that the classes are generated. | 8.1 SP1
CR105353 | Adding `useSOAP12="true"` to the `web-services.xml` file of a Web Service caused a `javax.management.InstanceAlreadyExistsException` to be generated during deployment of the Web Service. This problem was resolved with a code fix. | 8.1 SP1

## XML

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR095744 | The `XMLCacheRuntimeMBean` and `XMLCacheCumulativeRuntimeMBean` interfaces, which were not being used, have been deprecated and are now excluded from the Javadoc. | 8.1 SP1
CR100798 | In XMLDsig signed messages, the syntax for `X509SerialNumber` was invalid. This problem occurred because `X509SerialNumber` was base64 encoded instead of just a String, and the problem was resolved by making this modification. | 8.1 SP1
CR102397 | The Xerces parser always attempted a call to `System.getProperty()`. This would throw an exception in an Applet, which does not have permission to retrieve properties. The following partial exception could be observed in an Applet making a JMS call: `----------- Linked Exception ----------- java.rmi.MarshalException: failed to marshal connectionCreate(Lweblogic.jms.dispatcher.DispatcherWrapper;); nested exception is: java.rmi.UnexpectedException: Failed to parse descriptor file; nested exception is: java.security.AccessControlException: access denied (java.util.PropertyPermission weblogic.apache.xerces.maxentityrefs read) [...]` The code was modified so that the parser does not attempt to read system properties with Applet clients. | 6.1 SP6 8.1 SP1
CR103083 | Lookups on `xsd:include'`d types did not work for backward references. This problem was resolved by modifying the code so that if necessary, lookups properly went back up the include chain. | 8.1 SP1
CR103109 | For user-defined strings of simple type, the autotyper failed. The resulting generated code contained unqualified references to `java.lang.String`. This problem was resolved by making every usage of any class use the full package name. | 8.1 SP1