Skip navigation.
Downloads | Product Documentation | Support

Release Notes

# Resolved Problems for Service Pack 2

Service Packs are cumulative; Service Pack 2 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 2.

- Administration Console
- Classloader
- Cluster
- Connector
- CORE
- Deployment
- EJB
- Installation
- J2EE
- JCOM
- JDBC
- JMS
- JNDI
- JTA
- Node Manager
- Plug-Ins
- RMI/RMI-IIOP
- Security
- Servlets & JSPs
- System Administration
- Tools
- Web Services
- WTC
- XML

## Administration Console

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR076953 | If you created a security role using the context-sensitive (right-click) menu item "Define Policies and Roles for individual beans..." and added the security role to the security policy (defined using the same context sensitive menu/form sequence), the desired WebLogic resource could not be used by an external JCom client. The context-sensitive menu items create a scoped role, and clients outside the scoped role could not use the WebLogic resource. Adding a "Define JCom Roles" menu item to the JCom node solved this problem by allowing revision of the scope to include the current client. | 7.0 SP3 8.1 SP2
CR078764 | Security settings in the Administration Console for Web services did not function properly. A code change removed the ability to set policy and roles for Web services in the Administration Console. | 7.0 SP3 8.1 SP2
CR081673 | Realms created by the Administration Console lacked the `UserLockoutManager` on their RealmMBeans. The Administration Console now creates a ULMbean when it creates a new realm. | 7.0 SP3 8.1 SP2
CR082335 | The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close. Following a code fix, the cursors close. | 7.0 SP3 8.1 SP2
CR091853 | For a three-node cluster on separate Solaris 2.8 machines, the Administration Server threw an InstanceNotFound exception when accessing the default Execute Queue. The problem has been resolved. | 7.0 SP4 8.1 SP2
CR099721 | After edits to Cookie Max Age Secs using the Administration Console, the value sometimes reverted to the value before the edit. A code change removing a lower limit to the value fixed the problem. | 7.0 SP3 8.1 SP2
CR100006 | WebLogic Server sometimes displayed the following `NullPointerException` when a domain contained two Administration Servers and you tried to access the servers via the WebLogic Server Administration Console: `java.lang.NullPointerException at weblogic.management.console.helpers.UrlHelper.buildIconList(UrlHelper.java:149) at weblogic.management.console.helpers.UrlHelper.getIcon(UrlHelper.java:174) at weblogic.management.console.tags.SmartNavNodeTag.getIcon(SmartNavNodeTag.jacva:111) at weblogic.management.console.tags.SmartNavNodeTag.inferStuffFromContext(SmartNavNodeTag.java:96) at weblogic.management.console.tags.SmartNavNodeTag.doStartTag(SmartNavNodeTag.java:44) at weblogic.management.console.webapp._domain.__nav._jspService(__nav.java:301) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:250) [...]` This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR103104 | The `UserReader` MBean did not display users in the Administration Console. An Authentication provider can read users in the Administration Console while implementing the `UserEditor` but with `UserReader`, the message when trying to display users is "There are no Authentication providers available that support the creation of Users." The same thing was happening for Groups with the `GroupEditor` and `GroupReader` interfaces. The Administration Console was still calling the `userEditor.CreateUser` method, and never getting to the UserReader.`listUsers` method. The MBean has been fixed to look for appropriate provider type. | 7.0 SP3 8.1 SP2
CR105598 | New testing with an Active Directory LDAP uncovered a problem where a call to `group.isMember()` would fail if a member name contained a comma character (`,`). This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR106027 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. | 7.0 SP3 8.1 SP2
CR111321 | If there is only one server in a WebLogic Server domain, the WebLogic Server Administration Console does not display virtual hosts as potential targets during the deployment of a Web application. This was done to save users the extra step of having to select a target when there is only one target. However, this prevented users from deploying a Web application to a virtual host directly. Users could only deploy the Web application to the server and then re-target it to a virtual host. This worked fine for the first Web application, but for the second Web application, an exception was thrown indicating that the context was already in use. For Web applications, the Administration Console now checks for any virtual hosts configured in the domain and displays them as potential targets. As a result of this fix, customers should now be able to target Web applications to a virtual host directly from the Administration Console. If there are no virtual hosts, the Administration Console assumes that the lone server is the target for the Web application, just as it did prior to this fix. | 8.1 SP2
CR112726 | In the `FileChooserControlTag`, WebLogic Server defaulted to UTF-8 encoding for path settings. This fix causes WebLogic Server to extract the correct charset from the catalog and use that instead of defaulting to UTF-8. As a result of this change, paths are now displayed correctly (without any garbled characters). | 8.1 SP2
CR120537 | Users of the WebLogic Server Administration Console could not delete foreign JMS destinations. A trash can icon (delete) has been added to the foreign JMS destinations table. Users can now delete foreign JMS destinations. | 8.1 SP2
CR120603 | Editing the load order in the WebLogic Server Administration Console caused spaces to be embedded in the `path` attribute of the `config.xml` file's `<Application>` tag. This problem occurred because the method `pathToFormValue`, which is used to breakdown long path strings to more manageable pieces, was rejoining the strings with extra spaces. The code was changed to remove these extra spaces. As a result of this fix, the extra spaces in the `path` attribute will no longer be inserted when the `config.xml` is updated. | 8.1 SP2
CR124344 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_41.00.jsp. | 8.1 SP2

## Classloader

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR124348 | Client programs could not use `java.lang.reflect.Proxy` to access proxy objects deployed in WebLogic Server, unless the proxy classes were added to the system classpath. If an object did not reside in the system classpath, the client would receive a `ClassNotFoundException`. The `resolveProxyClass()` method was implemented to load interfaces from the application-specific classloader as well as the system classloader. | 6.1 SP6 8.1 SP2

## Cluster

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR094837 | The following sequence was causing a `ClassCastException`: define a server, assign that server to a cluster, create a Unix machine with the same name as the server, assign them to each other, stop and restart the Administration Server, and select the server name from the cluster or from the Servers list. Trying to bring up the Managed Server also caused a `ClassCastException`. Fixing a problem in a process that resolves an `UnresolvedMBean` during startup solved this problem. | 7.0 SP3 8.1 SP2
CR105698 | If two clusters have between them two distributed queues with the same JNDI name, and a message-driven bean is deployed on both the clusters, messages were being consumed in only one of the clusters. A message-driven bean now goes through the entire collection of distributed queues in a domain and adds their members appropriately. | 7.0 SP3 8.1 SP2
CR108127 | An error occurred when trying to update a secondary session. Given three clustered server instances: Server A, Server B, and Server C. 1. Initiate a session on Server A, PRIMARY A, SECONDARY C 2. Load balancing hardware migrates the session to Server C, PRIMARY C, SECONDARY B 3. Load balancing hardware migrates the session to Server A again This error occurred on Server A: `<Jun 4, 2003 4:24:56 PM PDT> <Debug> <Cluster> <Error updating secondary for 3535724191309537720 on 7312270160516507840S:<IPaddressdeleted>: [7005,7005,7002,7002,7005,7002,-1]:<IPaddressdeleted>:7005, <IPaddressdeleted>:7005,<IPaddressdeleted>:7005:mydomain:myserver3. Re-creating secondary.>` This error occurred on Server C: `<Jun 4, 2003 4:24:56 PM PDT> <Info> <Cluster> <Lost 0 replication updates of object 3535724191309537720. Re-fetching secondary.>` The problem was solved by a code change. | 6.1 SP6 8.1 SP2
CR108893 | The `ClusterRuntime.getName()` method returned the name of a server in the cluster, rather than the name of the cluster. This method has been fixed to properly return the name of the cluster. | 8.1 SP2
CR127643 | When a dynamic proxy that implemented interfaces declared inside a Web application was put into the `HttpSession` and the session was replicable, WebLogic Server was not able to load the interface classes on the secondary server. To correctly resolve the dynamic proxy, the secondary server needs the name of the application where the interface resides. An `annotateProxyClass` was implemented in `MsgAbbrevOutputStream` to write the `applicationName` in the stream. On the receiving side, `resolveProxyClass` uses this application name to load the interface classes from the application. As a result of this change, dynamic proxies (implementing interfaces stored in the application archive) can be put into the `HttpSession` and be correctly replicated. There should be no side effects. | 8.1 SP2

## Connector

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR091818 | There was no configuration parameter to disable Connection Proxy creation. This problem was resolved by adding a property called `use-connection-proxies` in the `weblogic-ra.xml` deployment descriptor. If the property is set to "true," then proxies will be used without performing the test for connection proxy viability. That is, the case where a resource adapter attempts to cast the wrapped connection (proxy) that WebLogic Server generates, and the cast fails. If the property is set to "false," then proxies will not be used. If no value is specified for the property, previous functionality will be used. (That is, the test for connection proxy viability will be performed and proxies will be used if and only if the test passes.) The only caveat to a late transaction enlistment is that client code cannot first acquire a connection handle, then start a transaction and have that connection automatically enlisted. If the client starts a transaction first and then acquires a connection handle, everything works fine. The absence of late-transaction enlistment implies nothing about the use of bean-demarcated vs. container-managed transactions. Both will work. | 8.1 SP2
CR105247 | When trying to deploy a RAR component with a set of its utility classes packaged as JAR files, WebLogic Server was unable to load the properties file, which is included in the JAR file. There was a "/" missing from the URL and this resulted in not being able to find the properties file. The code was modified to add the "/" when needed. | 8.1 SP2
CR106388 | During deployment of a RAR that uses the `ra-link-ref` element, called a 'logical' RAR, the logical RAR deployment was not getting the correct pool name or max-capacity as specified in its `weblogic-ra.xml` deployment descriptor. This caused unexpected behavior in WebLogic Integration. The element now functions properly. | 7.0 SP3 8.1 SP2
CR106663 | New validation checks created incompatibility with previous versions. Validation checks were changed to be backwards compatible. Entries that should be nullable are now allowed. The following parameters continue to prohibit `null` values: `connection-factory-name` `jndi-name` `shrinking-enabled` (true|false only) `connection-profiling-enabled` (true|false only) `match-connections-supported` `logging-enabled` (true|false only) `map-config-property-name` `initiating-principal resource-principal` Also, `log-filename` does not allow `null` if `logging-enabled` is true. Because of incompatible validation checks, some adapters that would deploy without error in 7.0 may not deploy in 8.1 or 8.1 SP1, because of `null` or empty values in the `weblogic-ra.xml` descriptor. The validation checks have been modified as of 8.1 SP2 so that it should now be backwards compatible with all previous versions. | 8.1 SP2
CR106960 | When a RAR was part of an EAR, redeployment of the EAR failed because the Connector Module code did not handle redeployment properly. Fixing the redeploy logic in the Connector module resolved the problem. | 7.0 SP4 8.1 SP2
CR111229 | In WebLogic Server 8.1 SP1, with multiple clients using connections for an adapter, XAER_PROTO errors could occur while initializing a connection to be used in a transaction. The problem was caused by the fact that a connection and the state of its transaction was not always being completely resolved before releasing the connection back to the pool of available connections. This could allow another client to start using the connection before its state was completely reset by the previously calling thread. In WebLogic Server 8.1SP2, the server ensures that the connection and transaction state are completely resolved before releasing the connection back to the pool of available connections. Thus, connection requests will no longer create XAER_PROTO exceptions while initializing the connection to be used in a transaction. | 8.1 SP2
CR112162 | If a resource adapter's implementation of `ManagedConnectionFactory.matchConnections(connectionSet)` sent the `CONNECTION_ERROR_OCCURRED` event for a `ManagedConnection` that was in the `connectionSet`, then the `ManagedConnection` instance would be destroyed by the Connector container calling `ManagedConnection.destroy()`, but it would not be properly removed from the pool of available managed connections. This problem occurred because during the processing of the error event, the code was only looking in the set of reserved connections to perform the removal from the pool. In other words, when an error occurred, the Connector container assumed that the connection was currently in use. During the processing of the `CONNECTION_ERROR_OCCURRED` event, the code will now check the set of available connections if the destroyed connection is not found in the set of reserved connections. With the fix, the `ManagedConnection` will be destroyed and removed from the pool appropriately when a `CONNECTION_ERROR_OCCURRED` event is invoked. | 8.1 SP2

## CORE

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR092375 | Manually doing a lookup and then persisting and caching the handle did not work when the methods were conversational. Changes to serialization and deserialization of the `EJBHandle` object resolved the problem. | 7.0 SP2 8.1 SP2
CR096091 | When starting WebLogic Server as an Windows service using a classpath from a file, the error `"Thread created successfully! Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/Server"` was thrown if classpath file is over about 2k length. The problem was solved by correcting an error related to reading the classpath from a file. | 6.1 SP6 8.1 SP2
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 SP2
CR105516 | Stateful session EJB failover did not work when multiple failovers were required. In a three node cluster a JSP creates or calls a replica-aware stateful session EJB. The remote EJB stub is stored in the http session. After each call to the stateful session EJB the updated EJB stub is also updated in the HTTPsession to reflect any changes for the EJB replica list (primary/secondary). The following call sequence with the same browser window leads to a `java.rmi.ConnectException` when only one node of the cluster survives: 1. All three cluster nodes are running. 2. Making a call to node1, create EJB and store remote in HTTP session (HTTP session replication is enabled) 3. Kill node1 4. Make a call to the secondary node2, the EJB remote is retrieved from the replicated HTTP session and the call to the EJB works fine. After this EJB call again the remote is stored in the HTTP session. 5. Kill node2 6. Make a call to node3, get the EJB remote from HTTP session. WebLogic Server tries to lookup the EJB on node2 and does not try to use node3 (this should now be the new secondary). The following exception is thrown on node3: `java.rmi.ConnectException: Could not establish a connection with -3088833905169218734S:172.23.64.38:[7001,7001,7002,7002 ,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:275) at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408) at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:255)` The problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR105980 | A memory leak occurred when creating a `QueueReceiver` for each message on a Distributed Queue and persisted even after the `QueueReceiver` had been shut down. A code change corrected memory leaks in `BasicServiceOffer` and `DistributedDestinationImpl` objects. | 7.0 SP3 8.1 SP2
CR110028 | The functionality to detect stuck threads in user-configured thread queues was not complete in WebLogic Server 7.0 and its service packs. Thread queues have been reworked and provisions made to identify an application thread from an internal server thread queue. Logic was added to loop through all application thread queues, checking for stuck threads. All application thread queues will now be monitored by the Core Health Monitoring Thread and proper warnings logged. | 8.1 SP2
CR110367 | User code such as servlet `destroy()` or `ejbRemove()` gets executed during shutdown. This fix ensures that lower order services like JMS and JDBC are available when this user code executes. | 8.1 SP2
CR110887 | When nodes in a cluster tried to get session information, they were attempting a lookup from a remote server, hence making a remote call that blocked a thread on the local server. When all nodes were doing the lookup under load, the execute thread queues became blocked and no server was in a position to send a response to the remote call (as all local threads were blocked). WebLogic Server now creates the stubs locally to avoid a remote call, until the point where it is necessary. When WebLogic Server makes the remote call, it lands on a separate replication queue on the remote server and the process does not block there. The replication behavior is still unchanged. As a result of this change, WebLogic Server only ensures less contention, avoids a deadlock situation, and reduces the number of remote calls. | 8.1 SP2
CR110892 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp. | 6.1 SP6 8.1 SP2
CR120841 | WebLogic Server did not collect timer threads during orderly shutdown. This did not result in any observable problems. Shutting down the ORB now shuts down heartbeat threads. This change should not result in any changed behavior. | 8.1 SP2
CR123846 | `ClassCastExceptions` were being thrown when a transaction was started in a user thread. This problem occurred because the parallel XA implementation was using a Kernel method, which was assuming that all requests would be executed on a ExecuteThread, and this method was casting the current thread as an ExecuteThread. When the work ran in a user thread on the server side, the exception would be thrown. This problem was resolved by allowing the execution to happen on any thread. | 8.1 SP2

