e-docs > WebLogic Server > Release Notes > Resolved Problems for Service Packs 1 - 6 |
Release Notes |
Resolved Problems for Service Packs 1 - 6
The following sections describe problems resolved in previous Service Packs for WebLogic Server 7.0. Service Packs are cumulative; Service Pack 6 contains all the fixes made in earlier Service Packs released for WebLogic Server 7.0. For a description of problems resolved in the most recent Service Pack, see Resolved Problems for Service Pack 7.
WebLogic Server 7.0 Service Pack 6 Solutions
The following sections describe problems that were resolved in WebLogic Server 7.0 Service Pack 6:
The weblogic.j2eeclient.Main did not work in webstart. The client jar file is an argument loaded by the webstart client and made available in the classpath. But the file was not available in the current directory resulting in an error. A system property (weblogic.j2ee.client.isWebStart) was added to WebLogic Server to load the client jar file from the system classpath. weblogic.j2eeclient.Main now works in webstart. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-70.00.jsp. |
|
While redeploying an application, J2EEApplicationContainer is now redeploying the internal modules such as JDBCModule as it did prior to WebLogic Server 7.0 Service Pack 5. |
|
When an application is removed from the Managed Server, the auxiliary jars are now also removed from the staging directory of the server. |
|
When deploying an exploded .ear directory that contains a directory whose name contains a period, ".", a NullPointerException is no longer being thrown. |
Operations, Administration, and Management
A BAD_CERTIFICATE error was received and the SSL connection was terminated when a client certificate with Extended Key Usage set to critical was sent to WebLogic Server. The problem was resolved by adding support for EnhancedKeyUsage. WebLogic Server can now accept Certificates with Enhanced Keyusage set to critical. |
|
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". |
|
If a user was defined while the File realm was calling the refresh() method, synchronization problems with the user table occurred. The File realm has been improved so that exceptions are no longer thrown when defining a user while the File realm is performing a refresh. |
|
Performance of outbound SSL connections was slowed compared to JSSE because WebLogic Server created a new SSLSocketFactory for each outbound request. WebLogic Server now caches the SSLSocketFactory when there is no certificate for the request. |
|
When Web browsers sent plain text through the secure port, SSL misunderstood the message header and waited for more data before finishing the message. This delay caused problems with the SSL handshake. The server was using 100%of its CPU usage trying to complete the SSL handshake. This problem was caused by an arithmetic error on the number of bytes read. This arithmetic problem has been solved. Clients that send plaintext messages to the secure port now receive errors earlier and the server will not hang because of 100% CPU utilization. |
|
Connections to external LDAP servers were sometimes dropped if a load balancer or firewall was configured between WebLogic Server and the external LDAP Server. WebLogic Server now automatically refreshes the connections if they are dropped and user requests complete if the connection is dropped during the request. |
|
Two aspects of SubjectUtils.isUserInGroup were problematic.
All Principals are now gotten from the Subject and are iterated through once looking for the specified WLSGroup. A second method has been added with an AuthenticatedSubject as the first parameter. Both public isUserInGroup () methods were changed to call an internal isUserInGroup ()method that works with a s ate of Principals rather than any Subject. This method eliminates the need for conversion from a Subject to an AuthenticatedSubject. |
|
WebLogic Server was unable to negotiate an SSL Handshake with an HTTPS URL connection to a site using the VeriSign Certificate. |
|
Synchronization in the TTL cache was not being handled properly thus causing an ArrayIndexOutofbounds exception. |
|
In certain cases, WebLogic Server was using its server certificate as a client certificate for the purpose of establishing two-way SSL communication. |
|
When a domain with a cluster is started through the Administration Console, the locking mechanism for the LDAP server is now working properly. As a result, Managed Servers are no longer hanging during startup. |
|
When ServletAuthentication.weak was used for authentication, WebLogic Server threw a NoSuchElement exception when the username and password were entered. To resolve the issue, InvalidLogin was modified so that the size is checked before elements are returned. |
|
A refresh of the File realm could potentially cause a NullPointer exception. The code modifications have eliminated this issue. NullPointer exceptions no longer occur when the File realm is refreshed. |
|
Some of the demonstration certificates and trusted CA certificates shipped in previous service packs of WebLogic Server 7.0 expired on May 14, 2004, or will not work with the Basic Constraints feature. WebLogic Server 7.0 service pack 2 included updated trusted CA certificates that 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 7.0 that contains expired trusted CA certificates, or demo certificates that do not work with the Basic Constraints feature, please see http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp for more information. |
|
When using the iPlanet LDAP Authentication provider, WebLogic Server maintains a pool of connections to the iPlanet LDAP server. These connections are actually connections to Big IP. Big IP is configured to close idle connection at regular intervals. In some cases, WebLogic Server would issue a query or command to the iPlanet LDAP server on a connection that Big IP closed. However, WebLogic Server did not produce an exception that detailed the problem. Now, if there are problems with connections to the iPlanet LDAP server, the LDAP server throws an exception that is propagated to the web tier. As a result, WebLogic Server now throws an exception message with the proper information. |
|
If a connection in the LDAP connection pool was invalid, an authenticate for the user was failing and a LoginException was being returned. Now, after a failed login with an existing LDAP connection from the connection pool, WebLogic Server creates a new connection in the pool and uses that connection. As a result, user requests no longer fail due to the LDAP connection timing out. |
|
Calling the ServletAuthentication.weak() method no longer results in an EmptyStack exception. |
|
Now, WebLogic Server processes the extendedkeyusage extension only when it is marked critical. As a result, WebLogic Server no longer throws a BAD_CERTIFICATE exception on the server side during two-way SSL communication. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-65.00.jsp. |
|
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_51.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-71.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_59.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-69.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_64.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-72.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp. |
Simple Network Management Protocol (SNMP)
When SNMP information was collected using a third-party collector task, the following message was logged: <Error> <SNMP Agent> <000000> < Unable to set Entry Field Value ...> |
WLEC clients were experiencing the following problems with WLEC connection pools: A code fix was implemented to resolve these issues and improve the overall performance of WLEC connection pools. |
WebLogic Server 7.0 Service Pack 5 Solutions
The following sections describe problems resolved for the release of WebLogic Server 7.0 Service Pack 5 (SP5). The following list of resolved problems is updated periodically.
A memory leak occurred when EOImpl instances of the EJB were not garbage-collected when remove() was called on an already passivated and deleted EJB. |
|
A collection valued cmr-field was accessed in a different transaction from the one in which it was created. Code was added to check if the current transaction is the same as the transaction in which the generated oneToManySet was created (createTx). If it is not, then set the createTx on the oneToManySet to the current transaction. |
|
A ClassCastException was thrown at runtime when "cache-between-transactions" is set to true for a BMP bean.java.rmi.RemoteException: EJB. A check for BMP and CMP20 beans was added to prevent the ClassCastException. |
|
When Allow Remove During Transaction was set to "False," and an application attempted to remove a stateful session bean during a transaction, an inaccurate error message appeared. weblogic.ejb20.locks.LockTimedOutException is not the exception called for in the EJB 2.0 specification, and it has been replaced with the exception required: |
|
When a Message Driven Bean uses the synchronous message polling scheme and the Sonic JMS server is used, the message-driven bean container's polling optimizations could result in a delay in the message receiving. To avoid this problem, do not use the optimized poller. As the Sonic message delivery scheme does not work well with this scheme, use a poller that continuously polls the Sonic JMS server. This new Message Driven Bean behavior is applicable to TIBCO and Sonic JMS providers only. |
|
WebLogic Server uses a special handling code for SonicMQ 4.* version, when XAconnections are used. This code was not required for Sonic 5.* version. For this reason, a connection leak occurred. Avoid the use of special code for Sonic 5.* version inside the WebLogic Server MDB container. |
|
The following part of the description for the max-beans-in-cache element in the weblogic-application.xml DTD was incorrect: If 0 is specified, then there is no limit for max-beans-in-cache. A max-beans-in-cache size of 0, would actually set the actual size of the cache to 0, thus causing a CacheFullException. The above note has been removed from the DTD. Also, a compliance check has been added to not allow a value of 0 to be set for the max-beans-in-cache in the weblogic-application.xml. If you need to set a large size (infinite) for your cache, you can set so by setting the value of the max-beans-in-cache to java.lang.Long.MAX_VALUE in the DDs. This makes it compliant with the behavior of the same element in the weblogic-ejb-jar.xml. |
|
A CMP bean threw a ClassCastException while persisting a blob/clob cmp-field to the database when using WebLogic JDriver (type 2). Code was added to handle casting of LOBs (Blob & Clob) for both Oracle type4 and WebLogic type2 drivers. |
|
WebLogic Server loaded optimistic-concurrency beans in a separate transaction, suspending the current transaction, starting a new one, loading the bean and resuming the old transaction for all databases except Oracle, to avoid acquiring locks during the SELECT. Since the default behavior in Sybase is for a a shared-lock to be acquired during the SELECT but released even before the statement has completed the statement, the loading behavior has been changed: When the concurrency-strategy is optimistic, WebLogic Server now suspends and resumes the transaction for databases other than Oracle only if the isolation-level is higher than Read-Uncommitted or Read-Committed. |
|
Entity beans use ActivatableServerRef to call activate to get the bean instance. After invoking the bean method, ActivatableServerRef calls deactivate to release the bean to the pool. The problem was that when a EJB was invoked from within the application, deactivate was not called and the bean was not released. ActivatableServerRef now explicitly calls notifyRemoteCallBegin and notifyRemoteCallEnd. |
|
EJBReplacer did not consider remote objects and hence threw a NotSerializableException while passivating a bean that contained a remote object as a member variable. Following a code change, EJBReplacer replaces the remote object as appropriate if the bean instance contains a remote object member variable. |
|
A less than useful deployment error message that the server displayed on an error setting up auto-pk generator table has been replaced with a more detailed one that gives the nested exception message with more clarity and details. |
|
When you precompiled JSPs on a machine in one time zone, and then deployed those same JSPs on a server in a different time zone, WebLogic Server sometimes recompiled the JSPs. This occurred because WebLogic Server checked JSPs by comparing the local timestamp of the JSPs (as embedded by the JAR utility) against the timestamps in the generated class files. The problem was resolved by storing the timezone at compile time and using that timezone at deployment time to determine whether recompilation is necessary. |
|
In previous WebLogic Server 7.0 service packs, getter methods for an EJB 1.1 CMP bean did not call isModified() when delay-updates-until-end-of-tx was set to false A session EJB called an entity EJB's getter methods. Both EJBs had container-managed transactions with the transaction attribute set to Required. Each call to a getter method is followed by a call to ejbStore(), and delay-updates-until-end-of-tx was false. However, before calling ejbStore on the bean, the container did not call the isModified method until the transaction committed. ejbStore is now called from postInvoke(), depending on the result of the isModified method in the bean. This has resolved the problem. |
|
When a sender posted a JMS message, triggering a message-driven bean, if the MDB never obtained the data in the database it would drop the message. The problem was caused by a known Oracle XA limitation wherein an open resultset is invalidated by a suspended transaction. |
|
An OutOfMemoryError occurred when the WebLogic Server stateful session bean example (examples.ejb20.basic.statefulSession) ran under heavy load. The out-of-the-box configuration had been modified to set: The application archive was deployed to a cluster of two Managed Servers. A Java client performed these steps: Loading the cluster with such requests resulted in the out-of-memory condition. When the client actions were stopped, the server instance did not recover—the console continued to report high heap usage. Analysis revealed the secondary EJBObjects were not being unexported, resulting in a memory leak. The problem was solved with a code change to unexport the secondary EJBObjects. |
|
In previous service packs of WebLogic Server 7.0, EJBC generated CMP code that caused a java.lang.ClassCastException: oracle.sql.BLOB error. Analysis revealed that the CMP RDBMS code generated for the query was incorrect. Prior to WebLogic Server 7.0 SP05, server-side JDBC went through the RMI drive, to the pool driver, then on to the DBMS driver. The problem was solved by correcting the EJBC to generate code that reflects the SP05 and later behavior. Starting in WebLogic Server 7.0 SP05, the RMI driver is now only invoked in external clients. Server-side client code accesses the pool driver directly, which returns the DBMS driver BLOBs directly, not wrapped in an RMI wrapper. This change requires that code cast directly to oracle.sql.BLOB instead of weblogic.jdbc.common.OracleBlob. |
|
After an unsuccessful attempt to create a connectionPool—for instance, using an invalid URL or driver class—it was not possible to create the pool successfully. This problem occurred because the connectionPool MBean was created before the connectionPool was created, regardless of whether the connectionPool was successfully created. Subsequent attempts to create a pool failed during the attempt to create a second MBean of the same type. The problem was solved by modifying the JDBCService to delete the associated MBean if an exception creating a connectionPool. |
|
When an update call followed by a remove call was performed on a container-managed relationship in a business method, ejbStore was invoked in the middle of the transaction. The extra ejbStore occurred because the flushModifiedBeans() method was called inside the BaseEntityManager.caseDeleteRemove() method. The problem was solved with a code change to ensure that the flushModifiedBeans() method is called on for cascade deletes. |
|
Failover did not work for a stateful session bean in a cluster with the following exception. Start server side stack trace: |
|
The following exception is no longer received when container-managed persistence EJBs are built using EJBGEN tags: <Jul 17, 2003 2:49:20 PM MDT> <Info> <EJB> <010097> <Exception |
|
The JMSConnectionPoller did not know the identity of the user that it required to get the remote username and password. This remote username and password is required for establishing a JMS connection with the remote JMS Server (MQ, WebLogic, and so on). This fix resolves the problem, but customers need to configure a security identity for an MDB. For instructions on how to do this, see Configuring a Security Identity for Message-Driven Beans in Programming WebLogic Enterprise JavaBeans. |
|
For BLOBs, in the generated code, WebLogic Server calls ObjectOutputStream.writeObject and ObjectInputStream.readObject to serialize or deserialize the object before writing or reading it to the database. These calls add extra header information. The writeObject method writes the class of the object, the signature of the class, the values of the non-transient and non-static fields of the class, and all of its supertypes. These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because WebLogic Server uses readObject to convert the bytes into the appropriate object, which needs the extra header information. However, if the BLOB has been inserted directly into the database by some other vendor or programmer using: OutputStream os = ((weblogic.jdbc.common.OracleBlob) then problems may occur because WebLogic Server uses readObject and the header information is missing. For the data inserted using WebLogic Server , the other programs that would read the bytes directly get the extra header information and fail. <serialize-byte-array-to-oracle-blob> has been added to control the persistence behavior. This element is used to specify whether a cmp-field of type byte[] mapped to an OracleBlob should be serialized. The tag has been added to a new compatibility stanza in the weblogic-cmp-rdbms descriptor. Note that, in versions prior to SP2, the default behavior was to serialize a cmp-field of type byte[] mapped to an OracleBlob. Now, the byte[] is written directly to the OutputStream obtained from the BLOB. To revert to the old behavior, set the value of this tag to true. |
|
A memory leak no longer occurs for a clusterable stateful EJB in the core of the server. |
|
The setBytes() method on the preparedStatement had issues when the byte[] data was greater than 4K. This problem was resolved by replacing the setBinaryStream() method with the setBytes() method. As a result, the cmp11 generated code has changed. Customers wanting to take advantage of this fix must rerun ejbc on their EJBs to generate the new code. Otherwise, this change will not have any impact. |
|
A java.lang.IndexOutOfBoundsException no longer occurs when a CMP-field and a CMR-field were mapped to the same column. |
|
In WebLogic Server 7.0 SP03, when using bean-managed persistence (BMP) EJBs, a ClassCastException occurred when trying to flushModified Beans using BMP beans. <Aug 25, 2003 9:39:35 AM EDT> <Info> <EJB> <010040> <Exception Analysis revealed that the exception occurred when a BMP with exclusive concurrency that was involved in a transaction with other EJBs was synchronizing the modified beans with the database prior to before running any finder. ExclusiveEntityManger's flushModified code was not considering the BMP case, and was assuming container-managed persistence as the default. The problem was resolved to avoid the ClasscastException. As a result of the change, the BMP EJB's ejbStore method may be called more than once in a transaction, when a finder is invoked on any bean with in the TX. |
|
For an entity cache timeout with a combined (application level) cache, if the idle-timeout-seconds for one of the beans is set to 0, other beans with idle-timeout-seconds > 0 are also not removed from the cache after timeout. A code change involving the registration of idle-timeout-seconds has resolved the problem. |
|
Stateless session beans were not returned to the free pool if they were invoked from the BMP ejbRemove. As a result, the pool reached maximum size and timed out while waiting to get an instance. |
A 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. |
|
For the WebLogic Server jDriver for Oracle versions 817, 901 and 920 with rmi_jndi and rmi_driver tiers, multiple ClassCastExceptions were thrown in connection with the closing of the JDBCHelper class. |
|
Oracle OCI NativeXA does not allow a connection to be used by threads other than the thread where it was created. The WebLogic Server connection pooling algorithm assumed that a connection can be used by any thread. If you used Oracle OCI NativeXA with the previous WebLogic Server connection pooling algorithm, you received an XAException. A code change backports the PinnedToThread connection pooling algorithm from WebLogic Server 8.1, allowing connections to be pinned to threads so that every thread can have its own connection for every connection pool. |
|
Current Multipool does not provide an option to define time based failover. We would like the exact condition under which failover will be triggered to a secondary connection pool. It would go through all the connections in the pool before it decides that it doesn't have any good connection. In order to avoid network glitches, we'd like have time based option like if all you checks fail for 10 minutes then failover to primary Database. We also need a failback mechanism through which we can failback to the primary once primary is in normal state. For example we have our secondary in remote datacenter, so response time will be more when in running in remote, we can live with when the primary database is down, but not when primary is backup So in summary, if my primary Database goes down, it needs to wait for xx time before my connection failover to secondary Database. Once my primary database is available then it should not go back to primary again until I say so. Either we can have an option which says what to do or run time check when these flag is turned on go back to primary or something like that. |
|
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. |
|
When an EJB transaction created many new entities or otherwise engaged many beans that all use JDBC, WebLogic Server risked running out of Oracle cursors, because in an attempt to avoid a suspected Oracle driver bug, WebLogic Server delayed closing JDBC statements until the end of a transaction, holding the cursors for the statement until then. This behavior has been changed so that the session need not hold cursors until the transaction ends. |
|
Statement.getResultSet() sometimes generated an unnecessary new ResultSet wrapper. |
|
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. |
|
When two applications with an 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. |
|
When statements or result sets that are not closed are garbage-collected, their finalize() method closes them if needed. A method that threw a useless exception if the connection had already been closed is no longer thrown. |
|
Under load testing, when the connection pool had refresh minutes set to 15 but the test connections on reserve and test connections on release set to false, the JDBC connection pool threw a weblogic.common.ResourceException: No available connections in pool exception. This occurred because when only a few of the connections in the pool are used, all the other connections in the pool were reserved for testing at the expiration of the configured refresh test minutes. A code change implemented a new algorithm that resolved the situation. |
|
When calling DatabaseMetaData meta = dbCon.getMetaData();ResultSet rs = meta.getColumns(null,meta.getUserName(),"dual".toUpperCase(),"%"); in a user transaction or inside a transactional EJB, if the ResultSet was not explicitly closed when the connection is closed, then each subsequent call leaked an Oracle database cursor. The cursors are held until the server shuts down, creating a risk that the database will run out of cursors. WebLogic Server now explicitly closes a ResultSet when it closes a connection. |
|
During a global transaction, when the client put a message into a JMS Queue and a database, the client looped repeatedly and then exited. If after this you restarted WebLogic Server following a crash (kill -9 or System.exit() ), when the client started a global transaction again, the following exception was thrown: Unknown Exception during dataInsert java.sql.SQLException: XA error: XAER_PROTO The addition of more robust error-handling code corrected the recovery behavior. |
|
In WebLogic Server 7.0SP5, the following enhancements were made to MultiPools:
See MultiPool Failover Enhancements in Programming WebLogic JDBC for more details. |
|
Remote clients can now clear the JDB connection prepare statement cache. Previously, objects of class weblogic.jdbc.rmi.SerialConnection did not implement WLConnection) so a remote client could not call the clearPrepareStatementCache() method. |
|
A DataSource for a MultiPool could be deployed to an Administration Server; however, attempts to deploy it to a Managed Server failed, resulting in this ResourceException: weblogic.common.ResourceException: DataSource(multiDataSource) can't be created with non-existent Pool (connection or multi) (multiPool) at weblogic.jdbc.common.internal.DataSourceManager.createDataSource(DataSourceManager.java:251) at weblogic.jdbc.common.internal.DataSourceManager.createAndStartDataSource(DataSourceManager.java:106) at weblogic.jdbc.common.internal.JDBCService.addDeployment(JDBCService.java:190) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:330) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:590) at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:568) at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:240) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at ... Analysis revealed that the exception occurred during the DataSourceManager.validateConnectionPool() method. The problem was resolved with a code change. |
|
With weblogic.JTAJDBC enabled, WebLogic Server prints out the driver vendor version as in the following: <Aug 5, 2003 3:22:55 PM PDT> <Debug> <JDBC XA> <000000> < -tx:null- -pool:OracleThinXAPool- Vendor:Oracle 8.1.7 XA> For Oracle, WebLogic Server printed the version as "Vendor:Oracle8.1.7 XA" regardless of the actual version. |
|
In previous service packs of WebLogic Server 7.0, resetting a connection pool using weblogic.Admin RESET_POOL (or an equivalent API) caused an exception similar to the following if a connection was already released: <Aug 13, 2003 1:33:11 PM EST> <Error> <HTTP> <[WebAppServletContext(7096795,jdbc_webapp,/jdbc_webapp)] Servlet failed with Exception java.lang.Error: 1 Was already released:weblogic.jdbc.common.internal.Connection After a garbage collection, the server would then display a connection leak <Aug 13, 2003 1:33:19 PM EST> <Warning> <JDBC> <A JDBC pool connection leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by the garbage collector and returned to the connection pool. The following stack trace at create shows where the leaked connection was created. Stack trace at connection create: at weblogic.jdbc.pool.Connection.<init>(Connection.java:55) The code was fixed to eradicate the connection leak warning; the server still correctly displays the initial exception if a connection was already released at the time the pool is reset." |
|
The jts.Connection.getVendorConnection() method returned null when the vendor connection was obtained before the JTS connection had been used for a standard JDBC call. All standard calls established the underlying connection, but getVendorConnection() did not. |
|
The format of the connection leak file was modified to make the information more readable. |
|
WebLogic Server sometimes threw a bogus warning about a JDBC connection leak that began: [SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n The leak detection code that sent this warning is obsolete. A code change resolved the problem. |
Node Manager's shared object code could cause a segment violation if certain code paths were taken while starting a server instance. The same code paths also failed when using IBM's zLinux JDK. These problems were solved with a code fix to Node Manager. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. |
Operations, Administration, and Management
WebLogic Server was calculating the Administration port URL incorrectly. A code change ensures that the URL is calculated correctly, based first on the Administration Port (if it is enabled), and then on the Administration channel (if it is enabled). |
|
Users sometimes got a beanshell exception when setting the ErrorDestination on a JMSQueue. In certain circumstances the parent was not set on the JMSQueue and caused setting the ErrorDestination to fail because the legal check used the parent. Code was added to modify the legal checker to pull the parent JMSServer from the name of the JMSQueue for the check. |
|
EXISTS_POOL did not work as expected. It was looking for runtime mbeans which may or may not exist even if the pool exists. DELETE_POOL, an undocumented command, was the internal implementation to delete a connection pool; however, this feature was documented as DESTROY_POOL externally. The Help menu also displayed some undocumented commands. EXISTS_POOL command implementation now looks for configuration mbeans to check whether the pool exists. DESTROY_POOL command now uses the underlying DELETE_POOL implementation. All the undocumented commands that appeared in the weblogic.Admin help menu are now disabled. Commands include TEST_POOL, REMOVE_POOL, SUSPEND_POOL, SHUTDOWN_POOL, RESUME_POOL, DELETE_POOL. These will not be supported going forward and will not work in 7.0 SP5. |
|
The code attempted to do a runAs where parameters needed to be passed. Instead of passing the parameters on the stack, however, the code attempted to stash them into object variables. It also tried to use a token scheme to identify which of the log methods to call from runAs(). These object variables were not synchronized. As a result, the same message was sometimes logged multiple times. The code was changed to use an anonymous inner class which made the code much cleaner and more thread safe. The code in the log handler was synchronized to write to the log file. |
|
The security sample providers sample on dev2dev was broken in earlier service packs of 7.0. When you built the sample, started the server, and tried to set up the domain, you received a number of javax.management.MBeanException errors. A code change was made that enables the server to consider "commotype" as a flag to the administration tool. |
|
Upon enabling JDBC logging for a Managed Server in a cluster, the Console showed an error while starting. This error did not effect the JDBC logging and JDBC logging worked correctly. Code was added to fix the logging server debug messages on Managed Servers. |
|
User identity is now being recorded in auditing log messages. |
|
The @exclude and @non-configurable tags on the DomainMBean.AdministrationMBeanAuditingEnabled attribute have been removed. |
|
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 already has the default URL internally. |
|
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 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 Convert weblogic.properties utility did does not add DOCTYPE to web.xml and weblogic.xml. The utility was corrected to add these sentences to the beginning of web.xml and weblogic.xml, respectively. <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web |
|
A Managed Server log was created, incorrectly, in the NodeManager home directory (NODEMGR_HOME) instead of in the RootDirectory specified. The access.log and the tlog files were correctly created under the RootDirectory. NodeManager had been configured on a machine, to allow remote start of the Managed Server. In the RemoteStart tab for the Managed Server in the console, the RootDirectory for the Managed Server and the FileName for the log were specified. config.xml contained this stanza for the Managed Server: <Server ExpectedToRun="true" ListenAddress="172.23.64.45" |
|
DomainMBean instances did not reflect the auditing state when enabled from the command-line. If MBean auditing is enabled on the command-line via the -Dweblogic.AdministrationMBeanAuditingEnabled switch, neither the Domain nor the DomainConfig MBean instances showed the attribute being set to true. Auditing was on, but the Mbeans did not reflect that fact. The problem was corrected with a code fix to set the domain mbean attribute from the system property during server startup. |
|
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. |
|
When a Managed Server with a custom COMMO bean was restarted without restarting its Administration Server, the Managed Server was unable to 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 un-registered 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 un-register 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 un-registers all MBeans associated with the Managed Server. |
|
The configuration of "Root Directory" is now working when using Node Manager. |
The Apache 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 earlier service packs, the ISAPI plug-in did not recognize the WLTempDir flag for the _wl_proxy folder. The code was fixed to use the flag. |
|
When the application servers are down the Apache access logs should record a 500 error but instead returned a 200 code: [Mon Jan 05 12:58:21 2004] [notice] Apache/2.0.44 (Unix) configured -- resuming normal operations [Mon Jan 05 12:58:25 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:27 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:29 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:31 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:33 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:35 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 |
|
A performance problem in the IIS plug-in has been resolved in Service Pack 5 by a code change that causes the plug-in to check whether data equivalent to a specified content length has already been read. |
|
In previous service packs, the Apache plug-in did not recognize the WLTempDir parameter. This has been corrected. |
|
The ISAPI plug-in sent the WL-PATH-TRIM HTTP Header value to a WebLogic Server in place of the WL-PATH-TRIM value. |
|
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 sometimes to fail. A fix to cookie parsing and the substitution of JVMIDs to locate primary and secondary servers resolved the problem. |
|
A memory leak in the ISAPI plug-in was fixed by a code change. |
|
The ISAPI plug-in sometimes failed after adding a persistent cookie to a servlet session. A correction to the cookie parsing code resolved the problem. |
|
If a connection is 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. |
|
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 was added which marks the server as bad on getting a 503 HTTP status error, gets the next available server and resends the request. All requests will now successfully fail over to next available server. |
|
Apache access logs improperly recorded a 200 code rather than a 500 error when application servers were down. A code change resolved the problem. |
|
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. |
|
String comparison for headers was case sensitive for the NSAPI plug-in, and is now case insensitive. |
|
Using the Post method to forward requests through the Apache plug-in caused the plug-in to set content-length to 0 and wlproxy.log to log this message: |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp. |
|
Requests that received the PROTOCOL_ERROR message from the primary server also received a message similar to the following: Mon Jun 30 21:52:57 2003 general list: trying connect to '10.84.133.182'/7305/7306 at line 1257 for .. Indicating that failover was applying to another server in the general list, instead of the secondary server. |
|
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: <Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object> was proxied to WebLogic Server, and Iplanet failed to serve 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 to not service the request, and to pass control to the Web server, allowing it to continue processing the request. |
|
A POST request %0A at the end sent to WebLogic Server through the NSAPI plug-in was not handled gracefully. The request 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. |
|
During load testing, when NSAPI running on HP11.00 proxying to a 6 node cluster on 2 Solaris boxes (3 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. Analysis revealed a problem in the code in proxy.cpp used strdup(), a native system call that allocates system memory to the program's heap space. WebLogic Server uses Iplanet's FREE macro to free previous allotted space when it is no longer needed. Because FREE does not free the allocated space by the 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 is instructed what space to free. |
|
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 Diagnosis revealed that the Reader::fill() method was not allocating enough memory while growing the initial buffer. Four bytes to mark the end of buffer were getting lost, which resulted in the core dump. The problem was solved with a code fix. |
|
When a client stopped a response from being sent to it (for example, by closing the browser before the response had completed), the plug-in wrote a 500 [WRITE TO CLIENT ERROR] to the Web server log file. This could cause problems with health monitoring tools that interpret the 500 error as a problem in the Web server. This problem was solved with a code fix. |
|
The plug-in could cause iPlanet to crash shortly after a request received a HALF_OPEN_SOCKET_RETRY, "Unexpected EOF reading HTTP status - request retry" message. The code was modified to retrieve the exception code from the exception object and then delete the object. |
|
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. |
|
The plug-in sometimes responded to the browser with a 500 error message. This problem had three additional symptoms:
|
|
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. |
|
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. |
|
The plug-in parameter WLExludeByPathOrMimeType did not work when forwarding by mime type. This problem was solved with a code fix. |
|
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. |
|
The plug-in failed to parse a cookie if the exclamation character, ?!?, was replaced by ?%21? in a URL. This replacement is commonly done by WAP gateways when using URL rewriting. The code was fixed to correctly parse the characters in the URL. |
|
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. |
|
In previous service packs of WebLogic Server 7.0, using the ISAPI plugin resulted in HTTP responses having two Date headers: one inserted by WebLogic Server and one inserted by IIS. This duplication of Date headers caused problems with certain caching services that expected a single Date header. The problem was solved by updating the ISAPI plugin to filter out the Date header inserted by WebLogic Server. |
|
The plug-in code failed to catch an exception, which in turn caused iPlanet server to crash during the sendResponse phase. The plug-in code was changed to catch the exception. |
|
The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (*/?). This could cause 404 errors to occur when using parameters such as: |
|
In previous service packs of WebLogic Server 7.0, the ISAPI plugin logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line: The HTTP Server encountered an unhandled exception while processing the ISAPI Application. This problem was solved with a code fix to the ISAPI plug-in. |
|
If you configured a virtual directory, configured a mime type with the wildcard * (proxy everything), and added a DefaultFileName in the iisproxy.ini file, on a request for a directory with no filename the DefaultFileName was not used. |
|
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 TO CLIENT ERROR] was inappropriately logged in the Web server logs. The server no longer logs a 500 error for this kind of response failure. |
|
In earlier WebLogic Server 7.0 service packs, the Apache plug-in did not read PathPrepend when using <IfModule mod_weblogic.c>. The problem occurred with plug-ins for Apache 1.3.x and Apache 2.0.43. This problem appeared only if PathPrepend and MatchExpression properties existed together within the <IfModule mod_weblogic.c> tag. This was also true for PathTrim property. |
|
A thread in the Netscape plug-in could obtain a critical lock for a long duration (5 minutes by default, or configured using WLIOTimeoutSecs), blocking all other threads and making the Web server appear to hang. This problem was fixed with a code change to the plug-in. |
|
Using the PathTrim and PathPrepend parameters in conjunction no longer creates a URL with an unexpected forward slash "/" at the end. |
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. |
|
A fat client application instantiated clients that called a stateless session EJB and experienced a memory leak when using WebLogic Server version 7.0 with Service Pack 3 and Service Pack 4. This issue was resolved by using the context classloader in the Appmanager. -Dweblogic.LoadStubUsingContextClassLoader option will no longer be available after this change. |
|
When an RMI/IIOP client was killed when the server was writing a response, some subsequent client requests failed with a MarshalException. When the initial client connection broke, the indirection map was not cleared when put back into the pool. Subsequent clients which used that particular map from the pool failed with the MarshalException. A code change ensures that the indirection maps are properly cleared even in cases when the client gets killed. |
|
When making an initial request, the WebLogic Server-IIOP runtime would not select the appropriate codeset for wide string transmission. The appropriate codeset for wide string transmission is now selected for all requests. Interoperability with WebLogic Server will now work correctly. |
|
Prior to this Service Pack, WebLogic Server could not handle typecode aliases when reading Java objects on AIX. The code was modified to discard the alias wrapper. |
|
WebLogic Server sometimes threw a java.rmi.UnmarshalException when a client application using the thin-client .jar (wlclient.jar) accessed an EJB. On the server, partial exception was: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.IOException: Serializable readObject method failed internally.java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.IOException: Serializable readObject method failed internally at com.ejb_cvps36_EOImpl_WLSkel.invoke(Unknown Source)[...] On the client, the partial exception was: java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is:org.omg.CORBA.MARSHAL: vmcid: 0x0 minor code: 0 completed: No at com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:97) at javax.rmi.CORBA.Util.mapSystemException(Util.java:65) [...] This problem did not occur when using weblogic.jar on the client. The code was modified to address this problem. |
|
Out Of Memory errors due to memory leakage of the DGCServerHelper class during repeated creation and close of InitialContext unnecessarily create a helper object to manage distributed garbage collection. |
|
In previous WebLogic Server 7.0 service packs, replicated session beans under heavy load resulted in increasing heap usage and OutOfmemoryErrors. Analysis revealed that examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl objects were not being garbage-collected even when garbage collection was forced. For clustered stateful session beans, strong references were maintained to the EOImpl object primary in the weblogic.rmi.cluster.PrimarySecondaryRemoteObject. As a remove is never called on the bean, the reference to the EOImpl was never removed from the eoMap. A code fix was implemented to unexport the EO when the passivated bean has been deleted, after session-timeout-seconds. |
|
When throwing a derived exception from the ejb method, the iiop layer was adding the Full Value Description for the derived exception but not for the base exception. When the client came back to get information about the base exception the server did not have it and threw an exception. Code has been added to ensure that when creating a Full Value Description for the derived class, the Full Value description of the base classes is created as well. |
There was a wait(1000) in the backendstandard that was delaying the some operations such as undeploy. A code change removed the wait(1000) and introduced tp.wait(). |
|
The CertificateAttribute needs to be defined to match the binary field that holds the certificate in LDAP, whether it is "userCertificate" or "userCertificate;binary", as described below. Currently it defaults to "userCertificate". If you load the certificate via the ldapbrowser, the attribute userCertificate is created, of type binary, whose value is the data of the certificate. To be able to access the certificate you must define CertificateAttribute="userCertificate". If you use ldapmodify to add the new attribute, as in: ldapmodify -p 1155 -D Principal -w Password dn: cn=support@bea.com,ou=Certs,dc=bea,dc=com userCertificate;binary:: MIICxDCCAi2gAwIBAgIBIDANBgkqh..... an attribute named userCertificate;binary is created where the certificate data is loaded. To be able to access this certificate you must define CertificateAttribute="userCertificate;binary". |
|
The SocketImpl class did not catch an IOException and continued to rethrow it, causing the socket not to close. This problem was resolved by adding code to close the socket and throw the IOException. As a result of this change, there are no idle sockets. |
|
In prior releases, WebLogic Server did not have an LDAP X509Identity Asserter. Code was added to allow the use of an LDAP X509 Identity Asserter. |
|
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_48.00.jsp. |
|
The Web services client loaded the local identity directly into the Certicom SSL context, but the Web services HttpsURLConnection class didn't associate the connection with that specific Certicom SSL context. The connection is now associated with the SSL context by the HttpsURLConnection class, which takes an SSL context as a parameter. |
|
When adding a duplicate entry, DefaultCredentialMapperLDAPHelper threw an exception without completing the method even though the exception was harmless. A code change causes DefaultCredentialMapperLDAPHelper to ignore the exception while adding duplicate entries. |
|
The connection pool was not being maintained correctly, and the size of the pool was insufficient for the load the request generated. These problems caused a performance problem while authenticating users. A code change corrected the problems with pool. In addition, an option was added to set the LDAP connection pool size. The option is -Dweblogic.security.providers.authentication.LDAPDelegatePoolSize. |
|
The month field in the DefaultAuditRecorder backup file name was reporting an incorrect value. Code was added to fix the expression. The Month field now reports the correct value. |
|
When two Managed Servers were started simultaneously, then same code was executed twice to create an LDAP entry as a part of deploying an application. The lack of synchronization was causing the creation of a duplicate entry in the LDAP. Code was added to check whether an entry exists in the synchronization before updating the id counter. If a duplicate entry is being created accidentally, WebLogic Server throws an exception, which prevents the creation of the entry. |
|
The following command-line arguments used to control the SSL time-to-live and cache size are no longer ignored in WebLogic Server 7.0: -Dweblogic.security.SSL.sessionCache.size= -Dweblogic.security.SSL.sessionCache.ttl= |
|
SSLLayeredSocket was not creating SSLIOContext when proxying requests, causing NullPointerException while tunneling SSL via proxy servers. A code change that creates SSLIOContext and adds it to context table solved the problem. |
|
WebLogic Server was unable to filter connections from LDAP servers because the LDAP protocol was not allowed in the connection filter rules. LDAP has 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. |
|
Removal of an application was delayed by a configured wait in the processing of embedded LDAP transactions. A code change has resolved the problem. |
|
When two-way SSL is turned on, the server invokes IdentityAssertion automatically, which is correct in a client-server scenario but causes problems when the connection is between instances of WebLogic Server. The scenario: Client hits WebLogic Server Instance1 and is authenticated correctly with two-way SSL. Instance1 then invokes an EJB on Instance2 via two-way SSL, and Instance2 authenticates based on Instance1's certificate. There are two issues: 1. The true user is the client, not Instance1, but Instance2 reads the user as Instance1 based on the DN in Instance1's certificate. 2. Authentication should not be required. You should be able to enforce client certificates for the SSL connection, but turn off the IdentityAssertion check if you want to use a trusted WebLogic Server domain. A code change has made certificate authentication configurable. If you do not want to treat the certificates submitted as a part of two-way SSL to do IdentityAssertion, use -Dweblogic.security.disableIdentityAssertion=true in the server startup. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_40.00.jsp. |
|
A problem that caused loss of information stored with the security subject has been resolved as follows. A new cache is used when a user logs in via two-way certificates or a token in a header or a cookie, improving the performance of identity assertion. The server receives an RMI call either from a 6.x or earlier instance of WebLogic Server, or when a servlet or EJB with a run-as tag is executed. If a user is deleted, identity assertion will continue to work for the deleted user until the cache TTL is reached. The cache TTL defaults to five minutes and can be adjusted on the command line as follows: -Dweblogic.security.identityAssertionTTL=N for N > 0 sets the cache TTL to N seconds |
|
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. |
|
The LDAPConnection used for the realm.getGroups() call retained the results and prevented their return to the pool, which was also used by an iteration of getGroups(). This caused a proliferation of open LDAP connections. Following a code change, an LDAP connection is associated with the getGroups() call to the group iterator, and the connection is closed when there are no more elements left in the iterator. |
|
Specifying java.lang. Integer.MAX_VALUE for ACLCacheTTLPositive resulted in a java.lang.IllegalArgumentException. The problem occurred after this sequence of events. 2. Under the Caching realm, enable the ACL cache and specify the value of ACL Cache Positive TTL = java.lang.Integer.MAX_VALUE and save changes. WebLogic Server throws the following exception: <Jun 25, 2003 4:31:44 PM PDT> <Notice> <Management> <140005> <Loading configuration D:\opt\weblogicapps\ecommerce\.\config.xml> <Jun 25, 2003 4:31:47 PM PDT> <Info> <Logging> <000000> <FileLogger Opened at D:\opt\weblogicapps\ecommerce\.\logs\ecommerce\myserver.log> <Jun 25, 2003 4:31:50 PM PDT> <Critical> <WebLogicServer> <000364> <Server failed during initialization. Exception:java.lang.IllegalArgumentException: ttl<= 0 java.lang.IllegalArgumentException: ttl <= 0 at weblogic.security.acl.TTLCache.<init>(TTLCache.java:195) at weblogic.security.acl.TTLCache.<init>(TTLCache.java:173) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:478) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:375) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:350) at ... The problem was solved with a change to the ttlcache creation code. |
|
The webflowCheckAccess() method now explicitly checks whether a logged in client has access to Web application resources before rendering them. |
|
The NetScape LDAP API released with earlier service packs of WebLogic Server 7.0 contained a bug that could cause deadlocks when more than one thread called deregister() on LDAPConnThread. |
|
In previous service packs, removing the Node Manager properties file caused problems. The Node Manager properties file is always created in the <saved logs dir>/NodeManagerInternal directory. Periodically archiving and deleting the contents of NodeManagerInternal removed the Node Manager properties file, so that the certificate password stored in the Node Manager properties file could not be decrypted, and Node Manager did not work correctly. A code change creates the Node Manager properties file in the directory specified by user.dir, if the file is not found in NodeManagerInternal, or in the user.dir directory. |
|
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 with the IPlanet 5.1 Authenticator. |
|
weblogic.net.http.HttpsURLConnection did not honor https.nonProxyHosts environment variable. Requests from the client, whether one running within WebLogic Server or a standalone Java program, always went through the proxy even if the targeted host was specified in https.nonProxyHosts. https.nonProxyHosts is detected by SSLParams and an internal list of hosts that should be proxied is constructed. When the SSLSocket is created and initialized, the host is compared against this list. If the host appears on the list, the host is used to open the socket. If the host is not on the list, the proxyHost is used to open the socket. (And, if there is no proxyHost, then this is all moot and the host is used to open the socket). A code change resolved the problem. A user can now set the following properties: For either http or https, one can define a proxyHost upon which the socket will be opened. However, one can also define a list of hosts (nonProxyHosts) to which a client should be connected directly, even if a proxyHost is defined. The change made by this fix is to add https.nonProxyHosts, so that a user can now specify the hosts that the client should always connect to directly using SSL even if https.proxyHost is defined. |
|
A MalformedURLException resulted when the dynamic group attribute memberURL contained a string value with a reserved character (such as forward slash '/') in the LDAP search filter portion of the LDAP URL. For example, this URL: ldap://text replaced:389/dc=text replaced2??sub?(&(|(objectclass=person) objectclass=groupofuniquenames))(uid=*text replaced/2*)) <Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance dyn group entry = LDAPEntry: cn=slashgroup,ou=Groups, dc=text replaced; LDAPAttributeSet: LDAPAttribute {type='cn', values='dynamicgroup001,slashgroup'} LDAPAttribute {type='memberURL', values='ldap:///dc=text replaced??sub?(&(|(objectclass=person)(objectclass=groupofuniquenames))(uid=*htext replaced/2*))'}> <Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance member url = ldap:///dc=text ... Analysis and investigation revealed that:
The problem was resolved with a code change to obtain the filter without using LDAPRealm object. |
|
The HTML page served by the CertificateServlet displayed the wrong value for the radio button—it displayed 2048 for the radio button, but using the button resulted in a 1024 bit certificate. A code change corrected the problem. |
|
Properties set directly in the JSP were not being captured and set in the HTTP client. |
|
JDK 1.3.1_08 threw an internal exception that caused two-way SSL communication between two WebLogic Server instances to fail under certain circumstances when LANG was set to univ.utf8. |
|
A BAD_CERTIFICATE error was received and the SSL connection was terminated when a client certificate with Extended Key Usage set to critical was sent to WebLogic Server. Analysis revealed that WebLogic Server did not support Enhanced KeyUsage in SSL. The problem was resolved by adding support for EnhancedKeyUsage. WebLogic Server can now accept Certificates with Enhanced Key Usage set to critical. |
|
After an upgrade from Service Pack 2 to Service Pack 3, an attempt to view the Security->User->Realms->myrealm->Users screen resulted in WebLogic Administration Console hang. |
|
The entitlement engine previously restricted the number of operands in a role expression to 100. This restriction in turn limited various attribute values. For example, the maximum number of principal-name elements that could be mapped to a role within a security-role-assignment in weblogic-ejb-jar.xml was limited to 50. Having more than principal-name 50 elements resulted in a weblogic.entitlement.data.EnCreateException during the deployment of an application. A code change resolved the problem by removing the restriction on the number of operands in a role expression. |
|
On deployment of an application, LDAP entries are written first to Administration and then to Managed Servers. In previous service packs, if writing to the Administration Server failed, the call was returned without writing to the Managed Server, which caused the EJB security layer not to return the correct roles. |
|
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. |
Simple Network Management Protocol (SNMP)
The value that the WebLogic Server SNMP agent returned for sysUpTime did not accurately report the duration since the SNMP agent had been initialized. |
There was no way to create the java.xml.soap.Detail object of the SOAPFaultException exception in version 7.0, as the SOAP Attachments API for Java (SAAJ) was not implemented. This problem was resolved through a code change which exposed the WebLogic API weblogic.webservice.util.FaultUtil. This code change includes the newDetail() method for creating a Detail object. Note: the weblogic.webservice.util.FaultUtil API is deprecated in Versions 8.1 and beyond of WebLogic Server. You should use the SAAJ APIs in these versions to create the Detail object. |
|
Custom type mapping file specified by typeMappingFile in clientgen was ignored. This problem was resolved by setting the custom type mapping file and overriding the default mapping file. |
|
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 Apache SOAP client connects correctly to WebLogic Server Web services for methods that take parameters, but for methods without parameters the following error was generated on the server side: javax.xml.soap.SOAPException: Found SOAPElement ['']. But |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_47.00.jsp. |
|
The class weblogic.xml.schema.binding.FaceUtils was present in webservices.jar but not in webserviceclient.jar. Its absence generated an error when it was declared missing when a client passed complex parameters to a Web server (a list of Java objects, for example). |
|
Accessing SOAPElement.getElementName() in a client -side handler caused a ClassCastException because the SOAPElement was created with a name class that did not implement javax.xml.soap.Name. The name class is now converted into javax.xml.soap.Name. |
|
The clientgen Ant task was removing the underscore "_" character when it generated Java code from WSDLs. A code change has corrected this problem. |
|
The autotype code generator did not properly handle attributes without types or with anonymous types. A code fix has resolved the problem. |
|
When you start the server with -Dweblogic.webservice.verbose=true, verbose output shows the response XML two times instead of the request and then the response XML. The title of the first output is "Request" even though it shows the response. Following a code change, the SOAP request and response print correctly to stdout on the server side when Dweblogic.webservice.verbose is turned on. |
|
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 |
|
Specifying useServerTypes with multiple services in clientgen did not work properly. If you ran servicegen with multiple service entries to generate a client that specified useServerTypes=true, the type files were not always copied from the Enterprise application for the client, and the generation of the type code removed the "_" from the method names for the getters and setters. You can now specify more than one service in a servicegen task whose client sets useServerTypes=true. For example, the following will now work: destEar="RetailServicesServerBEA" warName="RetailServicesServerBEAWebApp"> javaClassComponents="com.hp.wsmo.demo.retail.webservice. products.ProductsWS"targetNamespace="http://localhost:70 <client packageName="com.hp.wsmo.demo.retail.client.bea. products" clientJarName="PRODUCTS.jar" javaClassComponents="com.hp.wsmo.demo.retail.webservice. orders.OrdersWS"targetNamespace="http://localhost:7001/ javaclass"; style="rpc"> <client packageName="com.hp.wsmo.demo.retail.client.bea.orders" |
|
In previous 7.0 service packs, only the URL path was used in the Request-Line when writing the request to the socket, and HTTP query and reference parameters in the Web service URI were not being passed to the Web service. Query and reference parameters, when present, are now appended to the request URI. |
|
When testing a Web service that used Date as an argument, the Web service displayed a security dialog requesting a username and password. The problem did not occur when the argument was changed to a string. The problem was solved with a code change to eliminate the security dialog and invoke the service correctly when it uses a Date argument. |
|
Passing org.w3c.dom.Document[] as a parameter to a method causes a SOAPException beginning with the following lines: javax.xml.soap.SOAPException: Found SOAPElement |
|
In Service Pack 5, WebLogic Server implemented the following previously missing methods for the SOAPHeader class: |
|
A bogus Authorization header in a request caused the Web service engine to try to perform basic authentication even though there were no security constraints defined for the Web application. |
|
In WebLogic Server 7.0 SP02 and SP03, when a user accessed the webservices.basic.statelessSession example Webservice using the client call: String returnVal = port.sayHello(4, "\n\n <--spaces and the leading white spaces (new lines and spaces) were stripped off and did not appear on the server side. |
|
Problems occurred when char was passed to a Web service operation, whether the client was static, dynamic, or the Web Service Test Home page. Passing char as a parameter resulted in the following assertion error: run: |
|
Calling a method in the Web service through the ISAPI filter caused this exception: java.lang.IllegalArgumentException: Illegal MimeHeader name or value |
|
Clientgen failed to compile generated classes for an extended type if the base type had a different namespace. Analysis revealed that the base class from a different package was not being imported. The base class name is now generated with the complete package name, resolving the problem. |
WebLogic Server 7.0 Service Pack 4 Solutions
The following sections describe problems resolved for the release of WebLogic Server 7.0 Service Pack 4 (SP4). The following list of resolved problems is updated periodically.
ejbc now runs a compliance check that disallows optimistic concurrency for BMP (bean-managed persistence) beans. Optimistic concurrency is a feature of CMP (container-managed persistence) beans in EJB 2.0. See EJB Concurrency Strategy in The WebLogic Server EJB Container and Supported Services. |
|
The JDBC driver from Microsoft has a limitation whereby for a given result set of rows and columns, the getXXX method can only be called once per row. This limitation applied only if the query columns included a text or image column. WebLogic Server-generated JDBC obtained the key value from a row—for example, using a getLong(1)—and then passed the result set to another routine that read all the column values, including the first, re-executing a getLong(1). This re-execution caused the Microsoft driver to throw an exception. The problem is resolved by a code fix that avoids parsing the primary key columns in the resultSet twice. |
|
The inclusion of CMR fields in the field-group entry in weblogic-cmp-rdbms-jar.xml caused a compilation failure with the following error: D:\AA\bea70sp1\weblogic700\samples\server\src\examples\ejb20\relationships\Fathr\EJB_Problem2>java weblogic.ejbc fatherError.jar fathersonError.jar ejbcgen\temp_lr_sahre_jb8\SonBean_1saa__WebLogic_CMP_RDBMS.java:909: incompatible types found : <null> |
|
WebLogic Server-generated EJB SQL queries used ">= AND <=" as an operator. IBM DB2 does not handle "<=", and therefore requires "BETWEEN", which is equivalent. For DB2, generated EJB SQL now uses BETWEEN instead of ">= AND <=", and also handles NOT BETWEEN appropriately. |
The attribute KeepXAConnTillTxComplete, which is required for XA connection pools, now only performs a check if the XA isolation level has changed. |
Node Manager was unable to shut down a Managed Server after the Administration Server restarted. Node Manager now correctly updates the status of the Managed Server during shutdown. |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp. |
|
The identity assertion naming convention (WL-PROXY-CLIENT-*) for headers conflicted with WL-PROXY-CLIENT-KEYSIZE, WL-PROXY-SECRET-KEYSIZE and WL-PROXY-CLIENT-IP. Filtering these headers as identity assertion headers avoided a Client-Cert identity assertion error. |
WebLogic Server 7.0 Service Pack 3 Solutions
The following sections describe problems that were resolved for the release of WebLogic Server 7.0 Service Pack 3.
You no longer configure the Auto Deployed Enabled attribute on the Domain --> Configuration --> Applications tab in the Administration Console. To control auto deployment behavior, see Auto Deployment in Developing WebLogic Server Applications. |
|
Selecting Server --> Monitoring --> Process Output and selecting any of the view options did not display the output. If you selected the "View Node Manager Output" while the Node Manager was running, the Node Manager would crash. |
|
If you created a Role using the context-sensitive (right-click) menu item "Define Policies and Roles for individual beans..." and added the Role to the Policy (defined using the same context sensitive menu/form sequence) the desired resource could not be used by an external JCom client. The context-sensitive menu items create a scoped role, and clients outside the scoped role could not use the resource. Adding a "Define JCom Roles" menu item to the JCom node solved this problem by allowing revision of the scope to include the current client. |
|
Security settings in the Administration Console for Web services did not function properly. A code change removed the ability to set policy and roles for Web services in the Administration Console. |
|
Realms created by the Administration Console lacked the UserLockoutManager on their RealmMBeans. The Administration Console now creates a ULMbean when it creates a new realm. |
|
When customers configured a new security realm, the User Lockout tab displayed the message: 'User lockout feature not supported by the configured providers'. This problem resolved by modifying the code to ensure that a User Lockout Manager is created whenever a new security realm is created. |
|
The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close. |
|
A new attribute, LogTimeInGMT, was added to the Server -- > Logging --> HTTP console page. This attribute specifies that the time stamp of HTTP log messages is written in Greenwich Mean Time regardless of whether the host computer has specified a different local time zone. |
|
Fixed a problem saving migratable targets for JMS servers where the targets reverted to an earlier setting. |
|
Disabling the SSL Port for a Managed Server from the Administration Console caused an AssertionError that begins: weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ ServerIron for server not found ] Having the validation process check for the configuration MBean on the Managed Server fixed the problem. |
|
The WebLogic Server Administration Console requires you to specify how the WebLogic Security Service should perform security checks. You specify this preference using the fullyDelegateAuthorization flag, a command-line argument that you set when you start WebLogic Server. When the value of the fullyDelegateAuthorization flag is false, the WebLogic Security Service only performs security checks on URL and EJB resources that have security specified in their associated deployment descriptors (DDs). This is the default setting. See Understanding the fullyDelegateAuthorization Flag in Securing WebLogic Resources. |
|
The Application tag of config.xml has a LoadOrder attribute that was not settable from the Administration Console. |
|
You could not set the LoadOrder attribute in the Application tag in config.xml from the Administration Console. Adding the LoadOrder attribute to application modules (Application, ConnectorComponent, EJBComponent, WebAppComponent, JDBCPoolComponent) fixed this problem. |
|
In previous Service Packs, when WebLogic Server was installed on NTFS volumes, you could not view the server log in the Administration Console if an alternate log file location was specified. With a log location setting like the following: <Server Name="myserver" ServerVersion="7.0.0.0"> <Log FileName="c:\temp\myserver.log" Name="myserver"/> the server would throw a java.io.FileNotFoundException. This problem was solved by moving the call for the FileName attribute to a custom getter (breaking a previous dependency on FileStreamHandler), and having the LogFileSearchServlet get the FileName attribute directly from the MBean. |
|
When you tried to clone a new Web application, EJB, or connector on the Examples server, the Administration Console displayed an Unexpected Error page with this message: javax.management.InvalidAttributeValueException: Path is NULL The resolution was to remove the Clone icon from ApplicationTable, EJBComponentTable, WebAppComponentTable, ConnectorComponentTable. |
|
You can now configure policies for JMS topics and queues via the Administration Console. |
|
The Administration Console option Web Application->webapp1->Monitoring->Monitor all Active Web Applications... |
|
Fixed a problem whereby log messages displayed in the Administration Console were truncating part of the text when using UTF8 encoding. |
|
The Administration Console threw the following AssertionError when you specified 00:00 as the format date for the Rotation Time for the access log: weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Could not parse LogRotationTimeBegin: 00:00 because Unparseable date: "00:00" ] Adding legal validation for the time format in the Log and WebServer MBeans fixed the problem. |
|
Fixed a display problem in the file browser associated with the weblogic.properties file converter, in Japanese. |
|
The TransactionLogFileWritePolicy attribute was added in 7.0 SP01, but was never exposed in the Administration Console. A field for setting this attribute was added to the Server —> Logging —> JTA tab. |
|
After edits to Cookie Max Age Secs using the Administration Console, the value sometimes reverted to the value before the edit. A code change removing a lower limit to the value fixed the problem. |
|
The waitersTotalCount value was not being decremented, causing the Administration Console to report incorrect values. Adding a new method, WaiterCurrentCount, resolved the problem. |
|
The Client Cert Proxy Enabled check box was displayed on the Tuning tab for a server, but this attribute is not related to tuning. The ClientCertProxyEnabled field was relocated to the Configuration —> General tab for a server. |
|
The UserReader MBean did not display users in the Administration Console. An authentication provider can read users in the Console while implementing the UserEditor but with UserReader, the message when trying to display users is "There are no Authentication providers available that support the creation of Users." The same thing was happening for Groups with the GroupEditor and GroupReader interfaces. The Administration Console was still calling the userEditor.CreateUser method, and never getting to the UserReader.listUsers method. The MBean has been fixed to look for appropriate provider type. |
|
The WebLogic Server Administration Console was accessible via the Managed Server address and port when the server had been started in MSI (Managed Server Independence) mode. |
|
The weblogic.Admin utility used the T3 protocol regardless of which protocol you specified. For example, the command "java weblogic.Admin - url http://localhost:7001" used T3 to connect to the server instance listening at localhost:7001. The utility has been updated to use HTTP or HTTPS if you specify them. Note that you must enable HTTP tunneling if you want to use these protocols. See "Configuring the HTTP Protocol" in the Administration Console Help. |
The Node Manager was writing an unnecessary stack trace on shutdown of a Managed Server running under an Administration Server under certain conditions. The problem occurred because - HttpUrlConnection.getInputStream doesn't return because the Managed Server waits for a certain period of time before returning the response to a query. This was intentional behavior to provide almost continuous monitoring of the Managed Server. When the Managed Server shut down, however, the delayed servlet response was not sent and the socket was closed. The Node Manager subsequently tried to re-open the connection but failed to connect in openServer call because the server was not there. In response to this, a ConnectException was thrown and logged by openServer. The Node Manager no longer writes the unnecessary stack trace. |
|
A stack trace resulted from a error looking up a session. A secondary server instance was being shutdown. While making a log entry for a request it served, the HTTP server tried to get the user information from the session. As a result it tried to look up the secondary server even though it was down, resulting in this stack trace. <Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking The primary server correctly selected a new secondary from the available server list, and no session data was lost. This problem was resolved with a code fix. Now, the server obtains user information from ThreadLocal, instead of the session. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp. |
|
The following sequence was causing a ClassCastException: define a server, assign that server to a cluster, create a Unix machine with the same name as the server, assign them to each other, stop and restart the Administration Server, and select the server name from the cluster or from the Servers list. Trying to bring up the Managed Server also caused a ClassCastException. Fixing a problem in a process that resolves an UnresolvedMBean during startup solved this problem. |
|
Clustered servers could lose sessions when a client switched to a third server in the cluster from the first and second servers, which had been the client's primary and secondary servers. A process would remove the session from the first two servers, and when the client switched back to the primary server, the primary server looked for the session on the secondary server, instead of properly looking on the third server. A code fix resolved the problem by causing the session to be recreated from session information on the third server, completely removing the session from the primary and secondary servers. |
|
Starting a new Managed Server in a cluster that contained two running Managed Servers caused a ConcurrentModificationException on one of the running servers. A code change fixed the problem by making the members of a cluster meet synchronization requirements. |
|
If two clusters have between them two distributed queues with the same JNDI name, and a message-driven bean is deployed on both the clusters, messages were being consumed in only one of the clusters. A message-driven bean now goes through the entire collection of distributed queues in a domain and adds their members appropriately. |
|
An Administration Server and two Managed Servers were in a cluster. Application application1.ear contained EJBs and Web applications. The EJBs were deployed to the cluster. The Web applications were deployed to a VirtualHost, which was in turn targeted to the cluster. application1.ear contained application1.war, which was configured as DefaultWebApp of the VirtualHost. In addition to this, each cluster node had its own DefaultWebApp. Deployment succeeded, but attempts to undeploy application1.ear resulted in the exception below, and the application could not be redeployed, even if the entire domain was restarted. Exception caught for task Unprepare application application1 on The Web container was trying to undeploy its DefaultWebApp with the undeployment of every WAR. The first WAR succeeded and the second WAR failed because the DefaultWebApp is already undeployed. The code was changed so that if no context for the targeted Web application exists on the http server, the default Web application is not undeployed. This resolved the problem. |
|
In a cluster, if you set the value '0' for MulticastTTL, WebLogic Server ignored the setting and took the default value as 1, throwing an error like the following: "clusterdomain:Name=mycluster,Type=Cluster" is smaller than the A code change resolved the problem by allowing the value to be `0'. |
|
In WebLogic Server 6.1 SP04, session replication stopped working after a failure to replicate a non-serialized object. Invocation of a JSP that tried to set non-serialized data into the session object, resulted in the expected exception: <Mar 19, 2003 2:58:23 PM PST> <Error> <Cluster> <All session Then, for all subsequent requests, sessions were not replicated, and this exception occurred: <Mar 19, 2003 2:58:48 PM PST> <Debug> <Cluster> <Unable to create The problem was solved with a code change. Now, when a non-serializable object is encountered, the method returns, instead of trying other secondaries. |
|
To prevent an incorrect port number from being constructed in the HomeHandleImpl class while constructing the URL in NetworkChannel between two Managed Servers, listenPort and sslListenPort are now initialized with default values. |
The weblogic.Deployer utility generated "alternate descriptor" errors when deploying an EAR file. For example: Module: module_name Error: Alternative descriptor descriptor_name can't be found. This problem occurred because WebLogic Server did not look for the descriptor files in the directory where the EAR was extracted. |
|
All Managed Servers in a domain automatically redeployed EJBs when you restarted the domain's Administration Server. A code fix ensures that restarting an Administration Server does not redeploy EJBs on the domain's Managed Servers. |
|
WebLogic Server required an incorrect CODEBASE value to access applets deployed as part of an EAR file. For example, an applet packaged inside a Web Application, MyWar.war, and deployed as part of an EAR file, MyEar.ear, required a CODEBASE similar to: CODEBASE=/bea_WebLogic Server_internal/classes/MyEar@MyWar.war Where MyWar.war is the name of the WAR file that contains the applet. This was required even if the Web Application explicitly defined a CONTEXT-ROOT of MyWar. This problem occurred because WebLogic Server deployed using the URI of the Web Application, rather than its CONTEXT-ROOT. The code was fixed to deploy Web Applications using the CONTEXT-ROOT, if one is specified the EAR file's application.xml descriptor. For example, if the above EAR file specified a CONTEXT-ROOT of MyWar for the Web Application, the correct CODEBASE for the applet would be: |
|
Refreshing a Web application with weblogic.Deployer (with -activate -upload flags) was not working properly.The web app was deactivated, rolled back and destroyed before being loaded. This was a regression introduced by another fix. The code was changed to roll back the Web application under the appropriate circumstances. |
|
When the Web container is Tomcat 4.0 and the EJB container is WebLogic Server7.0SP1, and two Web applications which have different names and use different classloaders but the same classes are deployed on Tomcat, the first Web application is able to invoke the EJB, but the second Web application fails to invoke it, with a ClassCastException. A new -D flag enforces clients to generate stubs on the context classloader. The -D flag is as follows: |
|
Deleting a Web application from a Managed Server that had been stopped resulted in errors similar to the following: <Warning> <Management> <149311> <Rejecting deployment operations to non-running server, mgd1> <Warning> <Deployer> <149004> <Failures detected initiating weblogic.management.ManagementException: Rejecting deployment operations to non-running server, mgd1 task for application Remove application MyWebApp on mgd1> The Web application was not deleted. A code change fixed the problem by eliminating dangling WebAppComponentMBean references from the WebServer and VirtualHost MBeans. |
|
Web applications in an EAR deployed to a VirtualHost did not redeploy on domain restart. A code change has resolved the problem so that applications that target a Virtual Host restart when the domain restarts. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. |
In WebLogic Server 7.0 SP2, Configuration Wizard templates used in Silent Mode created unusable domains. |
Operations, Administration, and Management
LogManager's use of synchronization was causing a deadlock in the threads. Eliminating some synchronization in LogManager fixed the problem. There is no more deadlock. |
A sample custom Authentication provider that supports the user/group management Security Service Programming Interfaces (SSPIs) was included in the sample security providers code example on dev2dev. In addition, a custom Auditing provider was added to the code example. For more information, see http://dev2dev/codelibrary/code/security_prov81.jsp. |
|
Within two trusted domains, a Java client calls stateless session bean1 on server1 in domain1. This bean calls stateless session bean2 on server2 in domain2. The user calling the first server is user system in group Administrators with Role Admin (default). If the call from bean 1 to bean 2 used the t3 protocol, the principal was propagated properly. If the call from bean 1 to bean 2 was an IIOP call and there was a security role assignment in the weblogic-ejb-jar.xml that mapped the role Admin to user system, the principal was propagated properly. However, if the call from bean 1 to bean 2 was an IIOP call and the security role assignment mapped role Admin to group Administrators, an org.omg.CORBA.NO_PERMISSION error occurred. The principal propagation now works properly in all situations. |
|
After creating a domain with one Administration Server and one Managed Server, enabling the -Djava.security.manager for the two servers returned a java.io.Filepermissions error reported in the AdminServer log for <Error> <EmbeddedLDAP> <000000> <Error parsing Entry #19: access denied (java.io.FilePermission .\myserver\ldap\ldapfiles\EmbeddedLDAP.data read)>. This problem was resolved by updates to the weblogic.policy file, to which was added information about granting permissions to user applications, and examples of grant statements. The weblogic.policy works for Weblogic Server Examples, Pet Store, and Workshop. It needs to be modified to be used for user configurations; instructions are in the comments at the top of the file. |
|
WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority. This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA thus ensuring all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected. If WebLogic Server is booted with a certificate chain that won't pass the certificate validation, an information message is logged noting that clients could reject it. |
|
When using the Active Directory LDAP Authentication provider, the user search filter did not support the use of backslashes in a user name. The LDAPv3 Attribute Syntax Definition specification supports the use of backslashes in the user search filter. The code for the user search filter has been updated to support the use of backslashes. |
|
The methods getCurrentUser and getCurrentSubject are supposed to return the user ID of the user associated with the current thread. In previous Service Packs of WebLogic Server 7.0, if you forwarded from one servlet to another using RequestDispatcher.forward, these methods would return null (or an empty string). A code fix resolved this issue so that requests forwarded from one JSP or servlet to another will carry the authenticated user in the session. |
|
In previous releases of WebLogic Server, the SSL license check required both the 128 bit and the IP address using the license. The original intent of the license check was:
BEA recommended that Java clients not running on a server copy the license from the server to the Java client machine. However, the implementation of the license check in the SSL code asked for an IP validation. Therefore, the server SSL license could not be used on the client machine. The IP validation in the license check has been removed. The license can now be copied from the server to the Java client machine. |
|
When using the Active Directory LDAP Authentication provider, the user search filter did not support the use of nature language characters in a user name. The LDAPv3 Attribute Syntax Definition specification supports the use of natural language characters in the user search filter. The code for the user search filter is updated to support the use of nature language characters. |
|
The Realm Adapter Authentication provider in the Compatibility realm used the authenticated user name in the User object instead of creating a User object with a unique ID. This problem broke backward compatibility with custom security realms that perform simple authentication (username/password). The Realm Adapter Authentication provider code has been modified to create a User object with a unique ID. |
|
The password used to access the encrypted private key in the Node Manager key file, weblogic.nodemanager.keyPassword, was in plain text and accessible. The problem was resolved by the creation of the Node Manager properties file, nodemanager.properties. |
|
The hierarchy caching optimization has been removed from the resource engine within the WebLogic security framework. The resource cache has been updated to use Resource as a key. The cache now runs resource.equals() on every cache hit to make sure there is not a hash code collision. The resource string representation and parent are cached in the resource, so after the hierarchy is in cache only one cache lookup is required to get the resource name path. This change improves the performance of WebLogic Server. |
|
A call to weblogic.security.ntrealm.NTRealm username password always raised an exception. This problem has been resolved. |
|
In earlier versions of WebLogic Server 7.0, groups in LDAP had to be explicitly added to one another for WebLogic Server to recognize that the two groups were nested. Implicit nesting, by adding a group under another group in an LDAP tree, was not recognized. This problem has been resolved by a modification to the LDAP provider that makes it perform group membership checking by hierarchy. Set the property as follows: |
|
When two-way SSL and the weblogic.servlet.security.ServletAuthentication.strong() method were used, an exception occurred. The import in the authentication portion of the servlet code used javax.security.cert.X509Certificate instead of java.security.cert.X509Certificate as defined by the servlet specification. The servlet code now uses java.security.cert.X509Certificate. |
|
The LDAP Realm v2 had poor performance when handling groups with a large number of users. This problem could cause the WebLogic Portal server to hang and time out. The problem was related to the calls to: netscape.ldap.LDAPMessageQueue.waitForMessage Specifically, the calls hung if there were many groups in the groupDN were searched by the LDAPRealm v2 and the Group.isMember method was called in succession for all of these groups. Generally, the server would hang after several hundred calls in a row. The code for the LDAP Realm v2 was updated to resolve this problem and improve performance when handling groups with large numbers. |
|
The default value for backup minutes is now correctly calculated and reported under domain > Domain Wide Security Settings -> Embedded LDAP in the Administration Console. |
|
When using a 6.1 security configuration that uses the RDBMS security realm, the server (and therefore Compatibility security) would not start. 1. The RDBMS Realm config.xml entry needs to explicitly state the RealmClassName, Database Driver and Database URL attributes. When using the RDBMS security realm in 6.x, these values assumed the RDBMS code example and the examples database were used. |
|
weblogic.servlet.security.ServletAuthentication.strong() was failing with a class cast exception. Research revealed that the wrong certification class was being imported. A code fix resolved the problem. |
|
Construction of an AuthenticationProvider was not recognizing errors, because WebLogicBeanMaker was not seeing exceptions thrown by the AuthenticationMBI class constructor. The problem was resolved by a code change ensuring the propagation of errors. |
|
In past releases of WebLogic Server, the WebLogic Credential Mapping gave no notification when it received passwords that it could not validate. This problem has been resolved. The WebLogic Credential Mapping provider now throws an exception when it receives encrypted passwords that cannot be validated. |
|
In past releases of WebLogic Server, the passwords stored in the embedded LDAP server by the WebLogic Credential Mapping provider were in clear text. The WebLogic Credential Mapping provider now encrypts passwords when storing them in the embedded LDAP server. |
|
Node Manager allowed unauthorized starting of Managed Servers, because it supplied a cleared user name and password regardless of the authorization level of the user. |
|
The Bouncy Castle JCE provider was not tested prior to 7.0 SP3, and requires special case code to get it to work with SSL. In this release, code was added to SSL to detect when the BouncyCastle provider JCE is plugged in, and fall back to use internal cryptography instead. Customers that want to use the BouncyCastle JCE provider in their server side applications can do that now without provoking an exception. SSL will not use that provider if it is plugged in, but the exception will not occur. |
|
When a user account in one of the supported LDAP servers became disabled (for example, if the account was disabled for a long period time or locked because of a failure), any attempt to use that account (username/password) from an LDAP security realm resulted in the need to restart the server. The following exception was throw: <[WebAppServletContext(2052089,WebCM-Outages,/Webbed-Outages)] Servlet failed with Exception netscape.ldap.LDAPException |
|
In previous releases of WebLogic Server, the code that unloaded the SunJCE provider at runtime was still being used. This problem did not allow the use of the Sun JCE provider with WebLogic Server when the SSL protocol was enabled on the server instance. This problem has been resolved. Customers who are using JDK 1.4 clients with Sun JCE may experience a performance degradation due to a performance issue in the JDK 1.4 JCE implementation. If the client does not require the Sun JCE provider, you should comment out the Syncs provider from the JDK/re/lib/security/java.security file as follows: security.provider.1=sun.security.provider.Sun |
|
The default connection filter in WebLogic Server was not handling the HTTPS protocol properly. This problem has been resolved. |
|
In previous releases of WebLogic Server, it was not possible to make a secure connection to a third-party XML server because the XML server did not support the SSL protocol. The following workaround is provided: 2. Create an Java authenticator class according to the Java specification. This authenticator should obtain a surname and password for the used to connect to the XML server. |
|
Eracom and Entrust third-party security providers have been certified for this release. |
|
7.0 SP2 enabled JCE providers to be used for SSL cryptography operations. Unfortunately, all JCE providers do not behave the same way; each requires special handling and foreknowledge. The ERACOM/Entrust JCE providers require special case code to work with SSL. Code added to SSL causes it to detect when the ERACOM/Entrust providers are plugged in, and to use internal cryptography. ERACOM/Entrust JCE providers work in server-side applications now. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-33.jsp. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. |
|
When multiple authorization providers were installed, you could not define policy on Web applications. |
When creating large Field Manipulation Language (FML) tables (on the order of 4K entries), mkfldclass[32] generated a method to instantiate each entry into a hash table. For large FML tables, this single method exceeds the size limitation in the JVM. This problem was resolved by implementing a dynamic load field table mechanism. For more information, see Using the DynRdHdr Property for mkfldclass32 Class. |
|
viewj and viewj32 methods can create huge java classes (exceeding 65535 byte codes in the constructor method) when compiling view files that contain a large number of fields. Analysis of the problem revealed that majority of the code in the constructor involved assigning null values to fields and array elements and could be removed. This problem was resolved by providing a code fix that suppresses redundant code when compiling view files. |
|
Using WTC to access Tuxedo 8 Corba objects resulted ia n JavaIDL Reader thread leak. Running a simple example application resulted in a build-up of JavaIDL Reader threads in the JVM running WebLogic Server. The threads were not destroyed until the server was shut down. Analysis revealed the finalize() was not called at the correct time. A code fix to add a call to ORB.destroy() was implemented to resolve the problem. |
WebLogic Server 7.0 Service Pack 2 Solutions
The following sections describe problems that were resolved for the release of WebLogic Server 7.0 Service Pack 2.
Administration Console help no longer displays 404s or displays in English instead of displaying Japanese translation. |
A com2java.exe problem in which generated classes would not compile without manual intervention has been resolved. |
Prepared statement code no longer provokes a null pointer exception. The problem was that the prepared statement object was being set to null. |
|
Prepared statement caching is now off by default, that is, the default statement cache size is now 0. |
|
Creating connection pools with the weblogic.admin command-line interface no longer results in this authentication error: java.lang.ClassCastException: weblogic.security.service.PrincipalAuthenticator |
|
WebLogic Server JDBC now supports the NLS_LANG parameter WE8MSWIN1252. |
|
When a user transaction failed to roll back due to the Oracle being down, the JDBC connections used in the transaction were released. As a result, no connections were available in the pool. This problem has been resolved. |
|
WebLogic Server can now create a JDBC store configured for a JMSServer using Oracle 9.0.1 version. |
|
Previously, prepared statement cache functionality did not include support for calling setInt() for statement columns that were first used with setLong(), setFloat(), or setDouble(). In addition, calling setInt() on a column that had originally been bound with setNull(i, BIGINT) caused a "Re-Parse Cursor" SQLException. The missing functionality was supplied by the exposure of a new XA Prepared Statement Cache in the JDBC Connection Pool MBean, which is turned on by default with a default value of 5, and by other code changes. The default value for Prepared Statement Cache Size was also increased from 0 to 5, which enables the feature by default. See "Increasing Performance with the Prepared Statement Cache" for more details, including usage restrictions. |
|
Transaction isolation can now be set when using jDriver/Oracle XA and Oracle Thin XA. Previously, attempting to set it resulted in this error: get exception: java.sql.SQLException: Due to vendor limitations, setting transaction isolation for "Weblogic OCI XA" JDBC XA driver is not supported |
|
Running continuous Selects through a JDBC connection pool no longer provokes OutOfMemory errors. In previous releases of WebLogic Server, if application code created JDBC objects that were abandoned without being closed, the objects would be lost but would still hold memory or open cursors, even after being garbage collected. If too many such objects were created, the server would eventually run out of memory and the database may run out of cursors. In WebLogic Server 7.0SP2, the code was changed so that abandoned JDBC objects are closed before being garbage collected. Note: If you immediately create a JDBC object that is identical to an abandoned object, WebLogic Server creates a clone of the original JDBC object. However, when the original leaked object is closed, the clone will also be affected. |
DBAs no longer have to resolve distributed in-doubt transactions manually; WebLogic Server now resolves them automatically. |
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-17.jsp. |
|
Fixed a problem in which certificate data was not appearing in the Administration Console. |
|
The TLS_RSA_WITH_DES_CBC_SHA cipher suite is now exportable. |
|
The location of the log files for the WebLogic Auditing provider has changed. Auditing is configured for the security realm, but each server instance writes to its own log file located in the server directory. The new location is WL_HOME\mydomain\myserver\ |
|
In previous releases, WebLogic Server did not ensure each certificate in a certificate chain was issued by a certificate authority. This problem meant anyone could get a personal certificate from a trusted certificate authority, use that certificate to issue other certificates, and WebLogic Server would not detect the invalid certificates. Now all X509 V3 CA certificates used with WebLogic Server must have the Basic Constraint extension defined as CA, thus ensuring all certificates in a certificate chain were issued by a certificate authority. By default, any certificates for certificate authorities not meeting this criteria are rejected. For more information, see SSL Certificate Validation. |
|
Defining security policies in the weblogic.xml or weblogic-ejb-jar.xml files required creating a \lib directory in the domain and then granting permissions to the \lib directory in the weblogic.policy file. This known problem is fixed in this release. For information about defining security policies, see Securing WebLogic Resources. |
|
WebLogic Integration no longer experiences problems resuming the SSL session when interacting with WebLogic Server. |
|
The code example for the custom Authorization provider did not work because the web.xml file in the code example was incorrect. The file used a url-pattern of * to protect its pages when it should have used */. |
|
The javax.security.auth.login.LoginContext.logout() method did not delete the principal and credential information from the subject of a LoginContext. Therefore, the user was not logged out. |
|
Protected JNDI resources can no longer be accessed by unauthorized users. |
|
WebLogic resources with hierarchies (for example, JMS, JDBC, Server) now handle actions correctly from the getParentResource() method. |
|
Calling a stateful session bean from a JSP caused the following security violation: java.rmi.AccessException:Security Violation: user username has insufficient permission to access EJB This error occurred because an established security context was not closed properly. Use ServletAuthentication.runAs(Subject subject, HTTPServletRequest request) at the end of the JSP so that the user will be added to the HTTPServletRequest if the initial security context is not closed. |
|
WebLogic Server rejects digital certificates that have the KeyUsage constraint set as a critical, but do not have the KeyEncipherment constraint set. Older versions of WebLogic Server which use SSL V3.0 did not reject certificates under this circumstance. However, this release of WebLogic Server which uses TLS V1.0 will reject certificates under this circumstance. |
|
The ServerIron monitoring product sends a request to the SSL port during a server health check. During this health check, the SSLIOConect and related SSL objects were not released, causing an out-of-memory error. |
|
Dynamic groups now works properly with the IPlanet Authentication provider. |
|
The servlet container in WebLogic Server did not pass login exceptions to the error page as specified by the J2EE specification. |
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-29.jsp. |
|
Fixed a problem in which, when adding users to replicated LDAP databases in cluster, it took an unacceptably long time for users to be replicated on Managed Servers. |