Release Notes
|
 |
 |
|
 |
 |
Resolved Problems for Service Pack 3
Service Packs are cumulative; Service Pack 3 contains all the fixes made in earlier Service Packs released for WebLogic Server 8.1.
The following sections describe problems that were resolved in WebLogic Server 8.1 Service Pack 3:
- Administration Console
- Classloaders
- Clusters
- Compilers
- Configuration Wizard
- Connector
- Core WebLogic Server
- Deployment
- EJB
- Installation
- J2EE
- JCOM
- JDBC
- jDriver
- JMS
- JNDI
- JSP
- JTA
- JVM
- Node Manager
- Operations, Administration, and Management
- Plug-Ins
- RMI/RMI-IIOP
- Samples
- Security
- Servlets
- SNMP
- Tools
- Web Services
- WebLogic Type 4 JDBC Drivers
- WebLogic Tuxedo Connector
- WLEC
- XML
Administration Console
Classloaders
Clusters
Compilers
Configuration Wizard
Connector
Core WebLogic Server
Deployment
EJB
Installation
J2EE
JCOM
JDBC
HighestNumUnavailable defaulted to 0, which caused all idle connections to be locked for testing and released all at once. This condition held connections longer than necessary, and caused unexpected ResourceExceptions from pools that seemed to be sized correctly.
New code makes the HighestNumUnavailable test and release connections one at a time. There is also a new configurable attribute added, secondsToTrustIdleConnection, which allows a connection to skip testing if it has been used within the set number of seconds.
WebLogic Server Multipool did not provide an option to define time-based failover. The exact condition under which failover would be triggered to a secondary connection pool was uncertain. It would go through all the connections in the pool before it decided that it did not have a good connection. If the primary database went down, it needed to wait for xx time before the connection failed over to a secondary database.
Code was added to provide an option to run a time check before returning the connection to the primary database. See JDBC MultiPool Failover Enhancements.
In previous releases of WebLogic Server, memory leaks occurred when a BLOB column was used through a JDBC Tx Data Source.
When an applet made a connection via a datasource and the applet was killed, WebLogic Server printed leak detection messages. These messages were sometimes sent in error, and were not properly formatted for the JDBC/WLS log.
JDBCLogger is now used to format the message in case of connection leak detection.
A memory leak was discovered in WebLogic Server 6.1 Service Pack 2. The leak occurred when using a TxDataSource to access a BLOB column on a database with the WebLogic XA driver. This problem was solved with a code fix.
When a JDBC log name was specified with the ".log" suffix, JDBC logging did not rotate as expected. The prior log file was overwritten by a new JDBC log when WebLogic Server was restarted.
When PoolShrinking was enabled with an Informix database, XAConnectionPool
A JDBC XAConnection wrapper code change resolved the problem.
An Oracle BLOB sometimes used a pooled connection after the connection pool determined that the connection was available for reassignment.
Code was added to ensure the BLOB is completely processed before closing the pool connection or ending the transaction.
Configuring idle-connection-timeout limits could result in unintended thread blocks or deadlocks because the JDBC pool may try to reclaim a connection that has not changed for the idle-timeout period but is still waiting for the DBMS to respond.
A code fix was implemented to ensure that the JDBC pool correctly recognizes idle connections.
Note: Configuring idle-connection-timeout limits are not intended to aid in stopping runaway or deadlocked transactions.
When two applications with one application-scoped datasource per application were deployed on the same server and the datasources have the same name, an InstanceAlreadyExistsException was thrown.
Code was added to configure the pool name to be application-specific when necessary.
In an instance where DB side cursors were discarded, such as by running an Oracle STATS package for the cost based optimizer, the cached prepared statements for the JDBC connections on WLS side became invalid.
There was no transparent way to have the prepared statement cache cleared by WebLogic Server in case exceptions were thrown due to this scenario. The cached statements remained invalid in the WebLogic Server cache until either WebLogic Server was restarted or the cache was cleared via the WebLogic Server Administration Console, or a JMX call.
WebLogic Server now clears a prepared cache when an error occurs.
The connection pool held a "ConnectionEnv" object that did not refer to any connection directly, but contained a map with statements. Those statements had a reference to the connection that created them, and so were still holding on a hierarchy of database objects.
Code was added to release the ConnectionEnv object in a timely manner.
New versions of JDBC drivers track the transactional state of connections. If a local transaction was active on a connection, XA operations could not be performed on it, resulting in an XAER_PROTO or XAER_RMERR when an xa_start() was called on the connection. As a result, applications had to go through the tedious process of narrowing down where in their code they had started but not ended a local transaction.
The problem was resolved by a code change in the recovery method that prevents special XA connections from being released to the pool twice.
The format of the connection leak file was modified to make the information more readable.
You can now configure a data source so that it binds to the JNDI tree with multiple names. You can use a multi-named data source in place of configuring multiple data sources that point to a single JDBC connection pool.
For more details, see "Binding a Data Source to the JNDI Tree with Multiple Names" in the Administration Console Online Help.
The code that replaces a pooled JDBC connection did not completely remove all references to replaced objects, so memory grew with each replaced connection. The problem was noted when using the getVendorConnection() method.
Now when WebLogic Server replaces a pooled connection, the connection is not referenced by other objects. This makes the replaced connection available for garbage collection.
During a graceful shutdown, the BufferedOutputStream to the jdbc.log was not completely flushed/closed, which could result in data loss in the buffer.
The code was modified so that BinaryOutputStream is now closed() in the JDBCService.prepareToSuspend() method.
Batched RowSet updates were failing on Informix if a table name included an upper-case letter. Informix uses lower-case letters for all metadata names. The WebLogic Server RowSet implementation relies on metadata for batch updates.
The WebLogic Server RowSet implementation now converts metadata names to lower-case when using an Informix JDBC driver.
In jta.DataSource, when doing refreshAndEnlist, WebLogic Server called tx.enlist(), but the connection was not returned to the pool if there was an exception in the refreshAndEnlist call.
A code change catches the exception and releases the connection to the pool.
WebLogic Server sometimes threw a bogus warning about a JDBC connection leak:
[SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n
During an attempt to reset a connection pool during high load, a deadlock was occurring between DataSource.commit() and RESET_POOL.
In the weblogic.jdbc.common.internal.ConnectionPool.reset() method, the connection pool is now suspended before being refreshed, and is then resumed to avoid a deadlock.
For certain JDBC connections, the call to roll back a transaction was not being handled immediately because the driver had to wait for any currently-executing statement to return.
In order to remove this delay, code was implemented to send a Statement.cancel() to abort any such executing statement when WebLogic Server is in the process of rolling back an ongoing transaction.
The isClosed() method for all non-XA connections within a given transaction returned true after a Connection.close() call to any one of them.
A code fix supplies a separate wrapper for the same underlying connection to all users involved in the transaction.
When the test-connections-on-reserve is enabled and the isolation level is TransactionReadCommitted, a SQLException occurs when the customer is using the Ingres driver. The EJB has the TRANSACTION_READ_COMMITTED transaction isolation level. When calling the EJB, the database connection fails on the following SQLException: "SQLState(25000) vendor code(5932) ca.edbc.util.EdbcEx: SET TRANSACTION: This statement is not allowed.
No change, except that those calls which would fail on a connection that already held DBMS locks should now succeed.
A synchronization issue (not a deadlock) occurred when the ResourcePoolMaintanenceTask attempted to time out all inactive resources. It got a lock to the ConnectionPool and proceeded to check all the connections. However, if a connection was active at that point and locked on another object, the ResourcePoolMaintanenceTask had to wait to get that lock. This caused a slowdown and a "frozen" server to the end user. The task completed but took a very long time.
A code change prevents the connection pool from locking the entire connection pool. Another method to avoid this is to turn off the reclaim process, by setting the timeout value to zero.
WebLogic Server unexpectedly changed autocommit mode for a JTS connection. This occurred when WebLogic Server failed connection testing on reserve. Because a JTS connection accepts global transactions and a connection is in the user transaction, it should honor the user transaction boundary. Furthermore, connection testing should be implicit behavior for users. This has not been the case in prior releases.
When Connection Creation Retry Frequency on a JDBC connection pool was set to enable connection retries (not set to 0), the connection creation retry logic was invoked when an application attempted to reserve a connection. If the database was unavailable, the thread would hang during the wait and retry cycles.
Connection reserve requests now succeed or fail quickly as in previous releases.
The wlconfig ant task did not properly remove a pool. The problem is within the JDBC connection manager code.
Enhancement request to allow explicit naming of JDBC driver being used in class VendorId.
Changes in weblogic.jdbc.vendor.oracle.OracleStatement from 81SP1 to 81SP2 broke Oracle 9 Driver compatibility. The return type for the method getDBDescription() on Interface weblogic.jdbc.vendor.oracle.OracleStatement changed from DBColumn[] in 81SP1 to Object[] in 81SP2. This change made 81SP2 incompatible with Oracle 9 Drivers when a customer would like to wrap the java.sql.Statement object with a dynamic proxy.
This problem was resolved through a code change. In OracleStatement.java, references to the following two unsupported methods were removed: getDBDescription and getBinds.
In response to requests for a "Purge Policy" for JDBC connection pools, the StatementTimeout and TestStatementTimeout attributes were added to JDBC connection pools to limit the amount of time that a statement can execute on a database connection from a JDBC connection pool.
For detailed information, see "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC.
Using multiple different prepared statements in a single transaction invoked a bug in the XA statement cache, which lost the handle to unclosed JDBC statements. This quickly caused all the available cursors in Oracle to be consumed and leaked.
A fix was made to the underlying collection object being used to implement the XA statement cache.
A JDBC Multipool fails with an IndexOutOfBoundsException under a heavy load due to a non-threadsafe manner of incrementing an array index.
When a Java client that used Weblogic datasources experienced a "PeerGone" exception, the transaction contexts related to the connection were not properly cleaned up.
In a multi-server domain, a client involved in a global transaction got the following exception:
weblogic.transaction.RollbackException: delist() failed on resource jdbcXAPool
The code was changed so that if the data source is null, then the resource manager is not set. When the data source is initialized, the resource manager is wrapped by VendorXAResource.
The JDBC connection pool's "CountOfTestFailuresTillFlush" property neglected to clear statement caches.
The problem was resolved with a code fix.
For detailed information about using the "flush pool" feature, see "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC.
When a JDBC connection pool was created using the silent script mode, with the MaxCapacity parameter set to 1, the Administration Console incorrectly displayed the parameter's value as 15.
|
HighestNumUnavailable defaulted to 0, which caused all idle connections to be locked for testing and released all at once. This condition held connections longer than necessary, and caused unexpected ResourceExceptions from pools that seemed to be sized correctly. New code makes the HighestNumUnavailable test and release connections one at a time. There is also a new configurable attribute added, secondsToTrustIdleConnection, which allows a connection to skip testing if it has been used within the set number of seconds. |
||
|
WebLogic Server Multipool did not provide an option to define time-based failover. The exact condition under which failover would be triggered to a secondary connection pool was uncertain. It would go through all the connections in the pool before it decided that it did not have a good connection. If the primary database went down, it needed to wait for xx time before the connection failed over to a secondary database. Code was added to provide an option to run a time check before returning the connection to the primary database. See JDBC MultiPool Failover Enhancements. |
||
|
In previous releases of WebLogic Server, memory leaks occurred when a BLOB column was used through a JDBC Tx Data Source. |
||
|
When an applet made a connection via a datasource and the applet was killed, WebLogic Server printed leak detection messages. These messages were sometimes sent in error, and were not properly formatted for the JDBC/WLS log. JDBCLogger is now used to format the message in case of connection leak detection. |
||
|
A memory leak was discovered in WebLogic Server 6.1 Service Pack 2. The leak occurred when using a TxDataSource to access a BLOB column on a database with the WebLogic XA driver. This problem was solved with a code fix. |
||
|
When a JDBC log name was specified with the ".log" suffix, JDBC logging did not rotate as expected. The prior log file was overwritten by a new JDBC log when WebLogic Server was restarted. |
||
|
When PoolShrinking was enabled with an Informix database, XAConnectionPool A JDBC XAConnection wrapper code change resolved the problem. |
||
|
An Oracle BLOB sometimes used a pooled connection after the connection pool determined that the connection was available for reassignment. Code was added to ensure the BLOB is completely processed before closing the pool connection or ending the transaction. |
||
|
Configuring idle-connection-timeout limits could result in unintended thread blocks or deadlocks because the JDBC pool may try to reclaim a connection that has not changed for the idle-timeout period but is still waiting for the DBMS to respond. A code fix was implemented to ensure that the JDBC pool correctly recognizes idle connections. Note: Configuring idle-connection-timeout limits are not intended to aid in stopping runaway or deadlocked transactions. |
||
|
When two applications with one application-scoped datasource per application were deployed on the same server and the datasources have the same name, an Code was added to configure the pool name to be application-specific when necessary. |
||
|
In an instance where DB side cursors were discarded, such as by running an Oracle STATS package for the cost based optimizer, the cached prepared statements for the JDBC connections on WLS side became invalid. There was no transparent way to have the prepared statement cache cleared by WebLogic Server in case exceptions were thrown due to this scenario. The cached statements remained invalid in the WebLogic Server cache until either WebLogic Server was restarted or the cache was cleared via the WebLogic Server Administration Console, or a JMX call. WebLogic Server now clears a prepared cache when an error occurs. |
||
|
The connection pool held a "ConnectionEnv" object that did not refer to any connection directly, but contained a map with statements. Those statements had a reference to the connection that created them, and so were still holding on a hierarchy of database objects. Code was added to release the ConnectionEnv object in a timely manner. |
||
|
New versions of JDBC drivers track the transactional state of connections. If a local transaction was active on a connection, XA operations could not be performed on it, resulting in an The problem was resolved by a code change in the recovery method that prevents special XA connections from being released to the pool twice. |
||
|
The format of the connection leak file was modified to make the information more readable. |
||
|
You can now configure a data source so that it binds to the JNDI tree with multiple names. You can use a multi-named data source in place of configuring multiple data sources that point to a single JDBC connection pool. For more details, see "Binding a Data Source to the JNDI Tree with Multiple Names" in the Administration Console Online Help. |
||
|
The code that replaces a pooled JDBC connection did not completely remove all references to replaced objects, so memory grew with each replaced connection. The problem was noted when using the Now when WebLogic Server replaces a pooled connection, the connection is not referenced by other objects. This makes the replaced connection available for garbage collection. |
||
|
During a graceful shutdown, the The code was modified so that |
||
|
Batched RowSet updates were failing on Informix if a table name included an upper-case letter. Informix uses lower-case letters for all metadata names. The WebLogic Server RowSet implementation relies on metadata for batch updates. The WebLogic Server RowSet implementation now converts metadata names to lower-case when using an Informix JDBC driver. |
||
|
In A code change catches the exception and releases the connection to the pool. |
||
|
WebLogic Server sometimes threw a bogus warning about a JDBC connection leak:
|
||
|
During an attempt to reset a connection pool during high load, a deadlock was occurring between In the |
||
|
For certain JDBC connections, the call to roll back a transaction was not being handled immediately because the driver had to wait for any currently-executing statement to return. In order to remove this delay, code was implemented to send a |
||
|
The A code fix supplies a separate wrapper for the same underlying connection to all users involved in the transaction. |
||
|
When the test-connections-on-reserve is enabled and the isolation level is TransactionReadCommitted, a SQLException occurs when the customer is using the Ingres driver. The EJB has the TRANSACTION_READ_COMMITTED transaction isolation level. When calling the EJB, the database connection fails on the following SQLException: "SQLState(25000) vendor code(5932) ca.edbc.util.EdbcEx: SET TRANSACTION: This statement is not allowed. No change, except that those calls which would fail on a connection that already held DBMS locks should now succeed. |
||
|
A synchronization issue (not a deadlock) occurred when the ResourcePoolMaintanenceTask attempted to time out all inactive resources. It got a lock to the ConnectionPool and proceeded to check all the connections. However, if a connection was active at that point and locked on another object, the ResourcePoolMaintanenceTask had to wait to get that lock. This caused a slowdown and a "frozen" server to the end user. The task completed but took a very long time. A code change prevents the connection pool from locking the entire connection pool. Another method to avoid this is to turn off the reclaim process, by setting the timeout value to zero. |
||
|
WebLogic Server unexpectedly changed autocommit mode for a JTS connection. This occurred when WebLogic Server failed connection testing on reserve. Because a JTS connection accepts global transactions and a connection is in the user transaction, it should honor the user transaction boundary. Furthermore, connection testing should be implicit behavior for users. This has not been the case in prior releases. |
||
|
When Connection Creation Retry Frequency on a JDBC connection pool was set to enable connection retries (not set to 0), the connection creation retry logic was invoked when an application attempted to reserve a connection. If the database was unavailable, the thread would hang during the wait and retry cycles. Connection reserve requests now succeed or fail quickly as in previous releases. |
||
|
The wlconfig ant task did not properly remove a pool. The problem is within the JDBC connection manager code. |
||
|
Enhancement request to allow explicit naming of JDBC driver being used in class VendorId. |
||
|
Changes in weblogic.jdbc.vendor.oracle.OracleStatement from 81SP1 to 81SP2 broke Oracle 9 Driver compatibility. The return type for the method getDBDescription() on Interface weblogic.jdbc.vendor.oracle.OracleStatement changed from DBColumn[] in 81SP1 to Object[] in 81SP2. This change made 81SP2 incompatible with Oracle 9 Drivers when a customer would like to wrap the java.sql.Statement object with a dynamic proxy. This problem was resolved through a code change. In OracleStatement.java, references to the following two unsupported methods were removed: getDBDescription and getBinds. |
||
|
In response to requests for a "Purge Policy" for JDBC connection pools, the StatementTimeout and TestStatementTimeout attributes were added to JDBC connection pools to limit the amount of time that a statement can execute on a database connection from a JDBC connection pool. For detailed information, see "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC. |
||
|
Using multiple different prepared statements in a single transaction invoked a bug in the XA statement cache, which lost the handle to unclosed JDBC statements. This quickly caused all the available cursors in Oracle to be consumed and leaked. A fix was made to the underlying collection object being used to implement the XA statement cache. |
||
|
A JDBC Multipool fails with an |
||
|
When a Java client that used Weblogic datasources experienced a "PeerGone" exception, the transaction contexts related to the connection were not properly cleaned up. |
||
|
In a multi-server domain, a client involved in a global transaction got the following exception:
The code was changed so that if the data source is null, then the resource manager is not set. When the data source is initialized, the resource manager is wrapped by VendorXAResource. |
||
|
The JDBC connection pool's "CountOfTestFailuresTillFlush" property neglected to clear statement caches. The problem was resolved with a code fix. For detailed information about using the "flush pool" feature, see "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC. |
||
|
When a JDBC connection pool was created using the silent script mode, with the MaxCapacity parameter set to 1, the Administration Console incorrectly displayed the parameter's value as 15. |
jDriver
JMS
JNDI
JSP
JTA
JVM
Node Manager
UnixProcessControl|NodeManager.c sends a SIGTERM in offline, when it should send a SIGKILL, as JavaProcessControl does.
Following a code change, UnixProcessControl offline now returns SIGKILL.
When Node Manager was stopped and restarted, sometimes after restart Node Manager detected that it was monitoring a Managed Server. It waited for 180 seconds for the Managed Server to contact it, after which it tried to restart the Managed Server. The Managed Server has a timer which tried repeatedly to contact the Node Manager. The timer interval increased exponentially.It tried after 2,4,8,16... seconds. If the Node Manager was started after a long time then the Managed Server timer interval could be larger then 180 seconds, leading the Node Manager to behave as if the Managed Server was down. Additionally, the Managed Server was not starting a timer when the Node Manager failed because it received a NumberFormatException and the thread ended.
1) The Managed Server timer interval is restricted to a maximum of 128 seconds which is less than the 180 second interval at which the Node Manager attempts a restart.
2) When the Node Manager failed, the Managed Server got an exception. That exception is caught in NodeManagerCommandListener and a timer thread is started to attempt to connect to the Node Manager periodically.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp.
|
Following a code change, |
||
|
When Node Manager was stopped and restarted, sometimes after restart Node Manager detected that it was monitoring a Managed Server. It waited for 180 seconds for the Managed Server to contact it, after which it tried to restart the Managed Server. The Managed Server has a timer which tried repeatedly to contact the Node Manager. The timer interval increased exponentially.It tried after 2,4,8,16... seconds. If the Node Manager was started after a long time then the Managed Server timer interval could be larger then 180 seconds, leading the Node Manager to behave as if the Managed Server was down. Additionally, the Managed Server was not starting a timer when the Node Manager failed because it received a NumberFormatException and the thread ended. 1) The Managed Server timer interval is restricted to a maximum of 128 seconds which is less than the 180 second interval at which the Node Manager attempts a restart. 2) When the Node Manager failed, the Managed Server got an exception. That exception is caught in NodeManagerCommandListener and a timer thread is started to attempt to connect to the Node Manager periodically. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp. |
Operations, Administration, and Management
WebLogic Server calculated the Administration port URL incorrectly. A code change ensures that the URL is calculated based on the Administration Port if it is enabled or, secondly, on the Administration channel if it is enabled.
When using wlconfig Ant task to create a JMS server and two JMS queues for a running server instance, the JMS Server and the two JMS queues were created and reflected correctly through the Administration Console. However, wlconfig did not properly update the config.xml file, because it incorrectly placed the 2nd JMS queue outside the </JMSServer> end tag.
Previous releases of WebLogic Server required specification of the NAME attribute of the MLET element.
To comply with JMX specifications, the NAME attribute is now optional.
Restarting the Administration Server and then starting two Managed Servers simultaneously resulted in heavy CPU consumption. One Managed Server completed initialization, the second started initialization and stopped.
Use of kill -QUIT pid revealed that the main thread was stuck in HashMap.rehash, as shown:
"main" prio=5 tid=0x29240 nid=0x1 runnable
[0xffbec000..0xffbedbd4] at
java.util.HashMap.rehash(HashMap.java:292) at
java.util.HashMap.put(HashMap.java:344) at
weblogic.management.internal.DynamicMBeanImpl$XInfo.get(DynamicMBeanImpl.java:2270) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:195) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:167) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:70) at
weblogic.jms.frontend.FEConsumer.<init>(FEConsumer.java:100)
at weblogic.jms.frontend.FESession$3.run(FESession.java:952)
at ....
A code change increased the size of the default HashMap to accommodate all MBean attributes without resizing, and synchronized thread access to the HashMap.
The weblogic.Admin command returns to the main class. The main class returns an exit code that is determined by whether or not an exception was thrown. An unnecessary exception was thrown when the command succeeded.
WebLogic Server no longer throws an exception when a command succeeds.
weblogic.common.internal.AdminProxy code threw an exception if the caller was not an admin user. The operator user requests were dispatched to the default queue. The server hung during shutdown behaving as if it had a pending request on the default queue. But the admin user requests were dispatched to a different queue than the default.
Code was added to enable WebLogic Server to check if the user is an operator, and if so, allow the user to shut down the server. Additional code was added to dispatch the operator user requests to a queue other than the default. This resolves the problem.
Managed server logs could not be viewed when attempting a remote connection to the Managed Server because the url specified the wrong port when the administration port or admin channel were used.
WebLogic Server was updated to use the correct port and do the operation with QOS_ADMIN set.
MBean auditing was recording clear-text passwords in certain cases where properties were tagged with @exclude.
A code change ensures that WebLogic Server does not print the values of the encrypted attributes in clear text.
Mbeans for custom authentication providers no longer must be put inside of the WebLogic installation tree in the WL_HOME\server\lib\mbeantypes directory.
WL_HOME\server\lib\mbeantypes is the default directory for installing MBean types. However, if you want WebLogic Server to look for MBean types in additional directories, use the -Dweblogic.alternateTypesDirectory=<dir> command-line flag when starting your server, where <dir> is a comma-separated list of directory names. When you use this flag, WebLogic Server will always load MBean types from WL_HOME\server\lib\mbeantypes first, then will look in the additional directories and load all valid archives present in those directories (regardless of their extension). For example, if -Dweblogic.alternateTypesDirectory = dirX,dirY, WebLogic Server will first load MBean types from WL_HOME\server\lib\mbeantypes, then any valid archives present in dirX and dirY.
Note that you must continue to use the option or your server will be come unbootable (for example, if you used the option and created some users and then decided not to use the alternateTypesDirectory option).
For more information, see Install the MBean Type Into the WebLogic Server Environment in Developing Security Providers for WebLogic Server.
Time formatted log files caused infinite loop, resulting in the following issues:
The log files were rotated twice because WebLogic Server tried to log an exception to a log file when the log file was closed. During rotation, WebLogic Server tried to write to a closed file, which threw an exception.
Even when the log files were restricted, WebLogic Server would let them grow beyond the file count specified. There was no code in place to delete the older log files.
The correct rotation time is now set during startup.
If an exception is thrown during rotation, WebLogic Server no longer logs to the file, but prints it to stdout instead.
After each rotation, WebLogic Server now checks to see if the files exceed the limit, if restricted. It now deletes older log files.
When a Managed Server with a custom COMMO bean was restarted without restarting its Administration Server, the Managed Server could not create an instance of the COMMO bean. This exception occurred:
javax.Management.InstanceAlreadyExistsException is thrown, and the Detailed message in the exception is, The Object name specified 'wlidomain:Name=t,Server=managed1,Type=AppViewRuntime' is not unique across the domain. Please choose an unique Object Name
Analysis revealed that the Mbean was not unregistered on the Administration Server's MBeanServer when it went down. For this reason, upon restart, the Managed Server could not re-create the bean—the Administration Server still had a bean instance with that bean's name in its list of instantiated beans. Mbean names must be unique across a domain.
The problem was resolved by a code change to unregister all of a Managed Server's server-specific beans when it goes down. When a Managed Server goes down, the Administration Server receives a PeerGoneEvent and unregisters all MBeans associated with the Managed Server.
When you set the value of SqlStmtProfilingEnabled through MBeans or manually in the config.xml file and then attempted to retrieve that value through MBeans it did not show the value. Instead, it returned the following message, "It appears that no attributes have been specified for this MBean".
Could not shut down a server instance using the weblogic.Admin SHUTDOWN command.
A code fix ensures that weblogic.admin correctly uses the default URL (that is, t3://localhost:7001).
Applications were deployed on servers to which they were not targeted.
Code was added to check the target before deploying applications.
The Weblogic MBeanLoader generated the following error message:
weblogic.management.commo.WebLogicMBeanLoader security.xml Exception in thread "main" weblogic.management.ManagementError: [Management:141113] The management subsystem was accessed prior to its initialization.
This was resolved by fixing the weblogicMBeanLoader/weblogicMBeanDumper initialization code.
In previous service packs, the log method of the java.util.logging.Logger was not honored.
-Dweblogic.ProductionModeEnabled=true was not being processed correctly because WebLogic Server was expecting it to be a Boolean rather than a string.
This problem was fixed by adding code to make WebLogic Server process this as a string in the ant task.
In WebLogic Server 8.1, the log rotation methodology changed.
Log rotation was triggered by not only time, but also by the output activity to the log file. In other words, if there was no message at rotation time, WebLogic Server did not rotate the log until it was modified.
This problem has been addressed by forcing WebLogic Server to rotate the logs at the scheduled times, after initially rotating based on the first log activity after starting the server.
The Managed Server was started in production mode only when the Administration Server started in production mode. In all other combinations, the Managed Server was started in development mode.
Code was added to fix the logic for ProductionModeEnabled on the Managed Server.
Users from the Deployers group were not able to deploy applications either from the console or using the command line tool weblogic.Deployer. Deployment of applications required write permissions on certain attributes & execute permissions on other actions.
Permissions were added to users in deployers group to be able to deploy application to various targets (clusters, servers, virtual hosts).
When you configured a new Managed Server node using the Administration Console, the execute queue of the new server instance could not be configured on the console until the Administration Server was restarted.
Now new server nodes created after the Administration Server has been started have editable default execute queues.
The Log file was not stored relative to the server directory path.
The log file MBean now recognizes where the server was being started (in what directory), so the log can be found and rotated.
A local context lookup and call for a local server runtime MBean failed.
A code change was made so that when server runtime MBeans are called by class type, then "*" domain is used instead of null.
The weblogic.logging.NonCatalogLogger with the StdoutEnabled flag set to false disregarded this value by displaying the log output to the Administration Console for client-side logging.
Now the consoleHandler logger recognizes the stdoutEnabled flag.
WebLogic Server startup was failing when the configuration file (config.xml) was referencing other XML files.
A code fix resolved this problem with JDK 1.4 XML parser. However, other than the fact that the config.xml file is an .xml extension, WebLogic Server does not document the config.xml as an XML-compliant file, nor does the documentation recommend such XML-like references.
In a clustered configuration, the userExists() call sometimes fails after attempting to create a new user or group on a Managed Server.
The problem was resolved by a code fix so that newly created user lookups using the userExists() API occur on the Administration Server, and existing user lookups occur on the local Managed Server.
For Attribute Change Audit Notifications, the auditor printed the old value of the attribute as the new value.
A code fix ensures that the auditor uses the correct value as the new value for a given attribute.
For detailed information about obtaining auditing information from the Administration Console, see "Auditing Providers" in Developing Security Providers for WebLogic Server.
In previous version 8.1 service packs, weblogic.Admin did not properly handle the "commotype" syntax. This caused the sample security providers to break. When you built the samples, started the server, and tried to set up the domain, you received a number of javax.management.MBeanException errors.
A code change enables weblogic.Admin to correctly handle the "commotype" syntax. As a result, the sample security providers will run correctly against this service pack.
weblogic.Admin did not work properly with the default URL. For example: java weblogic.Admin -username ss -password ss VERSION returned no results, but adding -url t3://localhost:7001 returned correct results.
Following a code change, weblogic.Admin now checks the input URL for null, because it has the default URL internally already.
For Web applications deployed on a cluster, the number of servlets in the Web application displayed in the Administration Console was incorrect because of a java.lang.ClassCastException.
The weblogic.properties MBean conversion tool uses a separate MBeanServer than what is used for internal server operations. Therefore, an invalidAttributeValueException was thrown when the MBean being converted was not found in the MBeanServer, which was causing the conversion to fail.
A code change was made so that when an MBean properties conversion is in progress, a check is performed to see if the MBean exists in the MBeanServer that the weblogic.properties converter uses before throwing an exception.
Any file, regardless of extension, is loaded by the plug-in mechanism and produces server start-time errors. Only .jar files in lib/mbeantypes should be considered security providers; other suffixed files should be ignored.
Previously, any file that was in the .../lib/mbeantypes directory would be treated as security providers and be loaded at server boot time. This would happen independently of the file extension type. Now, only files that end in .jar or .zip will be treated as security providers. If you relied on security providers being loaded that were not in a file ending in .jar or .zip, then your domain will not boot any longer as those security providers will no longer be loaded. Those security provider files will have to be renamed to work correctly before booting the server.
A LogRotationException was thrown when rotating the domain log. This occurred when the logger generated log index(0001) based in a new log directory was rotated into the current log directory where a file by the same name existed.
The following weblogic.Server command-line options were restored to provide interoperability with previous releases:
Failure to specify a name while doing an MBean lookup resulted in a Null Pointer Exception.
WebLogic Server performance has been enhanced by minimizing the synchronization block to reduce excessive thread waiting.
When the startup class used the JDK1.4 logging API LogManager.getLogManager().readConfiguration(), WebLogic Server stopped the stdout and no further logging messages were available.
WebLogic Server now uses an anonymous logger to resolve this issue.
When a clustered server node was shut down, it was not removed from the migration managers active servers list. Therefore, in situations where a migratable server was then deleted and recreated, it would generate an InstanceNotFoundException (INFE).
Now during shutdown of a migratable server, INFEs are ignored when traversing the active server list in the migration manager.
During startup, the administration server failed to discover its managed servers.
During server shutdown, methods related to the managed server rediscovery process were incorrectly invoked. Also, the deployment callback handler used stale configuration MBean references.
This problem was resolved so that Managed Server rediscovery methods are no longer invoked during server shutdown. And the callback handler now uses administration MBean references to avoid stale configuration MBean references.
Adding or redeploying a module that was part of a large EAR file (600MB) took a very long time.
A code change to the WebApp module improved performance:
The WebApp module now considers the update of a module when the delta is for changing the whole module.
The logging handler (WLErrorManager.error) was causing re-entry into the logging code when reporting a fatal error, which was resulting in a logging deadlock with another logging thread.
A code change prevents a logging deadlock when logging handlers report a fatal error.
Certain userLockoutManager operations were incorrectly executed on the Administration server rather than on the local managed server;
Code was changed to ensure the operations are executed on the correct server.
|
WebLogic Server calculated the Administration port URL incorrectly. A code change ensures that the URL is calculated based on the Administration Port if it is enabled or, secondly, on the Administration channel if it is enabled. |
||
|
When using wlconfig Ant task to create a JMS server and two JMS queues for a running server instance, the JMS Server and the two JMS queues were created and reflected correctly through the Administration Console. However, wlconfig did not properly update the config.xml file, because it incorrectly placed the 2nd JMS queue outside the </JMSServer> end tag. |
||
|
Previous releases of WebLogic Server required specification of the NAME attribute of the MLET element. To comply with JMX specifications, the NAME attribute is now optional. |
||
|
Restarting the Administration Server and then starting two Managed Servers simultaneously resulted in heavy CPU consumption. One Managed Server completed initialization, the second started initialization and stopped. Use of
A code change increased the size of the default HashMap to accommodate all MBean attributes without resizing, and synchronized thread access to the HashMap. |
||
|
The weblogic.Admin command returns to the main class. The main class returns an exit code that is determined by whether or not an exception was thrown. An unnecessary exception was thrown when the command succeeded. WebLogic Server no longer throws an exception when a command succeeds. |
||
|
Code was added to enable WebLogic Server to check if the user is an operator, and if so, allow the user to shut down the server. Additional code was added to dispatch the operator user requests to a queue other than the default. This resolves the problem. |
||
|
Managed server logs could not be viewed when attempting a remote connection to the Managed Server because the url specified the wrong port when the administration port or admin channel were used. WebLogic Server was updated to use the correct port and do the operation with QOS_ADMIN set. |
||
|
MBean auditing was recording clear-text passwords in certain cases where properties were tagged with @exclude. A code change ensures that WebLogic Server does not print the values of the encrypted attributes in clear text. |
||
|
Mbeans for custom authentication providers no longer must be put inside of the WebLogic installation tree in the
Note that you must continue to use the option or your server will be come unbootable (for example, if you used the option and created some users and then decided not to use the For more information, see Install the MBean Type Into the WebLogic Server Environment in Developing Security Providers for WebLogic Server. |
||
|
Time formatted log files caused infinite loop, resulting in the following issues:
The correct rotation time is now set during startup. If an exception is thrown during rotation, WebLogic Server no longer logs to the file, but prints it to stdout instead. After each rotation, WebLogic Server now checks to see if the files exceed the limit, if restricted. It now deletes older log files. |
||
|
When a Managed Server with a custom COMMO bean was restarted without restarting its Administration Server, the Managed Server could not create an instance of the COMMO bean. This exception occurred:
Analysis revealed that the Mbean was not unregistered on the Administration Server's MBeanServer when it went down. For this reason, upon restart, the Managed Server could not re-create the bean—the Administration Server still had a bean instance with that bean's name in its list of instantiated beans. Mbean names must be unique across a domain. The problem was resolved by a code change to unregister all of a Managed Server's server-specific beans when it goes down. When a Managed Server goes down, the Administration Server receives a |
||
|
When you set the value of SqlStmtProfilingEnabled through MBeans or manually in the config.xml file and then attempted to retrieve that value through MBeans it did not show the value. Instead, it returned the following message, "It appears that no attributes have been specified for this MBean". |
||
|
Could not shut down a server instance using the weblogic.Admin SHUTDOWN command. A code fix ensures that weblogic.admin correctly uses the default URL (that is, |
||
|
Applications were deployed on servers to which they were not targeted. Code was added to check the target before deploying applications. |
||
|
The Weblogic MBeanLoader generated the following error message:
This was resolved by fixing the weblogicMBeanLoader/weblogicMBeanDumper initialization code. |
||
|
In previous service packs, the log method of the |
||
|
-Dweblogic.ProductionModeEnabled=true was not being processed correctly because WebLogic Server was expecting it to be a Boolean rather than a string. This problem was fixed by adding code to make WebLogic Server process this as a string in the ant task. |
||
|
In WebLogic Server 8.1, the log rotation methodology changed. Log rotation was triggered by not only time, but also by the output activity to the log file. In other words, if there was no message at rotation time, WebLogic Server did not rotate the log until it was modified. This problem has been addressed by forcing WebLogic Server to rotate the logs at the scheduled times, after initially rotating based on the first log activity after starting the server. |
||
|
The Managed Server was started in production mode only when the Administration Server started in production mode. In all other combinations, the Managed Server was started in development mode. Code was added to fix the logic for ProductionModeEnabled on the Managed Server. |
||
|
Users from the Deployers group were not able to deploy applications either from the console or using the command line tool weblogic.Deployer. Deployment of applications required write permissions on certain attributes & execute permissions on other actions. Permissions were added to users in deployers group to be able to deploy application to various targets (clusters, servers, virtual hosts). |
||
|
When you configured a new Managed Server node using the Administration Console, the execute queue of the new server instance could not be configured on the console until the Administration Server was restarted. Now new server nodes created after the Administration Server has been started have editable default execute queues. |
||
|
The Log file was not stored relative to the server directory path. The log file MBean now recognizes where the server was being started (in what directory), so the log can be found and rotated. |
||
|
A local context lookup and call for a local server runtime MBean failed. A code change was made so that when server runtime MBeans are called by class type, then "*" domain is used instead of null. |
||
|
The Now the |
||
|
WebLogic Server startup was failing when the configuration file (config.xml) was referencing other XML files. A code fix resolved this problem with JDK 1.4 XML parser. However, other than the fact that the config.xml file is an .xml extension, WebLogic Server does not document the config.xml as an XML-compliant file, nor does the documentation recommend such XML-like references. |
||
|
In a clustered configuration, the The problem was resolved by a code fix so that newly created user lookups using the |
||
|
For Attribute Change Audit Notifications, the auditor printed the old value of the attribute as the new value. A code fix ensures that the auditor uses the correct value as the new value for a given attribute. For detailed information about obtaining auditing information from the Administration Console, see "Auditing Providers" in Developing Security Providers for WebLogic Server. |
||
|
In previous version 8.1 service packs, A code change enables |
||
|
Following a code change, |
||
|
For Web applications deployed on a cluster, the number of servlets in the Web application displayed in the Administration Console was incorrect because of a java.lang.ClassCastException. |
||
|
The A code change was made so that when an MBean properties conversion is in progress, a check is performed to see if the MBean exists in the MBeanServer that the weblogic.properties converter uses before throwing an exception. |
||
|
Any file, regardless of extension, is loaded by the plug-in mechanism and produces server start-time errors. Only .jar files in lib/mbeantypes should be considered security providers; other suffixed files should be ignored. Previously, any file that was in the .../lib/mbeantypes directory would be treated as security providers and be loaded at server boot time. This would happen independently of the file extension type. Now, only files that end in .jar or .zip will be treated as security providers. If you relied on security providers being loaded that were not in a file ending in .jar or .zip, then your domain will not boot any longer as those security providers will no longer be loaded. Those security provider files will have to be renamed to work correctly before booting the server. |
||
|
A |
||
|
The following weblogic.Server command-line options were restored to provide interoperability with previous releases: |
||
|
Failure to specify a name while doing an MBean lookup resulted in a Null Pointer Exception. |
||
|
WebLogic Server performance has been enhanced by minimizing the synchronization block to reduce excessive thread waiting. |
||
|
When the startup class used the JDK1.4 logging API WebLogic Server now uses an anonymous logger to resolve this issue. |
||
|
When a clustered server node was shut down, it was not removed from the migration managers active servers list. Therefore, in situations where a migratable server was then deleted and recreated, it would generate an InstanceNotFoundException (INFE). Now during shutdown of a migratable server, INFEs are ignored when traversing the active server list in the migration manager. |
||
|
During startup, the administration server failed to discover its managed servers. |
||
|
During server shutdown, methods related to the managed server rediscovery process were incorrectly invoked. Also, the deployment callback handler used stale configuration MBean references. This problem was resolved so that Managed Server rediscovery methods are no longer invoked during server shutdown. And the callback handler now uses administration MBean references to avoid stale configuration MBean references. |
||
|
Adding or redeploying a module that was part of a large EAR file (600MB) took a very long time. A code change to the WebApp module improved performance:
|
||
|
The logging handler ( A code change prevents a logging deadlock when logging handlers report a fatal error. |
||
|
Certain userLockoutManager operations were incorrectly executed on the Administration server rather than on the local managed server; Code was changed to ensure the operations are executed on the correct server. |
Plug-Ins
WebLogic Server proxy plug-ins restricted the HTTP commands that could be submitted from the client to the server. The validation rules in the plug-in code now allow the following HTTP commands that are needed for WebDAV implementations:
(ISAPI) DefaultFileName did not work if iisforward.dll was not used. The problem was exhibited when:
On a request for a directory that had no filename, the DefaultFileName was not used. The problem was corrected with a code fix.
(NSAPI) When a client stopped a response from being sent to it (for example, closing the browser before the response is completely received), a 500 [WRITE TOCLIENT ERROR] was logged in the Web server logs.
The Web server health monitoring tools used a 500 error to indicate that something was wrong with the server's health and that since this was not a server health issue but the client terminating the response, the error if any should not have been 500.
The request response path is as follows:
client -> proxyWebserver->plug-in->wls
and the expected response path is
client <- proxyWebserver<-plug-in<-wls
After WebLogic Server had successfully sent the response, but the Web server had not completely sent it to the client, the client aborted the communication and a 500 error was logged in the Web server's access.log which normally indicates that something is wrong with the server.
A code change was implemented so that 500 errors are not generated if the client breaks the connection.
(ISAPI) In WebLogic Server 6.1 Service Pack 4, the plug-in did not recognize the WLTempDir flag for the _wl_proxy folder. The code was fixed to use the flag.
[Apache] When using multiple MatchExpression parameters in httpd.conf to route requests to different locations, as in:
MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001
MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003
Each request overwrote the same global parameter info, which caused requests to go to the wrong location. In the above example, this problem resulted in *.jsp requests going to the server at port 8003.
The code was fixed to ensure that each request uses its own copy of the parameter information.
(NSAPI) If KeepAliveEnabled and DynamicServerList were both enabled, the plug-in could leave sockets in a CLOSE_WAIT state. This problem was solved with a code fix.
(ISAPI) In WebLogic Server Service Pack 4, the plug-in parameter WLExludeByPathOrMimeType did not work when forwarding by mime type. This problem was solved with a code fix.
(ISAPI) In an earlier WebLogic Server Service Pack, the plug-in filter was bypassed if ".wlforward" was manually appended to a URL. The code was modified to throw a 404 error if the initial request has a mime type of .wlforward.
(Apache, NSAPI) If the POST method was used through the plug-in and the Content-Length was not defined, the proxy log file would contain message such as:
POST and PUT requests *must* contain a Content-Length.
The code was modified to set a content length of zero (0) if Content-Length is undefined.
(ISAPI) If IIS was configured with WlForwardPath=/, the plug-in would try to forward requests even if the server was down. The error page was never served to clients. The plug-in was modified to properly exclude paths in this situation.
(NSAPI) A memory leak was detected that could cause the plug-in to crash. The problem occurred because the plug-in accessed an exception object after the object had been deleted. The code was fixed to retrieve the exception code from the exception object and then delete the object, which prevents the memory leak from occurring.
(ISAPI) In a configuration that included nine IIS servers and nine clustered WebLogic Server instances, IIS crashed every a few hours, writing an Event 37 to the event log. The wlproxy log contained this message:
Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .\iisproxy.cpp
The Reader::fill() method was not allocating enough memory while growing the initial buffer. The four bytes used to mark the end of buffer were getting lost which resulted in the core dump. The problem was solved with a code fix.
(NSAPI) During load testing, when NSAPI was running on HP11.00 proxying to a six-node cluster on two Solaris boxes (three WebLogic Server instances on each), memory consumption steadily increased, and after approximately 50 minutes, the ns-httpd process crashed. The same load test did not crash on HP11.00 or Solaris. Codes in proxy.cpp used strdup(), a native system call. strdup() allocated system memory to the program's heap space. WebLogic Server used Iplanet's FREE macro to free previous allotted space when it is no longer needed. Because FREE did not free the allocated space by strdup() call, the memory leak occurred.
The problem was solved by replacing all native strdup() system calls in proxy.cpp with Iplanet's STRDUP macro so the FREE macro knows what to free.
(NSAPI) Plug-in did not handle %0A in the post request gracefully
A POST request %0A at the end sent to WebLogic Server through the NSAPI plug-in added extraneous data into the body stream, and headers appeared at the end of the body. Requests sent directly to WebLogic Server were processed correctly.
The problem was corrected by code change to the plug-in to detect and handle HTTP/0.9 responses correctly.
(NSAPI) When WLExcludePathOrMimeType was set, the file types were cut in the request to WebLogic Server, but iplanet failed to serve those files instead.
For example, this request for a .jsp that contained a .jpg was made:
<Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object>
The request for the .jsp was proxied to WebLogic Server, and the .jsp was displayed without the .jpg. Iplanet failed to server the jpg.The iplanet access log contained this message:
10.40.4.117 - - [28/Oct/2003:11:45:34 -0500] "GET /weblogic/images/logo_tm_onwt.jpg HTTP/1.1" 500 305 I get the following in wlproxy.log: Tue Oct 28 11:45:35 2003 ============================= new request =============================== Tue Oct 28 11:45:35 2003 INFO: SSL is not configured Tue Oct 28 11:45:35 2003 URI=[/hello.jsp] Tue Oct 28 11:45:35 2003 attempt #0 out of a max of 5 Tue Oct 28 11:45:35 2003 general list: trying connect to '10.40.4.117'/7001/7001 at line 1224 for '/hello.jsp' Tue Oct 28 11:45:35 2003 INFO: New NON-SSL URL Tue Oct 28 11:45:35 2003 Going to check the general server list Tue Oct 28 11:45:35 2003 WLS info : 10.40.4.117:7001 recycled? 0 Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept]=[*/*] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-language]=[en-us] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-encoding]=[gzip, deflate] Tue Oct 28 11:45:35 2003 Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)]
WLExcludePathOrMimeType should cause WebLogic Server not to service the request, and to pass control to the Web server, allowing it to continue processing the request.
A request did not fail over to the next available server in the cluster after receiving 503 HTTP status. The same server was tried repeatedly until a READ_ERROR_FROM_SERVER or a CONNECTION_REFUSED exception was raised.
Code now marks the server as failed on getting a 503 HTTP status error, gets the next available server and re-sends the request. All requests now successfully fail over to next available server.
If a connection was grabbed from the pool, but the server instance has already closed the connection, the HALF_OPEN_SOCKET_RETRY exception was thrown, causing the deletion of the previous connection object and the creation of a new one to connect to the same server.
The problem was resolved by the addition of code to handle the HALF_OPEN_SOCKET_RETRY exception properly.
The ISAPI plug-in sometimes failed after a persistent cookie was added to a servlet session.
A correction to the cookie parsing code resolved the problem.
(Apache) The plug-in was dropping sessions after WebLogic Server was restarted. The problem occurred because Apache 1.3.x creates multiple child processes to handle incoming requests. Each process maintains its own server list where each server entry is uniquely identified by the JVMID. Weblogic Server provides the JVMID to the process. When a server instance is restarted, it generates a new JVMID, so a request whose cookie contained a new JVMID could not locate the corresponding primary server plug-in if the JVMID was not refreshed in the plug-in.
A code fix ensures that if the JVMIDs extracted from a cookie do not match the ones stored in the server list, WebLogic Server refreshes the JVMIDs.
A memory leak in the ISAPI plug-in was fixed by a code change.
(NSAPI) When the NSAPI plug-in performed name resolution on backend WebLogic Server instances, name resolution used sysGetHostByName, which called getHostByName, which called internal methods that had maximum limits for open file descriptors, causing name resolution to occasionally fail.
A fix to cookie parsing and the substitution of JVMIDs to locate primary and secondary servers resolved the problem.
The ISAPI plug-in sent the WL-PATH-TRIM HTTP Header value to a WebLogic Server in place of the WL-PATH-TRIM value.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp.
In previous service packs, the Apache plug-in did not recognize the WLTempDir parameter. This has been corrected.
Request to provide a plug-in for the Sun Java System Web Server (Formerly Sun ONE Web Server).
The Sun Java System Web Server is now fully supported. For more information, see "Supported Web Servers, Browsers, and Firewalls" in the Supported Configurations documentation.
Request for certification of WebLogic Server on HP-UX 11i with Apache 2.0.48.
For more information, see "Supported Web Servers, Browsers, and Firewalls" in the Supported Configurations documentation.
The WebLogic plug-in was not translating http://hostname:port/ to http://hostname:port/index.html when using Netscape 4.0.
iPlanet users experienced a problem with host name verification and received the following:
(Apache) The plug-in caused a duplicated HTTP header and body for the 302 response. There was no problem between the plug-in and backend servers, but the Apache server added an additional 302 response.
Code was added which reverted the return value of the request_handler method to OK.
In an Apache configuration with multiple virtual hosts, if only one of the virtual hosts was configured with SecureProxy=ON for the WebLogic Server plug-in, and the other virtual hosts did not use SecureProxy or WLProxySSL, the virtual hosts with no SSL configured saw that the plug-in attempted an SSL connection with the backend WebLogic Server. This caused a performance problem.
The problem was resolved with a code change which provides a new parameter that determines whether the SSL connection needs to be initiated.
The plug-in returned the incorrect status code when the server was down.
The WebLogic plug-in failed to route requests by path when Apache is configured to use SSL between the browser and Apache.
When the FilterPriorityLevel was set in the iisforward.ini file, the forwarding path was broken.
A code fix was implemented to ensure that when a virtual host was not defined in the iisforward.ini file, the iisproxy.ini file from the same location as where the iisforward.dll file was loaded is used.
Provided an enhancement to the WLExcludePathOrMimeType parameter allowing it to be used at the Location tag level.
WLExcludePathOrMimeType parameter can now be defined locally at the Location tag level as wells as globally. When the property is defined locally, it does not override the global property but defines a union of the two parameters.
(NSAPI) The "pluginparams.ErrorPageTest" failed when attempting a proxy by extension.
The workaround for the ErrorPage to be loaded locally is to use the WLExcludePathOrMimeType property if proxying by MIME type.
For the SUN One Web Server, version 6.1, some additional configuration steps are required:
(Apache) The plug-in was logging a confusing "error page is unavailable" log message to the apache error.log, even when the client had closed the connection.
This was resolved by a code change that commented out the erroneous log message.
When the WLExcludePathOrMimeType property was defined within a Location tag, it should not have had a global scope. (However, when the property was defined outside a Location tag, then it should have had a global scope.)
This was resolved by a code change to ensure that the WLExcludePathOrMimeType property is applied only to the requests that match the appropriate Location path for the defined property.
(NSAPI) The Iplanet plug-in now gracefully handles an EINTR OS error.
[iPlanet] POST_TIMEOUT errors occurred in the iPlanet log file due to a broken pipe.
Code was added to throw a HALF_OPEN_SOCKET_RETRY exception if an EPIPE error is encountered while sending POST data to WebLogic Server.
(Apache) The Apache server is hanging when the WebLogic plug-in tries to open the wlproxy log file, even though Debug is OFF.
The code has been fixed so that the log file is not set if debugging is turned off.
(Apache) The Apache server generated core dumps when using the worker (multi-threaded) option instead of the prefork (only multi-process) option.
This was resolved by fixing the Locking and Unlocking logic.
When using the release 7.0 SP02 plug-in with client certificates, WebLogic Server worked fine. However, after an upgrade to release 8.1 SP02, the server log reported the following error:
Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException
The error occurred because the 8.1 SP02 plug-in truncated the WL-Proxy-Client-Cert header when it sent it to the server instance.
The code was changed so that WL-Proxy-Client-Cert is lazily added to the request sent to WebLogic Server.
(ISAPI) The IIS proxy plug-in caused heap corruption on the Microsoft Windows platform.
The release 8.1 SP02 plug-in with client certificates reported the following error:
Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException.
The error occurred because the plug-in truncated the WL-Proxy-Client-Cert header when sending it to the WebLogic Server instance.
When using multiple Location tags in a VirtualHost tag, PathPrepend parameter was not working correctly.
A code fix was used to ensure that custom properties defined within Location tags are stored locally and do not conflict with global properties.
|
WebLogic Server proxy plug-ins restricted the HTTP commands that could be submitted from the client to the server. The validation rules in the plug-in code now allow the following HTTP commands that are needed for WebDAV implementations: |
||
|
(ISAPI) DefaultFileName did not work if iisforward.dll was not used. The problem was exhibited when: On a request for a directory that had no filename, the DefaultFileName was not used. The problem was corrected with a code fix. |
||
|
(NSAPI) When a client stopped a response from being sent to it (for example, closing the browser before the response is completely received), a 500 [WRITE TOCLIENT ERROR] was logged in the Web server logs. The Web server health monitoring tools used a 500 error to indicate that something was wrong with the server's health and that since this was not a server health issue but the client terminating the response, the error if any should not have been 500. The request response path is as follows:
and the expected response path is
After WebLogic Server had successfully sent the response, but the Web server had not completely sent it to the client, the client aborted the communication and a 500 error was logged in the Web server's access.log which normally indicates that something is wrong with the server. A code change was implemented so that 500 errors are not generated if the client breaks the connection. |
||
|
(ISAPI) In WebLogic Server 6.1 Service Pack 4, the plug-in did not recognize the WLTempDir flag for the _wl_proxy folder. The code was fixed to use the flag. |
||
|
[Apache] When using multiple MatchExpression parameters in httpd.conf to route requests to different locations, as in:
Each request overwrote the same global parameter info, which caused requests to go to the wrong location. In the above example, this problem resulted in *.jsp requests going to the server at port 8003. The code was fixed to ensure that each request uses its own copy of the parameter information. |
||
|
(NSAPI) If KeepAliveEnabled and DynamicServerList were both enabled, the plug-in could leave sockets in a CLOSE_WAIT state. This problem was solved with a code fix. |
||
|
(ISAPI) In WebLogic Server Service Pack 4, the plug-in parameter |
||
|
(ISAPI) In an earlier WebLogic Server Service Pack, the plug-in filter was bypassed if ".wlforward" was manually appended to a URL. The code was modified to throw a 404 error if the initial request has a mime type of .wlforward. |
||
|
(Apache, NSAPI) If the POST method was used through the plug-in and the Content-Length was not defined, the proxy log file would contain message such as: POST and PUT requests *must* contain a Content-Length. The code was modified to set a content length of zero (0) if Content-Length is undefined. |
||
|
(ISAPI) If IIS was configured with WlForwardPath=/, the plug-in would try to forward requests even if the server was down. The error page was never served to clients. The plug-in was modified to properly exclude paths in this situation. |
||
|
(NSAPI) A memory leak was detected that could cause the plug-in to crash. The problem occurred because the plug-in accessed an exception object after the object had been deleted. The code was fixed to retrieve the exception code from the exception object and then delete the object, which prevents the memory leak from occurring. |
||
|
(ISAPI) In a configuration that included nine IIS servers and nine clustered WebLogic Server instances, IIS crashed every a few hours, writing an Event 37 to the event log. The wlproxy log contained this message: Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .\iisproxy.cpp The Reader::fill() method was not allocating enough memory while growing the initial buffer. The four bytes used to mark the end of buffer were getting lost which resulted in the core dump. The problem was solved with a code fix. |
||
|
(NSAPI) During load testing, when NSAPI was running on HP11.00 proxying to a six-node cluster on two Solaris boxes (three WebLogic Server instances on each), memory consumption steadily increased, and after approximately 50 minutes, the ns-httpd process crashed. The same load test did not crash on HP11.00 or Solaris. Codes in proxy.cpp used strdup(), a native system call. strdup() allocated system memory to the program's heap space. WebLogic Server used Iplanet's FREE macro to free previous allotted space when it is no longer needed. Because FREE did not free the allocated space by strdup() call, the memory leak occurred. The problem was solved by replacing all native strdup() system calls in proxy.cpp with Iplanet's STRDUP macro so the FREE macro knows what to free. |
||
|
(NSAPI) Plug-in did not handle %0A in the post request gracefully A POST request %0A at the end sent to WebLogic Server through the NSAPI plug-in added extraneous data into the body stream, and headers appeared at the end of the body. Requests sent directly to WebLogic Server were processed correctly. The problem was corrected by code change to the plug-in to detect and handle HTTP/0.9 responses correctly. |
||
|
(NSAPI) When WLExcludePathOrMimeType was set, the file types were cut in the request to WebLogic Server, but iplanet failed to serve those files instead. For example, this request for a .jsp that contained a .jpg was made:
The request for the .jsp was proxied to WebLogic Server, and the .jsp was displayed without the .jpg. Iplanet failed to server the jpg.The iplanet access log contained this message:
WLExcludePathOrMimeType should cause WebLogic Server not to service the request, and to pass control to the Web server, allowing it to continue processing the request. |
||
|
A request did not fail over to the next available server in the cluster after receiving 503 HTTP status. The same server was tried repeatedly until a READ_ERROR_FROM_SERVER or a CONNECTION_REFUSED exception was raised. Code now marks the server as failed on getting a 503 HTTP status error, gets the next available server and re-sends the request. All requests now successfully fail over to next available server. |
||
|
If a connection was grabbed from the pool, but the server instance has already closed the connection, the The problem was resolved by the addition of code to handle the |
||
|
The ISAPI plug-in sometimes failed after a persistent cookie was added to a servlet session. A correction to the cookie parsing code resolved the problem. |
||
|
(Apache) The plug-in was dropping sessions after WebLogic Server was restarted. The problem occurred because Apache 1.3.x creates multiple child processes to handle incoming requests. Each process maintains its own server list where each server entry is uniquely identified by the JVMID. Weblogic Server provides the JVMID to the process. When a server instance is restarted, it generates a new JVMID, so a request whose cookie contained a new JVMID could not locate the corresponding primary server plug-in if the JVMID was not refreshed in the plug-in. A code fix ensures that if the JVMIDs extracted from a cookie do not match the ones stored in the server list, WebLogic Server refreshes the JVMIDs. |
||
|
A memory leak in the ISAPI plug-in was fixed by a code change. |
||
|
(NSAPI) When the NSAPI plug-in performed name resolution on backend WebLogic Server instances, name resolution used A fix to cookie parsing and the substitution of JVMIDs to locate primary and secondary servers resolved the problem. |
||
|
The ISAPI plug-in sent the |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp. |
||
|
In previous service packs, the Apache plug-in did not recognize the |
||
|
Request to provide a plug-in for the Sun Java System Web Server (Formerly Sun ONE Web Server). The Sun Java System Web Server is now fully supported. For more information, see "Supported Web Servers, Browsers, and Firewalls" in the Supported Configurations documentation. |
||
|
Request for certification of WebLogic Server on HP-UX 11i with Apache 2.0.48. For more information, see "Supported Web Servers, Browsers, and Firewalls" in the Supported Configurations documentation. |
||
|
The WebLogic plug-in was not translating |
||
|
iPlanet users experienced a problem with host name verification and received the following: |
||
|
(Apache) The plug-in caused a duplicated HTTP header and body for the 302 response. There was no problem between the plug-in and backend servers, but the Apache server added an additional 302 response. Code was added which reverted the return value of the |
||
|
In an Apache configuration with multiple virtual hosts, if only one of the virtual hosts was configured with SecureProxy=ON for the WebLogic Server plug-in, and the other virtual hosts did not use SecureProxy or WLProxySSL, the virtual hosts with no SSL configured saw that the plug-in attempted an SSL connection with the backend WebLogic Server. This caused a performance problem. The problem was resolved with a code change which provides a new parameter that determines whether the SSL connection needs to be initiated. |
||
|
The plug-in returned the incorrect status code when the server was down. |
||
|
The WebLogic plug-in failed to route requests by path when Apache is configured to use SSL between the browser and Apache. |
||
|
When the A code fix was implemented to ensure that when a virtual host was not defined in the |
||
|
Provided an enhancement to the
|
||
|
(NSAPI) The "pluginparams.ErrorPageTest" failed when attempting a proxy by extension. The workaround for the ErrorPage to be loaded locally is to use the WLExcludePathOrMimeType property if proxying by MIME type. For the SUN One Web Server, version 6.1, some additional configuration steps are required: |
||
|
(Apache) The plug-in was logging a confusing "error page is unavailable" log message to the This was resolved by a code change that commented out the erroneous log message. |
||
|
When the This was resolved by a code change to ensure that the |
||
|
(NSAPI) The Iplanet plug-in now gracefully handles an EINTR OS error. |
||
|
[iPlanet] POST_TIMEOUT errors occurred in the iPlanet log file due to a broken pipe. Code was added to throw a |
||
|
(Apache) The Apache server is hanging when the WebLogic plug-in tries to open the The code has been fixed so that the log file is not set if debugging is turned off. |
||
|
(Apache) The Apache server generated core dumps when using the worker (multi-threaded) option instead of the prefork (only multi-process) option. This was resolved by fixing the Locking and Unlocking logic. |
||
|
When using the release 7.0 SP02 plug-in with client certificates, WebLogic Server worked fine. However, after an upgrade to release 8.1 SP02, the server log reported the following error:
The error occurred because the 8.1 SP02 plug-in truncated the The code was changed so that |
||
|
(ISAPI) The IIS proxy plug-in caused heap corruption on the Microsoft Windows platform. |
||
|
The release 8.1 SP02 plug-in with client certificates reported the following error:
The error occurred because the plug-in truncated the |
||
|
When using multiple Location tags in a VirtualHost tag, PathPrepend parameter was not working correctly. A code fix was used to ensure that custom properties defined within Location tags are stored locally and do not conflict with global properties. |
RMI/RMI-IIOP
An optional enhancement to the BEA ORB forces reconnection when bootstrapping and allows hardware load-balancers to correctly balance connection attempts.
For more information on this feature and its limitations, see Using RMI over IIOP with a Hardware LoadBalancer in Programming WebLogic RMI over IIOP.
Note: This feature was only partially implemented in WebLogic Server 8.1SP3. See RMI/IIOP Known Issues for more details.
Fragmentation was enabled by default and caused a decrease in performance.
Now Fragmentation is disabled by default, which eliminated the decrease in performance.
WebLogic Server could not handle typecode aliases when reading Java objects on AIX. The code was modified to discard the alias wrapper.
IIOP did not explicitly close socket connections on failed sends to non-responsive clients.
A thin client that transmitted large, complex objects concurrently over IIOP using multiple threads would result in the following exception:
Exception in thread ;ExecuteThread: '23' for queue: 'weblogic.kernel.Default'; org.omg.CORBA.MARSHAL: stream corrupted: reading past end of chunk at: 186504 vmcid: 0x0 minor code: 0 completed: No
This was due to GIOP version mismatch in the response triggered by the interleaving of response fragments with out-of-band heartbeat messages. A code fix to place the proper GIOP version in the response resolved this issue.
An IIOP client that started a transaction and executed methods on a CORBA object hosted within the WLS 8.1 ORB was experiencing a rollback exception because the transaction was started in one thread and ended in different thread.
The container seemed to cache the RMI Stub incorrectly and raised the issue of ClassCastException casting RMI objects. Once the RMI Stub is created for a Web application, subsequent lookup by another Web application with the same RMI interface as the former returns the Stub for the former Web application and hence causes a ClassCastException. This is due to the incompatibility in classloaders between the Web applications. This problem only occurs when the lookup happens over T3 and HTTP. IIOP does not seem to have the caching implementation in place and hence does not cause the ClassCastException.
This problem was fixed with a code change. Two Web applications looking up the same RMI object in the JNDI tree now have their individual stubs instead of trying to use the stub loaded by a previous invocation of one of the Web applications. This is the correct behavior.
For PeerGone handling in the server, the server pings the client when the muxer makes a request to close down a connection. If this ping hangs, the muxer never shuts down the socket.
To fix this, WebLogic Server now sets the failed flag before pinging the client so that a hang counts as a failure.
While testing ExceptionListener functions in a standalone JMS client with the wlclient.jar and wljmsclient.jar thin clients, the following errors occurred as the connection went down:
Error: CORBA COMM_FAILURE 1398079696 Maybe; nested exception is: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe
The thin client code was changed so that if the current user on the thread is null, then it will use the anonymous user instead.
ORBs using an SSL port greater than 32k could not be contacted by WebLogic Server. Such ports were interpreted as a signed short instead of an unsigned short, which resulted in ports greater than 32k being converted to a negative number.
The code was modified to treat the port as an unsigned short.
SSL was not enforceable for IIOP connections established by calling the string_to_object() method on a foreign IOR. This occurred because SSL was only used when there was an SSL port in the SSL tag and bootstrapping occurred over SSL, or when there was no plain port.
The code was fixed so that it observes protocol when bootstrapping using ORB functions. As a side effect, it is now possible to force SSL usage when using the string_to_object() method by setting the weblogic.corba.orb.ORBProtocol property to iiops.
When using the IIOP protocol (for example, when using the WebLogic Server Thin Client or when interoperating with a foreign application server), login attempts using a null password caused a null pointer exception. This failure was not occurring when using the T3 protocol.
The code was changed to allow null passwords when using IIOP.
The WebLogic Thin-client JAAS implementation did not allow passwords over 64 characters.
|
An optional enhancement to the BEA ORB forces reconnection when bootstrapping and allows hardware load-balancers to correctly balance connection attempts. For more information on this feature and its limitations, see Using RMI over IIOP with a Hardware LoadBalancer in Programming WebLogic RMI over IIOP. Note: This feature was only partially implemented in WebLogic Server 8.1SP3. See RMI/IIOP Known Issues for more details. |
||
|
Fragmentation was enabled by default and caused a decrease in performance. Now Fragmentation is disabled by default, which eliminated the decrease in performance. |
||
|
WebLogic Server could not handle typecode aliases when reading Java objects on AIX. The code was modified to discard the alias wrapper. |
||
|
IIOP did not explicitly close socket connections on failed sends to non-responsive clients. |
||
|
A thin client that transmitted large, complex objects concurrently over IIOP using multiple threads would result in the following exception:
This was due to GIOP version mismatch in the response triggered by the interleaving of response fragments with out-of-band heartbeat messages. A code fix to place the proper GIOP version in the response resolved this issue. |
||
|
An IIOP client that started a transaction and executed methods on a CORBA object hosted within the WLS 8.1 ORB was experiencing a rollback exception because the transaction was started in one thread and ended in different thread. |
||
|
The container seemed to cache the RMI Stub incorrectly and raised the issue of ClassCastException casting RMI objects. Once the RMI Stub is created for a Web application, subsequent lookup by another Web application with the same RMI interface as the former returns the Stub for the former Web application and hence causes a ClassCastException. This is due to the incompatibility in classloaders between the Web applications. This problem only occurs when the lookup happens over T3 and HTTP. IIOP does not seem to have the caching implementation in place and hence does not cause the ClassCastException. This problem was fixed with a code change. Two Web applications looking up the same RMI object in the JNDI tree now have their individual stubs instead of trying to use the stub loaded by a previous invocation of one of the Web applications. This is the correct behavior. |
||
|
For PeerGone handling in the server, the server pings the client when the muxer makes a request to close down a connection. If this ping hangs, the muxer never shuts down the socket. To fix this, WebLogic Server now sets the failed flag before pinging the client so that a hang counts as a failure. |
||
|
While testing
The thin client code was changed so that if the current user on the thread is null, then it will use the anonymous user instead. |
||
|
ORBs using an SSL port greater than 32k could not be contacted by WebLogic Server. Such ports were interpreted as a signed short instead of an unsigned short, which resulted in ports greater than 32k being converted to a negative number. The code was modified to treat the port as an unsigned short. |
||
|
SSL was not enforceable for IIOP connections established by calling the The code was fixed so that it observes protocol when bootstrapping using ORB functions. As a side effect, it is now possible to force SSL usage when using the |
||
|
When using the IIOP protocol (for example, when using the WebLogic Server Thin Client or when interoperating with a foreign application server), login attempts using a null password caused a null pointer exception. This failure was not occurring when using the T3 protocol. The code was changed to allow null passwords when using IIOP. |
||
|
The WebLogic Thin-client JAAS implementation did not allow passwords over 64 characters. |
Samples
Security
Previously, for an init.d script on a UNIX box to gracefully shut down WebLogic Server when the server rebooted, the user name and password needed to be specified on the command-line at invocation of weblogic.Admin.
Using a boot identity file plugs this security hole. A new command, StoreUserConfig, has been added to the weblogic.Admin utility and the weblogic.Deployer utility.
This command lets you specify the location of a pre-created boot identity (and SerializedSystemIni.dat) file.
WebLogic Server was unable to filter connections from LDAP servers because the LDAP protocol was not supported by the connection filter rules.
LDAP has now been added to the list of filterable protocols, so that connections from LDAP can be filtered.
When you set the security debug flags <ServerDebug DebugSecurityAtn="true" DebugSecurityAtz="true" ...> with StdoutDebugEnabled="true" StdoutSeverityLevel="64", the server logged the user password to stdout in clear text.
This problem has been resolved by removing the password string from the statement that is written to the log file.
CR107359 reported a problem in which the Node Manager instantiated its encryption service using the configured private key password as its password. This was an issue when the Node Manager configuration was modified to configure a new private key password because the encryption service could no longer be instantiated.
The Node Manager has been modified so that it instantiates its encryption service using an internal string as the password. However, existing encrypted properties cannot be decrypted with the new encryption service, so they must be decrypted with the old service and re-encrypted with the new service.
The Node Manager will do this conversion on the first reboot after the service pack is installed (or a patch applied). On any subsequent reboots, the new encryption service is instantiated.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_52.01.jsp.
In a performance tuning enhancement, new attributes were added that allow you to limit the depth of a group membership search in an LDAP directory. You can tune the search according to your membership hierarchy, and eliminate searching that you know will not find group members.
The new attributes are GroupMembershipSearching and MaxGroupMembershipSearchLevel.
The existing ServletAuthentication API methods such as weak, strong, authenticate etc., were not propagating the LoginException back to the caller. Two overridden login methods were added, which perform similarly to the weak and authenticate methods. The assertIdentity method, which performs in the same way as the strong method, was added. These new methods will propagate the LoginException to the calling code.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_61.00.jsp.
The All Groups filter was not included in a group search of the embedded LDAP server. Code was added to include the All Groups filter. This filter is enabled through the Administration Console.
In the weblogic.security.SSL.TrustManagerJSSE interface, a custom TrustManager contained a setting to govern certificateCallback() behavior. This setting was overridden by variable in validateErr.
A code change resolved this problem. Now SSL in WebLogic Server evaluates results returned by a custom trust manager.
A code change has resolved the problem that caused a java.lang.ArrayStoreException to be thrown when configuring a custom auditor and a custom role mapper.
In WebLogic Server 6.1 SP05, weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. The problem was exhibited in this scenario:
client <--> Proxy <---> Server
The client can be running within WebLogic Server or be a stand-alone Java program. Requests always went through the proxy even if the targeted host was specified in https.nonProxyHosts. If instead, the host is specified in http.nonProxyHosts, the problem does not occur: a direct connection to the host, not to the proxyHost is established, not to the proxyHost, if defined.
Analysis revealed that logic for connecting directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. This problem did not exist for http.nonProxyHosts, only with https.nonProxyHosts.
Appropriate logic was developed to connected directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined.
Properties set directly in the JSP were not being captured and set in the HTTP client.
Two-way SSL did not working properly with Web Services clients.
This problem was resolved by updating the WEBLOGIC_X509_WORKAROUND variation of the convertToCertiom() method to use the WLSDEBUG macros.
The X509 token used for asserting identity was taken from a certificate not from the request header. This occurred even when X509 identity assertion was not configured.
A test was added to determine if any of the Identity Assertion providers in the security realm were configured to use X509 tokens. If not, the X509 token type is ignored when determining what token to use for asserting identity.
The security policy for server shutdown was being applied to all server lifecycle methods.
The security policy has been updated so that it only applies to server shutdown.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-66.00.jsp.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_48.01.jsp.
In a performance tuning enhancement, new attributes were added that allow you to limit the depth of a group membership search. You can tune the search according to your membership hierarchy, and eliminate searching that you know will not find group members.
The new attributes are GroupMembershipSearching and MaxGroupMembershipSearchLevel. For more information see, "Improving the Performance of WebLogic and LDAP Authentication Providers" in Managing WebLogic Security.
A NullPointerException was sometimes encountered when data was imported from an LDAP directory.
When an Auditing MBean (or a similar non-server MBean) was configured in a domain, the Managed Server tried to add a Notification Listener to the MBean when the server was booting. The Managed Server would then try to cast a NotificationRelay Listener which would cause an exception.
WebLogic Server no longer tries to cast a Notification Relay Listener.
The WebLogic Security framework ignored security policies configured in the weblogic-ra.xml deployment descriptor file.
This problem was solved by combining the Java security policies and the WebLogic security policies. Security policies specified in the weblogic-ra.xml deployment descriptor file are now honored.
There was a problem getting a list of users through the listGroupMembers implementation used by the iPlanetAuthenticator MBean. Specifically, the listGroupMembers() method returned an empty cursor.
This was resolved by changing the default value of the StaticMemberDNAttribute to "uniquemember".
The WebLogic Authentication provider used a dynamic group to represent group membership while the rest of the LDAP Authentication providers used a static group. The recursive search used in the isMember() method of the GroupReader MBean expected a static group; therefore, group membership searches did not work correctly for the WebLogic Authentication provider.
Code was added to update the recursive search to handle dynamic groups. The isMember() method of the GroupReader MBean now works consistently for all LDAP-based Authentication providers.
The embedded LDAP server can become corrupt when an application is processed. The ArrayIndexOutOfBounds exception occurs in this situation.
The signature implementation in the WebLogic Security system incorrectly used the dsig:Id attribute on outbound messages and only checked for dsig:Id on inbound messages.
Users in the "Deployer" global role were prevented from performing the following tasks:
When other JCE providers existed in the classpath, RC4 did not work, which caused the SSL handshake to terminate.
Now with the nCiphr JCE provider, the SSL handshake will not break, even though RC4 is being used as the handshake algorithm.
If a WebLogic Server domain had two Active Directory Authentication providers configured to use the same Active Directory LDAP server, the connections to the LDAP server would fail if both providers tried to simultaneously access the LDAP server. WebLogic Server would have to be rebooted to clear the bad connection.
The Connection Retry Limit attribute was added to the Active Directory Authentication provider. When specified, this attribute to retries connections to the LDAP server if the initial connection failed.
When a server instance is configured with Verisign SGC/Stepup certificates, the SSL handshake is failing with the following exception:
<<WLS Kernel>> <> <BEA-000430> <isMessageComplete javax.net.ssl.SSLProtocolException: FATAL Alert:UNEXPECTED_MESSAGE - A message out of sequence was received.
This has been resolved by adding support for Verisign SGC/Stepup certificates.
Performance was unduly affected due to synchronization occurring in the SSLSocketFactory.getJSSE call
In a domain with a custom keystore, a user who had the Operator security role was not able to start a Managed Server using the Node Manager. This failure occurred because the Operator security role did not have the required permission to access the secured attributes necessary to start the Managed Server.
A code fix ensures that a user assigned the Operator security role can start a Managed Server from the Administration Console using the Node Manager.
The ProxyAuthenticator's constructor not being invoked and not using the SSLLayeredSocket causing a java.net.ConnectException.
A change was made to the T3SJvmConnection.newSocket method to use the proxy authenticated socket.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_55.00.jsp.
Connection pool code was not behaving properly, causing the LDAP searches to slow down, which caused, for example, slow authentication with a third-party LDAP.
The weblogic.Deployer utility threw a java.io.FileNotFoundException when using a STOREUSERCONFIG with username and password and the -upload flag.
Code was added to ensure that the deployer uses userconfig in all cases.
The configuration file (config.xml) could not be modified when using a setUID script due to a JVM bug in File.canWrite().
A code change workaround has been implemented in WebLogic Server. For more information on the File.canWrite() issue, see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4993360
Previously, any file in the security provider directory was treated as a security provider and loaded at server boot time without regard to its file extension. Now only files that end in .jar or .zip are treated as security providers.
Security providers that use other extensions will no longer load. If your domain uses alternate file extensions for security providers, change them for Service Pack 3.
Embedded LDAP has a search limit = 1000".
The problem was resolved with a code change. Embedded LDAP can return more elements when a search query is executed.
An applet that used the setIgnoreTrustValidation(true) method resulted in a java.lang.ExceptionInInitializerError.
A code fix was implemented so that the security manager for an applet would allow an SSL handshake.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_59.00.jsp
Authentication errors occur while creating local context after using t3s.
This problem was resolved with a code change, which clears the certificate from the thread when the context is closed.
On authentication, the default Authentication provider in the security realm should set the user principal name in the Subject with the same case stored in the LDAP. The Subject was set with whatever case the client uses to log in with (the user name is case-insensitive in the LDAP).
This was resolved by adding the UseRetrievedUserNameAsPrincipal attribute to the Details tab on the Administration Console for any WebLogic LDAP Authenticator provider. When enabled, this attribute retrieves the user name from the LDAP to use as the principal name for authentication, instead of the supplied user name.
The DefaultAuditRecorder.log file in the default domain directory can grow very large and possibly use up the available disk space.
This was resolved by providing a command-line argument for specifying a directory where the audit log file will be written:
-Dweblogic.security.audit.auditLogDir
For more information see "Configuring Security Providers" in Managing WebLogic Security.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-60.00.jsp.
The DefaultAuditRecorder.log file in the default domain directory can grow very large and possibly use up the available disk space.
This was resolved by introducing a Rotation Log Minutes attribute, which allows you to specify how many minutes to wait before creating a new DefaultAuditRecorder.log file. At the specified time, the audit file is closed and a new backup file is created.
For more information see "Configuring Security Providers" in Managing WebLogic Security.
The performance when querying Active Directory Group Membership was found to be inefficient.
A code fix has resolved this issue.
For more information see the "Improving the Performance of WebLogic and LDAP Authentication Providers" section in the "Configuring Security Providers" chapter of Managing WebLogic Security.
A custom object extending UserInfo could not be passed into InitialContext for authentication, which broke backwards compatibility.
The "Custom Object Authentication Enabled" attribute was added to the Security Mbean and the Compatibility Advanced tab on the Administration Console so that if a user passes a custom object that extends UserInfo for authentication, it will be taken care of. This attribute is disabled by default because it affects performance.
The connection filter for the t3s protocol was not working as documented.
The Administration Console allowed you to create a new user with a password that contained special characters (for example, German umlauts). However, when the new user attempted to log on with that password, the password was not accepted.
The problem was resolved with a code that obtains password bytes from an LDAP entry with UTF-8.
Some of the demonstration certificates and trusted CA certificates shipped in previous services packs of WebLogic Server 8.1 expired on May 14, 2004 or will not work with the Basic Constraints feature. This service pack includes updated trusted CA certificates that will work with the Basic Constraints feature. The certificates (democert.pem, democert1024.pem ca.pem, ca1024.pem, trusted.crt, demo.crt) are provided as files.
If you are using a previous service pack of WebLogic Server 8.1, you can upgrade to the updated demonstration certificates and trusted CA certificates following the instructions at http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp.
During server startup, static application deployment was freezing in the LDAP code. This occurred while deploying the security roles for components such as EJBs. The freeze happened because of missed notifications in the LDAP code.
The iPlanet LDAP server returned a wildcard search when performing an explicit user search.
A fix was made to the "wild card search" algorithm so that it also matches the "exact name search" algorithm.
When using identity assertion based on Common Secure Interoperability Version 2 (CSIv2) and Generic Security Service (GSS) tokens, certain lengths of principal names were not properly decoded. This sometimes resulted in the IdentityAssertionProvider not being called, or being called with a truncated principal.
|
Previously, for an Using a boot identity file plugs this security hole. A new command, This command lets you specify the location of a pre-created boot identity (and |
||
|
WebLogic Server was unable to filter connections from LDAP servers because the LDAP protocol was not supported by the connection filter rules. LDAP has now been added to the list of filterable protocols, so that connections from LDAP can be filtered. |
||
|
When you set the security debug flags This problem has been resolved by removing the password string from the statement that is written to the log file. |
||
|
CR107359 reported a problem in which the Node Manager instantiated its encryption service using the configured private key password as its password. This was an issue when the Node Manager configuration was modified to configure a new private key password because the encryption service could no longer be instantiated. The Node Manager has been modified so that it instantiates its encryption service using an internal string as the password. However, existing encrypted properties cannot be decrypted with the new encryption service, so they must be decrypted with the old service and re-encrypted with the new service. The Node Manager will do this conversion on the first reboot after the service pack is installed (or a patch applied). On any subsequent reboots, the new encryption service is instantiated. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_52.01.jsp. |
||
|
In a performance tuning enhancement, new attributes were added that allow you to limit the depth of a group membership search in an LDAP directory. You can tune the search according to your membership hierarchy, and eliminate searching that you know will not find group members. The new attributes are |
||
|
The existing ServletAuthentication API methods such as weak, strong, authenticate etc., were not propagating the LoginException back to the caller. Two overridden login methods were added, which perform similarly to the weak and authenticate methods. The assertIdentity method, which performs in the same way as the strong method, was added. These new methods will propagate the LoginException to the calling code. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_61.00.jsp. |
||
|
The All Groups filter was not included in a group search of the embedded LDAP server. Code was added to include the All Groups filter. This filter is enabled through the Administration Console. |
||
|
In the weblogic.security.SSL.TrustManagerJSSE interface, a custom TrustManager contained a setting to govern certificateCallback() behavior. This setting was overridden by variable in validateErr. A code change resolved this problem. Now SSL in WebLogic Server evaluates results returned by a custom trust manager. |
||
|
A code change has resolved the problem that caused a |
||
|
In WebLogic Server 6.1 SP05, weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. The problem was exhibited in this scenario: client <--> Proxy <---> Server The client can be running within WebLogic Server or be a stand-alone Java program. Requests always went through the proxy even if the targeted host was specified in https.nonProxyHosts. If instead, the host is specified in http.nonProxyHosts, the problem does not occur: a direct connection to the host, not to the proxyHost is established, not to the proxyHost, if defined. Analysis revealed that logic for connecting directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. This problem did not exist for http.nonProxyHosts, only with https.nonProxyHosts. Appropriate logic was developed to connected directly to a host specified in https.nonProxyHosts, even when a proxyHost is defined. |
||
|
Properties set directly in the JSP were not being captured and set in the HTTP client. |
||
|
Two-way SSL did not working properly with Web Services clients. This problem was resolved by updating the WEBLOGIC_X509_WORKAROUND variation of the |
||
|
The X509 token used for asserting identity was taken from a certificate not from the request header. This occurred even when X509 identity assertion was not configured. A test was added to determine if any of the Identity Assertion providers in the security realm were configured to use X509 tokens. If not, the X509 token type is ignored when determining what token to use for asserting identity. |
||
|
The security policy for server shutdown was being applied to all server lifecycle methods. The security policy has been updated so that it only applies to server shutdown. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-66.00.jsp. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_48.01.jsp. |
||
|
In a performance tuning enhancement, new attributes were added that allow you to limit the depth of a group membership search. You can tune the search according to your membership hierarchy, and eliminate searching that you know will not find group members. The new attributes are GroupMembershipSearching and MaxGroupMembershipSearchLevel. For more information see, "Improving the Performance of WebLogic and LDAP Authentication Providers" in Managing WebLogic Security. |
||
|
A NullPointerException was sometimes encountered when data was imported from an LDAP directory. |
||
|
When an Auditing MBean (or a similar non-server MBean) was configured in a domain, the Managed Server tried to add a Notification Listener to the MBean when the server was booting. The Managed Server would then try to cast a NotificationRelay Listener which would cause an exception. WebLogic Server no longer tries to cast a Notification Relay Listener. |
||
|
The WebLogic Security framework ignored security policies configured in the This problem was solved by combining the Java security policies and the WebLogic security policies. Security policies specified in the |
||
|
There was a problem getting a list of users through the listGroupMembers implementation used by the iPlanetAuthenticator MBean. Specifically, the This was resolved by changing the default value of the StaticMemberDNAttribute to "uniquemember". |
||
|
The WebLogic Authentication provider used a dynamic group to represent group membership while the rest of the LDAP Authentication providers used a static group. The recursive search used in the Code was added to update the recursive search to handle dynamic groups. The |
||
|
The embedded LDAP server can become corrupt when an application is processed. The ArrayIndexOutOfBounds exception occurs in this situation. |
||
|
The signature implementation in the WebLogic Security system incorrectly used the dsig:Id attribute on outbound messages and only checked for dsig:Id on inbound messages. |
||
|
Users in the "Deployer" global role were prevented from performing the following tasks: |
||
|
When other JCE providers existed in the classpath, RC4 did not work, which caused the SSL handshake to terminate. Now with the nCiphr JCE provider, the SSL handshake will not break, even though RC4 is being used as the handshake algorithm. |
||
|
If a WebLogic Server domain had two Active Directory Authentication providers configured to use the same Active Directory LDAP server, the connections to the LDAP server would fail if both providers tried to simultaneously access the LDAP server. WebLogic Server would have to be rebooted to clear the bad connection. The Connection Retry Limit attribute was added to the Active Directory Authentication provider. When specified, this attribute to retries connections to the LDAP server if the initial connection failed. |
||
|
When a server instance is configured with Verisign SGC/Stepup certificates, the SSL handshake is failing with the following exception:
This has been resolved by adding support for Verisign SGC/Stepup certificates. |
||
|
Performance was unduly affected due to synchronization occurring in the |
||
|
In a domain with a custom keystore, a user who had the Operator security role was not able to start a Managed Server using the Node Manager. This failure occurred because the Operator security role did not have the required permission to access the secured attributes necessary to start the Managed Server. A code fix ensures that a user assigned the Operator security role can start a Managed Server from the Administration Console using the Node Manager. |
||
|
The ProxyAuthenticator's constructor not being invoked and not using the A change was made to the |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_55.00.jsp. |
||
|
Connection pool code was not behaving properly, causing the LDAP searches to slow down, which caused, for example, slow authentication with a third-party LDAP. |
||
|
The weblogic.Deployer utility threw a Code was added to ensure that the deployer uses userconfig in all cases. |
||
|
The configuration file ( A code change workaround has been implemented in WebLogic Server. For more information on the |
||
|
Previously, any file in the security provider directory was treated as a security provider and loaded at server boot time without regard to its file extension. Now only files that end in Security providers that use other extensions will no longer load. If your domain uses alternate file extensions for security providers, change them for Service Pack 3. |
||
|
Embedded LDAP has a search limit = 1000". The problem was resolved with a code change. Embedded LDAP can return more elements when a search query is executed. |
||
|
An applet that used the A code fix was implemented so that the security manager for an applet would allow an SSL handshake. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_59.00.jsp |
||
|
Authentication errors occur while creating local context after using t3s. This problem was resolved with a code change, which clears the certificate from the thread when the context is closed. |
||
|
On authentication, the default Authentication provider in the security realm should set the user principal name in the Subject with the same case stored in the LDAP. The Subject was set with whatever case the client uses to log in with (the user name is case-insensitive in the LDAP). This was resolved by adding the |
||
|
The This was resolved by providing a command-line argument for specifying a directory where the audit log file will be written:
For more information see "Configuring Security Providers" in Managing WebLogic Security. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-60.00.jsp. |
||
|
The This was resolved by introducing a Rotation Log Minutes attribute, which allows you to specify how many minutes to wait before creating a new For more information see "Configuring Security Providers" in Managing WebLogic Security. |
||
|
The performance when querying Active Directory Group Membership was found to be inefficient. A code fix has resolved this issue. For more information see the "Improving the Performance of WebLogic and LDAP Authentication Providers" section in the "Configuring Security Providers" chapter of Managing WebLogic Security. |
||
|
A custom object extending UserInfo could not be passed into InitialContext for authentication, which broke backwards compatibility. The "Custom Object Authentication Enabled" attribute was added to the Security Mbean and the Compatibility Advanced tab on the Administration Console so that if a user passes a custom object that extends UserInfo for authentication, it will be taken care of. This attribute is disabled by default because it affects performance. |
||
|
The connection filter for the |
||
|
The Administration Console allowed you to create a new user with a password that contained special characters (for example, German umlauts). However, when the new user attempted to log on with that password, the password was not accepted. The problem was resolved with a code that obtains password bytes from an LDAP entry with UTF-8. |
||
|
Some of the demonstration certificates and trusted CA certificates shipped in previous services packs of WebLogic Server 8.1 expired on May 14, 2004 or will not work with the Basic Constraints feature. This service pack includes updated trusted CA certificates that will work with the Basic Constraints feature. The certificates (democert.pem, democert1024.pem ca.pem, ca1024.pem, trusted.crt, demo.crt) are provided as files. If you are using a previous service pack of WebLogic Server 8.1, you can upgrade to the updated demonstration certificates and trusted CA certificates following the instructions at http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp. |
||
|
During server startup, static application deployment was freezing in the LDAP code. This occurred while deploying the security roles for components such as EJBs. The freeze happened because of missed notifications in the LDAP code. |
||
|
The iPlanet LDAP server returned a wildcard search when performing an explicit user search. A fix was made to the "wild card search" algorithm so that it also matches the "exact name search" algorithm. |
||
|
When using identity assertion based on Common Secure Interoperability Version 2 (CSIv2) and Generic Security Service (GSS) tokens, certain lengths of principal names were not properly decoded. This sometimes resulted in the |
Servlets
SNMP
Tools
Web Services
The WebLogic Server clientgen Ant task was incorrectly allowing hyphens to remain in WSDL files. This caused generated Java code to have class and method names that contained hyphens, which is not legal in java.
A modification to NameUtils now causes clientgen to strip out hyphens. Additionally, for JAXRPC methods and classes, if the resulting string is also a Java keyword, WebLogic Server prepend a _ to it, as per JAXRPC Specifications 1.0 and 1.1
When a UDDI operation failed, a "dispositionReport" was returned. The dispositionReport XML was created by using SAAJ classes.
SOAPElement.addChildElement(Name name) now declares the namespace of "name" if its namespace is not already defined.
Setting the property in "Setting javax.xml.soap.MessageFactory" in the startWebLogic.cmd script did not work properly for org.xml.sax.driver, org.xml.sax.parser, javax.xml.soap.MessageFactory and javax.xml.rpc.ServiceFactory for JSPs and Servlets.
Following a code change, WebLogic Server checks whether the property is already set before setting it, and sets it to the default value if is not set.
The WebLogic Server clientgen Ant task was incorrectly allowing hyphens to remain in WSDL files. This caused generated Java code to have class and method names that contained hyphens, which is not legal in java.
A modification to NameUtils now causes clientgen to strip out hyphens. Additionally, for JAXRPC methods and classes, if the resulting string is also a Java keyword, WebLogic Server prepend a _ to it, as per JAXRPC Specifications 1.0 and 1.1
Setting useServerTypes=True with multiple service entries did not parse the correct tag, and did not parse more than one tag in web-services.xml. As a result, only the first tag in the web-services.xml was being processed correctly.
This was fixed by adding code to look for the correct tag in web-services.xml and process "all".
More than one service entry can now be processed for clients setting useServerTypes=True.
When the encryptKeyName and encryptKeyPass attributes are not specified in the security section for servicegen, the generated web-services.xml file would contain an EncryptionSpec attribute with the value of EncryptBody set to "true". This caused the SOAP messages to be encrypted
A code fix resolved this issue by ensuring the web-services.xml file is generated correctly.
When application resources were not loaded by the same classloader as webserviceclient.jar, an error occurred. Code was added enabling WebLogic Server to correctly handle application resources loaded by multiple classloaders.
Due to a change in some Security specifications, WebLogic Server has been updated in order to ensure that timestamps are now generated inside the security header.
Having multiple <soap:operation>s in the same WSDL that are set to different styles is a mixed-style Web Service and is not supported.
<soap:operation> now overrides <soap:binding>.
If there are multiple operations, each <soap:operation> should be set to the same value. However, if <soap:binding> is set to a value different from <soap:operation>, <soap:operation> will override <soap:binding>.
Calling a method in the Web service through the ISAPI filter caused this exception:
java.lang.IllegalArgumentException: Illegal MimeHeader name or value
<wsr:reliability persistDuration="60000"> entries were generated in WSDL files when reliable messaging was not enabled
Images attached to Web services were not working correctly. The problem occurred when the user attached a java.awt.Image to a webservice and the image was improperly serialized/deserialized.
The new draft of the x509 profile in the OASIS WSS Spec changed the reference model for x509 certificates.
Code was added to change the value type for SKIDs in the KeyIdentifier (to X509SubjectKeyIdentifier) and allow Issuer DN + Serial to be embedded in SecurityTokenReferences.
In using reliable SOAP Messaging to invoke a Web service from a Sender WebLogic Server instance to a Receiver WebLogic Server instance, the Sender continued to retry invocations beyond the configured retry limit. The retries continued until the Receiver was restarted or the Sender's container killed the client because it exceeded the transaction timeout value. This failure to observe the specified retry limit resulted in long running transactions and hung clients.
Code was added to ensure that the sender will not retry beyond the configured retry limit.
When the simpleType contains attribute final, autotype would fail with the following message: weblogic.xml.schema.model.parser.XSDParseException: invalid attribute "final" in element "xsd:simpleType"
A code fix was used to allow the attribute final to be used with simpleType.
Autotype failed to create typemapping for types that derive from anyType:
Types that depend on other types that are mapped to SOAPElement (like anyType) have to be mapped to SOAPElement themselves. Previously only the 'hasA' dependency was considered.
Code was added to map types that derive from anyType to SOAPElement.
Enhancement provided the WebLogic XML Digital Signatures API which contains classes to digitally sign and validate SOAP messages.
See Using the WebLogic XML Digital Signatures API for more details.
The Apache AXIS client was rejecting a SOAP response message because the elements Message and ErrorCode did not have the same namespace prefix. This occurred because WebLogic Server only qualified the top level element.
A code fix introduces a system property, -Dweblogic.xml.schema.binding.qualifytoplevelelementonly, to determine if the top level element is qualified. Valid values are:
A NullPointerException occurred while starting the server with a WebLogic Express 8.1 license.
An exception was thrown when a SOAP message had interlaced SOAP attachments and the start parameter of the MIME header did not match the content ID header.
servicegen failed when the accessors of a Java Bean threw checked exceptions.
WebLogic Server will now catch the checked exceptions and re-throw with the runtime exception weblogic.xml.schema.binding.PropertyException.
The SOAP HTTP Binding states that when an Exception occurs within a WebService, the server should throw a HTTP 500 "Internal Server Error", with a SOAP Fault response representing the exception.
Many WebService clients use URLConnection in order to make the HttpConnection to the WebService. Weblogic Server overrode the java.net.HttpURLConnection with a different version. WebLogic's version threw an exception from the getInputStream method if the status code was >= 400.
Since the exception was thrown there was no way for the WebService client to retrieve the inputstream, and thus it violated the Http SOAP Binding Specification.
WebLogic Server now retrieves the inputstream upon a 500 error.
Clientgen did not produce the right exception type when an exception extended another exception in a different package.
WebLogic Server only displayed request/response debugging on the client side.
When a browser was used, the debug message went to server out. If a Java client was used, the message should have been seen on the client out.
When generating the stub, the wrong parameter class was used due to typemapping information from the provided types.xml being overwritten by JAX-RPC default.
Typemapping information from types.xml is not overwritten anymore. Clients programming against the stub have to use the class that corresponds to the XML element as a parameter (as expected), not the class that corresponds to the type.
When a WSDL was generated from the JPD and a java client was used to invoke a method, the input request xml from the client was invalid and resulted in a NullPointerException.
Could not merge an existing web-services.xml file with a new one using the mergeWithExistingWS attribute in the source2wsdd task.
The problem was resolved by a fix to the source2wsdd task when setting mergeWithExistingWS="True", and by adding a new targetNameSpace attribute to source2wsdd.
As a result of this change, you cannot generate a WSDL file when there are two services in the web-services.xml; that is, you cannot specify the wsdlFile attribute for the source2wsdd task, because a WSDL is generated for one service only per web-services.xml.
When a .Net client (using a 512 bit key to encrypt) invoked a secure WebLogic Web Service (using a 1024 bit key to decrypt) it caused the following exception:
Unhandled Exception: System.Web.Services.Protocols.SoapException: Exception during processing: java.lang.AssertionError: weblogic.xml.stream.XMLStreamException: Unable to decrypt EncryptedKey - with nested exception: [weblogic.xml.security.encryption.EncryptionException: Invalid input length for decryption. Length should be multiple of 128 - Block Size. - with nested exception: [com.rsa.jsafe.JSAFE_InputException: Invalid input length for decryption. Length should be multiple of 128 - Block Size.]] (see Fault Detail for stacktrace)
A change was made to provide a clearer error message to explain mismatched encryption/decryption keys:
Unable to decrypt EncryptedKey: key size of encryption/decryption mismatched
The clientgen Ant task failed to generate a client .jar file for a WSDL with multiple services defined, throwing the following error:
Client FAIL Exception during Service Create javax.xml.rpc.JAXRPCException: unable to find port:SubmitStatusRequest This may be because the WSDL file and the generated stub is out sync. Doing clientgen again may fix this problem.
The Web Service client used to time out when the time is three times of the actual timeout value.
The problem was resolved with a code fix. Now the client times out at the exact value set.
The service interface generated by wsdl2service did not throw a custom exception when "element" is used in "part". For example:
<message name="WSException">
<part element="cio:WSException" name="WSException"/> </message>
However, it worked properly when using "type" instead of "element", as follows:
<message name="WSException">
<part name="WSException" type="cio:WSExceptionType" /> </message>
A code change ensures that the wsdl2service generates an exception properly in situations where "element" is used in "part".
A security configuration exception was thrown when invoking a secure WebLogic Web Service with encryption only.
The code was changed so that is no longer necessary to specify a signature key when not signing response.
When schema files were not in the same directory of a wsdl file, running the clientgen Ant tool would yield the following error:
[clientgen] Finished Schema2Java parameter validation [clientgen] schemaURL file:/C:/edrive/462245/AaisTransactionManagerService.WSDL [clientgen] java.io.FileNotFoundException: C:\edrive\462245\Ont.xsd (The system cannot find the file specified) [clientgen] at java.io.FileInputStream.open(Native Method) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:103) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:66) [clientgen] at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) [clientgen] at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.fetchSchemaLocation(SimpleSchemaResolver.java:120) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.doExternalLookup(SimpleSchemaResolver.java:90) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.resolveSchemaLocation(SimpleSchemaResolver.java:68) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:533) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:524) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclude(XSDSchema.java:489)
In previous service packs, WebLogic Web Services expected a WSDL file and the to-be-included schemas to reside in the same directory. With this change, Web Services now supports relative includes of schemas. For example:
Using the clientgen Ant task with a document-oriented Web Service caused the following exception:
[clientgen] weblogic.xml.schema.model.XSDValidityException: unable to resolve type name
During a call to a business process from a standalone Java Web Service client, an attempt was being made to retrieve the root element from XMLBean, causing a ClassCastException to be thrown. WebLogic Server wrote out xsi:type for anonymous inline types, which caused a ClassCastException in WebLogic Workshop when retrieving the root element from XMLBean.
Previous service packs of WebLogic Server 8.1 did not implement the Web Services "InclusiveNameSpaces" correctly. According to the Web Services specification, "all visibly used namespaces used in the document must be added in the InclusiveNameSpaces PrefixList," as demonstrated here:
<c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="n1"></c14n:InclusiveNamespaces>
Previous 8.1 service packs put the namespaces as the value of "InclusiveNameSpaces" tag instead of being an attribute of "PrefixList." For example:
<c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; >n1/c14n:InclusiveNamespaces>
WebLogic Web Services now adheres to the Web Services specification by using the "PrefixList" attribute. Therefore, documents signed by release 8.1 service pack 2 or earlier cannot be verified by service pack 3, and vice versa.
The XML was getting stripped to the next child node in the tree when passing org.w3c.dom.Document to a doc/literal web service.
Attempts to generate a clientJar for a Web Service that had http-soap12=true was failing with the following exception:
weblogic.webservice.tools.wsdlp.WSDLParseException: transport not supported:http://schemas.xmlsoap.org/soap12/http
In previous service packs, only the SOAP 1.1 HTTP transport in WSDL files was checked when running the clientgen command. A code fix ensure that checks are done for both SOAP 1.1 and SOAP 1.2 HTTP transport in WSDL files when running clientgen.
The Web Service SSL client left the socket in the CLOSE_WAIT state after execution.
The problem was resolved with a code fix to properly close the socket on the client after the execution.
The wsdl2service Ant task would only generate the interface of the service. By default, it would not generate the implementation class.
The code was changed so that the wsdl2Service Ant task generates the interface and the skeleton of the implementation class if "generateImpl" is set to true.
For more information, see "Web Service Ant Tasks and Command-Line Utilities" in Programming WebLogic Web Services.
WebLogic Server fails to validate .NET signed XML documents that contained timestamps.
WebLogic Web Services now implements the following final OASIS Standard 1.0 Web Services Security specifications, dated April 6 2004:
Service Pack 2 implemented a Working Draft Version 1.0 of the specification, which was the most up-to-date version of the specification at that time.
This implementation is not backwards-compatible with previous version 8.1 service packs. For more information on this lack of compatibility, see What's New in WebLogic Server 8.1 SP3.
For more information on Web Service security, see "Configuring Security" in Programming WebLogic Web Services.
The webservice ant task did not obey the second level include with autotype ant task.
If the first schema imported the second schema and the second schema included another schema, WebLogic Server did not search for this included schema. Thus autotype failed.
The problem was resolved with a code change. WebLogic Server now searches for child includes of imported schema.
A ClassCastException occurred when adding a filter in front of Weblogic 8.1 WebServiceServlet and at the end of the filter, passing a customized HttpServletRequestwrapper instance to the doFilter(req, resp) call.
The web-services.xml descriptor contained an extra element of <xsd:documentation>. For example: xsd:annotation> <xsd:documentation> <xsd:documentation>
Using servicegen to generate a webservice on a service method which throws javax.jms.JMSException caused a weblogic.xml.schema.binding.BindingException exception.
When creating a WSDL file from a web-services.xml file, the order of operations in the web-services.xml file was not preserved in the WSDL.
This problem was resolved with a code change, which preserves the order of operations appearing in the WSDL file while generating the web-services.xml.
For a document-style Web service, the client was failing to catch a user-defined exception because an incorrect namespace prefix was being returned by the service endpoint.
A web service endpoint could not understand HTTP requests with the "Accept-Charset: UTF-8, UTF-16" included in the request header.
Setting the -Dweblogic.webservice.i18n.charset=UTF-8 property generates a warning message: <Unrecognized property: webservice.i18n.charset.>
This was resolved by adding this property to management admin to remove this warning message.
Accessing an external web service via an outbound proxy server (iPlanet Web Proxy Server) returned a SOAP fault. This occurred because using http and https to invoke a remote web service through proxy server with proxy authentication turned on was not allowed.
A code change was made to allow http and https tunneling through a proxy server for a web service client.
The servicegen Ant task failed with the following error when the service method threw a java.sql.SQLException:
weblogic.xml.schema.binding.BindingException: No default constructor was found for class java.lang.StackTraceElement loaded from file:/usr/bea/jdk141_03/jre/lib/rt.jar!/java/lang/StackTraceElement.class. All classes that will be serialized or deserialized must be non-interface, non-abstract classes that provide a public default constructor - with nested exception: [java.lang.NoSuchMethodException: java.lang.StackTraceElement]
A Web Service client did not invoke a foreign Web Service when attempting to send an empty SOAP header element that had no child elements or attributes. For example, <env:Header/>
The code was fixed so that empty SOAP header elements are no longer sent if they do not contain child elements and attributes.
|
The WebLogic Server clientgen Ant task was incorrectly allowing hyphens to remain in WSDL files. This caused generated Java code to have class and method names that contained hyphens, which is not legal in java. A modification to |
||
|
When a UDDI operation failed, a "dispositionReport" was returned. The dispositionReport XML was created by using SAAJ classes. SOAPElement.addChildElement(Name name) now declares the namespace of "name" if its namespace is not already defined. |
||
|
Setting the property in " Following a code change, WebLogic Server checks whether the property is already set before setting it, and sets it to the default value if is not set. |
||
|
The WebLogic Server A modification to |
||
|
Setting useServerTypes=True with multiple service entries did not parse the correct tag, and did not parse more than one tag in web-services.xml. As a result, only the first tag in the web-services.xml was being processed correctly. This was fixed by adding code to look for the correct tag in web-services.xml and process "all". More than one service entry can now be processed for clients setting useServerTypes=True. |
||
|
When the A code fix resolved this issue by ensuring the |
||
|
When application resources were not loaded by the same classloader as webserviceclient.jar, an error occurred. Code was added enabling WebLogic Server to correctly handle application resources loaded by multiple classloaders. |
||
|
Due to a change in some Security specifications, WebLogic Server has been updated in order to ensure that timestamps are now generated inside the security header. |
||
|
Having multiple <soap:operation>s in the same WSDL that are set to different styles is a mixed-style Web Service and is not supported. <soap:operation> now overrides <soap:binding>. If there are multiple operations, each <soap:operation> should be set to the same value. However, if <soap:binding> is set to a value different from <soap:operation>, <soap:operation> will override <soap:binding>. |
||
|
Calling a method in the Web service through the ISAPI filter caused this exception:
|
||
|
|
||
|
Images attached to Web services were not working correctly. The problem occurred when the user attached a java.awt.Image to a webservice and the image was improperly serialized/deserialized. |
||
|
The new draft of the x509 profile in the OASIS WSS Spec changed the reference model for x509 certificates. Code was added to change the value type for SKIDs in the KeyIdentifier (to X509SubjectKeyIdentifier) and allow Issuer DN + Serial to be embedded in SecurityTokenReferences. |
||
|
In using reliable SOAP Messaging to invoke a Web service from a Sender WebLogic Server instance to a Receiver WebLogic Server instance, the Sender continued to retry invocations beyond the configured retry limit. The retries continued until the Receiver was restarted or the Sender's container killed the client because it exceeded the transaction timeout value. This failure to observe the specified retry limit resulted in long running transactions and hung clients. Code was added to ensure that the sender will not retry beyond the configured retry limit. |
||
|
When the A code fix was used to allow the attribute |
||
|
Autotype failed to create typemapping for types that derive from anyType: Types that depend on other types that are mapped to SOAPElement (like anyType) have to be mapped to SOAPElement themselves. Previously only the 'hasA' dependency was considered. Code was added to map types that derive from anyType to SOAPElement. |
||
|
Enhancement provided the WebLogic XML Digital Signatures API which contains classes to digitally sign and validate SOAP messages. See Using the WebLogic XML Digital Signatures API for more details. |
||
|
The Apache AXIS client was rejecting a SOAP response message because the elements Message and ErrorCode did not have the same namespace prefix. This occurred because WebLogic Server only qualified the top level element. A code fix introduces a system property, |
||
|
A NullPointerException occurred while starting the server with a WebLogic Express 8.1 license. |
||
|
An exception was thrown when a SOAP message had interlaced SOAP attachments and the start parameter of the MIME header did not match the content ID header. |
||
|
servicegen failed when the accessors of a Java Bean threw checked exceptions. WebLogic Server will now catch the checked exceptions and re-throw with the runtime exception weblogic.xml.schema.binding.PropertyException. |
||
|
The SOAP HTTP Binding states that when an Exception occurs within a WebService, the server should throw a HTTP 500 "Internal Server Error", with a SOAP Fault response representing the exception. Many WebService clients use URLConnection in order to make the HttpConnection to the WebService. Weblogic Server overrode the java.net.HttpURLConnection with a different version. WebLogic's version threw an exception from the getInputStream method if the status code was >= 400. Since the exception was thrown there was no way for the WebService client to retrieve the inputstream, and thus it violated the Http SOAP Binding Specification. WebLogic Server now retrieves the inputstream upon a 500 error. |
||
|
Clientgen did not produce the right exception type when an exception extended another exception in a different package. |
||
|
WebLogic Server only displayed request/response debugging on the client side. When a browser was used, the debug message went to server out. If a Java client was used, the message should have been seen on the client out. |
||
|
When generating the stub, the wrong parameter class was used due to typemapping information from the provided types.xml being overwritten by JAX-RPC default. Typemapping information from types.xml is not overwritten anymore. Clients programming against the stub have to use the class that corresponds to the XML element as a parameter (as expected), not the class that corresponds to the type. |
||
|
When a WSDL was generated from the JPD and a java client was used to invoke a method, the input request xml from the client was invalid and resulted in a NullPointerException. |
||
|
Could not merge an existing web-services.xml file with a new one using the The problem was resolved by a fix to the As a result of this change, you cannot generate a WSDL file when there are two services in the web-services.xml; that is, you cannot specify the |
||
|
When a .Net client (using a 512 bit key to encrypt) invoked a secure WebLogic Web Service (using a 1024 bit key to decrypt) it caused the following exception:
A change was made to provide a clearer error message to explain mismatched encryption/decryption keys:
|
||
|
The clientgen Ant task failed to generate a client .jar file for a WSDL with multiple services defined, throwing the following error:
|
||
|
The Web Service client used to time out when the time is three times of the actual timeout value. The problem was resolved with a code fix. Now the client times out at the exact value set. |
||
|
The service interface generated by wsdl2service did not throw a custom exception when "element" is used in "part". For example:
However, it worked properly when using "type" instead of "element", as follows:
A code change ensures that the wsdl2service generates an exception properly in situations where "element" is used in "part". |
||
|
A security configuration exception was thrown when invoking a secure WebLogic Web Service with encryption only. The code was changed so that is no longer necessary to specify a signature key when not signing response. |
||
|
When schema files were not in the same directory of a wsdl file, running the clientgen Ant tool would yield the following error:
In previous service packs, WebLogic Web Services expected a WSDL file and the to-be-included schemas to reside in the same directory. With this change, Web Services now supports relative includes of schemas. For example: |
||
|
Using the
|
||
|
During a call to a business process from a standalone Java Web Service client, an attempt was being made to retrieve the root element from XMLBean, causing a ClassCastException to be thrown. WebLogic Server wrote out |
||
|
Previous service packs of WebLogic Server 8.1 did not implement the Web Services "InclusiveNameSpaces" correctly. According to the Web Services specification, "all visibly used namespaces used in the document must be added in the InclusiveNameSpaces PrefixList," as demonstrated here:
Previous 8.1 service packs put the namespaces as the value of "InclusiveNameSpaces" tag instead of being an attribute of "PrefixList." For example:
WebLogic Web Services now adheres to the Web Services specification by using the "PrefixList" attribute. Therefore, documents signed by release 8.1 service pack 2 or earlier cannot be verified by service pack 3, and vice versa. |
||
|
The XML was getting stripped to the next child node in the tree when passing |
||
|
Attempts to generate a
In previous service packs, only the SOAP 1.1 HTTP transport in WSDL files was checked when running the |
||
|
The Web Service SSL client left the socket in the CLOSE_WAIT state after execution. The problem was resolved with a code fix to properly close the socket on the client after the execution. |
||
|
The wsdl2service Ant task would only generate the interface of the service. By default, it would not generate the implementation class. The code was changed so that the wsdl2Service Ant task generates the interface and the skeleton of the implementation class if "generateImpl" is set to true. For more information, see "Web Service Ant Tasks and Command-Line Utilities" in Programming WebLogic Web Services. |
||
|
WebLogic Server fails to validate .NET signed XML documents that contained timestamps. |
||
|
WebLogic Web Services now implements the following final OASIS Standard 1.0 Web Services Security specifications, dated April 6 2004: Service Pack 2 implemented a Working Draft Version 1.0 of the specification, which was the most up-to-date version of the specification at that time. This implementation is not backwards-compatible with previous version 8.1 service packs. For more information on this lack of compatibility, see What's New in WebLogic Server 8.1 SP3. For more information on Web Service security, see "Configuring Security" in Programming WebLogic Web Services. |
||
|
The webservice ant task did not obey the second level include with autotype ant task. If the first schema imported the second schema and the second schema included another schema, WebLogic Server did not search for this included schema. Thus autotype failed. The problem was resolved with a code change. WebLogic Server now searches for child includes of imported schema. |
||
|
A ClassCastException occurred when adding a filter in front of Weblogic 8.1 WebServiceServlet and at the end of the filter, passing a customized HttpServletRequestwrapper instance to the doFilter(req, resp) call. |
||
|
The web-services.xml descriptor contained an extra element of <xsd:documentation>. For example: xsd:annotation> <xsd:documentation> <xsd:documentation> |
||
|
Using servicegen to generate a webservice on a service method which throws |
||
|
When creating a WSDL file from a This problem was resolved with a code change, which preserves the order of operations appearing in the WSDL file while generating the |
||
|
For a document-style Web service, the client was failing to catch a user-defined exception because an incorrect namespace prefix was being returned by the service endpoint. |
||
|
A web service endpoint could not understand HTTP requests with the "Accept-Charset: UTF-8, UTF-16" included in the request header. |
||
|
Setting the This was resolved by adding this property to management admin to remove this warning message. |
||
|
Accessing an external web service via an outbound proxy server (iPlanet Web Proxy Server) returned a SOAP fault. This occurred because using http and https to invoke a remote web service through proxy server with proxy authentication turned on was not allowed. A code change was made to allow http and https tunneling through a proxy server for a web service client. |
||
|
The servicegen Ant task failed with the following error when the service method threw a
|
||
|
A Web Service client did not invoke a foreign Web Service when attempting to send an empty SOAP header element that had no child elements or attributes. For example, The code was fixed so that empty SOAP header elements are no longer sent if they do not contain child elements and attributes. |
WebLogic Type 4 JDBC Drivers
When using the XA WebLogic Type 4 JDBC driver for DB2 in a transaction, after executing a prepared statement and committing the transaction, the prepared statement could not be re-used.
Drivers for Microsoft SQL Server and Sybase
The WebLogic Type 4 JDBC drivers for MS SQL Server and Sybase did not support stored procedure versions with a full stored procedure name such as <stored_proc_name>;<versionNumber>.
XARecover failed with the XA WebLogic Type 4 JDBC driver for transactions that were prepared using a different JDBC driver.
XA Driver for Microsoft SQL Server
Performance degradation occurred the XA WebLogic Type 4 JDBC driver for MS SQL Server. The problem was corrected with a code fix to the driver.
Calling commit() after a batch update caused the database connection to be reset. The problem was corrected with a code fix to the driver.
When creating an XA connection, the driver interpreted an unknown warning message as an error message and prevented the connection creation.
Drivers for DB2, Informix, Microsoft SQL Server, and Sybase
The following issues were noted with the DATE and TIMESTAMP data types:
DB2—Using a TIMESTAMP data type failed with a server protocol error when running with Connection.setAutocommit(true).
MS SQL Server—Disallowed implicit conversion of data from the DATETIME data type to the TIMESTAMP data type.
The problem was corrected with a code fix to the drivers. The drivers now support the DATE and TIMESTAMP data types.
When using the YYYY-MM-DD and YY-MM-DD date formats in the Japanese locale, the TO_DATE function failed with an SQL exception.
XA Driver for Microsoft SQL Server
With clients using the XA WebLogic Type 4 JDBC driver, the DBMS can not detect a client disconnect. Client disconnects can cause abandoned transactions, and there was no way to provide a transaction timeout for abandoned transactions.
A setting was added to the driver to time out abandoned transactions.
WebLogic Server was updated so that if you use the XA WebLogic Type 4 JDBC driver for MS SQL Server, XASetTransactionTimeout is automatically set to true internally, to take advantage of the transaction timeout setting on the driver.
See Support for XAResource Transaction Timeout for more information about the XASetTransactionTimeout attribute.
Drivers for DB2, Informix, Oracle, and Sybase
A PreparedStatement with many parameters caused a StackOverflowError.
When callable statement was used multiple times, incorrect values were returned. The problem was corrected with a code fix to the driver.
XA Driver for DB2 and Microsoft SQL Server
Drivers return the error code of RMERR (-3) instead of NOTA (-4) which causes transactions to be retried until AbandonTimoutSeconds instead of the transaction being resolved on recovery.
|
When using the XA WebLogic Type 4 JDBC driver for DB2 in a transaction, after executing a prepared statement and committing the transaction, the prepared statement could not be re-used. |
||
|
Drivers for Microsoft SQL Server and Sybase The WebLogic Type 4 JDBC drivers for MS SQL Server and Sybase did not support stored procedure versions with a full stored procedure name such as |
||
|
XARecover failed with the XA WebLogic Type 4 JDBC driver for transactions that were prepared using a different JDBC driver. |
||
|
XA Driver for Microsoft SQL Server Performance degradation occurred the XA WebLogic Type 4 JDBC driver for MS SQL Server. The problem was corrected with a code fix to the driver. |
||
|
Calling |
||
|
When creating an XA connection, the driver interpreted an unknown warning message as an error message and prevented the connection creation. |
||
|
Drivers for DB2, Informix, Microsoft SQL Server, and Sybase The following issues were noted with the DATE and TIMESTAMP data types:
The problem was corrected with a code fix to the drivers. The drivers now support the DATE and TIMESTAMP data types. |
||
|
When using the YYYY-MM-DD and YY-MM-DD date formats in the Japanese locale, the TO_DATE function failed with an SQL exception. |
||
|
XA Driver for Microsoft SQL Server With clients using the XA WebLogic Type 4 JDBC driver, the DBMS can not detect a client disconnect. Client disconnects can cause abandoned transactions, and there was no way to provide a transaction timeout for abandoned transactions. A setting was added to the driver to time out abandoned transactions. WebLogic Server was updated so that if you use the XA WebLogic Type 4 JDBC driver for MS SQL Server, See Support for XAResource Transaction Timeout for more information about the |
||
|
Drivers for DB2, Informix, Oracle, and Sybase A PreparedStatement with many parameters caused a |
||
|
When callable statement was used multiple times, incorrect values were returned. The problem was corrected with a code fix to the driver. |
||
|
XA Driver for DB2 and Microsoft SQL Server Drivers return the error code of RMERR (-3) instead of NOTA (-4) which causes transactions to be retried until |