## Deployment

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR101760 | Deleting a Web application from a Managed Server that had been stopped resulted in errors similar to the following: `<Warning> <Management> <149311> <Rejecting deployment operations to non-running server, mgd1>` `<Warning> <Deployer> <149004> <Failures detected initiating weblogic.management.ManagementException: Rejecting deployment operations to non-running server, mgd1 task for application Remove application MyWebApp on mgd1>` The Web application was not deleted. A code change fixed the problem by eliminating dangling `WebAppComponentMBean` references from the `WebServer` and `VirtualHost` MBeans. | 7.0 SP3 8.1 SP2
CR102928 | Web applications in an EAR deployed to a VirtualHost did not redeploy on domain restart. A code change causes applications that target a Virtual Host to restart when the domain restarts. | 7.0 SP3 8.1 SP2
CR109668 | Running the following command caused all the modules in the application to transition from an active state to an inactive state, even though it was expected that only the specified module in the application would be undeployed. `java weblogic.Deployer -url <admin_url> -username <user_name> -password <passwd> -name <app_name> -undeploy -targets <module_name>@<cluster_name>` This problem occurred because in the `SlaveDeployer`, WebLogic Server did not factor in the possibility that a component could have been targeted to a cluster, and was performing checks based only on the server target type. The code has been modified to add a check for the possibility of a component target being of type cluster. Partial undeployment should now work as expected. | 8.1 SP2
CR111065 | In certain instances, the DRS system is creating the delta list of deployment tasks for the `SlaveDeployer` initialization. A code fix ensures that DRS always uses the `MasterDeployer` for creating the deployment task deltas. | 8.1 SP2
CR113178 | In the `SlaveDeployer` code, the applications are sorted and added to a `HashSet` (`ApplicationsSet`). The `Iterator` taken out of this `HashSet` does not retain the order of the elements that are added to it. A `TreeSet` was used to store these elements in a sorted order, but it could not store duplicate applications with the same deployment order. (One will overrode the other.) Applications are now added to a `List` instead of a `Set`. As a result of this change, the Iterator preserves the order, and applications will be deployed per the `loadOrder` attribute of the `config.xml` file. | 8.1 SP2
CR120714 | The `WLDeploy` task was printing the password to stdout. For example, if `build.xml` contained: `<project name="cr120714" basedir="."> <taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.WLDeploy"/> <target name="deploy-app" > <wldeploy action="redeploy" nostage="true" name="CR120714App" user = "system" password = "gumby1234" adminurl = "t3://172.17.24.109:7001" verbose = "false" debug = "false" /> </target> </project>` the output of `ant deploy-app` was: `Buildfile: build.xml` `deploy-app: [wldeploy] weblogic.Deployer -nostage -noexit -name CR120714App -adminurl t3://172.17.24.109:7001 -user system -password gumby1234 -redeploy [wldeploy] Initiated Task: [1] [Deployer:149026]Redeploy application CR120714App on myserver. [wldeploy] Task 1 completed: [Deployer:149026]Redeploy application CR120714App on myserver. [wldeploy] Deployment completed on Server myserver [wldeploy]` The original password is now replaced with "********" before printing the command to stdout. | 8.1 SP2

## EJB

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR087151 | For a stateless session bean, when the `weblogic-ejb-jar.xml` contained: `<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>` and the bean was deployed on a cluster, this error was generated: `<Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.>` This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are not replicated. | 6.1 SP5 8.1 SP2
CR094073 | Before running a finder method on the BMP beans, the EJB container was not synchronizing the bean state with the database. BMP entity bean handling has been changed to conform to the EJB 2.0 specification. Per the EJB specification, the EJB container now synchronizes the entity bean state by invoking `EJBStore` before running a Finder method. This does not affect the `findByPrimaryKey`. In a transaction, if a finder method is invoked on a BMP bean, it will now trigger the `ejbStore` of all modified beans (BMP and CMP beans) participating in the transaction. Thus, BMP beans might get more `ejbStore` callbacks within a transaction. | 7.0 SP3 8.1 SP2
CR095173 | The `idle-timeout-seconds` element determined how long the EJB container waits before passivating stateful session beans, that is, removing them from cache and writing them to disk. The EJB container also used this element to determine how long to wait before removing passivated EJBs from the disk. However, some customers wanted stateful session beans to remain on disk longer than `idle-timeout-seconds`. They wanted to specify how long stateful session beans stay idle in the cache and how long they stay idle on disk using two different elements. This enhancement is made possible by introducing the new element `session-timeout-seconds`, which specifies how long the EJB container waits before removing an idle stateful session bean from disk. | 7.0 SP3 8.1 SP2
CR096182 | Dynamic EJB-QL incorrectly passed long arguments as `MAX_INT` to the underlying SQL, resulting in an unsuccessful search. A code fix resolved the problem. | 7.0 SP3 8.1 SP2
CR096395 | The container was failing to call `unsetEntityContext` when the entity bean was undeployed. An `undeploy` method was added to the `BaseEntityManager` to clean up the pool when an entity bean is undeployed. This resolved the problem. | 7.0 SP3 8.1 SP2
CR097913 | Combining COUNT and EXISTS in a dynamic EJB-QL request resulted in invalid SQL and this exception: `[java] javax.ejb.FinderException: Exception in dynamicQuery while preparing or executing statement: 'weblogic.jdbc.rmi.SerialStatement@62b30' [java] java.sql.SQLException: ORA-00937: not a single-group group function [java] [java] java.sql.SQLException: ORA-00937: not a single-group group function` An unnecessary column was being added to the main select list while parsing a subquery. A fix to the parser code solved the problem. | 7.0 SP3 8.1 SP2
CR099626 | ejbc generated invalid SQL for an `ejbSelect` query. The query failed because table aliases were generated incorrectly, resulting in this error: `ORA-00904: invalid column name` The problem was corrected with a code fix. | 6.1 SP6 8.1 SP2
CR099760 | A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated, but whose value did not change, are not written to back to the database. The optimization is only done for primitives and immutable objects. | 6.1 SP6 8.1 SP2
CR100832 | Column version numbers were not updating correctly with Optimistic concurrency enabled, because blind writes were not checked . The code was changed so that blind writes are checked with Optimistic concurrency. | 7.0 SP3 8.1 SP2
CR102481 | In some bean-managed stateful session beans, an `IllegalStateException` occurred with bean-demarcated transactions when the number of bean instances is greater than `max-beans-in-cache` when the cache is full and activations and passivations occur. A code change results in the creation of one replacer per passivation request, so that each thread has its own replacer. | 7.0 SP3 8.1 SP2
CR103047 | It was reported that transaction timeouts on MDBs were not logged. When the time an MDB takes to process a message from a JMS Destination exceeds the transaction timeout limit, the transaction is rolled-back and the message is place backed on the destination for re-delivery, but no transaction-timeout or transaction-rollback messages were logged. This problem was resolved by a code change to the MDListener code to report the transaction timeouts. | 6.1 SP6 8.1 SP2
CR103391 | The JDBC driver from Microsoft has a limitation whereby for a given result set of rows and columns, the getXXX method can only be called once per row. This limitation applied only if the query columns included a text or image column. WebLogic Server-generated JDBC obtained the key value from a row—for example, using a getLong(1)—and then passed the result set to another routine that read all the column values, including the first, re-executing a getLong(1). This re-execution caused the Microsoft driver to throw an exception. The problem is resolved by a code fix that avoids parsing the primary key columns in the resultSet twice. | 7.0 SP4 8.1 SP2
CR105857 | EJBs with Bean-Managed Persistence and with concurrency set to exclusive called `ejbFindByPrimaryKey` rather than finding the bean in the cache. A code change resolved the problem so that the EJB finds the bean in the cache. | 7.0 SP3 8.1 SP2
CR106041 | ejbc now runs a compliance check that disallows optimistic concurrency for BMP (bean-managed persistence) beans. Optimistic concurrency is a feature of CMP (container-managed persistence) beans in EJB 2.0. See Choosing a Concurrency Strategy in Programming WebLogic Enterprise JavaBeans. | 7.0 SP4 8.1 SP2
CR106136 CR111025 | Getter methods for a EJB 1.1 CMP bean did not call `isModified()` when `delay-updates-until-end-of-tx` was set to false. A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to `Required`. Each call to a getter method is followed by a call to `ejbStore()` and `delay-updates-until-end-of-tx` was `false`. However, before calling `ejbStore` on the bean the container did not call the `isModified` method. The `isModified()` method was only called when the transaction committed. `ejbStore` should be called from `postInvoke()` depending on the result of the `isModified` method in the bean. The problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR106711 | Optimistic concurrency with a version column did not work in combination with bulk updates. (An "ORA-01008: not all variables bound" SQLException was thrown.) This problem was resolved by using the correct bean state tracking variable so the EJB container sets all of the variables in the SQL statement, including the version column. Optimistic concurrency with a version column now works in combination with bulk updates. | 8.1 SP2
CR107447 | The EJB QL query generator could not handle: `SELECT OBJECT(`target`)` where target is collection member variable as in: `SELECT OBJECT(target) FROM EJBean AS bean, IN(bean.collection)`target`` This problem has been fixed. The EJB QL compiler now properly handles this case. | 8.1 SP2
CR107455 | The `ROManager` was forced to add duplicate entries to its internal LRU list. This resulted in unlimited growth of the list, which lead to `OutOfMemoryErrors`. The duplicate entries occurred because of an unnecessary call to the `initLastLoad()` method in the `DBManager` method `getBeanFromRS()`. Removing the unnecessary call fixed the problem. | 8.1 SP2
CR108456 | With a CMR one-to-many relationship, in a single transaction, if the bean on the one side was accessed but not changed, the dependency between the database operations was not resolved properly by the container. This resulted in a java.sql.SQLException. This problem was resolved by storing the related bean to the database before checking the state of the current bean. | 8.1 SP2
CR109621 | The EJB container automatically detects situations where an EJB has been changed in a possibly incompatible way since it was last compiled. If such a change is detected, the EJB is automatically recompiled. Previously, any change to a deployment descriptor would result in such recompilation. Some changes, however, are guaranteed not to change the EJB, such as adding whitespace to a deployment descriptor. Such a change should not have caused the EJB to be recompiled. The algorithm used to determine whether an EJB needs to be recompiled now disregards whitespace in deployment descriptors when determining whether the descriptor has changed. Thus, an EJB is not recompiled needlessly when only whitespace is changed in a deployment descriptor. | 8.1 SP2
CR110917 | When using stateful session beans under load with `home-is-clusterable` set to `true` and `replication-type` set to `InMemory`, the proxy objects on the secondary server that call the bean were not being unexported and were therefore leaking. This resulted in an `OutOfMemoryError`. WebLogic Server now unexports the proxy objects on the secondary server. When the Replicated bean receives a `becomeUnregistered()` callback from the `ReplicationService`, the corresponding proxy object on the secondary server is unexported in the `StatefulEJBHome.removeSecondary()` method. There should not be any negative side-effects on existing user applications. | 7.0 SP5 8.1 SP2
CR111233 CR122832 | When a MDB and JMS server were targeted to different Weblogic Server instances, the MDB was not receiving messages. This problem occurred because the EJB container was not creating the necessary MDB pool, as they are not co-located. This problem has been fixed. When the MDB's destination is non-distributed and non-migratable, then the co-location rule is not applied. | 8.1 SP2
CR111476 | If an EJB uses container-managed transactions, the EJB specification requires transaction attributes to be set for all EJB methods (excluding methods of `EJBObject`\`EJBLocalObject` for session beans and all methods of the `home`\`local-home` interface for session beans). Previously, a method not assigned a transaction attribute would use a default value of `Supports` for interface methods and `NotSupported` for a message-driven bean's `onMessage` method. These default values did not result in transactions being started and this caught several customers by surprise. If any EJB methods are missing a transaction attribute setting, the default transaction attribute is still used for the method. However, a warning is now issued to alert users to the situation. Users can eliminate the warning by setting an explicit transaction attribute for the affected method(s) in the `ejb-jar.xml` deployment descriptor. Thus, users may now see warnings about missing transaction attribute settings when they run the EJB compiler and during EJB deployment. | 8.1 SP2
CR112225 | For BLOBs, in the generated code, WebLogic Server calls `ObjectOutputStream.writeObject` and `ObjectInputStream.readObject` to serialize/deserialize the object before writing/reading it to the database. These calls add extra header information. The `writeObject` method writes the class of the object, the signature of the class, the values of the non-transient and non-static fields of the class, and all of its supertypes are written. (This is the reason for the extra header seen in the database.) These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because it uses `readObject` to convert the bytes into the appropriate object, which needs that extra header information. However, if the BLOB has been inserted directly into the database by some other vendor or programmer using: `OutputStream os = ((weblogic.jdbc.common.OracleBlob) lob).getBinaryOutputStream(); os.write(this.tiffImage); // byte[] tiffImage` then problems may occur because WebLogic Server uses `readObject` and the header information is missing. For the data inserted using WebLogic Server , the other programs that would read the bytes directly get the extra header information and fail. `<serialize-byte-array-to-oracle-blob>` has been added to control the persistence behavior. This element is used to specify whether a `cmp-field` of type `byte[]` mapped to an OracleBlob should be serialized. The tag has been added to a new compatibility stanza in the `weblogic-cmp-rdbms` descriptor. Note that, in versions prior to SP2, the default behavior was to serialize a `cmp-field` of type `byte[]` mapped to an OracleBlob. Now, the `byte[]` is written directly to the `OutputStream` obtained from the BLOB. To revert to the old behavior, set the value of this tag to `true`. | 8.1 SP2
CR112615 | Use of the XA driver meant there was no guarantee that WebLogic Server obtained the same connection from the DataSource even when in the same transaction. The Insert was made using one connection and then queried with SELECT SCOPE_IDENTITY using another connection. The SCOPE_IDENTITY produced incorrect results in this case. The auto-key-gen feature for SQLServer2000 required SELECT SCOPE_IDENTITY() to get the value of the auto-gen key. The SCOPE_IDENTITY function can now used in the same scope (that is, in the same stored procedure, function, or batch). The code generation was changed to perform a batched query when the database is SQLServer or SQLServer2000 and AutoKeyGen is turned on. The GenKeyQuery will be fired immediately after the INSERT as follows: `__WL_query_array[0] = "INSERT INTO Employees (LastName, FirstName, Title, TitleOfCourtesy, BirthDate, HireDate, Address, City, Region, PostalCode, Country, HomePhone, Extension, Photo, Notes, ReportsTo, PhotoPath) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) SELECT SCOPE_IDENTITY()";` and the cmp-field will be assigned the auto generated key value. This change has no impact or side-effects other than resolving the problem of an incorrect primary key being returned when using SQLServer2000 with AutoKeyGen with a XA driver. | 8.1 SP2
CR112661 | The code to expand the size of the thread pool used for message-driven bean polling was failing due to a change in the "Kernel" APIs. The code for the MDB container was fixed to properly use the kernel APIs. Customers will now be able to deploy more than one MDB that receives messages from a foreign JMS provider with XA and have each MDB successfully receive messages. | 8.1 SP2
CR112703 | The `JMSConnectionPoller` did not know the identity of the user that it needed to pass to the WebLogic Security Framework to get the remote username and password. This remote username and password is required for establishing a JMS connection with the remote JMS Server (MQ, WebLogic, and so on). This fix resolves the problem, but customers need to configure a security identity for an MDB. For instructions on how to do this, see Configuring a Security Identity for Message-Driven Beans in Programming WebLogic Enterprise JavaBeans. | 8.1 SP2
CR113172 | When the AutoKey was specified in the `cmp-rdbms.xml` file as follows: `<automatic-key-generation> <generator-type>ORACLE</generator-type> <generator-name>scott.oracle_sequence</generator-name> <key-cache-size>10</key-cache-size> </automatic-key-generation>` (that is, the generator name is `schemaName.sequenceName`) WebLogic Server was not taking the schema name into account while performing the query to select the increment value. The schema name provided in the `<generator-name>` is now taken into account, and the queries are generated as follows: If the users specify the `<generator-name>` as `schemaName.sequenceName` in the `weblogic-cmp-rdbms-jar.xml`, WebLogic Server generates the following query to read the `INCREMENT_BY`: `query = "SELECT INCREMENT_BY "+ "FROM ALL_SEQUENCES "+ "WHERE SEQUENCE_NAME = UPPER('"+sequenceName+"') " + " AND SEQUENCE_OWNER = UPPER('"+schemaName+"')";` If users specify the `<generator-name>` without the schema, the query will be: `query = "SELECT INCREMENT_BY "+ "FROM USER_SEQUENCES "+ "WHERE SEQUENCE_NAME = UPPER('"+sequenceName+"')";` In the second query, WebLogic Server makes use of the `USER_SEQUENCES` view instead of `ALL_SEQUENCES`. This takes care of the case where two or more users have declared a sequence with the same name. A query to the `USER_SEQUENCES` view restricts the `ResultSet` to the user view with a connection to Oracle. | 8.1 SP2
CR116696 | The `setBytes()` method on the preparedStatement had issues when the `byte[]` data was greater than 4K. This problem was resolved by replacing the `setBinaryStream()` method with the `setBytes()` method. As a result, the cmp11 generated code has changed. Customers wanting to take advantage of this fix will have to rerun ejbc on their EJBs to generate the new code. Otherwise, this change will not have any impact. | 8.1 SP2
CR120257 | The EJB container code was not expecting the "Adaptive Server Enterprise" string as the correct database product name for the Sybase database. It was expecting the "Sybase" string in the product name. Because the WebLogic Sybase JDBC driver sends the database product name as "Adaptive Server Enterprise," this string is now considered in the database type verification code of the cmp descriptors. | 8.1 SP2
CR120300 | An extra AND was appended for ANSI compliant LEFT OUTER JOIN for the following databases: SqlServer2000, Pointbase and DB2. The code was modified not to append AND while generating ANSI compliant LEFT OUTER JOIN for these databases. No side-effects should result from fixing this problem. | 8.1 SP2
CR121143 | The EJB was correctly failing to deploy because the database table it depended on did not exist. The EJB was configured so the table would be automatically created during deployment if it did not exist. However, the server was in production mode and the auto table creation feature is only supported when the server is in development mode, so the table was not created by the EJB container. There was a problem in that the EJB container was not communicating this information properly to customers. A message was added, explaining auto table creation settings will be disregarded when the server is in production mode. In addition, each Managed Server now logs when an EJB deployment fails because of a missing database table. | 8.1 SP2
CR122511 | The `wls510-read.xpi` was not setting the `PersistenceMBean.setFindersLoadBean()` when the `<finders-call-ejbload>` element was encountered in the 5.1 `weblogic-ejb-jar.xml` deployment descriptor. When the `<finders-call-ejbload>` element is encountered in the 5.1 `weblogic-ejb-jar.xml` deployment descriptor, WebLogic Server now sets it on the `PersistenceMBean`. `<processing-action element="finders-call-ejbload" element-context="persistence-descriptor"> <validation nullable="false" values="true|True|false|False"/> <java> if(bd.isEntity()) { bd.getPersistence().setFindersLoadBean( "True".equalsIgnoreCase( @VALUE{} )); } </java> </processing-action>` | 8.1 SP2
CR124954 | The documentation for the procedure "Configure a Security Identity for a Message-Driven Bean" was missing some steps. This has been corrected, and the updated documentation can be found at http://edocs.bea.com/wls/docs81/ejb/message_beans.html#ConfiguringaSecurityIdentityforaMessage-DrivenBean. | 8.1 SP2

