Release Notes
|
 |
 |
|
 |
 |
Resolved Problems for Service Pack 2
Service Packs are cumulative; Service Pack 2 contains all the fixes made in earlier Service Packs released for WebLogic Server 8.1.
The following sections describe problems that were resolved for the release of WebLogic Server 8.1 Service Pack 2.
- Administration Console
- Classloader
- Cluster
- Connector
- Core
- Deployment
- EJB
- Installation
- J2EE
- JCOM
- JDBC
- JMS
- JNDI
- JTA
- Node Manager
- Plug-Ins
- RMI/RMI-IIOP
- Security
- Servlets & JSPs
- System Administration
- Tools
- Web Services
- WTC
- XML
Administration Console
If you created a security role using the context-sensitive (right-click) menu item "Define Policies and Roles for individual beans..." and added the security role to the security policy (defined using the same context sensitive menu/form sequence), the desired WebLogic resource could not be used by an external JCom client.
The context-sensitive menu items create a scoped role, and clients outside the scoped role could not use the WebLogic resource.
Adding a "Define JCom Roles" menu item to the JCom node solved this problem by allowing revision of the scope to include the current client.
Security settings in the Administration Console for Web services did not function properly.
A code change removed the ability to set policy and roles for Web services in the Administration Console.
Realms created by the Administration Console lacked the UserLockoutManager on their RealmMBeans.
The Administration Console now creates a ULMbean when it creates a new realm.
The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close.
For a three-node cluster on separate Solaris 2.8 machines, the Administration Server threw an InstanceNotFound exception when accessing the default Execute Queue.
After edits to Cookie Max Age Secs using the Administration Console, the value sometimes reverted to the value before the edit.
A code change removing a lower limit to the value fixed the problem.
WebLogic Server sometimes displayed the following NullPointerException when a domain contained two Administration Servers and you tried to access the servers via the WebLogic Server Administration Console:
java.lang.NullPointerException at
weblogic.management.console.helpers.UrlHelper.buildIconList(UrlHelper.java:149) at
weblogic.management.console.helpers.UrlHelper.getIcon(UrlHelper.java:174) at
weblogic.management.console.tags.SmartNavNodeTag.getIcon(SmartNavNodeTag.jacva:111) at
weblogic.management.console.tags.SmartNavNodeTag.inferStuffFromContext(SmartNavNodeTag.java:96) at
weblogic.management.console.tags.SmartNavNodeTag.doStartTag(SmartNavNodeTag.java:44) at
weblogic.management.console.webapp._domain.__nav._jspService(__nav.java:301) at
weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:250)
[...]
The UserReader MBean did not display users in the Administration Console. An Authentication provider can read users in the Administration Console while implementing the UserEditor but with UserReader, the message when trying to display users is "There are no Authentication providers available that support the creation of Users." The same thing was happening for Groups with the GroupEditor and GroupReader interfaces.
The Administration Console was still calling the userEditor.CreateUser method, and never getting to the UserReader.listUsers method.
The MBean has been fixed to look for appropriate provider type.
New testing with an Active Directory LDAP uncovered a problem where a call to group.isMember() would fail if a member name contained a comma character (,).
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp.
If there is only one server in a WebLogic Server domain, the WebLogic Server Administration Console does not display virtual hosts as potential targets during the deployment of a Web application. This was done to save users the extra step of having to select a target when there is only one target. However, this prevented users from deploying a Web application to a virtual host directly. Users could only deploy the Web application to the server and then re-target it to a virtual host. This worked fine for the first Web application, but for the second Web application, an exception was thrown indicating that the context was already in use.
For Web applications, the Administration Console now checks for any virtual hosts configured in the domain and displays them as potential targets. As a result of this fix, customers should now be able to target Web applications to a virtual host directly from the Administration Console. If there are no virtual hosts, the Administration Console assumes that the lone server is the target for the Web application, just as it did prior to this fix.
In the FileChooserControlTag, WebLogic Server defaulted to UTF-8 encoding for path settings.
This fix causes WebLogic Server to extract the correct charset from the catalog and use that instead of defaulting to UTF-8. As a result of this change, paths are now displayed correctly (without any garbled characters).
Users of the WebLogic Server Administration Console could not delete foreign JMS destinations.
A trash can icon (delete) has been added to the foreign JMS destinations table. Users can now delete foreign JMS destinations.
Editing the load order in the WebLogic Server Administration Console caused spaces to be embedded in the path attribute of the config.xml file's <Application> tag.
This problem occurred because the method pathToFormValue, which is used to breakdown long path strings to more manageable pieces, was rejoining the strings with extra spaces.
The code was changed to remove these extra spaces. As a result of this fix, the extra spaces in the path attribute will no longer be inserted when the config.xml is updated.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_41.00.jsp.
|
If you created a security role using the context-sensitive (right-click) menu item "Define Policies and Roles for individual beans..." and added the security role to the security policy (defined using the same context sensitive menu/form sequence), the desired WebLogic resource could not be used by an external JCom client. The context-sensitive menu items create a scoped role, and clients outside the scoped role could not use the WebLogic resource. Adding a "Define JCom Roles" menu item to the JCom node solved this problem by allowing revision of the scope to include the current client. |
||
|
Security settings in the Administration Console for Web services did not function properly. A code change removed the ability to set policy and roles for Web services in the Administration Console. |
||
|
Realms created by the Administration Console lacked the The Administration Console now creates a ULMbean when it creates a new realm. |
||
|
The cursors created by the Administration Console for listing users and groups caused potential memory leaks when they did not close. |
||
|
For a three-node cluster on separate Solaris 2.8 machines, the Administration Server threw an InstanceNotFound exception when accessing the default Execute Queue. |
||
|
After edits to Cookie Max Age Secs using the Administration Console, the value sometimes reverted to the value before the edit. A code change removing a lower limit to the value fixed the problem. |
||
|
WebLogic Server sometimes displayed the following
|
||
|
The The Administration Console was still calling the The MBean has been fixed to look for appropriate provider type. |
||
|
New testing with an Active Directory LDAP uncovered a problem where a call to |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp. |
||
|
If there is only one server in a WebLogic Server domain, the WebLogic Server Administration Console does not display virtual hosts as potential targets during the deployment of a Web application. This was done to save users the extra step of having to select a target when there is only one target. However, this prevented users from deploying a Web application to a virtual host directly. Users could only deploy the Web application to the server and then re-target it to a virtual host. This worked fine for the first Web application, but for the second Web application, an exception was thrown indicating that the context was already in use. For Web applications, the Administration Console now checks for any virtual hosts configured in the domain and displays them as potential targets. As a result of this fix, customers should now be able to target Web applications to a virtual host directly from the Administration Console. If there are no virtual hosts, the Administration Console assumes that the lone server is the target for the Web application, just as it did prior to this fix. |
||
|
In the This fix causes WebLogic Server to extract the correct charset from the catalog and use that instead of defaulting to UTF-8. As a result of this change, paths are now displayed correctly (without any garbled characters). |
||
|
Users of the WebLogic Server Administration Console could not delete foreign JMS destinations. A trash can icon (delete) has been added to the foreign JMS destinations table. Users can now delete foreign JMS destinations. |
||
|
Editing the load order in the WebLogic Server Administration Console caused spaces to be embedded in the This problem occurred because the method The code was changed to remove these extra spaces. As a result of this fix, the extra spaces in the |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_41.00.jsp. |
Classloader
Cluster
Connector
Core
Manually doing a lookup and then persisting and caching the handle did not work when the methods were conversational.
Changes to serialization and deserialization of the EJBHandle object resolved the problem.
When starting WebLogic Server as an Windows service using a classpath from a file, the error
"Thread created successfully! Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/Server"
was thrown if classpath file is over about 2k length.
The problem was solved by correcting an error related to reading the classpath from a file.
The CoreHealthMonitor was holding the ExecuteThreadManager lock while performing significant work, resulting in deadlocks and Administration Console freezes. The code was changed so that CoreHealthMontor now uses ExecuteThreadRuntimeMBean to get a list of stuck threads and avoids logging from all places in the ExecuteThreadManager if ETM lock is held.
Stateful session EJB failover did not work when multiple failovers were required.
In a three node cluster a JSP creates or calls a replica-aware stateful session EJB. The remote EJB stub is stored in the http session. After each call to the stateful session EJB the updated EJB stub is also updated in the HTTPsession to reflect any changes for the EJB replica list (primary/secondary).
The following call sequence with the same browser window leads to a java.rmi.ConnectException when only one node of the cluster survives:
2. Making a call to node1, create EJB and store remote in HTTP session (HTTP session replication is enabled)
4. Make a call to the secondary node2, the EJB remote is retrieved from the replicated HTTP session and the call to the EJB works fine. After this EJB call again the remote is stored in the HTTP session.
WebLogic Server tries to lookup the EJB on node2 and does not try to use node3 (this should now be the new secondary). The following exception is thrown on node3:
java.rmi.ConnectException: Could not establish a connection with -3088833905169218734S:172.23.64.38:[7001,7001,7002,7002 ,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:275)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408) at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:255)
A memory leak occurred when creating a QueueReceiver for each message on a Distributed Queue and persisted even after the QueueReceiver had been shut down.
A code change corrected memory leaks in BasicServiceOffer and DistributedDestinationImpl objects.
The functionality to detect stuck threads in user-configured thread queues was not complete in WebLogic Server 7.0 and its service packs.
Thread queues have been reworked and provisions made to identify an application thread from an internal server thread queue. Logic was added to loop through all application thread queues, checking for stuck threads. All application thread queues will now be monitored by the Core Health Monitoring Thread and proper warnings logged.
User code such as servlet destroy() or ejbRemove() gets executed during shutdown. This fix ensures that lower order services like JMS and JDBC are available when this user code executes.
When nodes in a cluster tried to get session information, they were attempting a lookup from a remote server, hence making a remote call that blocked a thread on the local server. When all nodes were doing the lookup under load, the execute thread queues became blocked and no server was in a position to send a response to the remote call (as all local threads were blocked).
WebLogic Server now creates the stubs locally to avoid a remote call, until the point where it is necessary. When WebLogic Server makes the remote call, it lands on a separate replication queue on the remote server and the process does not block there.
The replication behavior is still unchanged. As a result of this change, WebLogic Server only ensures less contention, avoids a deadlock situation, and reduces the number of remote calls.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp.
WebLogic Server did not collect timer threads during orderly shutdown. This did not result in any observable problems.
Shutting down the ORB now shuts down heartbeat threads. This change should not result in any changed behavior.
ClassCastExceptions were being thrown when a transaction was started in a user thread.
This problem occurred because the parallel XA implementation was using a Kernel method, which was assuming that all requests would be executed on a ExecuteThread, and this method was casting the current thread as an ExecuteThread. When the work ran in a user thread on the server side, the exception would be thrown.
This problem was resolved by allowing the execution to happen on any thread.
|
Manually doing a lookup and then persisting and caching the handle did not work when the methods were conversational. Changes to serialization and deserialization of the |
||
|
When starting WebLogic Server as an Windows service using a classpath from a file, the error
was thrown if classpath file is over about 2k length. The problem was solved by correcting an error related to reading the classpath from a file. |
||
|
The CoreHealthMonitor was holding the ExecuteThreadManager lock while performing significant work, resulting in deadlocks and Administration Console freezes. The code was changed so that CoreHealthMontor now uses ExecuteThreadRuntimeMBean to get a list of stuck threads and avoids logging from all places in the ExecuteThreadManager if ETM lock is held. |
||
|
Stateful session EJB failover did not work when multiple failovers were required. In a three node cluster a JSP creates or calls a replica-aware stateful session EJB. The remote EJB stub is stored in the http session. After each call to the stateful session EJB the updated EJB stub is also updated in the HTTPsession to reflect any changes for the EJB replica list (primary/secondary). The following call sequence with the same browser window leads to a 2. Making a call to node1, create EJB and store remote in HTTP session (HTTP session replication is enabled) 4. Make a call to the secondary node2, the EJB remote is retrieved from the replicated HTTP session and the call to the EJB works fine. After this EJB call again the remote is stored in the HTTP session. WebLogic Server tries to lookup the EJB on node2 and does not try to use node3 (this should now be the new secondary). The following exception is thrown on node3:
|
||
|
A memory leak occurred when creating a A code change corrected memory leaks in |
||
|
The functionality to detect stuck threads in user-configured thread queues was not complete in WebLogic Server 7.0 and its service packs. Thread queues have been reworked and provisions made to identify an application thread from an internal server thread queue. Logic was added to loop through all application thread queues, checking for stuck threads. All application thread queues will now be monitored by the Core Health Monitoring Thread and proper warnings logged. |
||
|
User code such as servlet |
||
|
When nodes in a cluster tried to get session information, they were attempting a lookup from a remote server, hence making a remote call that blocked a thread on the local server. When all nodes were doing the lookup under load, the execute thread queues became blocked and no server was in a position to send a response to the remote call (as all local threads were blocked). WebLogic Server now creates the stubs locally to avoid a remote call, until the point where it is necessary. When WebLogic Server makes the remote call, it lands on a separate replication queue on the remote server and the process does not block there. The replication behavior is still unchanged. As a result of this change, WebLogic Server only ensures less contention, avoids a deadlock situation, and reduces the number of remote calls. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp. |
||
|
WebLogic Server did not collect timer threads during orderly shutdown. This did not result in any observable problems. Shutting down the ORB now shuts down heartbeat threads. This change should not result in any changed behavior. |
||
|
This problem occurred because the parallel XA implementation was using a Kernel method, which was assuming that all requests would be executed on a ExecuteThread, and this method was casting the current thread as an ExecuteThread. When the work ran in a user thread on the server side, the exception would be thrown. This problem was resolved by allowing the execution to happen on any thread. |
Deployment
EJB
For a stateless session bean, when the weblogic-ejb-jar.xml contained:
<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>
and the bean was deployed on a cluster, this error was generated:
<Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.>
This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are not replicated.
Before running a finder method on the BMP beans, the EJB container was not synchronizing the bean state with the database.
BMP entity bean handling has been changed to conform to the EJB 2.0 specification. Per the EJB specification, the EJB container now synchronizes the entity bean state by invoking EJBStore before running a Finder method. This does not affect the findByPrimaryKey.
In a transaction, if a finder method is invoked on a BMP bean, it will now trigger the ejbStore of all modified beans (BMP and CMP beans) participating in the transaction. Thus, BMP beans might get more ejbStore callbacks within a transaction.
The idle-timeout-seconds element determined how long the EJB container waits before passivating stateful session beans, that is, removing them from cache and writing them to disk. The EJB container also used this element to determine how long to wait before removing passivated EJBs from the disk. However, some customers wanted stateful session beans to remain on disk longer than idle-timeout-seconds. They wanted to specify how long stateful session beans stay idle in the cache and how long they stay idle on disk using two different elements.
This enhancement is made possible by introducing the new element session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk.
Dynamic EJB-QL incorrectly passed long arguments as MAX_INT to the underlying SQL, resulting in an unsuccessful search. A code fix resolved the problem.
The container was failing to call unsetEntityContext when the entity bean was undeployed. An undeploy method was added to the BaseEntityManager to clean up the pool when an entity bean is undeployed. This resolved the problem.
Combining COUNT and EXISTS in a dynamic EJB-QL request resulted in invalid SQL and this exception:
[java] javax.ejb.FinderException: Exception in dynamicQuery while preparing or executing statement: 'weblogic.jdbc.rmi.SerialStatement@62b30' [java] java.sql.SQLException: ORA-00937: not a single-group group function [java] [java] java.sql.SQLException: ORA-00937: not a single-group group function
An unnecessary column was being added to the main select list while parsing a subquery. A fix to the parser code solved the problem.
ejbc generated invalid SQL for an ejbSelect query. The query failed because table aliases were generated incorrectly, resulting in this error:
A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated, but whose value did not change, are not written to back to the database. The optimization is only done for primitives and immutable objects.
Column version numbers were not updating correctly with Optimistic concurrency enabled, because blind writes were not checked . The code was changed so that blind writes are checked with Optimistic concurrency.
In some bean-managed stateful session beans, an IllegalStateException occurred with bean-demarcated transactions when the number of bean instances is greater than max-beans-in-cache when the cache is full and activations and passivations occur.
A code change results in the creation of one replacer per passivation request, so that each thread has its own replacer.
It was reported that transaction timeouts on MDBs were not logged. When the time an MDB takes to process a message from a JMS Destination exceeds the transaction timeout limit, the transaction is rolled-back and the message is place backed on the destination for re-delivery, but no transaction-timeout or transaction-rollback messages were logged.
This problem was resolved by a code change to the MDListener code to report the transaction timeouts.
The JDBC driver from Microsoft has a limitation whereby for a given result set of rows and columns, the getXXX method can only be called once per row. This limitation applied only if the query columns included a text or image column. WebLogic Server-generated JDBC obtained the key value from a row—for example, using a getLong(1)—and then passed the result set to another routine that read all the column values, including the first, re-executing a getLong(1). This re-execution caused the Microsoft driver to throw an exception.
The problem is resolved by a code fix that avoids parsing the primary key columns in the resultSet twice.
EJBs with Bean-Managed Persistence and with concurrency set to exclusive called ejbFindByPrimaryKey rather than finding the bean in the cache.
A code change resolved the problem so that the EJB finds the bean in the cache.
ejbc now runs a compliance check that disallows optimistic concurrency for BMP (bean-managed persistence) beans.
Optimistic concurrency is a feature of CMP (container-managed persistence) beans in EJB 2.0. See Choosing a Concurrency Strategy in Programming WebLogic Enterprise JavaBeans.
Getter methods for a EJB 1.1 CMP bean did not call isModified() when delay-updates-until-end-of-tx was set to false.
A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to Required. Each call to a getter method is followed by a call to ejbStore() and delay-updates-until-end-of-tx was false. However, before calling ejbStore on the bean the container did not call the isModified method. The isModified() method was only called when the transaction committed.
ejbStore should be called from postInvoke() depending on the result of the isModified method in the bean. The problem was solved with a code fix.
Optimistic concurrency with a version column did not work in combination with bulk updates. (An "ORA-01008: not all variables bound" SQLException was thrown.)
This problem was resolved by using the correct bean state tracking variable so the EJB container sets all of the variables in the SQL statement, including the version column. Optimistic concurrency with a version column now works in combination with bulk updates.
The EJB QL query generator could not handle:
where target is collection member variable as in:
SELECT OBJECT(target) FROM EJBean AS bean, IN(bean.collection)target
This problem has been fixed. The EJB QL compiler now properly handles this case.
The ROManager was forced to add duplicate entries to its internal LRU list. This resulted in unlimited growth of the list, which lead to OutOfMemoryErrors.
The duplicate entries occurred because of an unnecessary call to the initLastLoad() method in the DBManager method getBeanFromRS(). Removing the unnecessary call fixed the problem.
With a CMR one-to-many relationship, in a single transaction, if the bean on the one side was accessed but not changed, the dependency between the database operations was not resolved properly by the container. This resulted in a java.sql.SQLException.
This problem was resolved by storing the related bean to the database before checking the state of the current bean.
The EJB container automatically detects situations where an EJB has been changed in a possibly incompatible way since it was last compiled. If such a change is detected, the EJB is automatically recompiled. Previously, any change to a deployment descriptor would result in such recompilation. Some changes, however, are guaranteed not to change the EJB, such as adding whitespace to a deployment descriptor. Such a change should not have caused the EJB to be recompiled.
The algorithm used to determine whether an EJB needs to be recompiled now disregards whitespace in deployment descriptors when determining whether the descriptor has changed. Thus, an EJB is not recompiled needlessly when only whitespace is changed in a deployment descriptor.
When using stateful session beans under load with home-is-clusterable set to true and replication-type set to InMemory, the proxy objects on the secondary server that call the bean were not being unexported and were therefore leaking. This resulted in an OutOfMemoryError.
WebLogic Server now unexports the proxy objects on the secondary server. When the Replicated bean receives a becomeUnregistered() callback from the ReplicationService, the corresponding proxy object on the secondary server is unexported in the StatefulEJBHome.removeSecondary() method.
There should not be any negative side-effects on existing user applications.
When a MDB and JMS server were targeted to different Weblogic Server instances, the MDB was not receiving messages.
This problem occurred because the EJB container was not creating the necessary MDB pool, as they are not co-located.
This problem has been fixed. When the MDB's destination is non-distributed and non-migratable, then the co-location rule is not applied.
If an EJB uses container-managed transactions, the EJB specification requires transaction attributes to be set for all EJB methods (excluding methods of EJBObject\EJBLocalObject for session beans and all methods of the home\local-home interface for session beans). Previously, a method not assigned a transaction attribute would use a default value of Supports for interface methods and NotSupported for a message-driven bean's onMessage method. These default values did not result in transactions being started and this caught several customers by surprise.
If any EJB methods are missing a transaction attribute setting, the default transaction attribute is still used for the method. However, a warning is now issued to alert users to the situation. Users can eliminate the warning by setting an explicit transaction attribute for the affected method(s) in the ejb-jar.xml deployment descriptor. Thus, users may now see warnings about missing transaction attribute settings when they run the EJB compiler and during EJB deployment.
For BLOBs, in the generated code, WebLogic Server calls ObjectOutputStream.writeObject and ObjectInputStream.readObject to serialize/deserialize the object before writing/reading it to the database. These calls add extra header information. The writeObject method writes the class of the object, the signature of the class, the values of the non-transient and non-static fields of the class, and all of its supertypes are written. (This is the reason for the extra header seen in the database.) These calls do not cause a problem when customers are using only WebLogic Server to set and get BLOBs, because it uses readObject to convert the bytes into the appropriate object, which needs that extra header information. However, if the BLOB has been inserted directly into the database by some other vendor or programmer using:
OutputStream os = ((weblogic.jdbc.common.OracleBlob) lob).getBinaryOutputStream(); os.write(this.tiffImage); // byte[] tiffImage
then problems may occur because WebLogic Server uses readObject and the header information is missing. For the data inserted using WebLogic Server , the other programs that would read the bytes directly get the extra header information and fail.
<serialize-byte-array-to-oracle-blob> has been added to control the persistence behavior. This element is used to specify whether a cmp-field of type byte[] mapped to an OracleBlob should be serialized. The tag has been added to a new compatibility stanza in the weblogic-cmp-rdbms descriptor.
Note that, in versions prior to SP2, the default behavior was to serialize a cmp-field of type byte[] mapped to an OracleBlob. Now, the byte[] is written directly to the OutputStream obtained from the BLOB. To revert to the old behavior, set the value of this tag to true.
Use of the XA driver meant there was no guarantee that WebLogic Server obtained the same connection from the DataSource even when in the same transaction. The Insert was made using one connection and then queried with SELECT SCOPE_IDENTITY using another connection. The SCOPE_IDENTITY produced incorrect results in this case.
The auto-key-gen feature for SQLServer2000 required SELECT SCOPE_IDENTITY() to get the value of the auto-gen key.
The SCOPE_IDENTITY function can now used in the same scope (that is, in the same stored procedure, function, or batch). The code generation was changed to perform a batched query when the database is SQLServer or SQLServer2000 and AutoKeyGen is turned on. The GenKeyQuery will be fired immediately after the INSERT as follows:
__WL_query_array[0] = "INSERT INTO Employees (LastName, FirstName, Title, TitleOfCourtesy, BirthDate, HireDate, Address, City, Region, PostalCode, Country, HomePhone, Extension, Photo, Notes, ReportsTo, PhotoPath) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) SELECT SCOPE_IDENTITY()";
and the cmp-field will be assigned the auto generated key value.
This change has no impact or side-effects other than resolving the problem of an incorrect primary key being returned when using SQLServer2000 with AutoKeyGen with a XA driver.
The code to expand the size of the thread pool used for message-driven bean polling was failing due to a change in the "Kernel" APIs.
The code for the MDB container was fixed to properly use the kernel APIs. Customers will now be able to deploy more than one MDB that receives messages from a foreign JMS provider with XA and have each MDB successfully receive messages.
The JMSConnectionPoller did not know the identity of the user that it needed to pass to the WebLogic Security Framework to get the remote username and password. This remote username and password is required for establishing a JMS connection with the remote JMS Server (MQ, WebLogic, and so on).
This fix resolves the problem, but customers need to configure a security identity for an MDB. For instructions on how to do this, see Configuring a Security Identity for Message-Driven Beans in Programming WebLogic Enterprise JavaBeans.
When the AutoKey was specified in the cmp-rdbms.xml file as follows:
<automatic-key-generation>
<generator-type>ORACLE</generator-type>
<generator-name>scott.oracle_sequence</generator-name>
<key-cache-size>10</key-cache-size>
</automatic-key-generation>
(that is, the generator name is schemaName.sequenceName) WebLogic Server was not taking the schema name into account while performing the query to select the increment value.
The schema name provided in the <generator-name> is now taken into account, and the queries are generated as follows:
If the users specify the <generator-name> as schemaName.sequenceName in the weblogic-cmp-rdbms-jar.xml, WebLogic Server generates the following query to read the INCREMENT_BY:
query = "SELECT INCREMENT_BY "+
"FROM ALL_SEQUENCES "+
"WHERE SEQUENCE_NAME = UPPER('"+sequenceName+"') " + "
AND SEQUENCE_OWNER = UPPER('"+schemaName+"')";
If users specify the <generator-name> without the schema, the query will be:
query = "SELECT INCREMENT_BY "+
"FROM USER_SEQUENCES "+
"WHERE SEQUENCE_NAME = UPPER('"+sequenceName+"')";
In the second query, WebLogic Server makes use of the USER_SEQUENCES view instead of ALL_SEQUENCES. This takes care of the case where two or more users have declared a sequence with the same name. A query to the USER_SEQUENCES view restricts the ResultSet to the user view with a connection to Oracle.
The setBytes() method on the preparedStatement had issues when the byte[] data was greater than 4K.
This problem was resolved by replacing the setBinaryStream() method with the setBytes() method. As a result, the cmp11 generated code has changed. Customers wanting to take advantage of this fix will have to rerun ejbc on their EJBs to generate the new code. Otherwise, this change will not have any impact.
The EJB container code was not expecting the "Adaptive Server Enterprise" string as the correct database product name for the Sybase database. It was expecting the "Sybase" string in the product name.
Because the WebLogic Sybase JDBC driver sends the database product name as "Adaptive Server Enterprise," this string is now considered in the database type verification code of the cmp descriptors.
An extra AND was appended for ANSI compliant LEFT OUTER JOIN for the following databases: SqlServer2000, Pointbase and DB2.
The code was modified not to append AND while generating ANSI compliant LEFT OUTER JOIN for these databases. No side-effects should result from fixing this problem.
The EJB was correctly failing to deploy because the database table it depended on did not exist. The EJB was configured so the table would be automatically created during deployment if it did not exist. However, the server was in production mode and the auto table creation feature is only supported when the server is in development mode, so the table was not created by the EJB container. There was a problem in that the EJB container was not communicating this information properly to customers.
A message was added, explaining auto table creation settings will be disregarded when the server is in production mode. In addition, each Managed Server now logs when an EJB deployment fails because of a missing database table.
The wls510-read.xpi was not setting the PersistenceMBean.setFindersLoadBean() when the <finders-call-ejbload> element was encountered in the 5.1 weblogic-ejb-jar.xml deployment descriptor.
When the <finders-call-ejbload> element is encountered in the 5.1 weblogic-ejb-jar.xml deployment descriptor, WebLogic Server now sets it on the PersistenceMBean.
<processing-action element="finders-call-ejbload" element-context="persistence-descriptor">
<validation nullable="false"
values="true|True|false|False"/>
<java>
if(bd.isEntity()) {
bd.getPersistence().setFindersLoadBean(
"True".equalsIgnoreCase( @VALUE{} )); }
</java>
</processing-action>
The documentation for the procedure "Configure a Security Identity for a Message-Driven Bean" was missing some steps. This has been corrected, and the updated documentation can be found at http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ejb/message_beans.html#ConfiguringaSecurityIdentityforaMessage-DrivenBean.
|
For a stateless session bean, when the
and the bean was deployed on a cluster, this error was generated:
This problem was resolved by a code fix to ensure that JNDI bindings for non-clustered stubs are not replicated. |
||
|
Before running a finder method on the BMP beans, the EJB container was not synchronizing the bean state with the database. BMP entity bean handling has been changed to conform to the EJB 2.0 specification. Per the EJB specification, the EJB container now synchronizes the entity bean state by invoking In a transaction, if a finder method is invoked on a BMP bean, it will now trigger the |
||
|
The This enhancement is made possible by introducing the new element |
||
|
Dynamic EJB-QL incorrectly passed long arguments as |
||
|
The container was failing to call |
||
|
Combining COUNT and EXISTS in a dynamic EJB-QL request resulted in invalid SQL and this exception:
An unnecessary column was being added to the main select list while parsing a subquery. A fix to the parser code solved the problem. |
||
|
ejbc generated invalid SQL for an |
||
|
A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated, but whose value did not change, are not written to back to the database. The optimization is only done for primitives and immutable objects. |
||
|
Column version numbers were not updating correctly with Optimistic concurrency enabled, because blind writes were not checked . The code was changed so that blind writes are checked with Optimistic concurrency. |
||
|
In some bean-managed stateful session beans, an A code change results in the creation of one replacer per passivation request, so that each thread has its own replacer. |
||
|
It was reported that transaction timeouts on MDBs were not logged. When the time an MDB takes to process a message from a JMS Destination exceeds the transaction timeout limit, the transaction is rolled-back and the message is place backed on the destination for re-delivery, but no transaction-timeout or transaction-rollback messages were logged. This problem was resolved by a code change to the MDListener code to report the transaction timeouts. |
||
|
The JDBC driver from Microsoft has a limitation whereby for a given result set of rows and columns, the getXXX method can only be called once per row. This limitation applied only if the query columns included a text or image column. WebLogic Server-generated JDBC obtained the key value from a row—for example, using a getLong(1)—and then passed the result set to another routine that read all the column values, including the first, re-executing a getLong(1). This re-execution caused the Microsoft driver to throw an exception. The problem is resolved by a code fix that avoids parsing the primary key columns in the resultSet twice. |
||
|
EJBs with Bean-Managed Persistence and with concurrency set to exclusive called A code change resolved the problem so that the EJB finds the bean in the cache. |
||
|
ejbc now runs a compliance check that disallows optimistic concurrency for BMP (bean-managed persistence) beans. Optimistic concurrency is a feature of CMP (container-managed persistence) beans in EJB 2.0. See Choosing a Concurrency Strategy in Programming WebLogic Enterprise JavaBeans. |
||
|
Getter methods for a EJB 1.1 CMP bean did not call A session EJB called an entity EJB's getter methods. Both EJBs had container managed transaction with transaction attribute set to
|
||
|
Optimistic concurrency with a version column did not work in combination with bulk updates. (An "ORA-01008: not all variables bound" SQLException was thrown.) This problem was resolved by using the correct bean state tracking variable so the EJB container sets all of the variables in the SQL statement, including the version column. Optimistic concurrency with a version column now works in combination with bulk updates. |
||
|
The EJB QL query generator could not handle: where target is collection member variable as in:
This problem has been fixed. The EJB QL compiler now properly handles this case. |
||
|
The The duplicate entries occurred because of an unnecessary call to the |
||
|
With a CMR one-to-many relationship, in a single transaction, if the bean on the one side was accessed but not changed, the dependency between the database operations was not resolved properly by the container. This resulted in a java.sql.SQLException. This problem was resolved by storing the related bean to the database before checking the state of the current bean. |
||
|
The EJB container automatically detects situations where an EJB has been changed in a possibly incompatible way since it was last compiled. If such a change is detected, the EJB is automatically recompiled. Previously, any change to a deployment descriptor would result in such recompilation. Some changes, however, are guaranteed not to change the EJB, such as adding whitespace to a deployment descriptor. Such a change should not have caused the EJB to be recompiled. The algorithm used to determine whether an EJB needs to be recompiled now disregards whitespace in deployment descriptors when determining whether the descriptor has changed. Thus, an EJB is not recompiled needlessly when only whitespace is changed in a deployment descriptor. |
||
|
When using stateful session beans under load with WebLogic Server now unexports the proxy objects on the secondary server. When the Replicated bean receives a There should not be any negative side-effects on existing user applications. |
||
|
When a MDB and JMS server were targeted to different Weblogic Server instances, the MDB was not receiving messages. This problem occurred because the EJB container was not creating the necessary MDB pool, as they are not co-located. This problem has been fixed. When the MDB's destination is non-distributed and non-migratable, then the co-location rule is not applied. |
||
|
If an EJB uses container-managed transactions, the EJB specification requires transaction attributes to be set for all EJB methods (excluding methods of If any EJB methods are missing a transaction attribute setting, the default transaction attribute is still used for the method. However, a warning is now issued to alert users to the situation. Users can eliminate the warning by setting an explicit transaction attribute for the affected method(s) in the |
||
|
For BLOBs, in the generated code, WebLogic Server calls
then problems may occur because WebLogic Server uses
Note that, in versions prior to SP2, the default behavior was to serialize a |
||
|
Use of the XA driver meant there was no guarantee that WebLogic Server obtained the same connection from the DataSource even when in the same transaction. The Insert was made using one connection and then queried with SELECT SCOPE_IDENTITY using another connection. The SCOPE_IDENTITY produced incorrect results in this case. The auto-key-gen feature for SQLServer2000 required SELECT SCOPE_IDENTITY() to get the value of the auto-gen key. The SCOPE_IDENTITY function can now used in the same scope (that is, in the same stored procedure, function, or batch). The code generation was changed to perform a batched query when the database is SQLServer or SQLServer2000 and AutoKeyGen is turned on. The GenKeyQuery will be fired immediately after the INSERT as follows:
and the cmp-field will be assigned the auto generated key value. This change has no impact or side-effects other than resolving the problem of an incorrect primary key being returned when using SQLServer2000 with AutoKeyGen with a XA driver. |
||
|
The code to expand the size of the thread pool used for message-driven bean polling was failing due to a change in the "Kernel" APIs. The code for the MDB container was fixed to properly use the kernel APIs. Customers will now be able to deploy more than one MDB that receives messages from a foreign JMS provider with XA and have each MDB successfully receive messages. |
||
|
The This fix resolves the problem, but customers need to configure a security identity for an MDB. For instructions on how to do this, see Configuring a Security Identity for Message-Driven Beans in Programming WebLogic Enterprise JavaBeans. |
||
|
When the AutoKey was specified in the
(that is, the generator name is The schema name provided in the If the users specify the
If users specify the
In the second query, WebLogic Server makes use of the |
||
|
The This problem was resolved by replacing the |
||
|
The EJB container code was not expecting the "Adaptive Server Enterprise" string as the correct database product name for the Sybase database. It was expecting the "Sybase" string in the product name. Because the WebLogic Sybase JDBC driver sends the database product name as "Adaptive Server Enterprise," this string is now considered in the database type verification code of the cmp descriptors. |
||
|
An extra AND was appended for ANSI compliant LEFT OUTER JOIN for the following databases: SqlServer2000, Pointbase and DB2. The code was modified not to append AND while generating ANSI compliant LEFT OUTER JOIN for these databases. No side-effects should result from fixing this problem. |
||
|
The EJB was correctly failing to deploy because the database table it depended on did not exist. The EJB was configured so the table would be automatically created during deployment if it did not exist. However, the server was in production mode and the auto table creation feature is only supported when the server is in development mode, so the table was not created by the EJB container. There was a problem in that the EJB container was not communicating this information properly to customers. A message was added, explaining auto table creation settings will be disregarded when the server is in production mode. In addition, each Managed Server now logs when an EJB deployment fails because of a missing database table. |
||
|
The When the
|
||
|
The documentation for the procedure "Configure a Security Identity for a Message-Driven Bean" was missing some steps. This has been corrected, and the updated documentation can be found at http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ejb/message_beans.html#ConfiguringaSecurityIdentityforaMessage-DrivenBean. |
Installation
J2EE
JCOM
JDBC
WebLogic Server now provides support for Oracle Virtual Private Databases (VPDs). A VPD is an aggregation of server-enforced, application-defined fine-grained access control, combined with a secure application context in the Oracle 9i database server.
For more information, see Programming with Oracle Virtual Private Databases in Programming WebLogic JDBC.
WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a java.sql.SQLException when retrieving double or float values if a comma (\Q,') was used as a decimal separator in the database:
java.sql.SQLException: java.lang.NumberFormatException - '1,2'
at weblogic.jdbc.oci.ResultSet.getFloat(ResultSet.java:312)
at weblogic.jdbc.jta.ResultSet.getFloat(ResultSet.java:190)
at
weblogic.jdbc.rmi.internal.ResultSetImpl.getFloat(ResultSetImpl.java:224)
at
weblogic.jdbc.rmi.internal.ResultSetStraightReader.getFloat(ResultSetStraightReader.java:67)
at
weblogic.jdbc.rmi.SerialResultSet.getFloat(SerialResultSet.java:219)
at examples.servlets.DBAccess.service(DBAccess.java:54)
at
[...]
The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix.
The WebLogic Server jDriver for MS SQLServer can mistakenly accept the jdbc:microsoft:... URL for the Microsoft JDBC driver. If a JVM tries to use both drivers, loading the WebLogic Server driver first prevents the Microsoft driver from being used.
OciObjectStream did not nullify a buffer after a close() was performed.
Using LDAP with SSL caused a NullPointerException.
This problem occurred because the MuxableSocketLDAP registered itself directly (instead of the SSLFilter for itself) with the socket muxer. Thus, when SSL was used, it was not accessing the right muxable socket instance.
This problem was resolved by a change the MuxableSocketLDAP code, so that it registers the SSLFilter with the socket muxer.
A transactional (JTS) JDBC connection could falsely return true for the isClosed() method in a remote application.
The cause of the problem was an unnecessary and failure-prone delegation of the isClosed() call to the remote connection rather than simply reporting the already-known state of the RMI connection.
The RMI connection object was modified to return the known state. User code now works as expected with isClosed().
When a JNDI lookup on a JDBC DataSource and then a ds.getConnection was performed in applet code, a Security Exception that indicated there was no privilege to generate code in the applet would be thrown.
JDBCWrapperFactory now detects whether the lookup is performed within the applet JVM. If it is, rather than generating a JDBC RMI wrapper class in the applet JVM, a request will be sent to ClasspathServlet. ClasspathServlet will generate the JDBC RMI wrapper classes on the server side, then ship them back to the applet. Applets do not work with JDBC RMI without this fix.
WebLogic Server's Oracle jDriver now understands the non-standard Oracle CURSOR output parameter type, whose numerical value is -10. Customers wanting to use WebLogic Server's Oracle jDriver to accommodate a WebLogic extension will no longer get exceptions.
During EJB deployment time, certain validations are done to verify the table, check if connection pools exist or not, and so on. If any of these validations fail, a DeploymentException is thrown. In this case, the DeploymentException was being thrown because the TableVerifier.checkPool() method returned false.
This problem occurred because in weblogic.jdbc.common.internal.ConnectionPoolManager.poolExists() method, WebLogic Server only checked whether the pool (used by the EJB) existed in the list of available connection pools, and failed to do the same for the list of MultiPools.
For the pool associated with the DataSource for the CMP EJB, WebLogic Server now checks that the pool exists in both the connection pool list and the MultiPool list. As a result, customers can use a DataSource mapped to a multipool inside a CMP EJB.
Many of the Sybase JDBC driver's metadata methods, including getAutoCommit(), interacted with the DBMS in a way that caused the DBMS to think a transaction had been started. This precluded any further changes to transaction properties. For example, the following valid JDBC code caused an application to receive an exception stating: `can't call set CHAINED within a transaction':
Connection c = ... // get fresh connection
c.setAutCommit(false); // set connection for future multistatement tx's
// Now test connection (like after a tx) Change back to default mode if needed
if (c.getAutoCommit()) c.setAutoCommit(true); // fails here
Code that is enacted (only) when the initial call to setAutoCommit(true) fails has been added. In this case, WebLogic Server rolls back the transaction and retries the setAutoCommit(). BEA has worked with Sybase to improve their driver, and as of this writing, the latest EBFs of the Sybase driver should include changes that will also fix this problem.
When running WebLogic Server with the WebLogic Sybase XA JDBC driver, attempts to create a table after suspending the current transaction and starting a new transaction failed, but no exception was thrown.
This problem occurred because of cleanup processing WebLogic Server does inside the JDBC layer. When application code calls commit(), WebLogic Server internally checks the Auto Commit setting for the connection. When running with Sybase XA, WebLogic Server needs to call a rollback() because the getAutoCommit() call starts a local transaction. This rollback() also causes the SQL DDL call to create the table to be rolled back. Thus, the table will appear to not have been created.
This problem was resolved by removing the call to rollback() after calls to get/setAutoCommit and get/setTransactionIsolation for the Sybase XA driver. Application code now gets the correct results.
A server thread dump showed a deadlock with one thread calling JTSConnection.doClose(), which was blocked in this method.
This problem occurred because doClose() had a block synchronized on the JTSConnection with the purpose of ensuring only one thread went into the block at a time. Unfortunately, any other thread running any other synchronized JTSConnection method would stop a thread getting this doClose() block.
A private locking object for the doClose() block was provided. As a result of this fix, there will be no detectable change in behavior, except for fortunate cases where a deadlock is averted and normal function proceeds.
Oracle-related JDBC operations hung when the ResourcePool maintenance thread locked the resource pool and attempted to obtain a connection that was being held by other threads.
This problem occurred because doClose() had a block synchronized on the JTSConnection with the purpose of ensuring only one thread went into the block at a time. Unfortunately, any other thread running any other synchronized JTSConnection method would stop a thread getting this doClose() block.
A private locking object for the doClose() block was provided. As a result of this fix, there will be no detectable change in behavior, except for fortunate cases where a deadlock is averted and normal function proceeds.
Oracle OCI NativeXA does not allow a connection to be used by threads other than the one where it is created. The WebLogic Server connection pooling algorithm assumed that a connection could be used by any thread, as this is the behavior of all other JDBC drivers (including the Oracle Thin Driver). Customers who used Oracle OCI NativeXA with this connection pooling algorithm received an XAException.
This problem was resolved by pinning the connection to the thread. As a result of this fix, every thread now has its own connection for every connection pool.
Applications with stringent RASP and HA requirements require Pools to be capable of gracefully recovering from failure conditions such as failure of the database server, the machine hosting the database server, network connectivity to the machine hosting the database server, and so on. The above requires applications to put upper bounds on:
and require support from the JDBC driver; the BEA WebLogic Type 4 JDBC drivers now provide this support. Item 1 is configurable by simply setting the corresponding driver property in the connection pool definition. Item 2 requires support from WebLogic Server and is exposed via the following pool attributes:
testStatementTimeout—the time after which the test statement query (specified by applications using the pool attribute TestTableName) currently being executed will be timed-out. The default value implies that this feature is disabled.
statementTimeout—the time after which a statement currently being executed will be timed-out. The default value implies that this feature is disabled.
For more information about the BEA WebLogic Type 4 JDBC drivers, see WebLogic Type 4 JDBC Drivers.
|
WebLogic Server now provides support for Oracle Virtual Private Databases (VPDs). A VPD is an aggregation of server-enforced, application-defined fine-grained access control, combined with a secure application context in the Oracle 9i database server. For more information, see Programming with Oracle Virtual Private Databases in Programming WebLogic JDBC. |
||
|
WebLogic jDriver for Oracle/XA did not properly handle the NLS_NUMERIC_CHARACTERS parameter set by an Oracle RDBMS instance. This caused a
The problem did not occur with the non-XA version of WebLogic jDriver for Oracle. This problem was solved with a code fix. |
||
|
The WebLogic Server jDriver for MS SQLServer can mistakenly accept the |
||
|
|
||
|
Using LDAP with SSL caused a This problem occurred because the MuxableSocketLDAP registered itself directly (instead of the SSLFilter for itself) with the socket muxer. Thus, when SSL was used, it was not accessing the right muxable socket instance. This problem was resolved by a change the MuxableSocketLDAP code, so that it registers the SSLFilter with the socket muxer. |
||
|
A transactional (JTS) JDBC connection could falsely return true for the The cause of the problem was an unnecessary and failure-prone delegation of the The RMI connection object was modified to return the known state. User code now works as expected with |
||
|
When a JNDI lookup on a JDBC DataSource and then a
|
||
|
WebLogic Server's Oracle jDriver now understands the non-standard Oracle CURSOR output parameter type, whose numerical value is -10. Customers wanting to use WebLogic Server's Oracle jDriver to accommodate a WebLogic extension will no longer get exceptions. |
||
|
During EJB deployment time, certain validations are done to verify the table, check if connection pools exist or not, and so on. If any of these validations fail, a This problem occurred because in For the pool associated with the DataSource for the CMP EJB, WebLogic Server now checks that the pool exists in both the connection pool list and the MultiPool list. As a result, customers can use a DataSource mapped to a multipool inside a CMP EJB. |
||
|
Many of the Sybase JDBC driver's metadata methods, including
Code that is enacted (only) when the initial call to |
||
|
When running WebLogic Server with the WebLogic Sybase XA JDBC driver, attempts to create a table after suspending the current transaction and starting a new transaction failed, but no exception was thrown. This problem occurred because of cleanup processing WebLogic Server does inside the JDBC layer. When application code calls This problem was resolved by removing the call to |
||
|
A server thread dump showed a deadlock with one thread calling This problem occurred because A private locking object for the |
||
|
Oracle-related JDBC operations hung when the This problem occurred because A private locking object for the |
||
|
Oracle OCI NativeXA does not allow a connection to be used by threads other than the one where it is created. The WebLogic Server connection pooling algorithm assumed that a connection could be used by any thread, as this is the behavior of all other JDBC drivers (including the Oracle Thin Driver). Customers who used Oracle OCI NativeXA with this connection pooling algorithm received an This problem was resolved by pinning the connection to the thread. As a result of this fix, every thread now has its own connection for every connection pool. |
||
|
Applications with stringent RASP and HA requirements require Pools to be capable of gracefully recovering from failure conditions such as failure of the database server, the machine hosting the database server, network connectivity to the machine hosting the database server, and so on. The above requires applications to put upper bounds on: and require support from the JDBC driver; the BEA WebLogic Type 4 JDBC drivers now provide this support. Item 1 is configurable by simply setting the corresponding driver property in the connection pool definition. Item 2 requires support from WebLogic Server and is exposed via the following pool attributes:
For more information about the BEA WebLogic Type 4 JDBC drivers, see WebLogic Type 4 JDBC Drivers. |
JMS
JNDI
JTA
Node Manager
Many parts of WebLogic Server encrypt credentials using a salt. When attempting to reuse the same file with a different salt, a "bad padding exception" (because of a salt mismatch) occurred. This exception was thrown when WebLogic Server was not able to decrypt the password written in a previous incarnation.
WebLogic Server now catches this exception and prints a message stating the problem and the corrective action one should take.
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.
Attempts to start multiple WebLogic Server instances using Node Manager on slower hardware produced the following error:
<Jun 25, 2003 5:16:15 PM CDT> <Error> <NodeManager@192.168.190.4:5555> <__COMMAND_EXCEPTION__Request: failed to execute command 'online' on server 'ifgw1catapp4 - reason: '[JavaProcessControlOnline: Could not get valid pid for WebLogic process.]'>
This problem occurred because Node Manager looked for the PID file before there had been a chance to write to that file.
A new property allows users to specify how many times Node Manager will retry reading the PID from the file. Every retry will have a 2 second wait. The property introduced is PIDFileReadRetryCount, which can be specified as a system property or in the nodemanager.properties file. When the value of PIDFileReadRetryCount is greater than zero, Node Manager attempts PIDFileReadRetryCount number of times before giving up on reading the PID from the file. The default value of PIDFileReadRetryCount is zero, so there is no change in default behavior.
If debug was turned on, the password for starting the Managed Server was being printed in plain text in the Node Manager logs.
The password is no longer printed in the logs even if debug is turned on.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp.
|
Many parts of WebLogic Server encrypt credentials using a salt. When attempting to reuse the same file with a different salt, a "bad padding exception" (because of a salt mismatch) occurred. This exception was thrown when WebLogic Server was not able to decrypt the password written in a previous incarnation. WebLogic Server now catches this exception and prints a message stating the problem and the corrective action one should take. |
||
|
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. |
||
|
Attempts to start multiple WebLogic Server instances using Node Manager on slower hardware produced the following error:
This problem occurred because Node Manager looked for the PID file before there had been a chance to write to that file. A new property allows users to specify how many times Node Manager will retry reading the PID from the file. Every retry will have a 2 second wait. The property introduced is |
||
|
If debug was turned on, the password for starting the Managed Server was being printed in plain text in the Node Manager logs. The password is no longer printed in the logs even if debug is turned on. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. |
Plug-Ins
[Apache] In WebLogic Server 6.1 SP03, PathTrim and PathPrepend added an unexpected "/" at the end of URL. After PathTrim was applied to the original URL and it results to '/', an extra '/' was appended to the PathPrepend variable.
(NSAPI) Plug-in did not read the SESSIONID from post data.
Analysis revealed a problem in getPreferredServersFromCookie(). When session.getId() was kept as post data, getId() included an extra string: |time.
(Apache) the Apache plug-in did not read PathPrepend when using <IfModule mod_weblogic.c>. The problem occurred with plug-ins for Apache 1.3.x and Apache 2.0.43.
(NSAPI) A thread in the plug-in could obtain a critical lock for a long duration (5 minutes by default, or configured using WLIOTimeoutSecs), blocking all other threads and making WebLogic Server appear to hang. This problem was fixed with a code change to the plug-in.
(Apache) Because Hewlett-Packard ceased to support the HP Apache-based Web Server version 1.3.x, WebLogic Server removed the Apache 1.3 plug-in for HP.
(ISAPI) The ISAPI plug-in logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line:
The HTTP Server encountered an unhandled exception while processing the ISAPI Application.
This problem was solved with a code fix to the ISAPI plug-in.
(NSAPI) The plug-in that shipped with WebLogic Server used the WL-Proxy-Client-IP header to send client IP addresses. This caused problems in heterogeneous environments, because earlier servers expected the plug-in to use the X-Forwarded-For and Proxy-Client-IP headers to transmit client IP addresses.
The code was fixed to include both the X-Forwarded-For and Proxy-Client-IP headers, as well as WL-Proxy-Client-IP, so that heterogeneous environments can retrieve client addresses without modification.
(Apache) The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (*/?). This could cause 404 errors to occur when using parameters such as:
LocationMatch "/weblogic/(abc|def)/ghi"
(Apache) Not passing back the status from the Java command made it impossible to tell if the command executed successfully or not.
The line: if errorlevel 1 exit /b 1 was added after the two Java commands in the ant.bat file. Therefore, the status of the Java commands are now passed back to the shell if they fail.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp.
(All) As of WebLogic Server 6.1 SP6, 7.0 SP5, and 8.1 SP2, the WebLogic plug-ins are now certified to proxy to any version of WebLogic, including 5.1.
|
[Apache] In WebLogic Server 6.1 SP03, PathTrim and PathPrepend added an unexpected "/" at the end of URL. After PathTrim was applied to the original URL and it results to '/', an extra '/' was appended to the PathPrepend variable. |
||
|
(NSAPI) Plug-in did not read the Analysis revealed a problem in |
||
|
(Apache) the Apache plug-in did not read |
||
|
(NSAPI) A thread in the plug-in could obtain a critical lock for a long duration (5 minutes by default, or configured using |
||
|
(Apache) Because Hewlett-Packard ceased to support the HP Apache-based Web Server version 1.3.x, WebLogic Server removed the Apache 1.3 plug-in for HP. |
||
|
(ISAPI) The ISAPI plug-in logged an unhandled exception error in the Windows event log when it encountered a modified cookie. The event text began with the line:
This problem was solved with a code fix to the ISAPI plug-in. |
||
|
(NSAPI) The plug-in that shipped with WebLogic Server used the The code was fixed to include both the |
||
|
(Apache) The plug-in ignored configuration parameters that contained regular expressions other than wildcard characters (
|
||
|
(Apache) Not passing back the status from the Java command made it impossible to tell if the command executed successfully or not. The line: |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp. |
||
|
(All) As of WebLogic Server 6.1 SP6, 7.0 SP5, and 8.1 SP2, the WebLogic plug-ins are now certified to proxy to any version of WebLogic, including 5.1. |
RMI/RMI-IIOP
Security
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.
The default value for backup minutes is now correctly calculated and reported under domain > Domain Wide Security Settings -> Embedded LDAP in the Administration Console.
Construction of an AuthenticationProvider was not recognizing errors, because WebLogic MBeanMaker was not seeing exceptions thrown by the AuthenticationMBI class constructor.
The problem was resolved by a code change ensuring the propagation of errors.
The weblogic.security.acl.SSLUserInfo.getCertificates() method was not added to the SSLUserInfo class for WebLogic Server 8.1 or 8.1 SP1, even though it was added for 7.0 SP2.
The getCertificates() method has been added to SSLUserInfo for 8.1 SP2.
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.
SSL initialization failed with a Not listening for SSL, java.io.IOException: Inconsistent security configuration, null error. This occurred when the parsing of the server certificate resulted in a null modulus & exponent.
RSAKey.toString() did not check for a null value, and was therefore trying to call the toString() method of its null member variables. This caused the method to fail with a NullPointerException.
A modification to the toString() method to check for null values fixed this problem.
The WebLogic Server Administration Console hung while attempting to list the users and groups in an Active Directory.
This problem occurred because the connection was hanging with LDAP results, causing a problem in iterating those results.
The code was modified to release the connection with search results and was upgraded to new Netscape open source API. As a result of this change, the listing of users and groups in the Administration Console no longer hangs.
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 security policies on Web applications.
If you created a user that contained special characters such as "&", "(", ")", or "*" , then the user would be created in the Embedded LDAP server, but an error message would be displayed. For example, if you created a user with name myuser&(, then the following error message would be displayed:
weblogic.management.utils.NotFoundException: User or Group myuser&(
The user myuser&( would be added to the Embedded LDAP server, but from then on, no users would be displayed in the console.
This problem was resolved by ensuring that special characters are escaped when retrieving the users from the Embedded LDAP server. This allows the user names with special characters to be created and displayed correctly. User names with special characters can now be successfully created and displayed by the console.
Clients sending a request to a WebLogic Server instance were not able to parse the returned SOAP response.
This problem occurred because WebLogic Server was using a static variable to hold the prefix that the runtime uses for the SOAP envelope.
The output stream now picks up the prefix for the SOAP namespace from the stream. WebLogic Server looks for the namespace currently in use by the SOAP stack. There is also a SecureSoapOutputStream constructor that allows customers to specify a preferred SOAP envelope namespace.
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.
The Node Manager properties file is always created in the <saved logs dir>/NodeManagerInternal directory. Some customers periodically archive and delete the contents of NodeManagerInternal. This removes the Node Manager properties file, so that the certificate password stored in the Node Manager properties file cannot be decrypted, and Node Manager will not work correctly.
The problem was solved by a code change to create the Node Manager properties file in the directory specified by user.dir, if the file is not found in NodeManagerInternal, or in the user.dir directory.
When using webserviceclient.jar and ssl.jar in a standalone client application, the entire SOAP envelope was being written to stdout for every call. Attempts to disable verbose mode on the command-line and programmatically did not resolve the problem.
This problem occurred because HttpUrlConnection was printing out the unnecessary log. This logging has been deleted, so HttpURLConnection no longer shows post data on the system.out.
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.
The MedRec sample application has been enhanced to support identity assertion in the LoginModule.
Performance regressed from WebLogic Server 7.0 when using SSL Web Services because socket pooling was disabled.
In WebLogic Server 7.0, SSLSockets were pooled in the Web Service runtime, in the thread safe socket pool that is a singleton shared across all invocations in the VM. In cases where SSL Client Authentication is used, this may lead to a problem: If there are multiple clients invoking the service within the application with different identities, the second client will possibly get the SSL Socket from the first client—this connection on this socket carries the first client identity. This is potentially a severe problem when using the client in a server setting—a transaction may occur while authenticated under the wrong identity, and this may lead to unprivileged users executing privileged actions.
The shared socket pool has been replaced with a single socket that is shared only for a single client in the HTTPS binding. The socket sharing is disabled by default, however it can be enabled using either the system property or the new API provided.
The default operational characteristics out of the box remain the same as WebLogic Server 8.1, with socket sharing disabled. Turning this feature on allows multiple serial invocations to share the same socket, but has the following properties that users must understand and accept:
The Web Service generated client stubs are thread safe. When this socket sharing feature is enabled the client is no longer thread safe, therefore users must manage access of the client by multiple threads.
The client has security properties (such as client certs and sharing sockets) that require careful thought. Additionally, users will also be tying up JVM resources, and are responsible for closing the socket.
Socket sharing is "false" by default. Socket sharing is enabled using the following system property (boolean): https.sharedsocket. Socket sharing can also be enabled using the following API (referenced in weblogic.webservice.binding.https.HttpsBindingInfo) setSocketSharing(boolean value). Socket sharing carries a timeout value based in seconds. This value can be set using the following system property: https.sharedsocket.timeout. Socket sharing timeout is defaulted to 15 seconds. Socket sharing timeout can also be set by using the following API: setSharedSocketTimeout(long value) where value is in seconds. The shared socket can also be closed using void closeSharedSocket().
Please review the security advisory information at http://dev2dev/resourcelibrary/advisoriesnotifications/BEA03_43.00.jsp.
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp.
WebLogic Server Version 8.1 uses the SUN JDK 1.4 which does not support RSA keys larger than 2048 bits. Therefore, certificates with 4096 bit keys can not be used.
|
After creating a domain with one Administration Server and one Managed Server, enabling the This problem was resolved by updates to the |
||
|
The default value for backup minutes is now correctly calculated and reported under domain > Domain Wide Security Settings -> Embedded LDAP in the Administration Console. |
||
|
Construction of an The problem was resolved by a code change ensuring the propagation of errors. |
||
|
The The |
||
|
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. |
||
|
SSL initialization failed with a
A modification to the |
||
|
The WebLogic Server Administration Console hung while attempting to list the users and groups in an Active Directory. This problem occurred because the connection was hanging with LDAP results, causing a problem in iterating those results. The code was modified to release the connection with search results and was upgraded to new Netscape open source API. As a result of this change, the listing of users and groups in the Administration Console no longer hangs. |
||
|
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 security policies on Web applications. |
||
|
If you created a user that contained special characters such as "
The user This problem was resolved by ensuring that special characters are escaped when retrieving the users from the Embedded LDAP server. This allows the user names with special characters to be created and displayed correctly. User names with special characters can now be successfully created and displayed by the console. |
||
|
Clients sending a request to a WebLogic Server instance were not able to parse the returned SOAP response. This problem occurred because WebLogic Server was using a static variable to hold the prefix that the runtime uses for the SOAP envelope. The output stream now picks up the prefix for the SOAP namespace from the stream. WebLogic Server looks for the namespace currently in use by the SOAP stack. There is also a SecureSoapOutputStream constructor that allows customers to specify a preferred SOAP envelope namespace. |
||
|
The identity assertion naming convention ( Filtering these headers as identity assertion headers avoided a Client-Cert identity assertion error. |
||
|
The Node Manager properties file is always created in the The problem was solved by a code change to create the Node Manager properties file in the directory specified by |
||
|
When using This problem occurred because |
||
|
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. |
||
|
The MedRec sample application has been enhanced to support identity assertion in the LoginModule. |
||
|
Performance regressed from WebLogic Server 7.0 when using SSL Web Services because socket pooling was disabled. In WebLogic Server 7.0, SSLSockets were pooled in the Web Service runtime, in the thread safe socket pool that is a singleton shared across all invocations in the VM. In cases where SSL Client Authentication is used, this may lead to a problem: If there are multiple clients invoking the service within the application with different identities, the second client will possibly get the SSL Socket from the first client—this connection on this socket carries the first client identity. This is potentially a severe problem when using the client in a server setting—a transaction may occur while authenticated under the wrong identity, and this may lead to unprivileged users executing privileged actions. The shared socket pool has been replaced with a single socket that is shared only for a single client in the HTTPS binding. The socket sharing is disabled by default, however it can be enabled using either the system property or the new API provided. The default operational characteristics out of the box remain the same as WebLogic Server 8.1, with socket sharing disabled. Turning this feature on allows multiple serial invocations to share the same socket, but has the following properties that users must understand and accept:
|
||
|
Please review the security advisory information at http://dev2dev/resourcelibrary/advisoriesnotifications/BEA03_43.00.jsp. |
||
|
Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp. |
||
|
WebLogic Server Version 8.1 uses the SUN JDK 1.4 which does not support RSA keys larger than 2048 bits. Therefore, certificates with 4096 bit keys can not be used. |
Servlets & JSPs
System Administration
When multiple elements in WebLogic Server's config.xml had the same objectnames, later elements overwrote configurations for preceding elements. This used to happen silently. Now, WebLogic Server throws an error message (ID=150012) to standard output.
The getAttributes() method in the RequiredModelMBean should return a javax.management.AttributeList, which should contain javax.management.Attribute objects, but in the WebLogic Server JMX implementation the AttributeList returned by RequiredModelMBean contained the value of the MBean attribute directly and not as a javax.management.Attribute object, causing the following exception:
java.lang.ClassCastException: java.lang.String at weblogic.management.internal.RemoteMBeanServerImpl.getAttributes(RemoteMBeanServerImpl.java:210) at weblogic.management.internal.RemoteMBeanServerImpl_WebLogic Serverkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)End server side stack trace at com.adventnet.beasupport.client.JMXConverter.convertInvocationTargetException(JMXConverter.java:744) at com.adventnet.beasupport.client.ProxyMBeanServer.getAttributes(ProxyMBeanServer.java:511) at com.adventnet.beasupport.client.WebLogicClient.getAttributes(WebLogicClient.java:593) at com.adventnet.beasupport.client.WebLogicClient.cmdline(WebLogicClient.java:1279) at com.adventnet.beasupport.client.WebLogicClient.access$000(WebLogicClient.java:15) at com.adventnet.beasupport.client.WebLogicClient$2.run(WebLogicClient.java:1293)
Setting a JMSServer's Store property via the weblogic.Admin utility:
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -mbean examples:Name=examplesJMSServer,Type=JMSServer -property Store examples:Name=examplesJMSFileStore,Type=JMSStore
resulted in the following exception:
<Mar 10, 2003 3:32:15 PM EST> <Error> <Management> <141033> <Error importing MBean examples:Name=examplesJMSFileStore,Type=JMSStore to server examplesServer.javax.management.InstanceNotFoundException: examples:Name=examplesJMSFileStore,Type=JMSStore
This problem was partially fixed by checking when setting an attribute that is a WebLogicObjectName on a configuration MBean. The code checks to see if the bean is a valid one and will throw an InvalidAttributeValueException. This is logged on the Administration Server and the JMSServer remains usable but does not have the file store set.
Some load-balancing applications such as Cisco Loadbalancer became unable to use session stickiness because of a change to the SessionID format.
A new server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true , retains the information that the load-balancing application needs for session stickiness.
Exception propagation was not working properly because RemoteException was not being treated as a valuetype for rapid caching.
An exploded Web application was allowed to load classes from the docroot.
This inappropriate classloading behavior has been disallowed.
On GroupReaderMBean, isMember was failing when member name contained a comma.
A code change resolved this problem so that member names containing commas are now accepted.
The log handlers assumed that only WLLogRecord instances were being published. In the case of users directly invoking the logger using the Java 1.4 Logging APIs, the handlers threw a ClassCastException because it got a java.util.logging.LogRecord instance instead of a weblogic.logging.WLLogRecord.
A java.util.logging.LogRecord is now converted to a WLRecord object before being processed by the handlers. This avoids the ClassCastException. Users can now invoke the JDK Logger directly using the Java 1.4 Logging APIs and messages are logged to the server log file.
During server startup in a cluster on WebLogic Platform, the following error occurred:
<Jun 18, 2003 4:46:53 PM EDT> <Error> <Management> <BEA-141009> <Error occurred in the file distribution servlet while processing request type "wl_ear_resource_request", java.net.SocketException: Software caused connection abort: socket write error. java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at weblogic.servlet.internal.ChunkUtils.writeChunkNoTransfer(ChunkUtils.java:263) at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:228) at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:296) at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:371) at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:241) at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:114) at weblogic.servlet.internal.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:171) at weblogic.management.servlet.FileDistributionServlet.returnInputStream (FileDistributionServlet.java:568) at weblogic.management.servlet.FileDistributionServlet.doGetEarResourceR equest(FileDistributionServlet.java:787) at weblogic.management.servlet.FileDistributionServlet.doGet(FileDistributionServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run (ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio n.run(WebAppServletContext.java:6310) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2564) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
For any weblogic.Admin command that connects to a WebLogic Server instance, you must provide user credentials. You can now use the new STOREUSERCONFIG command to encrypt the user credentials instead of passing credentials directly on the command line or storing unencrypted credentials in scripts. See STOREUSERCONFIG for more information.
In WebLogic Server 8.1 and below, Weblogic MBeans (SecurityConfigurationMBean) could not have references to Security MBeans (RealmMBean). As a result, the realm could not be an attribute on the SecurityConfigurationMBean. Instead, it had to be an operation (a finder) as opposed to a getter. This was problematic because only users in the Administrators group have access to operations (except for special cases).
The findRealm() and findRealms() methods on the SecurityConfigurationMBean are now special-cased. As a result, these two methods are now publicly accessible.
Three commands—wlconfig, wldeploy, and wlserver—were modified so they can obtain a username and password from secured locations.
For wlconfig and wldeploy, customers can use the User Configuration functionality as described for the weblogic.Admin tool. The command: STOREUSERCONFIG option wlserver uses the boot.properties file to obtain a username and password.
As a result, usernames and passwords can be omitted from ant scripts, as long as an administrator has created the user config/key files (for wlconfig/wldeploy), or the server has been booted at least once in the domain (for wlserver). These actions create the files in which the encrypted usernames and passwords are stored. The username and password can still be provided on the ant task command line. In this case, they are used (that is, the user config or boot.properties files are ignored). In short, existing ant task scripts will continue to work as usual, but administrators who want to remove the username/password from the scripts can use the new functionality of these commands.
A NullPointerException occurred when security MBeans attempted to de-crypt the encrypted security MBean attributes during initialization.
This problem occurred because WebLogic Server MBeans were not yet initialized, and the encryption service relied on getting the salt from these MBeans.
The NullPointerException is now caught and the salt is obtained from the domain log file.
There were multiple issues associated with this CR.
1. SecurityConfiguration.findDefaultRealm(), findRealms(), and findRealm() always turned to the Administration Server for this information.
2. Whenever a CommoProxy object was initialized, it tried to obtain a reference to AdminMBeanHome in its constructor, although this was not required until later for setters and certain operations.
3. For read-only operations that required access to Embedded LDAP, WebLogic Server would always attempt to obtain this information from the Administration Server's LDAP. Whenever the Administration Server was down, exceptions were thrown in different layers.
4. Even after these problems were fixed, the response was slow when the Administration Server was down (what took about 30 seconds would have taken 3-5 seconds if the Administration Server was running). This was because WebLogic Server attempted to initialize the adminMBeanHome in CommoProxy in its constructor.
A startup class failed to access the local instance's MBeanHome. It failed with the following error message when the startup class was deployed with LoadBeforeAppDeployments="true":
Unable to resolve 'weblogic.management.home.localhome' Resolved: 'weblogic.management' Unresolved:'home'
This problem occurred because WebLogic Server 8.1 SP1 could not get the local instance's MBeanHome with LOCAL_JNDI_NAME (weblogic.management.home.localhome).
|
When multiple elements in WebLogic Server's |
||
|
The
|
||
|
Setting a JMSServer's Store property via the
resulted in the following exception:
This problem was partially fixed by checking when setting an attribute that is a |
||
|
Some load-balancing applications such as Cisco Loadbalancer became unable to use session stickiness because of a change to the SessionID format. A new server startup flag, |
||
|
Exception propagation was not working properly because |
||
|
An exploded Web application was allowed to load classes from the docroot. This inappropriate classloading behavior has been disallowed. |
||
|
On A code change resolved this problem so that member names containing commas are now accepted. |
||
|
The log handlers assumed that only A |
||
|
During server startup in a cluster on WebLogic Platform, the following error occurred: <Jun 18, 2003 4:46:53 PM EDT> <Error> <Management> <BEA-141009> <Error occurred in the file distribution servlet while processing request type "wl_ear_resource_request", java.net.SocketException: Software caused connection abort: socket write error. java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at weblogic.servlet.internal.ChunkUtils.writeChunkNoTransfer(ChunkUtils.java:263) at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:228) at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:296) at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:371) at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:241) at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:114) at weblogic.servlet.internal.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:171) at weblogic.management.servlet.FileDistributionServlet.returnInputStream (FileDistributionServlet.java:568) at weblogic.management.servlet.FileDistributionServlet.doGetEarResourceR equest(FileDistributionServlet.java:787) at weblogic.management.servlet.FileDistributionServlet.doGet(FileDistributionServlet.java:500) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run (ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio n.run(WebAppServletContext.java:6310) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2564) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170) |
||
|
For any |
||
|
In WebLogic Server 8.1 and below, Weblogic MBeans ( The |
||
|
Three commands— For As a result, usernames and passwords can be omitted from ant scripts, as long as an administrator has created the user config/key files (for |
||
|
A This problem occurred because WebLogic Server MBeans were not yet initialized, and the encryption service relied on getting the salt from these MBeans. The |
||
|
There were multiple issues associated with this CR. 1. 2. Whenever a 3. For read-only operations that required access to Embedded LDAP, WebLogic Server would always attempt to obtain this information from the Administration Server's LDAP. Whenever the Administration Server was down, exceptions were thrown in different layers. 4. Even after these problems were fixed, the response was slow when the Administration Server was down (what took about 30 seconds would have taken 3-5 seconds if the Administration Server was running). This was because WebLogic Server attempted to initialize the |
||
|
A startup class failed to access the local instance's MBeanHome. It failed with the following error message when the startup class was deployed with
This problem occurred because WebLogic Server 8.1 SP1 could not get the local instance's |
Tools
Web Services
The JSSEAdapter was pending a change to JDK 1.4, and therefore was not complete.
The JSSEAdapter has been brought up to parity with the WLSSLAdapter for strict checking, verbose and localIdentity features. As a result of this change, the JSSEAdapter now provides the same functionality as the WLSSLAdapter.
A client running behind a firewall needed to set properties on a Web service stub.
The problem was resolved by the introduction of two new properties, weblogic.webservice.client.proxyusername and weblogic.webservice.client.proxypassword.
The Web Service test page did not support the documentwrapped invocation style.
Support for testing the documentwrapped invocation style was added to the Web Service test page.
Some properties set on the stub were not copied into the MessageContext.
After a code change, WebLogic Server now supports the following usecases:
If you used a .NET C# client to access a WebLogic Server Web service and requested two strings returned, the first a result and the second an in/out parameter, the order of the strings returned was incorrect. The second string returned as the result, and the in/out parameter returned as null. A code change ensures that the first accessor returned is the return value.
The command-line flag -Dweblogic.webservice.verbose=true was causing an error message during startup, saying that it is not recognized by WebLogic Server.
This error message was wrong, since the flag was being recognized by WebLogic Server. This message has been removed.
A Web Service whose method contains multi-byte characters could not be accessed from the testing page in the Administration Console. (The client application can, however, access the Web Service.)
This problem occurred because a request parameter was being parsed using ISO-8859-1 encoding. It was resolved by modifying the code to set a character encoding before parsing a request parameter.
HTTPRequest and HTTPResponse not available in the server handler's message context. This was a regression from WebLogic Server 7.0.
This problem has been resolved by adding support for MessageContext.getProperty("HTTPRequest") and MessageContext.getProperty("HTTPResponse") in the server handler.
Note: HTTPRequest and HTTPResponse are now deprecated. Use weblogic.webservice.transport.http.request and weblogic.webservice.transport.http.response instead.
Running with invocation-style="one-way" resulted in the WSDL containing an <output> in the <binding> section for that operation as can be seen from the snippet below.
<portType name="MyServicePort">
<operation name="sayNothing">
<input message="tns:sayNothing" />
</operation>
</portType>
<binding name="MyServicePortSoapBinding" type="tns:MyServicePort">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"; />
<operation name="sayNothing">
<soap:operation soapAction="" style="document" />
<input>
<soap:body use="literal" namespace="http://tempuri.org/"; />
</input>
<output>
<soap:body use="literal" namespace="http://tempuri.org/"; />
</output>
</operation>
</binding>
This behavior was exhibited in both "rpc" and "document" style Web services. Running with Microsoft's WSDL.EXE against this WSDL resulted in an unsuccessful validation and consequently in a failure to generate the .Net client proxy or stubs.
A code change stopped the generation of output messages in one-way bindings, resolving the problem.
Clientgen-generated clients wrote attributes in the SOAP request without namespaces, even if attributeFormDefault="qualified" was specified. WebLogic Workshop Web Services did not recognize these attributes, causing the corresponding field of the Java object to be set to null.
Namespaces of attributes are now written out if attributeFormDefault="qualified".
The servicegen task did not support the "mergewithexistingws" attribute, resulting in a build failure.
This problem occurred because no setMergeWithExistingWS method was defined in the weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask class.
The following method is now part of the ServiceGenTask class:
public void setMergeWithExistingWS(boolean b) { mergeWithExistingWS = b; }
When casting an SSLAdapter to a WLSSLAdapter at runtime as shown below, a ClassCastException was thrown.
SSLAdapterFactory factory = SSLAdapterFactory.getDefaultFactory(); WLSSLAdapter adapter = (WLSSLAdapter) factory.getSSLAdapter();
This problem was caused by an incomplete feature addition.
The JSSEAdapter was correctly entered secondary to the default WLSSLAdapter. This fix restored the original behavior.
Exceptions were always being printed to stdout from Web Service clients.
Logging on the client side now only happens if the system property weblogic.webservice.client.logging is set to true. The default is false.
Passing org.w3c.dom.Document[] as a parameter to a method causes a SOAPException beginning with the following lines:
javax.xml.soap.SOAPException: Found SOAPElement [<anyType> <this xmlns="mynamespace"> <f:that xmlns:f="yournamespace"> <or> a lot of random < </or> <f:the> </f:the> <f:other> foo bar blaz</f:other> </f:that> </this> </anyType>]. But was not able to find a Part that is registered with this Message which corresponds to this SOAPElement ...
When the Web Service runtime attempted to find out the encoding of the XML represented by the Source object, its underlying stream was read and not reset.
Clients failed with an IllegalArgumentException if the XML returned from the server did not explicitly indicate the size of a SOAP array.
This problem occurred because the argument used for creating a new array instance was null because of missing size information.
For a SOAP array of an unspecified size, objects are now stored in a list first, and then the array is created.
A document or literal Web Service involving arrays generated a SOAP response message whereby the namespaces were not being applied properly. This resulted in .Net clients to ignore some of the data. WebLogic Server ant tasks (autotype, wsdl2service, and wspackage) are used to generate the Web Service.
This problem was resolved by modifying the code to write proper namespaces to the generated codec.
When iterating through the child nodes of the SOAP header, empty text nodes were casted to SOAPHeaderElement's.
Text nodes are now discarded. However, there was another change required to make the examineHeaderElements() method work. The mustUnderstand and actor attributes are now being recognized with and without namespace qualification. Previously, only the non-qualified form was recognized.
In the weblogic.webservice.binding.soap.HttpResponse class, the method getBodyAsString threw a "String index out of range" error.
A code change causes the method to use the length of the body, instead of the end, resolving the problem.
A NullPointerException occurred during deployment of a simple EAR file using WebLogic Builder.
Customers could not specify a KeyWrappingMethod for encryption, then configure the data security for Web Services. (By default, only rsa-oaep-mgf1p was used.)
Customers can now specify any supported KeyWrappingMethod in the deployment descriptor for a Web Service. For example:
<spec:EncryptionSpec
EncryptionMethod="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
KeyWrappingMethod="http://www.w3.org/2001/04/xmlenc#rsa-1_5"
EncryptBody="true">
</spec:EncryptionSpec>
WebLogic Server did not provide a timeout to a Web Service invocation on the client-side.
To timeout a Web Service invocation on the client-side in WebLogic Server SP 2:
With the API for BindingInfo: BindingInfo bInfo = (BindingInfo) stub._getProperty("weblogic.webservice.bindinginfo"); bInfo.setTimeout(5 /* secs */);
Note: In WebLogic Server 8.1 SP1, BindingInfo.setTimeout(5000/*millisecs*/) took milliseconds as the parameter. However, this had no effect on the client side. With SP 2, the parameter takes seconds instead of milliseconds.
When using wsdl2service to generate a service for mixed-style WSDL, the client side threw a SerializationException while invoking the service.
Mixed style is only supported on the client-side but not on the server-side. As a result of this change, wsdl2service will no longer generate a service if it is mixed style. Instead, a WSBuildException will be thrown while running wsdl2service.
Note: Prior to this change, wsdl2service would generate a mixed-style service.
WebLogic Server 8.1 supported an old version of the SOAP 1.2 specification.
In WebLogic Server 8.1 SP2, support for the latest SOAP1.2 specification has been added.
A java.lang.Object could not be used as a parameter or return type of a Web Service. As a result, an error similar to the following occurred during compilation:
Client.java:79: inconvertible types found : void required: java.lang.Object java.lang.Object retVal = (java.lang.Object)port.mapbasic8Data(arg0);
While calling the getContent() method in the handleResponse() method of a server-handler chain as follows:
SOAPMessage msg = ( (SOAPMessageContext)context ).getMessage(); javax.xml.transform.Source src = msg.getSOAPPart().getContent();
an exception starting with the following lines was thrown:
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces....
This exception has been eliminated, and the correct javax.xml.transform.Source object will now be returned when invoking msg.getSOAPPart().getContent().
The following classes were missing from webserviceclient.jar:
weblogic/webservice/encoding/AttachmentCodec.class
weblogic/webservice/encoding/DataHandlerArrayCodec.class
weblogic/webservice/encoding/DataHandlerCodec.class
weblogic/webservice/encoding/ImageArrayCodec.class
weblogic/webservice/encoding/ImageCodec.class
weblogic/webservice/encoding/MimeMultipartArrayCodec.class
weblogic/webservice/encoding/MimeMultipartCodec.class
weblogic/webservice/encoding/XMLSourceArrayCodec.class
weblogic/webservice/encoding/XMLSourceCodec.class
A class required to process client-side JAX-RPC handlers (javax.xml.rpc.handler.GenericHandler) was not included in the webserviceclient.jar file that ships with WebLogic Server.
The required class was added to webserviceclient.jar. Now Web Service clients can use JAX-RPC handlers using only webserviceclient.jar, and it is not necessary to include webservices.jar in the client's classpath.
Static clients did not throw the correct exception when multiple exceptions are thrown from a EJB method. For example, a static client for the method signature:
public void throwExceptions() throws ExceptionA, ExceptionB
always threw ExceptionA, regardless of what exception had been thrown from the server side.
The static client now throws the exception which matches the one thrown from server-side.
If an authenticated subject has been set on the message context, it is now used for invoking the backend component.
In WebLogic Server 8.1 SP1, an MDB is published as a Web Service using servicegen. This MDB listens on a foreign JMS provider (MQ-Series 5.3). Testing of the Web Service through the Administration Console, a ClassCastException starting with the following lines was raised:
Invocation failed ! Parameter Name Parameter Value Request sent to the server <!--REQUEST.................-->
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <env:Header>
</env:Header>
<env:Body>
<n1:toupper xmlns:n1="http://localhost:7001/messageToupperWebservices"; sample string</n1:toupper>
</env:Body>
</env:Envelope>
Response from the server
<!--RESPONSE.................--> <env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";> ...
The ClassCastException will no longer be raised; a code fix resolved the problem.
The InputStream field of StreamSource was always used, even if it was null.
If the InputStream is null, the Reader is now used. If both are null, a SOAPException is thrown.
Clientgen failed to compile a generated class for an extended type if the base type had a different namespace.
This problem occurred because base classes from different packages were not being imported.
Base class names are now generated with complete package names.
Clientgen failed with a ClassNotFoundException on WSDL with references to types in another schema, which had no targetNamespace via the generic <xs:import> tag.
A code fix resolved this problem. The fix also requires <clientgen> to define typePackageName or typePackageBase if there is no targetNamespace in the schema.
WebLogic Server generated a MIME header with the string "start=null". This violated RFC2387 in which "start element" is optional but can not be null. For example:
[java] Content-Type=multipart/related;boundary="----=_Part_0_19561502.106 8580828000";start=null
[java] Transfer-Encoding=Chunked
[java] Envelope :
[java]
[java] ------=_Part_0_19561502.1068580828000
[java] Content-Type: text/xml; charset='utf-8'
[java] Content-Transfer-Encoding: 8bit
This problem was resolved by modifying WebLogic Server to generate the correct "start element". For example,
[java] Content-Type=multipart/related;boundary="----=_Part_0_2960804.1068582126531";start=__WLS__1068582126546__SOAP__
[java] Transfer-Encoding=Chunked [java] Envelope :
[java]
[java] ------=_Part_0_2960804.1068582126531
[java] Content-Type: text/xml; charset='utf-8'
[java] Content-Transfer-Encoding: 8bit
[java] Content-ID: __WLS__1068582126546__SOAP__
|
The JSSEAdapter was pending a change to JDK 1.4, and therefore was not complete. The JSSEAdapter has been brought up to parity with the WLSSLAdapter for strict checking, verbose and localIdentity features. As a result of this change, the JSSEAdapter now provides the same functionality as the WLSSLAdapter. |
||
|
A client running behind a firewall needed to set properties on a Web service stub. The problem was resolved by the introduction of two new properties, |
||
|
The Web Service test page did not support the Support for testing the |
||
|
Some properties set on the stub were not copied into the MessageContext. After a code change, WebLogic Server now supports the following usecases: |
||
|
If you used a .NET C# client to access a WebLogic Server Web service and requested two strings returned, the first a result and the second an in/out parameter, the order of the strings returned was incorrect. The second string returned as the result, and the in/out parameter returned as null. A code change ensures that the first accessor returned is the return value. |
||
|
The command-line flag This error message was wrong, since the flag was being recognized by WebLogic Server. This message has been removed. |
||
|
A Web Service whose method contains multi-byte characters could not be accessed from the testing page in the Administration Console. (The client application can, however, access the Web Service.) This problem occurred because a request parameter was being parsed using ISO-8859-1 encoding. It was resolved by modifying the code to set a character encoding before parsing a request parameter. |
||
|
This problem has been resolved by adding support for Note: |
||
|
Running with
This behavior was exhibited in both "rpc" and "document" style Web services. Running with Microsoft's A code change stopped the generation of output messages in one-way bindings, resolving the problem. |
||
|
Namespaces of attributes are now written out if |
||
|
The servicegen task did not support the "mergewithexistingws" attribute, resulting in a build failure. This problem occurred because no The following method is now part of the
|
||
|
When casting an
This problem was caused by an incomplete feature addition. The |
||
|
Exceptions were always being printed to Logging on the client side now only happens if the system property |
||
|
Passing
|
||
|
When the Web Service runtime attempted to find out the encoding of the XML represented by the Source object, its underlying stream was read and not reset. |
||
|
Clients failed with an This problem occurred because the argument used for creating a new array instance was null because of missing size information. For a SOAP array of an unspecified size, objects are now stored in a list first, and then the array is created. |
||
|
A document or literal Web Service involving arrays generated a SOAP response message whereby the namespaces were not being applied properly. This resulted in .Net clients to ignore some of the data. WebLogic Server ant tasks ( This problem was resolved by modifying the code to write proper namespaces to the generated codec. |
||
|
When iterating through the child nodes of the SOAP header, empty text nodes were casted to Text nodes are now discarded. However, there was another change required to make the |
||
|
In the A code change causes the method to use the length of the body, instead of the end, resolving the problem. |
||
|
A |
||
|
Customers could not specify a Customers can now specify any supported
|
||
|
WebLogic Server did not provide a timeout to a Web Service invocation on the client-side. To timeout a Web Service invocation on the client-side in WebLogic Server SP 2:
Note: In WebLogic Server 8.1 SP1, |
||
|
When using Mixed style is only supported on the client-side but not on the server-side. As a result of this change, Note: Prior to this change, |
||
|
WebLogic Server 8.1 supported an old version of the SOAP 1.2 specification. In WebLogic Server 8.1 SP2, support for the latest SOAP1.2 specification has been added. |
||
|
A
|
||
|
While calling the
an exception starting with the following lines was thrown:
This exception has been eliminated, and the correct |
||
|
The following classes were missing from
|
||
|
A class required to process client-side JAX-RPC handlers ( The required class was added to |
||
|
Static clients did not throw the correct exception when multiple exceptions are thrown from a EJB method. For example, a static client for the method signature:
always threw The static client now throws the exception which matches the one thrown from server-side. |
||
|
If an authenticated subject has been set on the message context, it is now used for invoking the backend component. |
||
|
In WebLogic Server 8.1 SP1, an MDB is published as a Web Service using
The |
||
|
The If the |
||
|
Clientgen failed to compile a generated class for an extended type if the base type had a different namespace. This problem occurred because base classes from different packages were not being imported. Base class names are now generated with complete package names. |
||
|
A code fix resolved this problem. The fix also requires |
||
|
WebLogic Server generated a MIME header with the string
This problem was resolved by modifying WebLogic Server to generate the correct " |
