Release Notes
|
 |
 |
|
 |
 |
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.
|
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. |
||
|
Security settings in the Administration Console for Web services did not function properly. A code change removed the ability to set policy and roles for Web services in the Administration Console. |
||
|
Realms created by the Administration Console lacked the The Administration Console now creates a ULMbean when it creates a new realm. |
||
|
The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close. |
||
|
For a three-node cluster on separate Solaris 2.8 machines, the Administration Server threw an InstanceNotFound exception when accessing the default Execute Queue. |
||
|
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. |
||
|
WebLogic Server sometimes displayed the following
|
||
|
The The Administration Console was still calling the The MBean has been fixed to look for appropriate provider type. |
||
|
New testing with an Active Directory LDAP uncovered a problem where a call to |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. |
||
|
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. |
||
|
In the 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). |
||
|
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. |
||
|
Editing the load order in the WebLogic Server Administration Console caused spaces to be embedded in the This problem occurred because the method The code was changed to remove these extra spaces. As a result of this fix, the extra spaces in the |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_41.00.jsp. |
|
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 |
||
|
When starting WebLogic Server as an Windows service using a classpath from a file, the error
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. |
||
|
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. |
||
|
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 2. Making a call to node1, create EJB and store remote in HTTP session (HTTP session replication is enabled) 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. 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:
|
||
|
A memory leak occurred when creating a A code change corrected memory leaks in |
||
|
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. |
||
|
User code such as servlet |
||
|
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. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp. |
||
|
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. |
||
|
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. |
|
For a stateless session bean, when the
and the bean was deployed on a cluster, this error was generated:
This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are not replicated. |
||
|
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 In a transaction, if a finder method is invoked on a BMP bean, it will now trigger the |
||
|
The This enhancement is made possible by introducing the new element |
||
|
Dynamic EJB-QL incorrectly passed long arguments as |
||
|
The container was failing to call |
||
|
Combining COUNT and EXISTS in a dynamic EJB-QL request resulted in invalid SQL and this exception:
An unnecessary column was being added to the main select list while parsing a subquery. A fix to the parser code solved the problem. |
||
|
ejbc generated invalid SQL for an |
||
|
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. |
||
|
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. |
||
|
In some bean-managed stateful session beans, an A code change results in the creation of one replacer per passivation request, so that each thread has its own replacer. |
||
|
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. |
||
|
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. |
||
|
EJBs with Bean-Managed Persistence and with concurrency set to exclusive called A code change resolved the problem so that the EJB finds the bean in the cache. |
||
|
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. |
||
|
Getter methods for a EJB 1.1 CMP bean did not call A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to
|
||
|
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. |
||
|
The EJB QL query generator could not handle: where target is collection member variable as in:
This problem has been fixed. The EJB QL compiler now properly handles this case. |
||
|
The The duplicate entries occurred because of an unnecessary call to the |
||
|
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. |
||
|
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. |
||
|
When using stateful session beans under load with WebLogic Server now unexports the proxy objects on the secondary server. When the Replicated bean receives a There should not be any negative side-effects on existing user applications. |
||
|
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. |
||
|
If an EJB uses container-managed transactions, the EJB specification requires transaction attributes to be set for all EJB methods (excluding methods of 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 |
||
|
For BLOBs, in the generated code, WebLogic Server calls
then problems may occur because WebLogic Server uses
Note that, in versions prior to SP2, the default behavior was to serialize a |
||
|
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:
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. |
||
|
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. |
||
|
The 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. |
||
|
When the AutoKey was specified in the
(that is, the generator name is The schema name provided in the If the users specify the
If users specify the
In the second query, WebLogic Server makes use of the |
||
|
The This problem was resolved by replacing the |
||
|
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. |
||
|
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. |
||
|
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. |
||
|
The When the
|
||
|
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. |
|
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. |
||
|
WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a
The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix. |
||
|
The WebLogic Server jDriver for MS SQLServer can mistakenly accept the |
||
|
|
||
|
Using LDAP with SSL caused a 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. |
||
|
A transactional (JTS) JDBC connection could falsely return true for the The cause of the problem was an unnecessary and failure-prone delegation of the The RMI connection object was modified to return the known state. User code now works as expected with |
||
|
When a JNDI lookup on a JDBC DataSource and then a
|
||
|
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. |
||
|
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 This problem occurred because in 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. |
||
|
Many of the Sybase JDBC driver's metadata methods, including
Code that is enacted (only) when the initial call to |
||
|
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 This problem was resolved by removing the call to |
||
|
A server thread dump showed a deadlock with one thread calling This problem occurred because A private locking object for the |
||
|
Oracle-related JDBC operations hung when the This problem occurred because A private locking object for the |
||
|
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 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. |
||
|
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: 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:
For more information about the BEA WebLogic Type 4 JDBC drivers, see WebLogic Type 4 JDBC Drivers. |