## Installation

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR105921 | The state was not preserved on the "Choose BEA Home Directory" panel. The state of controls on the above referenced panel is now retained. Paging back to the "Choose BEA Home Directory" panel will show expected UI control state based on prior user interaction. | 8.1 SP2
CR111201 | The internal URL format used for database loading was not normalized for all potential runtime platforms. This problem resulted, for example, in a `java.lang.IllegalArgumentException` when customers attempted to create an e2e domain from the e2e domain template using the Configuration Wizard on Solaris platforms. The URL format used for database loading has been normalized to enable cross platform compatibility. | 8.1 SP2

## J2EE

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR110964 | The J2EEApplicationContainer notifies the listeners of the application deployment phase. During this time, the thread had the system classloader as the contextclassloader. The listener is now notified of the application deployment event with the application classloader as the thread's contextclassloader. | 8.1 SP2
CR111138 | J2EEApplicationContainer was not notifying the application listeners regarding the "PRESTOP" event on the applications during the server shutdown. Code was added to fire the notifications. Application listeners now receive the PRESTOP notifications. | 8.1 SP2
CR122772 | JNDI lookup could not resolve an object because the EJB `HomeImpl` class was not found. This situation resulted in inconsistent assertions and occurred because the `HomeImpl` class was searched on a classloader different from the one with which the EJB was originally deployed. The `J2EEContainer` code was fixed to ensure that the `CLNode` annotation is unique. One annotation should resolve to one `CLNode`. If this service pack is used, then it should be used in all the clustered servers. Otherwise there are no side-effects. | 8.1 SP2

## JCOM

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR108495 | When using `com2wls`, the security context was not getting propagated between client invocations. A code fix now ensures that a cache is maintained on the server-side when NTLM authentication is not used. When a user is authenticated as a part of the first request from the JCOM client, the client's `ThreadContext`, the `AuthenticatedSubject`, and the `LastAccesssedTime` are stored in the cache. If a client remains idle for more than 5 minutes (configured via the `weblogic.jcom.clientTimeout` property), WebLogic Server removes that client entry from the cache. The trigger frequency is 1 minute by default (configured via `weblogic.jcom.invalidationInterval` property). This property controls how frequently WebLogic Server runs the trigger to check the cache and clean up idle clients. Note that the values for these properties must be specified in milliseconds. | 8.1 SP2
CR120495 | DCOM sockets were timing out based on the DefaultNetworkChannel's idle connection timeout value. This would result in the DCOM socket being closed. Code was added to ensure that the DCOM connections will not timeout. | 8.1 SP2

## JDBC

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR093038 | WebLogic Server now provides support for Oracle Virtual Private Databases (VPDs). A VPD is an aggregation of server-enforced, application-defined fine-grained access control, combined with a secure application context in the Oracle 9i database server. For more information, see Programming with Oracle Virtual Private Databases in Programming WebLogic JDBC. | 7.0 SP3 8.1 SP2
CR104968 | WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a `java.sql.SQLException` when retrieving double or float values if a comma (\Q,') was used as a decimal separator in the database: `java.sql.SQLException: java.lang.NumberFormatException - '1,2' at weblogic.jdbc.oci.ResultSet.getFloat(ResultSet.java:312) at weblogic.jdbc.jta.ResultSet.getFloat(ResultSet.java:190) at weblogic.jdbc.rmi.internal.ResultSetImpl.getFloat(ResultSetImpl.java:224) at weblogic.jdbc.rmi.internal.ResultSetStraightReader.getFloat(ResultSetStraightReader.java:67) at weblogic.jdbc.rmi.SerialResultSet.getFloat(SerialResultSet.java:219) at examples.servlets.DBAccess.service(DBAccess.java:54) at [...]` The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR106522 | The WebLogic Server jDriver for MS SQLServer can mistakenly accept the`jdbc:microsoft:...` URL for the Microsoft JDBC driver. If a JVM tries to use both drivers, loading the WebLogic Server driver first prevents the Microsoft driver from being used. This jDriver has been deprecated. | 7.0 SP4 8.1 SP2
CR107474 | `OciObjectStream` did not nullify a buffer after a `close()` was performed. This problem was resolved with a code fix. | 6.1 SP6 8.1 SP2
CR108051 | Using LDAP with SSL caused a `NullPointerException`. This problem occurred because the MuxableSocketLDAP registered itself directly (instead of the SSLFilter for itself) with the socket muxer. Thus, when SSL was used, it was not accessing the right muxable socket instance. This problem was resolved by a change the MuxableSocketLDAP code, so that it registers the SSLFilter with the socket muxer. | 8.1 SP2
CR108436 | A transactional (JTS) JDBC connection could falsely return true for the `isClosed()` method in a remote application. The cause of the problem was an unnecessary and failure-prone delegation of the `isClosed()` call to the remote connection rather than simply reporting the already-known state of the RMI connection. The RMI connection object was modified to return the known state. User code now works as expected with `isClosed()`. | 8.1 SP2
CR109268 | When a JNDI lookup on a JDBC DataSource and then a `ds.getConnection` was performed in applet code, a Security Exception that indicated there was no privilege to generate code in the applet would be thrown. `JDBCWrapperFactory` now detects whether the lookup is performed within the applet JVM. If it is, rather than generating a JDBC RMI wrapper class in the applet JVM, a request will be sent to `ClasspathServlet`. `ClasspathServlet` will generate the JDBC RMI wrapper classes on the server side, then ship them back to the applet. Applets do not work with JDBC RMI without this fix. | 8.1 SP2
CR111136 | WebLogic Server's Oracle jDriver now understands the non-standard Oracle CURSOR output parameter type, whose numerical value is -10. Customers wanting to use WebLogic Server's Oracle jDriver to accommodate a WebLogic extension will no longer get exceptions. | 8.1 SP2
CR111230 | During EJB deployment time, certain validations are done to verify the table, check if connection pools exist or not, and so on. If any of these validations fail, a `DeploymentException` is thrown. In this case, the `DeploymentException` was being thrown because the `TableVerifier.checkPool()` method returned `false`. This problem occurred because in `weblogic.jdbc.common.internal.ConnectionPoolManager.poolExists()` method, WebLogic Server only checked whether the pool (used by the EJB) existed in the list of available connection pools, and failed to do the same for the list of MultiPools. For the pool associated with the DataSource for the CMP EJB, WebLogic Server now checks that the pool exists in both the connection pool list and the MultiPool list. As a result, customers can use a DataSource mapped to a multipool inside a CMP EJB. | 8.1 SP2
CR120224 | Many of the Sybase JDBC driver's metadata methods, including `getAutoCommit()`, interacted with the DBMS in a way that caused the DBMS to think a transaction had been started. This precluded any further changes to transaction properties. For example, the following valid JDBC code caused an application to receive an exception stating: `can't call set CHAINED within a transaction': `Connection c = ... // get fresh connection c.setAutCommit(false); // set connection for future multistatement tx's // Now test connection (like after a tx) Change back to default mode if needed if (c.getAutoCommit()) c.setAutoCommit(true); // fails here` Code that is enacted (only) when the initial call to `setAutoCommit(true)` fails has been added. In this case, WebLogic Server rolls back the transaction and retries the `setAutoCommit()`. BEA has worked with Sybase to improve their driver, and as of this writing, the latest EBFs of the Sybase driver should include changes that will also fix this problem. | 8.1 SP2
CR121635 | When running WebLogic Server with the WebLogic Sybase XA JDBC driver, attempts to create a table after suspending the current transaction and starting a new transaction failed, but no exception was thrown. This problem occurred because of cleanup processing WebLogic Server does inside the JDBC layer. When application code calls `commit()`, WebLogic Server internally checks the Auto Commit setting for the connection. When running with Sybase XA, WebLogic Server needs to call a `rollback()` because the `getAutoCommit()` call starts a local transaction. This `rollback()` also causes the SQL DDL call to create the table to be rolled back. Thus, the table will appear to not have been created. This problem was resolved by removing the call to `rollback()` after calls to `get/setAutoCommit` and `get/setTransactionIsolation` for the Sybase XA driver. Application code now gets the correct results. | 8.1 SP2
CR125320 | A server thread dump showed a deadlock with one thread calling `JTSConnection.doClose()`, which was blocked in this method. This problem occurred because `doClose()` had a block synchronized on the `JTSConnection` with the purpose of ensuring only one thread went into the block at a time. Unfortunately, any other thread running any other synchronized `JTSConnection` method would stop a thread getting this `doClose()` block. A private locking object for the `doClose()` block was provided. As a result of this fix, there will be no detectable change in behavior, except for fortunate cases where a deadlock is averted and normal function proceeds. | 8.1 SP2
CR125496 | Oracle-related JDBC operations hung when the `ResourcePool` maintenance thread locked the resource pool and attempted to obtain a connection that was being held by other threads. This problem occurred because `doClose()` had a block synchronized on the `JTSConnection` with the purpose of ensuring only one thread went into the block at a time. Unfortunately, any other thread running any other synchronized `JTSConnection` method would stop a thread getting this `doClose()` block. A private locking object for the `doClose()` block was provided. As a result of this fix, there will be no detectable change in behavior, except for fortunate cases where a deadlock is averted and normal function proceeds. | 8.1 SP2
CR126038 | Oracle OCI NativeXA does not allow a connection to be used by threads other than the one where it is created. The WebLogic Server connection pooling algorithm assumed that a connection could be used by any thread, as this is the behavior of all other JDBC drivers (including the Oracle Thin Driver). Customers who used Oracle OCI NativeXA with this connection pooling algorithm received an `XAException`. This problem was resolved by pinning the connection to the thread. As a result of this fix, every thread now has its own connection for every connection pool. | 8.1 SP2
CR127969 | Applications with stringent RASP and HA requirements require Pools to be capable of gracefully recovering from failure conditions such as failure of the database server, the machine hosting the database server, network connectivity to the machine hosting the database server, and so on. The above requires applications to put upper bounds on: 1. How long a request to create JDBC connections stays blocked 2. How long a statement executes and require support from the JDBC driver; the BEA WebLogic Type 4 JDBC drivers now provide this support. Item 1 is configurable by simply setting the corresponding driver property in the connection pool definition. Item 2 requires support from WebLogic Server and is exposed via the following pool attributes: `testStatementTimeout`—the time after which the test statement query (specified by applications using the pool attribute `TestTableName`) currently being executed will be timed-out. The default value implies that this feature is disabled. `statementTimeout`—the time after which a statement currently being executed will be timed-out. The default value implies that this feature is disabled. For more information about the BEA WebLogic Type 4 JDBC drivers, see WebLogic Type 4 JDBC Drivers. For more information about the testStatementTimeout and statementTimeout attributes, see Timeouts for JDBC Connection Creation and Statement Execution. | 8.1 SP2

## JMS

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR103213 | When the server failed to send JMS messages, there was no error message on the client. The transaction manager had declared the messages unhealthy, and JMS was rolling back the messages when it failed to enlist resources. The failure to enlist the transaction is now communicated back to client, which will be able to report that the commit failed. | 7.0 SP3 8.1 SP2
CR103596 | Under a rare situation on a multiprocessor computer, a `NullPointerException` could occur when a message was acknowledged twice. The code was changed to protect against a `NullPointerException`. Thus, the `NullPointerException` will no longer occur in this situation. | 7.0 SP4 8.1 SP2
CR104538 | A JMS deadlock was fixed by changing the `BESession.java close(long lastSequenceNumber)` method. The deadlock could be viewed in the partial thread dump: `ExecuteThread: '9' for queue: 'queue_1'" daemon prio=5 tid=0x2757938 nid=0x5e waiting for monitor entry [0xce97f000..0xce97fc68] at weblogic.jms.backend.BETopic._addMessageToConsumers(BETopic java:590) at weblogic.jms.backend.BETopic.addMessageToConsumers(BETopic.java:296) at weblogic.jms.backend.BEMessageWriteListener.storeIOComplete(BEMessageWriteListener.java:85) at weblogic.jms.store.StoreRequest.execute(StoreRequest.java:342) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) "ExecuteThread: '14' for queue: 'queue_2'" daemon prio=5 tid=0x57b200 nid=0x54 waiting for monitor entry [0xd1b7f000..0xd1b7fc68] at weblogic.jms.backend.BESession.stop(BESession.java:386) at weblogic.jms.backend.BESession.close(BESession.java:434) at weblogic.jms.backend.BESession.close(BESession.java:1083) at weblogic.jms.backend.BESession.invoke(BESession.java:1024) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:585)....` | 6.1 SP6 8.1 SP2
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 SP4 8.1 SP2
CR106538 | When a new Topic Member X was added to a Distributed Topic, consumers on previous Members Y and Z would not get messages published to X. When Member X was on a Migratable Target and added to the Distributed Topic while Y and Z were already booted. Rebooting Y and Z should not be required. This problem was resolved with a code fix to register dynamically added members. Messages published to X are now available on Y and Z. | 8.1 SP2
CR106789 | A memory leak occurred because unused JMS objects remained open. The problem was resolved by the following fixes: Normalized the destination for all the Producers created on the same destination. Removed the listener from the correct `DispatcherWrapperState` when substituting the `DispatcherWrapperState` for `FEProducer` Removed the listener from the correct `DispatcherWrapperState` when closing the `FEProducer` unconditionally Removed the leak for Temporary Destinations on `FrontEnd` when the `BackEnd` goes down. | 7.0 SP3 8.1 SP2
CR108665 | The JMS server deleted an expired message from the persistent store when a queue browser still had the message in its reference list, resulting in a paging IO exception. A code change improved the handling of paging and resolved the problem. | 7.0 SP4 8.1 SP2
CR109599 | Due to limitations in the Microsoft-provided SQL Server driver, the JMS JDBC store did not work with this driver. The JMS JDBC store software was changed to code around the driver limitation. Thus, the JMS JDBC store can now use the SQL Server driver provided by Microsoft. | 7.0 SP4 8.1 SP2
CR111172 | Foreign JMS Service Provider names were required to be unique. Otherwise, WebLogic Server threw a PROTO error. WebLogic Server has changed the name of the XAResource that is registered by the JMS wrapper code to include the domain name and server name. The JMS TxResource name for `foreignServiceProvider` has been made unique by adding `domain+servername` to the `resourcename`. Thus, the naming convention used to register a foreign JMS provider with an EJB or a servlet has been changed. When using a foreign provider (such as MQSeries) with an EJB or a servlet using the "resource-reference" feature, you must gracefully shut down your WebLogic Server instance to ensure that there are no outstanding two-phase commit transactions before installing this SP. Otherwise, "in-doubt" transactions on the foreign JMS server may not be properly resolved after the server is restarted with the SP the first time. This limitation does not apply to message-driven beans. Also, this precaution is only necessary the first time the server is started after installing this SP, not every time the server is started. | 8.1 SP2
CR111538 | If `res-auth` was set to `Application`, `JMSConnectionHelper` was not allowing a null value for the username and password. The `weblogic.deployment.jms.JMSConnectionHelper` constructor has been modified to allow null for the username and password in cases where `res-auth` is set to `Application`. Thus, a `SecurityException` will no longer be thrown for a null username and password if `res-auth` set to `Application`. | 8.1 SP2
CR112431 | The Bytes Maximum and Messages Maximum fields on the Thresholds and Quotas tab for JMS destinations only accepted 32-bit integers, although the help text specified that 64-bit integers were accepted. The validation was corrected to allow for a 64-bit integer. | 8.1 SP2
CR121011 CR126883 | A `NullPointerException` resulted on the restart of a JMS Server when a message in the JMS Store had a `ReplyTo` that was not in the same cluster to which the store belonged and was a Distributed Destination. This problem occurred because WebLogic Server attempted to locate the `configMBeanName` for the DD member instance that was written to the store, but could not. The code has been modified so that if WebLogic Server cannot locate the `configMBeanName`, then it will use the instance name and create a `DestinationImpl` (non-DD queue) for the `replyTo` field. In other words, WebLogic Server will downgrade the `replyTo` queue from a `DistributedDestination` to a normal destination for this scenario. Clients using this `replyTo` will not get load balancing. | 7.0 SP5 8.1 SP2
CR122749 | Sorting on a `DestinationKey JMSCorrelationID` could have resulted in a `NullPointerException` if not all of the messages in the queue had a `JMSCorrelationID` set. The same failure could have occurred for `DestinationKey` `JMSType`. Code was modified to check for a null `JMSCorrelationID` and null `JMSTypes` before calling `compareTo`. As a result, sorting will work correctly, without throwing a `NullPointerException`. | 8.1 SP2 6.1 SP6
CR129067 | The JMS Server failed to create tables in SQL Server 2K when configured with case sensitive sort order. This problem occurred because JMS was changing the name of tables during creation to all uppercase letters. During creation of JMS tables, table names are now kept as it is, without making all of them upper case. Thus, JMS will now work for all types of SQL Server 2K installations. | 8.1 SP2

## JNDI

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR103148 | A startup class failed to access the local instance `MBeanHome` with `LOCAL_JNDI_NAME` (`weblogic.management.home.localhome`) with `LoadBeforeAppDeployments` set to true. It failed with the following error message: `Unable to resolve 'weblogic.management.home.localhome' Resolved: 'weblogic.management' Unresolved:'home'` Moving the bindings of the other JNDI names into the AdminService so that they are available to startup classes fixed the problem. | 7.0 SP3 8.1 SP2
CR120522 | When a context is created a `TransactionHelperImpl` object is pushed onto the stack. When the context is closed the pushed object is popped. While creating a subcontext, the `TransactionHelperImpl` object was not being pushed onto the stack but when the subcontext was closed, it tried to pop the object resulting in an `EmptyStackException`. The code was modified to push the `TransactionHelperImpl` object while creating a subcontext. An `EmptyStackException` will no longer be seen if subcontexts are created and closed. | 8.1 SP2
CR122820 | Binding a remote object from a Managed Server to the Administration Server using a startup class and then looking it up resulted in a `java.io.StreamCorruptedException` on the Managed Server. This problem occurred because the stub of the remote object was being passed over the wire, instead of a dynamically-generated stub from a `StubInfo` object. The problem was solved by modifying the `weblogic.rmi.utils.io.RemoteObjectReplacer replaceObject` method. Now, before writing the stub on the wire, it is replaced with a `StubInfo` object. As a result of this change, a client that binds a remote object to the JNDI tree of the server will be able to look up that object and invoke methods on it. | 8.1 SP2

## JTA

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR091974 | If XA recovery did not return an XID, WebLogic Server could throw a `NullPointerException`: `java.lang.NullPointerException at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:721) at weblogic.transaction.internal.ServerSCInfo.rollback(ServerSCInfo.java:318) at weblogic.transaction.internal.ResourceDescriptor.rollbackXids(ResourceDescriptor.java:1160) at weblogic.transaction.internal.ResourceDescriptor.recover(ResourceDescriptor.java:1060) at weblogic.transaction.internal.ResourceDescriptor.access$9(ResourceDescriptor.java:1029) at weblogic.transaction.internal.ResourceDescriptor$1.execute(ResourceDescriptor.java:770) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)` The code was modified to check for the presence of an XID and prevent the exception from occurring. | 6.1 SP6 8.1 SP2
CR092301 CR107866 | A `NullPointerException` exception could occur during transaction coordination for some configurations. This problem was fixed by a code change. | 7.0 SP3 8.1 SP2
CR108952 | The Sybase JConnect XA driver started local transactions when set/getAutoCommit or set/getTransactionIsolation methods were called. This resulted in errors like the following: `XAER_RMERR : A resource manager error has occurred in the transaction branch javax.transaction.xa.XAException at com.sybase.jdbc2.jdbc.SybXAResource.sendRPC(SybXAResource.java:711) at com.sybase.jdbc2.jdbc.SybXAResource.sendRPC(SybXAResource.java:602) at com.sybase.jdbc2.jdbc.SybXAResource.start(SybXAResource.java:312) at weblogic.jdbc.jta.VendorXAResource.start(VendorXAResource.java:41) at weblogic.jdbc.jta.DataSource.start(DataSource.java:569) at weblogic.transaction.internal.ServerResourceInfo.start(ServerResourceInfo.java:1165) at weblogic.transaction.internal.ServerResourceInfo.xaStart(ServerResourceInfo.java:1108) at weblogic.transaction.internal.ServerResourceInfo.enlist(ServerResourceInfo.java:287) at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:391) at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1143) at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1098) at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145) at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:211)` WebLogic Server now calls `connection.rollback()` after any invocation of the above methods. Thus, these errors will no longer be seen. | 8.1 SP2
CR111719 | The attribute `KeepXAConnTillTxComplete`, which is required for XA connection pools, now only performs a check if the XA isolation level has changed. | 7.0 SP4 8.1 SP2
CR116697 | The following `SQLException` occurred when customers attempted to migrate their system from WebLogic Server 6.1: `java.sql.SQLException: start() failed on resource 'weblogic.jdbc.wrapper.JTSXAResourceImpl': XAER_RMFAIL : Resource manager is unavailable` This problem occurred because the transaction blocked this XAResource for more than 2 minutes, so the JTA health monitoring system decided to disable its connection pool completely because the XAResource was supposed to be unavailable. This problem was resolved by importing the correct class to allow for the disabling of health monitoring. | 8.1 SP2

## Node Manager

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR092678 | Many parts of WebLogic Server encrypt credentials using a salt. When attempting to reuse the same file with a different salt, a "bad padding exception" (because of a salt mismatch) occurred. This exception was thrown when WebLogic Server was not able to decrypt the password written in a previous incarnation. WebLogic Server now catches this exception and prints a message stating the problem and the corrective action one should take. | 8.1 SP2
CR104285 | Node Manager's shared object code could cause a segment violation if certain code paths were taken while starting a server instance. The same code paths also failed when using IBM's zLinux JDK. These problems were solved with a code fix to Node Manager. | 6.1 SP6 8.1 SP2
CR111339 | Attempts to start multiple WebLogic Server instances using Node Manager on slower hardware produced the following error: `<Jun 25, 2003 5:16:15 PM CDT> <Error> <NodeManager@192.168.190.4:5555> <__COMMAND_EXCEPTION__Request: failed to execute command 'online' on server 'ifgw1catapp4 - reason: '[JavaProcessControlOnline: Could not get valid pid for WebLogic process.]'>` This problem occurred because Node Manager looked for the PID file before there had been a chance to write to that file. A new property allows users to specify how many times Node Manager will retry reading the PID from the file. Every retry will have a 2 second wait. The property introduced is `PIDFileReadRetryCount`, which can be specified as a system property or in the `nodemanager.properties` file. When the value of `PIDFileReadRetryCount` is greater than zero, Node Manager attempts `PIDFileReadRetryCount` number of times before giving up on reading the PID from the file. The default value of `PIDFileReadRetryCount` is zero, so there is no change in default behavior. | 8.1 SP2
CR111639 | If debug was turned on, the password for starting the Managed Server was being printed in plain text in the Node Manager logs. The password is no longer printed in the logs even if debug is turned on. | 8.1 SP2
CR125829 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. | 8.1 SP2

## Plug-Ins

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR087204 | [Apache] In WebLogic Server 6.1 SP03, PathTrim and PathPrepend added an unexpected "/" at the end of URL. After PathTrim was applied to the original URL and it results to '/', an extra '/' was appended to the PathPrepend variable. This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR086224 | (NSAPI) Plug-in did not read the `SESSIONID` from post data. Analysis revealed a problem in `getPreferredServersFromCookie()`. When `session.getId()` was kept as post data, `getId()` included an extra string: `|time`. The problem was solved by a code fix. | 6.1 SP5 8.1 SP2
CR091910 | (Apache) the Apache plug-in did not read `PathPrepend` when using `<IfModule mod_weblogic.c>`. The problem occurred with plug-ins for Apache 1.3.x and Apache 2.0.43. The problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR106764 | (NSAPI) A thread in the plug-in could obtain a critical lock for a long duration (5 minutes by default, or configured using `WLIOTimeoutSecs`), blocking all other threads and making WebLogic Server appear to hang. This problem was fixed with a code change to the plug-in. | 6.1 SP6 8.1 SP2
CR107254 | (Apache) Because Hewlett-Packard ceased to support the HP Apache-based Web Server version 1.3.x, WebLogic Server removed the Apache 1.3 plug-in for HP. | 7.0 SP3 8.1 SP2
CR108092 | (ISAPI) The ISAPI plug-in logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line: `The HTTP Server encountered an unhandled exception while processing the ISAPI Application.` This problem was solved with a code fix to the ISAPI plug-in. | 6.1 SP6 8.1 SP2
CR108747 | (NSAPI) The plug-in that shipped with WebLogic Server used the `WL-Proxy-Client-IP` header to send client IP addresses. This caused problems in heterogeneous environments, because earlier servers expected the plug-in to use the `X-Forwarded-For` and `Proxy-Client-IP` headers to transmit client IP addresses. The code was fixed to include both the `X-Forwarded-For` and `Proxy-Client-IP` headers, as well as `WL-Proxy-Client-IP`, so that heterogeneous environments can retrieve client addresses without modification. | 6.1 SP6 8.1 SP2
> CR109755 | (Apache) The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (`*/?`). This could cause 404 errors to occur when using parameters such as:
>     LocationMatch "/weblogic/(abc|def)/ghi"
This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR120806 | (Apache) Not passing back the status from the Java command made it impossible to tell if the command executed successfully or not. The line: `if errorlevel 1 exit /b 1` was added after the two Java commands in the `ant.bat` file. Therefore, the status of the Java commands are now passed back to the shell if they fail. | 8.1 SP2
CR121341 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp. | 6.1 SP6 7.0 SP5 8.1 SP2
CR123149 | (All) As of WebLogic Server 6.1 SP6, 7.0 SP5, and 8.1 SP2, the WebLogic plug-ins are now certified to proxy to any version of WebLogic, including 5.1. | 8.1 SP2

## RMI/RMI-IIOP

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR124806 | Multiple problems were found in iiop tunneling - - Assertion violation when registering for pending responses due to HttpURLConnection retrying some http requests when tunneling. - Thin client attempting a direct connection to the cluster nodes instead of going through the plug-in or load balancer - Method descriptor corruption due to thread safety problem. The above mentioned problems were fixed by adding code to - Detect duplicate http requests made by HttpURLConnection and discard duplicate pending responses. - Ensure that all requests made by iiop thin client during tunneling will go through the proxy. - Ensure that iiop initialization is synchronized. |
CR081853 | Fixed some complicated problems with RMI-IIOP and the marshalling of complex objects, notably in environments using a mixture of JDKs. | 6.1 SP5 8.1 SP2
CR106281 | Replicated session beans under heavy load resulted in increasing heap usage and `OutOfmemoryErrors`. Analysis revealed that `examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl` objects were not being garbage-collected even when garbage collection was forced. For clustered stateful session beans, strong references were maintained to the `EOImpl` object primary in the `weblogic.rmi.cluster.PrimarySecondaryRemoteObject`. As a remove is never called on the bean, the reference to the `EOImpl` was never removed from the `eoMap`. A code fix was implemented to unexport the EO when the passivated bean has been deleted, after `session-timeout-seconds`. | 6.1 SP6 8.1 SP2
CR107547 | When using JMS and the thin-client, connection timeouts were turned off on the server side. This left the possibility of clients not being detected as dead when a network was partitioned. Timeouts are now switched back on, and the server pings the client just before closing the connection. If the ping succeeds, then the connection is not closed. As a result of this change, partitions are correctly detected when using the thin-client. | 8.1 SP2
CR108317 | Some accessors did not map properly in the ejbc-generated IDL (Interface-Definition-Language). The problem has been resolved. | 7.0 SP3 8.1 SP2
CR112648 | Tuxedo clients would crash when trying to decode a `valuetype` contained within an `any`. This problem occurred because the `TypeCode` in the `any` was set incorrectly. The `TypeCode` of the `any` is now set to that of the contained `valuetype`. As a result of this change, Tuxedo no longer crashes. | 8.1 SP2
CR112791 | Servers send component keys with host port information. Clients use that host port information to make further remote requests. In WebLogic Server 8.1, clients did not have enough information on what scheme the connection was created with, and therefore used default scheme of HTTP. The code has been modified so that the `TunneledSSLORBSocketFactory` will be created initially with the HTTPS scheme. This fix forces clients to always use an HTTPS scheme when in the context of `TunneledSSLORBSocketFactory` for all succeeding requests. | 8.1 SP2
CR116690 | The IIOP encoding routines had an element which involved linear search. This became very expensive for large data objects. The linear search problem has been removed. Marshaling large objects is now fast over RMI-IIOP. | 8.1 SP2
CR116692 | Linear search was being used for decoding indirections. This became very expensive for large objects. The linear search problem has been removed. Marshaling large objects is now fast over RMI-IIOP. | 8.1 SP2
CR120180 | When using the HTTPS protocol with thin clients and network channels (IIOPS tunneling), the server did not honor the secure protocol when sending default network channel information back to the client. As a result, the client received the response and started talking to the server directly using the information in the response, hence creating another handshake. The Connection code was modified so that it can identify whether the protocol being used is secure or not. As a result of this change, the server will correctly identify that the established connection is secure and use the correct network channel. Clients will make succeeding requests properly. | 8.1 SP2
CR120593 | When a WebLogic Server instance went down, clients did not realize it and attempted to connect to the server by sending Tunnel Recv requests. This caused additional traffic to the server when it came up. At the same time, the execution of existing JMS sessions caused the server to create a new connection with the same ID as the previous one. As a result, the server received the requests on the same connection (recv followed by send) and tried to register a pending response when it already had one, producing an `AssertionError`. A code fix now causes clients to realize that the server has died and to close the existing connection. Therefore, there is no way the client can use the existing JMS session to connect to server when the server comes back up again. The client will now get `IllegalStateExceptions` if it reuses the same JMS session after a server restart. | 8.1 SP2
CR120898 | Customers using the thin-client and tunneling experienced poor performance for large objects. This was caused by the JDK ORB splitting messages into 1k packets. The ORB has been configured to not use fragmentation when doing tunneling. As a result of this change, customers should experience up to 30% performance improvement with tunneling in the thin-client. | 8.1 SP2
CR121005 | Customers would like to register `valuetype` factories for base types. WebLogic Server could allow this by publishing repository ID lists for `valuetypes`, but there were some bugs in the handling of these. In addition, the IBM ORB sends repository ID lists. Bugs in the IIOP decoder were fixed and a new `IIOPBean` property, `UseFullRepositoryIdList`, was introduced. When customers set the `UseFullRepositoryIdList` property to `true` in `config.xml`, the WebLogic Server-IIOP runtime will send full `RepositoryId` lists for `valuetypes`. This enables C++ ORB users to register base types for decoding. However, `RepositoryId` lists are incorrectly handled by JDK 1.4.x and earlier versions of Tuxedo 8.1, so this property should only be set in exceptional circumstances. | 8.1 SP2
CR121079 | When making an initial request, the 8.1 WebLogic Server-IIOP runtime would not select the appropriate codeset for wide string transmission. The appropriate codeset for wide string transmission is now selected for all requests. Interoperability with WebLogic Server 8.1 will now work correctly. | 8.1 SP2
CR121309 | A regression was introduced in WebLogic Server 8.1 that prevented WebLogic Server from selecting an appropriate codeset for wide string transmission. It would always default to UCS-2. The appropriate codeset selection is now made. Interoperability with foreign ORBs such as WebSphere should now work correctly. | 8.1 SP2
CR121501 | The Java to IDL specification requires that interfaces of the form: `public interface FooInterface { public void mymethod() throws IOException; }` be treated as abstract interfaces just as `public interface FooInterface { public void mymethod() throws RemoteException; }` already is. The abstract interface detection routine was changed to correctly detect interfaces of this type. Interfaces of this type can now be used with the thin-client and other RMI-IIOP ORBs. | 8.1 SP2
CR121897 | The IIOP implementation in WebLogic Server incorrectly serialized `String.class` (the class itself, not an instance of the class). The serialization of `String.class` has been fixed so it can now be used in RMI-IIOP requests. | 8.1 SP2
CR122478 | The `ORB.string_to_object()` method was handled incorrectly for foreign initial references. The problem was fixed by ensuring that the initial reference is encoded in the generated IOR. As a result of this change, the `ORB.string_to_object()` method now behaves correctly. | 8.1 SP2

## Security

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR085094 | After creating a domain with one Administration Server and one Managed Server, enabling the `-Djava.security.manager` for the two servers returned a `java.io.Filepermissions` error reported in the AdminServer log f`or <Error> <EmbeddedLDAP> <000000> <Error parsing Entry #19: access denied (java.io.FilePermission.\myserver\ldap\ldapfiles\EmbeddedLDAP.data read)>.` This problem was resolved by updates to the `weblogic.policy` file, to which was added information about granting permissions to user applications, and examples of grant statements. The `weblogic.policy` works for Weblogic Server Examples, Pet Store, and Workshop. It needs to be modified to be used for user configurations; instructions are in the comments at the top of the file. | 7.0 SP3 8.1 SP2
CR095836 | The default value for backup minutes is now correctly calculated and reported under domain > Domain Wide Security Settings -> Embedded LDAP in the Administration Console. | 7.0 SP3 8.1 SP2
CR096934 | Construction of an `AuthenticationProvider` was not recognizing errors, because WebLogic MBeanMaker was not seeing exceptions thrown by the `AuthenticationMBI` class constructor. The problem was resolved by a code change ensuring the propagation of errors. | 7.0 SP3 8.1 SP2
CR099759 | The `weblogic.security.acl.SSLUserInfo.getCertificates()` method was not added to the `SSLUserInfo` class for WebLogic Server 8.1 or 8.1 SP1, even though it was added for 7.0 SP2. The `getCertificates()` method has been added to `SSLUserInfo` for 8.1 SP2. | 8.1 SP2
CR101652 | In previous releases of WebLogic Server, it was not possible to make a secure connection to a third-party XML server because the XML server did not support the SSL protocol. The following workaround is provided: 1. Create a WebLogic client (a JavaServer page (JSP) deployed in WebLogic Server). 2. Create an Java authenticator class according to the Java specification. This authenticator should obtain a surname and password for the used to connect to the XML server. 3. Specify Net Permission for the Java authenticator class in the `weblogic.policy` file. The Net Permission is granted to all users of that Java VM. Note this presents a possible security weakness and should therefore be used carefully. 4. Use `java.net.HttpConnection` to establish a connection to the XML server. 5. Specify `-DUseSunHttpHandler` as a command-line argument when starting WebLogic Server. | 7.0 SP3 8.1 SP2
CR103405 | SSL initialization failed with a `Not listening for SSL, java.io.IOException: Inconsistent security configuration, null` error. This occurred when the parsing of the server certificate resulted in a null modulus & exponent. `RSAKey.toString()` did not check for a `null` value, and was therefore trying to call the `toString()` method of its null member variables. This caused the method to fail with a `NullPointerException`. A modification to the `toString()` method to check for `null` values fixed this problem. | 8.1 SP2
CR105234 | The WebLogic Server Administration Console hung while attempting to list the users and groups in an Active Directory. This problem occurred because the connection was hanging with LDAP results, causing a problem in iterating those results. The code was modified to release the connection with search results and was upgraded to new Netscape open source API. As a result of this change, the listing of users and groups in the Administration Console no longer hangs. | 8.1 SP2
CR106027 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. | 7.0 SP3 8.1 SP2
CR106357 | When multiple Authorization providers were installed, you could not define security policies on Web applications. This problem has been fixed. | 7.0 SP3 8.1 SP2
CR106404 | If you created a user that contained special characters such as "`&`", "`(`", "`)`", or "`*`" , then the user would be created in the Embedded LDAP server, but an error message would be displayed. For example, if you created a user with name `myuser&(`, then the following error message would be displayed: `weblogic.management.utils.NotFoundException: User or Group myuser&amp;(` The user `myuser&(` would be added to the Embedded LDAP server, but from then on, no users would be displayed in the console. This problem was resolved by ensuring that special characters are escaped when retrieving the users from the Embedded LDAP server. This allows the user names with special characters to be created and displayed correctly. User names with special characters can now be successfully created and displayed by the console. | 8.1 SP2
CR108886 | Clients sending a request to a WebLogic Server instance were not able to parse the returned SOAP response. This problem occurred because WebLogic Server was using a static variable to hold the prefix that the runtime uses for the SOAP envelope. The output stream now picks up the prefix for the SOAP namespace from the stream. WebLogic Server looks for the namespace currently in use by the SOAP stack. There is also a SecureSoapOutputStream constructor that allows customers to specify a preferred SOAP envelope namespace. | 8.1 SP2
CR112886 | The identity assertion naming convention (`WL-PROXY-CLIENT-*`) for headers conflicted with `WL-PROXY-CLIENT-KEYSIZE`, `WL-PROXY-SECRET-KEYSIZE` and `WL-PROXY-CLIENT-IP`. Filtering these headers as identity assertion headers avoided a Client-Cert identity assertion error. | 7.0 SP4 8.1 SP2
CR113459 | The Node Manager properties file is always created in the `<saved logs dir>/NodeManagerInternal` directory. Some customers periodically archive and delete the contents of `NodeManagerInternal`. This removes the Node Manager properties file, so that the certificate password stored in the Node Manager properties file cannot be decrypted, and Node Manager will not work correctly. The problem was solved by a code change to create the Node Manager properties file in the directory specified by `user.dir`, if the file is not found in `NodeManagerInternal`, or in the `user.dir` directory. | 6.1 SP6 8.1 SP2
CR120265 | When using `webserviceclient.jar` and `ssl.jar` in a standalone client application, the entire SOAP envelope was being written to `stdout` for every call. Attempts to disable verbose mode on the command-line and programmatically did not resolve the problem. This problem occurred because `HttpUrlConnection` was printing out the unnecessary log. This logging has been deleted, so `HttpURLConnection` no longer shows post data on the `system.out`. | 8.1 SP2
CR120460 | The ServerIron monitoring product sends a request to the SSL port during a server health check. During this health check, the SSLIOConect and related SSL objects were not released, causing an out-of-memory error. This known problem is fixed in this release. | 7.0 SP2 8.1 SP2
CR123801 | The MedRec sample application has been enhanced to support identity assertion in the LoginModule. | 8.1 SP2
CR125446 | Performance regressed from WebLogic Server 7.0 when using SSL Web Services because socket pooling was disabled. In WebLogic Server 7.0, SSLSockets were pooled in the Web Service runtime, in the thread safe socket pool that is a singleton shared across all invocations in the VM. In cases where SSL Client Authentication is used, this may lead to a problem: If there are multiple clients invoking the service within the application with different identities, the second client will possibly get the SSL Socket from the first client—this connection on this socket carries the first client identity. This is potentially a severe problem when using the client in a server setting—a transaction may occur while authenticated under the wrong identity, and this may lead to unprivileged users executing privileged actions. The shared socket pool has been replaced with a single socket that is shared only for a single client in the HTTPS binding. The socket sharing is disabled by default, however it can be enabled using either the system property or the new API provided. The default operational characteristics out of the box remain the same as WebLogic Server 8.1, with socket sharing disabled. Turning this feature on allows multiple serial invocations to share the same socket, but has the following properties that users must understand and accept: The Web Service generated client stubs are thread safe. When this socket sharing feature is enabled the client is no longer thread safe, therefore users must manage access of the client by multiple threads. The client has security properties (such as client certs and sharing sockets) that require careful thought. Additionally, users will also be tying up JVM resources, and are responsible for closing the socket. Socket sharing is "false" by default. Socket sharing is enabled using the following system property (boolean): `https.sharedsocket`. Socket sharing can also be enabled using the following API (referenced in `weblogic.webservice.binding.https.HttpsBindingInfo`) `setSocketSharing(boolean value)`. Socket sharing carries a timeout value based in seconds. This value can be set using the following system property: `https.sharedsocket.timeout`. Socket sharing timeout is defaulted to 15 seconds. Socket sharing timeout can also be set by using the following API: `setSharedSocketTimeout(long value)` where `value` is in seconds. The shared socket can also be closed using `void closeSharedSocket()`. | 8.1 SP2
CR125457 | Please review the security advisory information at http://dev2dev/resourcelibrary/advisoriesnotifications/BEA03_43.00.jsp. | 8.1 SP2
CR125829 | Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. | 8.1 SP2
CR190838 | WebLogic Server Version 8.1 uses the SUN JDK 1.4 which does not support RSA keys larger than 2048 bits. Therefore, certificates with 4096 bit keys can not be used. |

## Servlets & JSPs

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR084785 | The `GenericProxyServlet` can now handle wrapped responses. | 6.1 SP4 8.1 SP2
CR088525 | In previous WebLogic Server 8.1 Service Packs, JSP parameters with a value of "`/////`" were interpreted by the `getParameter()` as having the value "`/`". The problem was resolved with a code change. | 7.0 SP3 8.1 SP2
CR090465 | When hosting a Web application with user-defined error pages, WebLogic Server returned the following response for 400 error and closed the connection immediately, with no `Connection: close` header: `HTTP/1.1 400 Bad Request Date: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 463 Content-Type: text/html Last-Modified: Thu, 07 Nov 2002 21:56:52 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html>` The problem was solved with a code fix. | 6.1 SP5 8.1 SP2
CR091472 | A JSP compilation exception propagated to `weblogic.Deployer` by the server did not contain the exact error message and just had a stack trace. The exact compilation error, including the JSP error, has now been propagated to `weblogic.Deployer`. Thus, the exception has more details and context information. | 8.1 SP2
CR091831 | The WebLogic Server implementation of `HttpURLConnection` did not check whether keep-alive connection had been timed out on the server side when using POST method, resulting in the error: `Connection aborted by peer: socket write error` on flush. Turning off keep-alive on the server made the problem disappear. Increasing Keep-Alive periods still showed the problem with different length of sleep. Checks were added to ensure that the HttpClient is non-null before updating the timestamp. | 7.0 SP3 8.1 SP2
CR092039 | The `JspParser` threw an `UnsupportedEncodingException` for the extra quoted value in charset with JSP tag: `<%@ page contentType="text/html; charset=\"Shift_JIS\"" %>` resulted in this error: `java.lang.RuntimeException: Unknown/unsupported charset: "Shift_JIS" - java.io.UnsupportedEncodingException: Charset: '"Shift_JIS"' not recognized, and there is no alias for it in the WebServerMBean` WebLogic Server did not correctly support the HTTP specification. The problem was resolved by adding support for quoted strings and comments to `Content-Type` header charset attribute value. | 6.1 SP5 8.1 SP2
CR092625 | WebLogic Server threw a `NullPointerException` when you enabled HTTP logging on a Managed Server that was booted with HTTP logging disabled and had no existing log file. On each HTTP access to the Managed Server, the following exception was thrown: `java.lang.NullPointerException at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292) at weblogic.servlet.internal.HttpServer.log(HttpServer.java:865) at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)` The problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR093014 | Java comments that start in one scriptlet and end in the next one cause an error: `<22.07.2002 14:12:24 CEST> <Error> <HTTP>` `<[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at ....` The problem was solved by back-porting grammar from WebLogic Server 7.0 that caused the ScriptletScopeLexer to skip an entire Java comment. | 6.1 SP5 8.1 SP2
CR093520 | When you precompiled JSPs on a machine in one time zone, and then deployed those same JSPs on a server in a different time zone, WebLogic Server sometimes re-compiled the JSPs. This occurred because WebLogic Server checked JSPs by comparing the local timestamp of the JSPs (as embedded by the JAR utility) against the timestamps in the generated class files. The problem was resolved by storing the time zone at compile time and using that time zone at deployment time to determine whether recompilation is necessary. | 6.1 SP6 8.1 SP2
CR093625 | WebLogic Server misdirected output for JSP includes in JSP pages. The problem was solved with changes to the servlet engine to unify handling of includes, forwards, wrapped-responses, and JSP BodyTags. | 6.1 SP5 8.1 SP2
CR093649 | The ejb2jsp utility was generating incorrect tag classes for methods that contained parameter types other than String. The problem was fixed by changing the tag library generator to use `getAttribute` rather than `getAttributeString`. | 7.0 SP3 8.1 SP2
CR094190 | According to the JVM specification, the size limit for a method size is 64K. In WebLogic Server, a customer has JSPs with many body tags for which the generated Java code exceeded the 64K limit for the `__jspService` method. The problem was solved by a code change. Now, when an empty `BodyTag` of the form `<my:tag ... />` is encountered, the generated code that would normally set up scope for the body is replaced by a single call to a static method in `StandardTagLib.java` that tricks the `BodyTag` into thinking it is being invoked as usual from the JSP source. | 6.1 SP5 8.1 SP2
CR094252 | Displaying error/warning messages with staged copies of WAR files made it difficult to decipher the actual WAR/Web application being deployed. Now, the application name is always appended to the module name in all descriptor validation messages. As a result of this change, error messages look different from previous versions. No other side-effects are envisioned. | 8.1 SP2
CR094997 | When two interacting Web applications use different session cookie names, the session ID was lost. Analysis revealed that session attributes were not updated correctly when a Web application specifies `cookieName`, a resource from another Web application is included, and a `RemoteUser` exists in the request prior to the inclusion of the external resource. The problem was solved by a code fix. | 6.1 SP5 8.1 SP2
CR096041 | WebLogic Server no longer uses redirection (HTTP status code 302) when returning a Welcome file. WebLogic Server versions prior to 8.1 SP2 and 7.0SP4 were returning a 302 (moved temporary) status code and the location of the Welcome file. WebLogic Server versions 8.1 SP2, 7.0 SP4 and later return a 200 (OK) status code displaying the content of the Welcome file. WebLogic Server performance is improved as a result of this change, however the relative URL in the Welcome file may point to a different location which would result in a 404-Not Found error. | 7.0 SP4 8.1 SP2
CR096399 | JSP compilation errors were handled improperly. The filter communicated with `OutputStream` instead of with `HttpServletResponseWrapper getWriter`, with this result: java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream() at weblogic.servlet.internal.ServletResponseImpl.getWriter(ServletResponseImpl.java:171) at weblogic.servlet.internal.ServletRequestImpl.reportJSPFailure(ServletRequestImpl.java:227) at weblogic.servlet.internal.ServletRequestImpl.reportJSPCompilationFailure(ServletRequestImpl.java:239) at weblogic.servlet.jsp.JspStub.reportCompilationFailure(JspStub.java:523) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:430) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:210) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:517) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:351) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:445) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:20) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at WebLogic ServerBugFilter.doFilter(WebLogic ServerBugFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5418) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:744) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3086) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2544) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)... WebLogic ServerBugFilter.doFilter after The problem was fixed by the implementation of a wrapper-aware `RequestCallback`. | 7.0 SP3 8.1 SP2
CR096459 | When invoking a flush in a Servlet or JSP in HTTP 1.0, WebLogic Server sometimes failed to close the socket, causing the client to wait for a period of time until the socket timed out. The problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR098388 | Right after server startup, some server requests were rejected because the MBean did not update server state before the listening thread started receiving requests. This problem has been resolved by using Boolean flags inside the Web container to update the server state for the listening thread. | 7.P SP3 8.1 SP2
CR098518 | The following EJB/Web application setup was causing a class cast exception: `Servlet Filter1 --> WebApp1 -- forward to WebApp2 ctx --> Servlet` `Filter2(WebApp2) --> Ejb Lookup (fails)` This problem has been fixed by locating the EJB lookup in the Servlet instead of a Servlet Filter when doing a forward between two Web applications. | 7.0 SP3 8.1 SP2
CR101838 | A change in the behavior of the `CGIServlet` that could affect the execution of CGI scripts having no filename extension. For example, if a `web.xml` file defined the CGI directory and Servlet mapping in the following way: `<param-name>cgiDir</param-name> <param-value>/home/user/cgi-bin</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>CGIServlet</servlet-name> <url-pattern>/cgi-bin/*</url-pattern> </servlet-mapping>` and stored a script named `myscript` in the `/home/user/cgi-bin` directory, a URL such as `http://localhost/mywebapp/cgi-bin/myscript` would map to `/home/user/cgi-bin` without specifying the script name. (This problem did not occur with scripts having an extension, such as `myscript.ksh`). The code was fixed to make the behavior match earlier releases of `CGIServlet`. Using the above example, the code fix ensures that the URL `http://localhost/mywebapp/cgi-bin/myscript` maps to `/home/user/cgi-bin/myscript`. | 6.1 SP6 8.1 SP2
CR102036 | The first access to deleted JSP pages was causing a `JspFileNotFoundException` instead of 404 File Not Found. Further access to this page correctly returned 404. The problem is fixed so that deleted JSP pages always return 404. | 7.0 SP3 8.1 SP2
CR102628 | The following JSP code: `<jsp:plugin type="applet" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/" height="800" width="500" type="applet" jreversion="1.3.1_06" nspluginurl="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; iepluginurl="http://java.sun.com/products/plugin/1.1.3/jinstall-113-win32.cab#Version=1,1,3,0" >` generated this HTML: `<embed type="application/x-java-applet;version=1.3.1_06" pluginspage="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; height="800" width="500" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogicServer_internal/classes/DefaultWebApp@DefaultWebApp/">` The generated HTML code failed on Netscape: Netscape attempted to download the plug-in from WebLogic Server instead from the SUN site. When the plug-ins page line was moved before the codebase line, the code worked correctly on Netscape. A code fix to order the applet attributes properly resolved the problem. | 6.1 SP6 8.1 SP2
CR102675 | If a taglib is imported once via the taglib directive in a page that includes a second page, and that second page also imports that same taglib, then invalid XML results in the following `browser output:` `Error 500--Internal Server Error From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:` `10.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.` And the following log file output: `<[ServletContext(id=287644,name=jspVal.war,context-path=/jspVal)] Servlet` `failed withIOException java.io.IOException: javax.servlet.jsp.JspException: The taglib validator` `rejected the page: "Exception TestValidator XML parsing: org.xml.sax.SAXParseException:` `Attribute "xmlns:valtest" was already specified for element "jsp:root". -- stack trace written to stderr., "...` Because of a code change to `weblogic.servlet.jsp.jsp2xml.Jsp2XmlOutputter`, duplicate tag prefixes are ignored in the generation of the XML views of the JSPs. | 7.0 SP3 8.1 SP2
CR102769 | Forwarding a request from a servlet or JSP to another JSP page did not log `queryString` in the `access.log`. Additionally, `access.log` logged the forwarded request, but not the original request. A code change to `RequestDispatcherImpl` fixed the problem. | 7.0 SP3 8.1 SP2
CR103256 | A code change resulted in performance improvement in JDBC regarding bubble caches in `JDBCSessionContext` and `JDBCSessionData`. | 6.1 SP6 8.1 SP2
CR103304 | `jsp_precompile` now works for all kinds of JSPs, including those that extend custom classes. | 7.0 SP4 8.1 SP2
CR103214 | When you set the `compilerclass` JSP parameter, WebLogic Server logged a `compilerclass=null` message in the startup log, as in: `JSPServlet with initArgs '[JspConfig: verbose=true,packagePrefix=jsp_servlet,-compiler= C:\61sp4\jdk131/bin/javac,compileFlags=,workingDir=C:\61sp4 wlserver6.1\config\examples\applications\examplesWebApp\WEB-INF\_tmp_war_examples_examplesWebApp, pageCheckSeconds=1,superclass=weblogic.servlet.jsp.JspBase, keepgenerated=false,precompileContinue=false, compilerSupportsEncoding=true,encoding=null,defaultfilename index.jsp,compilerclass= null,noTryBlocks=false]'>` The problem occurred because the setting of `compilerclass` was not used during startup. The correct setting was used for compiling JSPs. The code was fixed to obtain the correct parameter value during server startup. | 6.1 SP6 8.1 SP2
CR103339 | Servlet output capitalized the `Transfer-Encode` value, Chunked, instead of using lowercase chunked as required by the HTTP/1.1 specification. The code was fixed to ensure that Servlets use the `Transfer-Encode` type of "`chunked`" in lowercase. | 6.1 SP6 8.1 SP2
CR103719 | When users log in to a protected page through HTTPS, the client receives two cookies back: `JSESSION` and `_wl_authcookie_`. When the server sends the second request (HTTPS) to a unprotected page without `_wl_authcookie_`, a 401 error was returned. An issue where access was denied to an unprotected (that is, no security restrictions) HTTPS page when the browser client did not send back the `_wl_authcookie_` has been fixed. Unprotected pages should no longer require the cookie. | 8.1 SP2
CR103861 | Applications deployed with relative paths caused `UnsafeFilenameExceptions` because WebLogic Server did not resolve the parent directory. The code was modified so that when WebLogic Server attempts to obtain a safe file name, it checks the parent directory first, and resolves it if needed. | 8.1 SP2
CR106072 | The `pageCheckSeconds` attribute, which sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling, did not work the first time a JSP was modified. This problem occurred because WebLogic Server did not set a `lastStaleCheck` time the first time a JSP was invoked. The code was modified so that if `lastStaleCheck` is not set yet, it is set to the current time. This prevents the JSP from being recompiled unnecessarily. | 8.1 SP2
CR106226 | Code that used a response wrapper and called `getOutputStream` on the original response passed into a JSP resulted in `NestedBodyResponse` always throwing an `IllegalStateException`. Mixed use of `getWriter()` and `getOutputStream()` from `NestedBodyResponse` are now allowed, so the exception will only be thrown when appropriate. | 8.1 SP2
CR106577 | In prior releases, WebLogic Server served requests containing extra spaces in the URI by trimming off the ending spaces. As of WebLogic Server 8.1 SP2, however, extra spaces in a URI will now result in a 404 (resource not found). For example: `http://server:port/mywebapp/foo%20%20` used to resolve to the resource `foo` in the Web application `mywebapp`. This URI will now result in a 404. No backward compatibility issues are expected. | 8.1 SP2
CR106856 | When customers using servlet filtering in their application do a forward or include via the request dispatcher, WebLogic Server ran the request though the filter again and caused an infinite loop. According to the 2.3 servlet specification, this is undefined behavior; in the 2.4 servlet specification, the default behavior is not to refilter the request on forward and include when processing via the request dispatcher. A `filter-dispatched-requests-enabled` configuration parameter has been added to `weblogic.xml` to enable customer control of servlet filtering. | 8.1 SP2
CR107419 | JSP code that intended to set double byte characters as a parameter's value—for example: `<jsp:include page="included.jsp"> <jsp:param name="title" value="<%= java.net.URLEncoder.encode(\"[double byte characters]\") %>"/> </jsp:include>` —resulted in specified double byte characters being changed to their URL-encoded code. This problem has been resolved. | 6.1 SP6 8.1 SP2
CR108046 | `weblogic.net.http.HttpURLConnection` did not implement the `getHeaderFields()` method that exists in JDK 1.4. As a result, `weblogic.net.http.HttpURLConnection.getHeaderFields()` returned an empty map. The implementation of `getHeaderFields()` has now been added to `weblogic.net.http.HttpURLConnection`. As a result of this change, `weblogic.net.http.HttpURLConnection.getHeaderFields()` now correctly returns a map of header fields. | 8.1 SP2
CR108607 | WebLogic Server produced errors when applications used XSL with the FOP output method to get an image from an archive file. This problem did not occur for applications deployed in exploded format. This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR109479 | The `JnlpDownloadServlet` uses the timestamp on a WAR file to determine whether the client's resources are older than what is available on the Web server. To get the timestamp, `JnlpDownloadServlet` calls the `URLConnection.getLastModified()` method. However, the `getLastModified()` method returned 0. The code has been modified so that a `ZipURLConnection.getLastModified()` method returns the modification time of the zip file, and thus the WAR file. | 7.0 SP5 8.1 SP2
CR109586 | Load-on-startup Servlets were being constructed (static initializers and constructor) as the kernel user. The static initializers, constructs and the init method will now be invoked as: init-as user, if specified run-as user, if specified anonymous user | 8.1 SP2
CR109821 | IndexFile resolution, which does expensive IO operations, was happening in the pre-dispatch phase (muxer queue). The code was modified to defer this resolution until after the dispatch phase. | 8.1 SP2
CR109958 | When processing requests through a proxy servlet, WebLogic Server only honored the `SecureProxy` setting for incoming requests that used HTTPS. If the incoming request used HTTP, WebLogic Server did not use an HTTPS connection even when `SecureProxy` was enabled in the proxy servlet. This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR110293 | The session count was an approximate number but was not initialized back to 0 when the server was restarted. Also the increment/decrement was not synchronized. As a result, a race condition could have contributed to a wrong count. In addition, for replicated sessions the count was not incremented/decremented for `becomePrimary`, `becomeSecondary`, and `becomeUnregistered` callbacks. The code was modified to obtain the count from the map directly for memory and replicated sessions. For file-based sessions, the count is obtained from the file system and for JDBC, it is obtained via a database query. As a result of this fix, counts will not be broken anymore. Note, however, that the runtime MBean returns now two more counts: 1. Total sessions opened by the server so far. 2. The maximum open sessions in memory. These two counts remain unaffected by this change. They will still use the old method of increment and decrement; they are approximate and represent a number since the time the server was restarted. These two counts will be reset to 0 after the server restarts. | 8.1 SP2
CR110914 | If `TrackingEnabled` was set to `false`, WebLogic Server created a new session for each request, but the sessions were not getting invalidated. The code was modified to invalidate a session immediately if `TrackingEnabled` is set to `false`. This is the correct behavior. | 8.1 SP2
CR111406 | If session data was accessed after redeployment—even with the `save-sessions-enabled` property set to true—a `java.lang.NoClassDefFoundError` occurred. This problem has been resolved with a code fix. | 8.1 SP2
CR111600 | The `request.isUserInRole` method was not querying the WebLogic Security Framework's Role Manager for security roles when no users were logged in. The `request.isUserInRole` method will now query the Role Manager for security roles even when no users have logged in. | 8.1 SP2
CR112413 | When the Web application container reloads a modified servlet class dynamically, it calls the `destroy()` method on the old instance. However, the destroy was not being invoked with the Web application classloader as the thread's ContextClassLoader. The code has been modified so that the `destroy()` method is always invoked with the Web application classloader as the thread's ContextClassLoader. | 8.1 SP2
CR112547 | When the number of servers in the cluster was large, it was difficult to configure the same property for all of them. To make this easier, the properties `FrontendHost`, `FrontendHTTPPort` and `FrontendHTTPSPort` in the `ClusterMBean` have been exposed. The `ClusterMBean` values will take effect only for the default Web Servers of the servers in the cluster. Virtual host properties need to be set separately. This fix does not result in any change to existing behavior. | 8.1 SP2
CR112799 | WebLogic Server attempted to write to an output stream even after an `IOException` occurred. This led to 100% CPU utilization if an unexpected socket disconnection occurred with a Web Application that did not handle `IOException`. `org.apache.xml.serialize.XMLSerializer` ignores `IOException` until the end of its process. This caused the problem to occur if an `IOException` was thrown in the middle of returning XML documents as part of an HTTP response. The code was modified to ensure that writes to an output stream stop after an `IOException` occurs. | 6.1 SP6 8.1 SP2
CR112803 | When running `appc`, an Exception stating that the `ejb-ref` had no mapping to the JNDI name of the target EJB was incorrectly thrown. This problem occurred because of a logic error in the Web application compliance checker. The logic was corrected to correctly recognize when an `ejb-ref` declared in `web.xml` has a corresponding JNDI name mapping in `weblogic.xml`. As a result, `appc` will no longer incorrectly throw this exception. | 8.1 SP2
CR112992 | If XML schema caching was enabled and a JSP was refreshed, it threw an exception starting with the following lines: `weblogic.servlet.jsp.JspException: (line -1): cannot load TLD: weblogic.xml.dom.ChildCountException: missing child tagclass in tag ...` This problem occurred because the caching caused the entity not to be resolved, which made the `TLDDescriptor` assume that the TLD was 1.1, when in fact the TLD was 1.2. The `TLDDescriptor` constructor now takes a boolean `flag _12` and an `org.w3c.dom.Element`, then calls `Document.getDoctype()` to inspect the type of the document. | 8.1 SP2
CR114936 | WebLogic Server drained an inputstream even if a client cancelled a proceeding request. It would therefore consume CPU resources. The code was changed so that connections are thrown away so they do not drain an inputstream. As a result of this change, if an `IOException` occurs while writing to a client, `GenericProxyServer` does not recycle this connection and will create a new connection for a subsequent request. | 7.0 SP5 8.1 SP2
CR116209 | If customers added a Serializable `ServletContext` attribute, then overwrote it with a non-Serializable value, the original value masked the new value. This problem occurred because the old value was never removed from the attributes Hashtable. The code has been modified to remove the value from an attributes Hashtable, if necessary, when replacing a Serializable value with a non-Serializable one. | 8.1 SP2
CR111752 | Under certain conditions, WebLogic Server threw a `NullPointerException` when using `CGIServlet` with the `useByteStream` parameter set to true. The problem occurred when using framesets where one frame contained static URL links and another frame used `CGIServlet`. If a user selected the frame containing static links before the other frame completed downloading a page, an IO exception was caught and presented to the user as: `java.lang.NullPointerException at weblogic.utils.Executable$Drainer.run(Executable.java:366)` This problem was solved with a code fix. | 6.1 SP6 8.1 SP2
CR120630 | Weblogic Portal 8.1 calls the `RequestDispatcher.include()` method many times using an original `ServletRequest`, which extends `ServletRequestWrapper`. To handle a `ServletRequestWrapper` object, WebLogic Server needs to do casting. In the `RequestDispatcherImpl.include()` method, WebLogic Server attempted this casting operation and caught a `ClassCastException` if the referenced `ServletRequest` object was not an instance of the `ServletRequestImpl` class. This caused performance degradation when using WebLogic Portal 8.1 because the performance cost of the exception generated by an unpermitted cast attempt is expensive. The code has been modified so that the `instanceof` operator is used instead of the `ClassCastException` to determine whether or not a specific casting operation is permitted. As a result of this change, the `weblogic.servlet.internal.RequestDispatcherImpl.forward()` and `include()` methods use the `instanceof` operator for flow control. | 8.1 SP2
CR121748 | Due to a problem with Supplementary Policies support, the temporary directory (which normally contains JSP class files) would be deleted whenever an application was undeployed. This temporary directory was not intended to be deleted unless the application was explicitly removed. A code fix solved the problem. | 8.1 SP2
CR125108 | In WebLogic Server 6.x, the URL pattern: `/foo*` matched `/foo`. This was not legal per the Servlet 2.3 specification. In WebLogic Server 7.x the `URLResource` was introduced, and WebLogic Server unintentionally stopped supporting this. In addition, due to eccentricities in the Servlet container, the `/foo*` URL pattern worked if the `fullyDelegateAuthorization` flag was disabled, but not if it was enabled. Users would view this as a degradation in security when upgrading from WebLogic Server 6.x to 7.x or 8.x. With this fix, only a string beginning with a `/` character and ending with a`/*` postfix is used for path mapping. Since customers may rely on the old mapping, WebLogic Server does not deploy Web applications with a `<url-pattern>` set to `/foo*` in `<security-constraints>`, to prevent a security vulnerability. As a result of this fix, a URL pattern like `/foo*` will be treated as an exact match, and Web applications with a `<url-pattern>` set to `/foo*` in `<security-constraints>` will not be deployed. | 8.1 SP2
CR126319 | When a server in a cluster is (forcibly) shut down, the server invalidates the primary and secondary sessions, thereby causing session failover to fail. Code to check the cluster size when a session was destroyed upon server shutdown was available. (That is, if the server was not the last server in the cluster, the session was not invalidated.) However, WebLogic Server did not pass the `serverShutdown` flag correctly so the checking logic was ignored. Code was modified so that the server state is checked, and the checking logic is invoked when destroying a session. | 8.1 SP2

## System Administration

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR063279 | When multiple elements in WebLogic Server's `config.xml` had the same objectnames, later elements overwrote configurations for preceding elements. This used to happen silently. Now, WebLogic Server throws an error message (ID=150012) to standard output. | 7.0 SP3 8.1 SP2
CR099474 | The `getAttributes()` method in the `RequiredModelMBean` should return a `javax.management.AttributeList`, which should contain `javax.management.Attribute` objects, but in the WebLogic Server JMX implementation the `AttributeList` returned by `RequiredModelMBean` contained the value of the MBean attribute directly and not as a `javax.management.Attribute` object, causing the following exception: `java.lang.ClassCastException: java.lang.String at weblogic.management.internal.RemoteMBeanServerImpl.getAttributes(RemoteMBeanServerImpl.java:210) at weblogic.management.internal.RemoteMBeanServerImpl_WebLogic Serverkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821) 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:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)End server side stack trace at com.adventnet.beasupport.client.JMXConverter.convertInvocationTargetException(JMXConverter.java:744) at com.adventnet.beasupport.client.ProxyMBeanServer.getAttributes(ProxyMBeanServer.java:511) at com.adventnet.beasupport.client.WebLogicClient.getAttributes(WebLogicClient.java:593) at com.adventnet.beasupport.client.WebLogicClient.cmdline(WebLogicClient.java:1279) at com.adventnet.beasupport.client.WebLogicClient.access$000(WebLogicClient.java:15) at com.adventnet.beasupport.client.WebLogicClient$2.run(WebLogicClient.java:1293)` The `GetAttributes` method now returns an `Attribute` object. | 7.0 SP3 8.1 SP2
CR100756 | Setting a JMSServer's Store property via the `weblogic.Admin` utility: `java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -mbean examples:Name=examplesJMSServer,Type=JMSServer -property Store examples:Name=examplesJMSFileStore,Type=JMSStore` resulted in the following exception: `<Mar 10, 2003 3:32:15 PM EST> <Error> <Management> <141033> <Error importing MBean examples:Name=examplesJMSFileStore,Type=JMSStore to server examplesServer.javax.management.InstanceNotFoundException: examples:Name=examplesJMSFileStore,Type=JMSStore` This problem was partially fixed by checking when setting an attribute that is a `WebLogicObjectName` on a configuration MBean. The code checks to see if the bean is a valid one and will throw an `InvalidAttributeValueException`. This is logged on the Administration Server and the JMSServer remains usable but does not have the file store set. | 7.0 SP3 8.1 SP2
CR105736 CR121053 | Some load-balancing applications such as Cisco Loadbalancer became unable to use session stickiness because of a change to the SessionID format. A new server startup flag, `-Dweblogic.servlet.useExtendedSessionFormat=true` , retains the information that the load-balancing application needs for session stickiness. | 7.0 SP3 8.1 SP2
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 SP2
CR105831 | An exploded Web application was allowed to load classes from the docroot. This inappropriate classloading behavior has been disallowed. | 7.0 SP3 8.1 SP2
CR106198 | On `GroupReaderMBean`, `isMember` was failing when member name contained a comma. A code change resolved this problem so that member names containing commas are now accepted. | 7.0 SP3 8.1 SP2
CR106728 | The log handlers assumed that only `WLLogRecord` instances were being published. In the case of users directly invoking the logger using the Java 1.4 Logging APIs, the handlers threw a `ClassCastException` because it got a `java.util.logging.LogRecord` instance instead of a `weblogic.logging.WLLogRecord`. A `java.util.logging.LogRecord` is now converted to a `WLRecord` object before being processed by the handlers. This avoids the `ClassCastException`. Users can now invoke the JDK Logger directly using the Java 1.4 Logging APIs and messages are logged to the server log file. | 8.1 SP2
CR107805 CR109620 | During server startup in a cluster on WebLogic Platform, the following error occurred: <Jun 18, 2003 4:46:53 PM EDT> <Error> <Management> <BEA-141009> <Error occurred in the file distribution servlet while processing request type "wl_ear_resource_request", java.net.SocketException: Software caused connection abort: socket write error. java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at weblogic.servlet.internal.ChunkUtils.writeChunkNoTransfer(ChunkUtils.java:263) at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:228) at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:296) at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:371) at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:241) at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:114) at weblogic.servlet.internal.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:171) at weblogic.management.servlet.FileDistributionServlet.returnInputStream (FileDistributionServlet.java:568) at weblogic.management.servlet.FileDistributionServlet.doGetEarResourceR equest(FileDistributionServlet.java:787) at weblogic.management.servlet.FileDistributionServlet.doGet(FileDistributionServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run (ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio n.run(WebAppServletContext.java:6310) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2564) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170) This socket write error has been eliminated. | 8.1 SP2
CR110161 | For any `weblogic.Admin` command that connects to a WebLogic Server instance, you must provide user credentials. You can now use the new `STOREUSERCONFIG` command to encrypt the user credentials instead of passing credentials directly on the command line or storing unencrypted credentials in scripts. See STOREUSERCONFIG for more information. | 8.1 SP2
CR112123 | In WebLogic Server 8.1 and below, Weblogic MBeans (`SecurityConfigurationMBean`) could not have references to Security MBeans (`RealmMBean`). As a result, the realm could not be an attribute on the `SecurityConfigurationMBean`. Instead, it had to be an operation (a finder) as opposed to a getter. This was problematic because only users in the `Administrators` group have access to operations (except for special cases). The `findRealm()` and `findRealms()` methods on the `SecurityConfigurationMBean` are now special-cased. As a result, these two methods are now publicly accessible. | 8.1 SP2
CR112324 | Three commands—`wlconfig`, `wldeploy`, and `wlserver`—were modified so they can obtain a username and password from secured locations. For `wlconfig` and `wldeploy`, customers can use the User Configuration functionality as described for the `weblogic.Admin` tool. The command: `STOREUSERCONFIG option wlserver` uses the `boot.properties` file to obtain a username and password. As a result, usernames and passwords can be omitted from ant scripts, as long as an administrator has created the user config/key files (for `wlconfig`/`wldeploy`), or the server has been booted at least once in the domain (for `wlserver`). These actions create the files in which the encrypted usernames and passwords are stored. The username and password can still be provided on the ant task command line. In this case, they are used (that is, the user config or `boot.properties` files are ignored). In short, existing ant task scripts will continue to work as usual, but administrators who want to remove the username/password from the scripts can use the new functionality of these commands. | 8.1 SP2
CR113475 | A `NullPointerException` occurred when security MBeans attempted to de-crypt the encrypted security MBean attributes during initialization. This problem occurred because WebLogic Server MBeans were not yet initialized, and the encryption service relied on getting the salt from these MBeans. The `NullPointerException` is now caught and the salt is obtained from the domain log file. | 8.1 SP2
CR124392 | There were multiple issues associated with this CR. 1. `SecurityConfiguration.findDefaultRealm()`, `findRealms()`, and `findRealm()` always turned to the Administration Server for this information. 2. Whenever a `CommoProxy` object was initialized, it tried to obtain a reference to `AdminMBeanHome` in its constructor, although this was not required until later for setters and certain operations. 3. For read-only operations that required access to Embedded LDAP, WebLogic Server would always attempt to obtain this information from the Administration Server's LDAP. Whenever the Administration Server was down, exceptions were thrown in different layers. 4. Even after these problems were fixed, the response was slow when the Administration Server was down (what took about 30 seconds would have taken 3-5 seconds if the Administration Server was running). This was because WebLogic Server attempted to initialize the `adminMBeanHome` in `CommoProxy` in its constructor. These problems were solved as follows: `SecurityConfiguration` now obtains necessary information from the local MBean Server. WebLogic Server defers the initialization of `AdminServerMBeanHome` until it is actually required. For certain operations, WebLogic Server now always goes to the local MBean Server as opposed to the Administration Server. | 8.1 SP2
CR122568 | A startup class failed to access the local instance's MBeanHome. It failed with the following error message when the startup class was deployed with `LoadBeforeAppDeployments="true"`: `Unable to resolve 'weblogic.management.home.localhome' Resolved: 'weblogic.management' Unresolved:'home'` This problem occurred because WebLogic Server 8.1 SP1 could not get the local instance's `MBeanHome` with `LOCAL_JNDI_NAME` (`weblogic.management.home.localhome`). `LOCAL_JNDI_NAME` is now available to startup classes. | 8.1 SP2

## Tools

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR074637 | WebLogic Builder did not provide a way to remove a default transaction. Customers can now delete a default transaction by selecting the blank line in the combo box. | 8.1 SP2
CR074714 | In the WebLogic Builder WebLogic Settings panel, when a RAR's "Capacity increment" was larger than the difference between "Maximum capacity" and "Initial capacity", WebLogic Builder failed to load the RAR, and printed a SAXProcessorException beginning: `weblogic.xml.process.: capacity-increment should be less than or equal to (max_capacity-initial_capacity)` A code change resolved the problem. | 7.0 SP3 8.1 SP2
CR083151 | Command-line DDInit now works for EAR files. | 7.0 SP3 8.1 SP2
CR093658 | Calling `getLogFileName` on the `VirtualHostMBean` was returning an incorrect path. | 7.0 SP3 8.1 SP2
CR093833 | Redeploying to a Managed Server using `weblogic.Deployer` without specifying the server was deploying the application to the Administration Server. The problem has been resolved by a change to the `weblogic.Deployer` utility. | 7.0 SP3 8.1 SP2
CR098134 | `weblogic.Admin` prompted for a password, and then threw an exception before you could type it. A code change resolved this problem. | 7.0 SP3 8.1 SP2
CR099461 | WebLogic Builder did not prompt users about what the valid entries might be for CMP fields. Instead, these had to be hand-typed by the user. WebLogic Builder now populates a menu that allows users to select entries for CMP fields. | 8.1 SP2
CR100538 | WebLogic Builder threw a `NullPointerException` if users attempted to open a `ejb.jar` file that did not have an `assembly-descriptor` stanza in its `ejb-jar.xml` file. The `NullPointerException` is now guarded against, and users of WebLogic Builder can open an `ejb.jar` file where the `ejb-jar.xml` has no `assembly-descriptor` stanza. | 8.1 SP2
CR103188 | When WebLogic Builder was loading the Web application deployment descriptors, the `resource-ref` stanza was being deleted. This problem was caused by a bug in the servlet descriptor processing code. The servlet descriptor processing code has been modified so that it properly reads the `resource-ref` stanza. Web applications with a `resource-ref` stanza in their deployment descriptors are now loaded properly. | 8.1 SP2
CR107916 | Deleting and adding back a CMP field shuffled the DD CMP field and column mappings. This problem occurred because when editing an existing CMP Field, the field-name is readOnly, but WebLogic Builder was still populating the entire combo box from scratch. In addition, the `EJBUtils.getCMPFields()` method returned not only CMP fields, but also CMR fields. Therefore, the nodes appeared to have random values in them, because they were getting accidentally set to a value that was actually a CMR field. Customers who experienced these problems would also notice a corrupted `ejb-jar.xml` file. The code now determines if users are adding a new CMP field or editing an existing one, and only populates the combo box when users are adding a new one. In addition, a filter method now filters out CMR fields. As a result of these changes, `ejb-jar.xml` files will no longer get corrupted. | 8.1 SP2
CR108648 | Running the WebLogic EJB-to-JSP integration tool on the command line resulted in a `NoClassDefFound` error. In addition, this tool only worked for 1.0 EJBs. The class `weblogic.servlet.ejb2jsp.gui.Main` was added to prevent the `NoClassDefFound` error, and code was added to handle 2.0 EJBs. Now, if an EJB has ONLY a `Local/LocalHome` interface, the tool reads the methods from that interface pair. If an EJB has ONLY a `Remote/RemoteHome` interface, the tool reads the methods from that interface pair. If an EJB has BOTH interface pairs, the tool reads the methods from the `Local/LocalHome` interface. | 8.1 SP2

## Web Services

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR086326 | The JSSEAdapter was pending a change to JDK 1.4, and therefore was not complete. The JSSEAdapter has been brought up to parity with the WLSSLAdapter for strict checking, verbose and localIdentity features. As a result of this change, the JSSEAdapter now provides the same functionality as the WLSSLAdapter. | 8.1 SP2
CR092268 | A client running behind a firewall needed to set properties on a Web service stub. The problem was resolved by the introduction of two new properties, `weblogic.webservice.client.proxyusername` and `weblogic.webservice.client.proxypassword`. | 7.0 SP4 8.1 SP2
CR103346 | The Web Service test page did not support the `documentwrapped` invocation style. Support for testing the `documentwrapped` invocation style was added to the Web Service test page. | 8.1 SP2
CR103512 CR107171 | Some properties set on the stub were not copied into the MessageContext. After a code change, WebLogic Server now supports the following usecases: Endpoint can be modified in the following flow: `Stub->MessageContext` in `handleRequest->MessageContext` in `handleResponse->StubCall->MessageContext` in `handleRequest->Call` Timeout can be set in the following order: Stub->MessageContext in handleRequest Call->MessageContext in handleRequest | 7.0 SP4 8.1 SP2
CR104199 | If you used a .NET C# client to access a WebLogic Server Web service and requested two strings returned, the first a result and the second an in/out parameter, the order of the strings returned was incorrect. The second string returned as the result, and the in/out parameter returned as null. A code change ensures that the first accessor returned is the return value. | 7.0 SP4 8.1 SP2
CR104276 | The command-line flag `-Dweblogic.webservice.verbose=true` was causing an error message during startup, saying that it is not recognized by WebLogic Server. This error message was wrong, since the flag was being recognized by WebLogic Server. This message has been removed. | 8.1 SP2
CR104481 | A Web Service whose method contains multi-byte characters could not be accessed from the testing page in the Administration Console. (The client application can, however, access the Web Service.) This problem occurred because a request parameter was being parsed using ISO-8859-1 encoding. It was resolved by modifying the code to set a character encoding before parsing a request parameter. | 8.1 SP2
CR105140 | `HTTPRequest` and `HTTPResponse` not available in the server handler's message context. This was a regression from WebLogic Server 7.0. This problem has been resolved by adding support for `MessageContext.getProperty("HTTPRequest")` and `MessageContext.getProperty("HTTPResponse")` in the server handler. Note: `HTTPRequest` and `HTTPResponse` are now deprecated. Use `weblogic.webservice.transport.http.request` and `weblogic.webservice.transport.http.response` instead. | 8.1 SP2
CR106392 | Running with `invocation-style="one-way"` resulted in the WSDL containing an `<output>` in the `<binding>` section for that operation as can be seen from the snippet below. `<portType name="MyServicePort"> <operation name="sayNothing"> <input message="tns:sayNothing" /> </operation> </portType>` `<binding name="MyServicePortSoapBinding" type="tns:MyServicePort"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"; /> <operation name="sayNothing"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" namespace="http://tempuri.org/"; /> </input>` `<output> <soap:body use="literal" namespace="http://tempuri.org/"; /> </output> </operation> </binding>` This behavior was exhibited in both "rpc" and "document" style Web services. Running with Microsoft's `WSDL.EXE` against this WSDL resulted in an unsuccessful validation and consequently in a failure to generate the .Net client proxy or stubs. A code change stopped the generation of output messages in one-way bindings, resolving the problem. | 7.0 SP3 8.1 SP2
CR107312 | `Clientgen`-generated clients wrote attributes in the SOAP request without namespaces, even if `attributeFormDefault="qualified"` was specified. WebLogic Workshop Web Services did not recognize these attributes, causing the corresponding field of the Java object to be set to `null`. Namespaces of attributes are now written out if `attributeFormDefault="qualified"`. | 8.1 SP2
CR108646 | The servicegen task did not support the "mergewithexistingws" attribute, resulting in a build failure. This problem occurred because no `setMergeWithExistingWS` method was defined in the `weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask` class. The following method is now part of the `ServiceGenTask` class: `public void setMergeWithExistingWS(boolean b) { mergeWithExistingWS = b; }` | 8.1 SP2
CR109437 | When casting an `SSLAdapter` to a `WLSSLAdapter` at runtime as shown below, a `ClassCastException` was thrown. `SSLAdapterFactory factory = SSLAdapterFactory.getDefaultFactory(); WLSSLAdapter adapter = (WLSSLAdapter) factory.getSSLAdapter();` This problem was caused by an incomplete feature addition. The `JSSEAdapter` was correctly entered secondary to the default `WLSSLAdapter`. This fix restored the original behavior. | 8.1 SP2
CR109624 | Exceptions were always being printed to `stdout` from Web Service clients. Logging on the client side now only happens if the system property `weblogic.webservice.client.logging` is set to `true`. The default is `false`. | 8.1 SP2
CR109898 CR112443 | Passing `org.w3c.dom.Document[]` as a parameter to a method causes a `SOAPException` beginning with the following lines: `javax.xml.soap.SOAPException: Found SOAPElement [<anyType> <this xmlns="mynamespace"> <f:that xmlns:f="yournamespace"> <or> a lot of random &lt; </or> <f:the> </f:the> <f:other> foo bar blaz</f:other> </f:that> </this> </anyType>]. But was not able to find a Part that is registered with this Message which corresponds to this SOAPElement ...` A code fix resolved this problem. | 8.1 SP2
CR109938 | When the Web Service runtime attempted to find out the encoding of the XML represented by the Source object, its underlying stream was read and not reset. The XML stream is now reset. | 8.1 SP2
CR110168 | Clients failed with an `IllegalArgumentException` if the XML returned from the server did not explicitly indicate the size of a SOAP array. This problem occurred because the argument used for creating a new array instance was null because of missing size information. For a SOAP array of an unspecified size, objects are now stored in a list first, and then the array is created. | 7.0 SP4 8.1 SP2
CR110945 | A document or literal Web Service involving arrays generated a SOAP response message whereby the namespaces were not being applied properly. This resulted in .Net clients to ignore some of the data. WebLogic Server ant tasks (`autotype`, `wsdl2service`, and `wspackage`) are used to generate the Web Service. This problem was resolved by modifying the code to write proper namespaces to the generated codec. | 8.1 SP2
CR111163 | When iterating through the child nodes of the SOAP header, empty text nodes were casted to `SOAPHeaderElement`'s. Text nodes are now discarded. However, there was another change required to make the `examineHeaderElements()` method work. The `mustUnderstand` and `actor` attributes are now being recognized with and without namespace qualification. Previously, only the non-qualified form was recognized. | 8.1 SP2
CR111187 | In the `weblogic.webservice.binding.soap.HttpResponse` class, the method `getBodyAsString` threw a "String index out of range" error. A code change causes the method to use the length of the body, instead of the end, resolving the problem. | 7.0 SP4 8.1 SP2
CR111393 | A `NullPointerException` occurred during deployment of a simple EAR file using WebLogic Builder. This problem has been resolved. | 8.1 SP2
CR109033 CR111653 | Customers could not specify a `KeyWrappingMethod` for encryption, then configure the data security for Web Services. (By default, only `rsa-oaep-mgf1p` was used.) Customers can now specify any supported `KeyWrappingMethod` in the deployment descriptor for a Web Service. For example: `<spec:EncryptionSpec EncryptionMethod="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" KeyWrappingMethod="http://www.w3.org/2001/04/xmlenc#rsa-1_5" EncryptBody="true"> </spec:EncryptionSpec>` | 8.1 SP2
CR111881 CR128662 | WebLogic Server did not provide a timeout to a Web Service invocation on the client-side. To timeout a Web Service invocation on the client-side in WebLogic Server SP 2: 1. Make sure `weblogic.jar` is available on the client side. 2. Set the `weblogic.webservice.UseWebLogicURLStreamHandler` system property to `true`. 3. Set the timeout on the stub as follows: With the API for `BindingInfo`: `BindingInfo bInfo = (BindingInfo) stub._getProperty("weblogic.webservice.bindinginfo"); bInfo.setTimeout(5 /* secs */);` With the stub property: `stub._setProperty("weblogic.webservice.rpc.timeoutsecs", "5" /* secs */);` Note: In WebLogic Server 8.1 SP1, `BindingInfo.setTimeout(5000/*millisecs*/)` took milliseconds as the parameter. However, this had no effect on the client side. With SP 2, the parameter takes seconds instead of milliseconds. | 8.1 SP2
CR112835 | When using `wsdl2service` to generate a service for mixed-style WSDL, the client side threw a `SerializationException` while invoking the service. Mixed style is only supported on the client-side but not on the server-side. As a result of this change, `wsdl2service` will no longer generate a service if it is mixed style. Instead, a `WSBuildException` will be thrown while running `wsdl2service`. Note: Prior to this change, `wsdl2service` would generate a mixed-style service. | 8.1 SP2
CR113038 | WebLogic Server 8.1 supported an old version of the SOAP 1.2 specification. In WebLogic Server 8.1 SP2, support for the latest SOAP1.2 specification has been added. | 8.1 SP2
CR113082 | A `java.lang.Object` could not be used as a parameter or return type of a Web Service. As a result, an error similar to the following occurred during compilation: `Client.java:79: inconvertible types found : void required: java.lang.Object java.lang.Object retVal = (java.lang.Object)port.mapbasic8Data(arg0);` A code fix resolved the problem. | 8.1 SP2
CR113095 | While calling the `getContent()` method in the `handleResponse()` method of a server-handler chain as follows: `SOAPMessage msg = ( (SOAPMessageContext)context ).getMessage(); javax.xml.transform.Source src = msg.getSOAPPart().getContent();` an exception starting with the following lines was thrown: `org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces....` This exception has been eliminated, and the correct `javax.xml.transform.Source` object will now be returned when invoking `msg.getSOAPPart().getContent()`. | 8.1 SP2
CR120422 | The following classes were missing from `webserviceclient.jar`: `weblogic/webservice/encoding/AttachmentCodec.class weblogic/webservice/encoding/DataHandlerArrayCodec.class weblogic/webservice/encoding/DataHandlerCodec.class weblogic/webservice/encoding/ImageArrayCodec.class weblogic/webservice/encoding/ImageCodec.class weblogic/webservice/encoding/MimeMultipartArrayCodec.class weblogic/webservice/encoding/MimeMultipartCodec.class weblogic/webservice/encoding/XMLSourceArrayCodec.class weblogic/webservice/encoding/XMLSourceCodec.class` The missing classes have been added. | 8.1 SP2
CR120835 | A class required to process client-side JAX-RPC handlers (`javax.xml.rpc.handler.GenericHandler`) was not included in the `webserviceclient.jar` file that ships with WebLogic Server. The required class was added to `webserviceclient.jar`. Now Web Service clients can use JAX-RPC handlers using only `webserviceclient.jar`, and it is not necessary to include `webservices.jar` in the client's classpath. | 8.1 SP2
CR120957 | Static clients did not throw the correct exception when multiple exceptions are thrown from a EJB method. For example, a static client for the method signature: `public void throwExceptions() throws ExceptionA, ExceptionB` always threw `ExceptionA`, regardless of what exception had been thrown from the server side. The static client now throws the exception which matches the one thrown from server-side. | 8.1 SP2
CR121013 | If an authenticated subject has been set on the message context, it is now used for invoking the backend component. | 8.1 SP2
CR121088 | In WebLogic Server 8.1 SP1, an MDB is published as a Web Service using `servicegen`. This MDB listens on a foreign JMS provider (MQ-Series 5.3). Testing of the Web Service through the Administration Console, a `ClassCastException` starting with the following lines was raised: `Invocation failed ! Parameter Name Parameter Value Request sent to the server <!--REQUEST.................--> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <env:Header> </env:Header> <env:Body> <n1:toupper xmlns:n1="http://localhost:7001/messageToupperWebservices"; sample string</n1:toupper> </env:Body> </env:Envelope>` `Response from the server <!--RESPONSE.................--> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";> ...` The `ClassCastException` will no longer be raised; a code fix resolved the problem. | 8.1 SP2
CR122437 | The `InputStream` field of `StreamSource` was always used, even if it was `null`. If the `InputStream` is `null`, the `Reader` is now used. If both are `null`, a `SOAPException` is thrown. | 8.1 SP2
CR124019 | Clientgen failed to compile a generated class for an extended type if the base type had a different namespace. This problem occurred because base classes from different packages were not being imported. Base class names are now generated with complete package names. | 8.1 SP2
CR124285 | `Clientgen` failed with a `ClassNotFoundException` on WSDL with references to types in another schema, which had no `targetNamespace` via the generic `<xs:import>` tag. A code fix resolved this problem. The fix also requires `<clientgen>` to define `typePackageName` or `typePackageBase` if there is no `targetNamespace` in the schema. | 8.1 SP2
CR127338 | WebLogic Server generated a MIME header with the string `"start=null"`. This violated RFC2387 in which `"start element"` is optional but can not be `null`. For example: `[java] Content-Type=multipart/related;boundary="----=_Part_0_19561502.106 8580828000";start=null [java] Transfer-Encoding=Chunked [java] Envelope : [java] [java] ------=_Part_0_19561502.1068580828000 [java] Content-Type: text/xml; charset='utf-8' [java] Content-Transfer-Encoding: 8bit` This problem was resolved by modifying WebLogic Server to generate the correct "`start element`". For example, `[java] Content-Type=multipart/related;boundary="----=_Part_0_2960804.1068582126531";start=__WLS__1068582126546__SOAP__ [java] Transfer-Encoding=Chunked [java] Envelope : [java] [java] ------=_Part_0_2960804.1068582126531 [java] Content-Type: text/xml; charset='utf-8' [java] Content-Transfer-Encoding: 8bit [java] Content-ID: __WLS__1068582126546__SOAP__` | 8.1 SP2

## WTC

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR070627 | The WebLogic Server Administration Console did not check the format for the Network Address field. This problem occurred for either WTC LocalTuxDom or RemoteTuxDom configurations. This problem was resolved by updating `WTCLegalHelper` to include a method for checking that the format of a network address is valid. As a result of this change, an error will now be reported when an invalid format is used to define the Network Address field. | 8.1 SP2
CR107333 | The design for configuring the View classes to be used by WTC was expected to be only through the JMX interface. This has proven to be an unwieldy usage for WebLogic Workshop with Tuxedo-controls. A method has been added to the `TuxedoConnection` that permits customers to append the WTC View HashTable with a View class they have loaded. Now customers do not need to update the `WTCResourcesMBean` with the View class they will be using when a WTCService is running. Customer applications may load the class and then call the `updateViewMap` method on the `TuxedoConnection`. Side-effects are that the MBean information is not updated and the View Hashtable is open to appends from non-administrators. | 8.1 SP2
CR109849 | WTC uses a separate protocol for communication with Tuxedo 6.5 domains. One part of this communication is creating a `TypedBuffer` to receive the data that is read in. In this case, a view buffer must be created, and this requires that the view subtype be provided. (The subtype is the name of a view which maps to a class listed in the Resources configuration section.) However, no subtype was being given to the `createTypedBuffer` method. The subtype value is now read in from the input stream and passed to the `createTypedBuffer` method. As a result, WTC 8.1 will now process View buffers from Tuxedo 6.5 domains. | 8.1 SP2
CR109877 | The `TypedFML.FldId()` method was returning a null value instead of throwing a `Ferror` exception as expected. A throw statement was added to `TypedFML.Flid()` for the case where no field ID is found. As a result of this change, when no field ID is found that corresponds to the input `name` parameter, an Ferror.`FBADNAME` exception will be thrown. | 8.1 SP2
CR110488 CR110619 | The `wsdl2service` task had the following problems handling user-defined exceptions: Operations of the interface did not throw the user-defined exception as specified in the WSDL. There were no fault entries in the deployment descriptor `web-services.xml`. This issue has been resolved. As a result, `wsdl2service` now handles user-defined exception properly. | 8.1 SP2
CR110957 | Web Service applications had problems with VIEW buffer fields defined as strings. While these fields are intended to hold null-terminated character strings, Tuxedo actually creates them as fixed length character arrays. Tuxedo sends the entire array as part of a VIEW buffer. When WTC receives such a buffer, it converts the entire array to a Java byte array and then to a Java `String`. The resulting string may contain many '0' characters or garbage characters at the end of the real data. WTC should have searched the incoming character array for the first null byte and truncated the byte array it created at that point. A new option was added to the `viewj` and `viewj32` compilers: `-modify_strings`. Additionally, new versions of the `xdr_encode_string` and `xdr_decode_string` methods of the `wtc.jatmi.Utilities` class were added. If `-modify_strings` is specified, the compilers will generate code to use the new versions of the string encode and decode routines. These versions will truncate strings received from Tuxedo at the first null character and add a null character to any string sent to Tuxedo. No behavior changes unless the new `-modify_strings` option is given. | 8.1 SP2
CR122200 | Viewj and Viewj32 now generate code in the field setters and getters that will set and use the values of the associated length and count fields, if the view definition specifies the L or C flags for a given field. The setters will set the count for a field and the length for a string or carray field. The getters for array fields will return an array that is at most the size of the associated count field. The getters for a string or carray will return data that is at most the length of the associated length field. This behavior can be controlled both at the time the TypedView or TypedView32 class is generated by viewj or viewj32, and at run-time. Two methods control the run-time behavior: 1. `boolean getAssociatedFieldHandling()` returns `true` if the current state is set so that setters and getters will use the associated length and count fields; otherwise it returns `false`. 2. `void setAssociatedFieldHandling(boolean state)` sets the state of associated field handling. If set to `false`, the setters and getters ignore the length and count fields. If set to `true`, they set and use the associated fields as described above. The default state for associated field handling is `false`. If the `-associated_fields` option is given to viewj or viewj32, the default state is set to `true`. | 8.1 SP2
CR122953 | The `Fchg(FmlKey key, Object value)` method in the `weblogic.wtc.jatmi.TypedFML32` class did not correctly fill all prior entries with null values as documented. This problem was resolved with a code fix. | 7.0 8.1 SP2

## XML

####

Change Request Number | Description | Release Fixed
--- | --- | ---
CR120910 | In `web.xml`, if "MS950" or "CP950" was specified as the encoding name, an exception starting with the following lines was thrown: `weblogic.management.ApplicationException: Exception:weblogic.management.ApplicationException: Prepare failed. Task Id = 21 Module: encoding Error: [HTTP:101062][HTTP] Error reading Web application "C:\bea811\user_projects\domains\mydomain\.\myserver\upload\encoding\encoding.war". java.io.UnsupportedEncodingException: [J2EE:160098]Unable to parse the file 'C:\bea811\user_projects\domains\mydomain\.\myserver\upload\encoding\encoding.war:WEB-INF/web.xml' because it uses an invalid encoding name, 'Cp950'. All deployment descriptors must use an IANA or Java encoding name. Please change the encoding of the descriptor to be a supported encoding. ...` A code change fixed the above exception, since "MS950" and "CP950" are valid Java encoding names. | 8.1 SP2

##