Release Notes

Resolved Problems for Service Pack 1

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

• Administration Console
• Classloader
• Cluster
• Connector
• CORE
• Deployment
• EJB
• Installation
• Internationalization
• J2EE
• JDBC
• JMS
• JNDI
• JTA
• JVM
• Localization
• Node Manager
• Plug-Ins
• RMI/RMI-IIOP
• Security
• Servlets & JSPs
• System Administration
• Tools
• Utilities
• WebLogic Workshop
• Web Services
• XML

Administration Console

Change Request Number	Description	Release Fixed
CR094513	For Connectors that had not yet been used, the Connector monitoring table displayed the last used time as "Wed Dec 31 19:00:00 EST 1969." It now displays the text: "Never."	8.1 SP1
CR095863	Custom attributes defined in the MBean Definition Files (MDFs) for several WebLogic security providers were displayed on the General tab for that provider, rather than on the Details tab. These attributes were as follows: RequireUnanimousPermit for the WebLogic Adjudication provider Severity for the WebLogic Auditing provider MinimumPasswordLength of the WebLogic Authentication provider PolicyDeploymentEnabled for the WebLogic Authorization provider CredentialMappingDeploymentEnabled for the WebLogic Credential Mapping provider RoleDeploymentEnabled for the WebLogic Role Mapping provider These attributes are now on the Details tabs for these WebLogic security providers.	8.1 SP1
CR097818	No online help was available for the View Idle Connections or View Leaked Connections pages. Online help for these pages is now available.	8.1 SP1
CR098353	The TransactionLogFileWritePolicy attribute was added in 7.0 SP01, but was never exposed in the Administration Console. A field for setting this attribute is now available on the Server —> Logging —> JTA tab.	7.0 SP3 8.1 SP1
CR099541	The Delete button at the bottom of the Policy Editor page did not delete the highlighted security policy. It also did not delete the default security policy. However, the Remove button would delete the default security policy. This action occurred because of a problem in the JavaScript code. The JavaScript code was modified so that the buttons on the Policy Editor page now work properly.	8.1 SP1
CR099771	The JDBC Assistant did not allow users to enable "Advanced Options" when creating data sources. The particular option of interest was `Emulate Two Phase Commit for non XA Driver' . The `Emulate Two Phase Commit for non XA Driver' option is now available in the JDBC Assistant.	8.1 SP1
CR099866	If the administration port is enabled, the Administration Console must use it. However, console extension Web applications do not use the administration port, so the links in the navigation tree that pointed to the console extension Web application did not work. This problem occurred because console extension Web applications were not labeled internal (which is required to access the administration port), and thus the servlet container rejected the request. Console extension Web applications are now labeled as internal.	8.1 SP1
CR100224	Exceptions were not correctly handled when viewing the JNDI tree for a Managed Server. The exceptions showed up in the log, but there was no indication in the Administration Console that an exception had occurred or that anything out of the ordinary had happened. The JSP code has been modified so that when an exception in the JNDI tree occurs, an "Access Denied" entry for the node in question is made in the navigation tree. The exception is also printed to the log.	8.1 SP1
CR100460	When an attempt was made to clone a server that is a target of an existing JMS distributed queue/topic, a javax.management.InvalidAttributeValueException was displayed in the Administration Console. This exception stated that the server was an "Illegal target" and that "A JMSDistributedQueue/JMSDistributedTopic, if it has members, should be deployed to a cluster or a single server that is not in a cluster." While the newly created/clone server was created, it did not show up in the navigation tree, but did show in the summary server view. Code has been modified so that the cloning of a server would not cause existing JMS distributed queues/topics to be added as targets, since these have already been targeted to a cluster. Additionally, the newly created/clone server now shows up in the navigation tree.	8.1 SP1
CR100638	Clicking the Distributed Topic Members or Distributed Queue Members links in the banner of the page for a specific Distributed Topic/Queue Member resulted in a 404 error. This problem was resolved by removing the links from the banner, since they duplicated the functionality of the links for the specific Distributed Topic/Queue Member.	8.1 SP1
CR100731	After the apparently successful deletion of a Web application, clicking the Continue link caused a javax.management.InstanceNotFoundException to be displayed. This problem was resolved with a code fix.	8.1 SP1
CR100974	When configuring a new Network Channel for a server, the Administration Console required that a Listen Address be specified, when this field is not required. This problem was resolved by removing validation on the Listen Address field so that it is not required by the Administration Console.	8.1 SP1
CR101247	If you were logged in to the Administration Console as a user who was granted a non-Admin security role and clicked the Services —> JCOM node in the navigation tree, the Domain Configuration page was displayed. This problem was resolved by removing the Services —> JCOM node from the navigation tree when users do not have permission to modify security settings (that is, for all users granted a non-Admin security role).	8.1 SP1
CR101317	When using the Administration Console with Internet Explorer 5.5, you may have seen the following JavaScript error message: "Object does not support this property or method". Upgrading to Internet Explorer 6.0 corrects this problem. This error appeared only occasionally on some computers where unspecified Internet Explorer patches have been applied. This problem was resolved by adding a JavaScript workaround for the bug in this version of Internet Explorer.	8.1 SP1
CR101770	The SSL Login Timeout field was unintentionally dropped from the WebLogic Server Administration Console. This problem was resolved by adding this field to the Configuration —> Tuning tab, under the Login Timeout field.	8.1 SP1
CR102441	There was no help text displayed on the pages that allow you to select which configured Authentication provider, Authorization provider, Role Mapping provider, or Credential Mapping provider should store a new user, group, security policy, or security role that was being defined (respectively). This problem was resolved by adding and displaying help text for these pages.	8.1 SP1
CR102561	When a JMS file store was assigned to a single JMS Server, and a distributed topic was created with the Enable Store box checked (that is, set to true), errors similar to the following may have been displayed: StoreEnabled set to 'true' for destination 'MyJMS Topic' but no Store configured for server 'TendrilJMSServer'. Can not set Enable Store to True if the JMS Server does not have a store defined. This problem occurred because the Enable Store setting is non-dynamic and the JMS Server was being auto-targeted too early in the process. This problem was resolved by removing the auto-targeting of JMS Servers.	8.1 SP1
CR102846	The Administration Console displayed a Channel Weight field in the Server —> Protocol —> Channels —> Network Channel tab's Advanced Options pane, when this field was obsolete. This problem was resolved by removing the Channel Weight field from the Administration Console.	8.1 SP1
CR102982	The Client Cert Proxy Enabled check box was displayed on the Tuning tab for a server, but this attribute is not related to tuning. This problem was resolved by relocating the ClientCertProxyEnabled field to the Configuration —> General tab for a server.	7.0 SP3 8.1 SP1
CR103328	When attempting to view server log message details using the Administration Console, the following exception may have occurred: java.lang.IllegalArgumentException: Cannot format given Object as a Number This problem occurred because messages with number arguments were not being handled properly. This problem was resolved by modifying the code so that messages with number arguments were handled properly. In addition, unexpected exceptions that may have occurred while they were being formatted were also fixed. A localized message will now be presented to users as happens elsewhere in the Administration Console.	8.1 SP1
CR103536	When multiple JMS Servers were configured and new distributed topics/queues were created with the Enable Store box unchecked (that is, set to false) and then later checked (that is, set to true), an error similar to the following was displayed: Can not set Enable Store to True if the JMS Server does not have a store defined. This error also occurred if the Enable Store box was checked, a new topic/queue was prepared, and the Apply button was clicked after the topic/queue was created (by clicking the Create button). This problem was resolved by correcting the verification logic.	8.1 SP1
CR105226	When attempting to view global roles without use of the navigation tree (by clicking Realms —> myrealm —> User Management —> Manage Role within this Security Realm), the resulting page displayed all security roles, not just the global roles. This may have resulted in seemingly duplicate security roles, when in fact a global role and scoped role with the same name may have been listed. This problem was resolved by modifying the page so that the navigation path shown above displays only global roles.	8.1 SP1
CR105262	Attempting to view scoped roles for a Web application deployed as part of an enterprise application (EAR) resulted in the following error: There are no appropriate RoleEditor providers configured. This problem was resolved by modifying the code so that it locates a Role Mapping provider that supports the editing, deploying, and so on of security roles by implementing the RoleEditor optional SSPI.	8.1 SP1
CR108134	The JDBC Assistant listed a number of JDBC drivers, but only a subset of those drivers are actually certified for WebLogic Server JDBC. The drivers that are certified for WebLogic Server JDBC are now marked as such in the JDBC Assistant.	8.1 SP1

Classloader

Change Request Number	Description	Release Fixed
CR102530	When WebLogic Server executes external processes that require CLASSPATH information, a String representation is generated based on the classpath of the current classloader. This representation includes information from any MANIFEST classpath entries and could have caused duplicate elements in the generated path. In some cases, this might have led to an OutOfMemoryError. The algorithm that generates the classpath has been modified to filter duplicate entries in order to prevent this problem.	8.1 SP1

Cluster

Change Request Number	Description	Release Fixed
CR102526	When an HTTP network channel was defined on a server (using the Administration Console's Protocols —> Channels tab for that server), session replication did not work. This problem occurred because there was a problem in the remote channel selection code. This problem was resolved by modifying the remote channel selection code so that it does not try to use invalid channels for t3.	8.1 SP1

Connector

Change Request Number	Description	Release Fixed
CR100269	JDBC Resource Adapter using Oracle Thin Client driver failed during completion of client-controlled transactions. This problem occurred when using a transaction started from a client application. The client started a transaction and then accessed a bean or Web application that used the resource adapter. When the client application attempted to commit or roll back the transaction, the server threw an exception of type javax.transaction.xa.XAException. This problem occurred because the Oracle Thin Client driver did not properly handle a call to XAResource.end with a TMSUSPEND flag. This problem was resolved by having the connection intercept the calls to the XAResource.	8.1 SP1
CR100707 CR101761	When using JCA in versions of WebLogic Server prior to 7.0 SP3, a java.lang.ClassCastException with java.naming.CompositeName was thrown. When using JCA in WebLogic Server 8.1, resource-ref entries (Auth, SharingScope) returned null for Web applications. This problem occurred because of an internal error, and was resolved with a code fix.	7.0 SP3 8.1 SP1
CR101906	A client invoked a method on an EJB. When the connection failed between the ManagedConnection (MC) and the EIS while in XA transaction state, the container called XAResource.rollback and ManagedConnection.cleanup every 60 seconds after the transaction had already been rolled back. Subsequent calls made to the EIS resulted in a java.lang.NullPointerException exception: <Mar 21, 2003 5:50:52 PM PST> <Error> <Connector> <190041> << JCA Resource Adapter for ClearPath MCP_eis/comsRAJNDINAMEBrazil > The returned ManagedConnection instance is null> <Mar 21, 2003 5:50:52 PM PST> <Info> <EJB> <010051> <EJB Exception during invocation from home: drummer.CedarBank.CedarBankBeanBrazil_ris6bf_HomeImpl@12fc36 threw exception: java.lang.NullPointerException java.lang.NullPointerException at drummer.CedarBank.CedarBankBeanBrazil.cedarBank(CedarBankBeanBrazil.java:130) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl.cedarBank(CedarBankBeanBrazil_ris6bf_EOImpl.java:46) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:785) 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:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134) Research revealed that WebLogic Server failed to wait for the transaction to complete before trying to destroy the connection. A code fix resolved the problem.	7.0 SP3 8.1 SP1
CR101924	When there is more than one matching credential, creating a new credential mapping resulted in an exception that began with the following lines: java.lang.IllegalStateException: Subject is read-only at javax.security.auth.Subject$SecureSet.add(Subject.java:1046) at weblogic.connector.common.internal.SecurityContext$1.run(SecurityContext.java:250) at java.security.AccessController.doPrivileged(Native Method) at weblogic.connector.common.internal.SecurityContext.initSubject(SecurityContext.java:244) ... This problem occurred because WebLogic Server called the setReadOnly method on the Subject as it added each credential in the list to the Subject. Therefore, only the first credential added to the Subject would not throw the above exception. This problem was resolved by modifying the code so that the setReadOnly method was called only once, after all the credentials were added to the Subject.	8.1 SP1
CR102220	A messaging bridge could not reconnect to the source/target destinations when the source Weblogic Server instance was killed and then restarted. This problem occurred because the ConnectionPool code was synchronized on the connection pool for the entire duration of releasing a resource or destroying a connection. This resulted in a deadlock of two threads, with the first thread releasing the resource and obtaining a lock, and then waiting on a second thread that was trying to destroy a resource that was waiting to get a lock on the connection pool. The problem was resolved by modifying the ConnectionPool code to obtain a lock only when it is required to remove any potential lock contention issues.	8.1 SP1
CR104642	When an error occurred in a ManagedConnection, it was removed from the connection pool, but the count of available connections in the pool was not being decremented. As a result, the maximum connection limit may have been reached sooner than expected, and an error message similar to the following may have been encountered when clients requested a new connection: <Reached maximum capacity of pool "Archiv_eis/ArchivAdapter", making "0" new resource instances instead of "1".> This problem was resolved by modifying the code to properly decrement the number of available connections in the pool following an error in the ManagedConnection.	8.1 SP1
CR105085 CR105712	After doing a proxy test, the connection was not being closed. This problem was resolved by modifying the code to call the close() method on the opened connection returned by getConnection. The connector container now introspects the connection handle to find the close() method and invokes it. If the close() method is not found, the container will log an error message stating that it did not find the close() method, and that it is required by the revised J2EE Connector Architecture Specification.	8.1 SP1
CR112051	In some cases with transactions involving connections to a resource adapter, if one thread was in the middle of beginning a transaction, and another thread was completing a transaction, a deadlock situation may have occurred causing both threads to hang. The deadlock occurred because both the JTA and Connector subsystems were performing synchronization on the same object in a conflicting way. The internal synchronization mechanisms have been repaired so that the conflict will no longer occur. As a result, the server will no longer hang in cases where one thread is starting a transaction while at the same time another thread is completing a transaction.	8.1 SP1

CORE

Change Request Number	Description	Release Fixed
CR071415	When the WebLogic Server security manager starts and sets the policy file, the path /usr/lib was prepended to javac during JSP compilation, causing a java.security.AccessControlException. The problem was solved with a code fix.	6.1 SP6 8.1 SP1
CR087808 CR095487	When multiple initial context lookups were attempted from a client with different server URLs simultaneously, there was a possibility that WebLogic Server would shut down the healthy RJVM when detecting duplicate connections. This problem has been resolved.	6.1 SP5 7.0 SP3 8.1 SP1
CR092155	If remote calls are made to a stale stub (that is, a stub obtained from a previous incarnation of the server that can no longer be used to make remote calls), network resources may be depleted. This problem was resolved by modifying the code so that the communication layers detects this occurrence and throws a ConnectException without actually connecting to the server.	8.1 SP1
CR097077	When using a custom realm that made many outbound RMI calls, the reader threads became blocked by making outbound calls, leaving no threads for reading the response. This happens from the BootServicesImpl.invoke method from within the RJVM layer on a reader thread. This problem was resolved by moving BootServicesImpl into the RMI layer so that it can dispatch to the default execute queue.	7.0 SP3 8.1 SP1
CR098865	When SSL sockets were closed, they wrote data by sending a CLOSE alert to the peer. This caused threads to hang when clients became unresponsive or when the connection was very slow. This problem was resolved by ensuring that after t3s RJVM timeout, the socket will be forcibly closed.	8.1 SP1
CR100177	The use of weblogic.security.service.ServerResource was inconsistent with the way server resources were created in the Administration Console and with the documentation. When used to secure a T3 server, the name of the WebLogic resource was always "T3Srvr." In all other cases, the name of the server being acted upon was used as the name of the WebLogic resource. This problem was resolved by always using the name of the server being acted upon as the name of the WebLogic resource.	7.0 SP3 8.1 SP1
CR101103	WebLogic Server experienced a performance regression when running SPECjAppServer with IIOP. This problem occurred because the JDK IIOP serialization code queried the system class loader for two classes for every request, and because loadClass is synchronized. This made the lock highly contended across the whole VM. This problem was resolved by caching these two classes in GenericClassLoader.	8.1 SP1
CR101720	With connection filtering enabled, Connection rejected messages would accumulate in the log file, resulting in the log filling up. This was resolved with the new ConnectionLogger property, which lets users configure whether to log such messages to the log file.	7.0 SP3 8.1 SP1
CR101946 CR101808	If you used the Java socket reader implementation, extended use of JMS sometimes led to an Out of Memory error. This problem occurred because of a memory leak in the Java socket muxer, which happened when socket read errors occurred. The problem was resolved by modifying the code to ensure that data structures related to the sockets were freed properly when the socket read errors occurred.	8.1 SP1
CR102196	In some rare error conditions, there was a memory leak in the NTSocketMuxer when the initiation of an NT asynchronous read failed. This problem was resolved by modifying the NTSocketMuxer to set a "read complete" status correctly after a SocketException occurred.	8.1 SP1
CR102848	The CoreHealthMonitor was holding the ExecuteThreadManager lock while performing significant work, resulting in deadlocks and Administration Console freezes. The code was changed so that CoreHealthMontor now uses ExecuteThreadRuntimeMBean to get a list of stuck threads and avoids logging from all places in the ExecuteThreadManager if ETM lock is held.	7.0 SP3 8.1 SP1
CR102874 CR103973	By default, network channel tunneling was on, which may have posed a security risk if you had explicitly configured network channels for a WebLogic Server instance. This problem is resolved by disabling network channel tunneling by default.	8.1 SP1
CR103203	The AcceptBacklog server attribute was erroneously marked as dynamically configurable. This was wrong because the accept backlog for a server socket can only be changed at creation time. WebLogic Server has no dynamic means of recreating server sockets on demand, and so the accept backlog can only be configured statically. This problem was resolved by ensuring that the accept backlog is only statically configurable.	8.1 SP1
CR103721	Attempts by a Java client to obtain an initial context over t3 using the address of a load balancer as the Provider_URL failed with a connection refused or connection timeout. A software change now allows a Java client to obtain an initial context over t3, with the Provider_URL set to the IP address of the load balancer. This is only possible when there is not already an established socket connection between the Java client and a server instance in the cluster. Only requests from the Java client that can be addressed to the load balancer are initial context requests. When using a default channel and t3, it is not necessary to set ExternalDNSName to traverse a NAT firewall. (Initial context requests described above will fail if ExternalDNSName is set.)	7.0 SP3 8.1 SP1
CR103853	If a start-up class or a start-up servlet attempted to set some system properties, a java.util.ConcurrentModificationException was thrown, which would prevent WebLogic Server from starting up. The problem was resolved by working on a clone of system properties when attempting to log the system properties during startup.	8.1 SP1
CR103967	Child threads of WebLogic Server execute threads did not inherit the correct context classloader. This common problem occurred when a servlet or an EJB created a timer (java.util.Timer). Analysis revealed that WebLogic Server execute threads maintained their own context classloader and child threads of these execute threads did not inherit the context because java.lang.Thread directly assigned the member variable of its own to the child threads. The problem was solved with a code fix.	6.1 SP6 8.1 SP1
CR104030	If an EJB that was not compiled with ejbc or appc, WebLogic Server will automatically compile it at deployment time. The compiler will be picked up from the PATH environment variable. However the commEnv.sh did not export the PATH variable which was causing a wrong compiler to be picked up. This is now resolved.	8.1 SP1
CR104373	When a Java client attempted to invoke the create method on the home stub of a stateless session bean using just the wlclient.jar, a ClassCastException would sometimes occur. This is because the client was unable to retrieve a suitable IIOP stub for the object from the server. This problem was resolved by modifying the stub generator to generate stubs with names that precisely reflect the IIOP Repository IDs used for remote objects.	8.1 SP1
CR107950	Idle RJVMs that lasted for more than 4 minutes were shutdown in the WebLogic Server 8.1 GA version, which was a regression from WebLogic Server 7.0. In WebLogic Server 8.1 SP1, idle RJVMs are not timed out.	8.1 SP1

Deployment

Change Request Number	Description	Release Fixed
CR083731	All system-created temporary files are now removed when an auto-deployed application is removed while the Administration Server is down. The corresponding configuration and files are cleaned up the next time the Administration Server is started.	8.1 SP1
CR091897	Deployment failed for a Web application with a short name, such as ab.war or i.war. This error occurred: java.lang.IllegalArgumentException: Prefix string too short at java.io.File.createTempFile(File.java:1232 at weblogic.j2ee.Component.retrieveComponent(Component.java:296 at weblogic.j2ee.Component.<init>(Component.java:188)at weblogic.j2ee.WebAppComponent.<init>(WebAppComponent.java:45 at weblogic.j2ee.Application.addComponent(Application.java:149) at weblogic.j2ee.J2EEService.addDeployment (J2EEService.java:117)... The bug was corrected.	6.1 SP5 8.1 SP1
CR099405	Duplicate state transition messages were being logged during deployment operations. This problem was resolved with a code fix.	8.1 SP1
CR101836	A request to deactivate (undeploy) a non-existent JSP using weblogic.Deployer returned a message indicating the operation was successful, rather than returning an error. This problem was resolved by modifying the code so that an error message containing information about how to undeploy a single JSP is returned.	8.1 SP1
CR104230	Javadoc for the weblogic.management.deploy.DeployerRuntime class was modified to remove documentation for extraneous methods.	8.1 SP1
CR104231	Javadoc for the DeployerRuntimeMBean class did not mark deprecated methods. The following methods are now marked as deprecated: activate deactivate remove unprepare lookupActiveTargetsForComponent lookupActiveVirtualHostsFor lookupActiveServers	8.1 SP1
CR104258	If security constraints on a Web application were modified and the Redeploy button for that Web application (in the Administration Console) was clicked, old security constraints were not removed. Note: This problem did not occur when the Stop and Deploy buttons were clicked instead of the Redeploy button. This problem was resolved by ensuring that the appropriate methods are called to notify the WebLogic Security Service any time the deployment descriptors are read and security might change.	8.1 SP1
CR108934	Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp.	7.0 SP3 8.1 SP1

EJB

Change Request Number	Description	Release Fixed
CR069896	Inside of a CMP deployment descriptor, if a weblogic-rdbms-relation contained two weblogic-relationship-roles with the same relationship-role-name, a NullPointerException could result when the EJB compiler was run. This problem was resolved by adding a compliance check to ensure that the relationship-role-names are unique within a weblogic-rdbms-relation.	8.1 SP1
CR084768	ejbc now logs a warning message when a field group or relationship cache was declared, but not associated with a finder (that is, never used).	8.1 SP1
CR090104	EJBs that specify an isolation level in their descriptor got an exception at runtime. There were two problems. One, WebLogic Server was checking for the wrong vendor workaround; it was checking for supportsTxIsolation instead of supportsTxIsolationUponEnlistment. Two, different database vendors and drivers have different rules/behaviors when (re)setting the isolation level while the transaction is active. For example, when using the WebLogic Server jDriver/XA for Oracle, the isolation level can only be set when creating the transaction branch, but not when joining/resuming the branch. Code changes rectified both the problems.	7.0 SP3 8.1 SP1
CR091352	ejbc code generation was failing for 4-level relationship caching, with the following exception: Found 4 semantic errors compiling "D:/labs/cluster70/src/com/bea/ps/cmr_orders/ejbcgen/com/bea/ps/cmr_orders/CustomerBean_1q1rpd__WebLogic_CMP_RDBMS.java": 789. if (__WL_bean__orderLines != null) <-------------------> *** Error: No entity named "__WL_bean__orderLines" was found in this environment. 791. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** Error: "__WL_bean__orderLines" is either a misplaced package name or a non-existent entity. 1310. if (__WL_bean__orderLines != null) { <-------------------> *** Error: No entity named "__WL_bean__orderLines" was found in this environment. 1312. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** Error: "__WL_bean__orderLines" is either a misplaced package name or a non-existent entity. Analysis revealed that RDBMSCodeGenerator.java was trimming an extra character when creating the prevCmrFieldName string, when caching was more than 3 levels. A fix to RDBMSCodeGenerator.java solved the problem.	7.0 SP3 8.1 SP1
CR092202	WebLogic Server did not check that an Oracle sequence existed when a bean was deployed. This problem was resolved by adding the following behaviors: The create/alter feature works in non-production mode only. The container never drops a sequence. If the container creates a sequence, it leaves an indication that the sequence has been created. (The indicator has the format: <sequence-name>_created_by_webLogic). The container may only alter a sequence that has an indicator in the database. When deploying in development mode, the container looks for <sequence-name> and if found, uses that sequence. Otherwise, the container looks for <sequence-name>_created_by_weblogic indicator.	8.1 SP1
CR094629 CR098386	With a CMR one-to-one (created in the same transaction), a database SELECT is issued to ensure the database consistence. This database SELECT can be avoided in some cases, if the proper constraints are set on the database. This database SELECT is now avoided by modifying the code so that __WL_CMR_isLoaded_ is set to true. This causes the database round-trip to be skipped when the bean state is STATE_EJB_POSTCREATE. Because this resolution causes the database check to be skipped, customers must be sure to create the database with the proper constraints. This resolution is limited to the case where a bean that has a 1 to 1 relationship with the current bean is being created in one of the bean's ejbPostCreate methods, and the CMR field in a bean's create method is implicitly set using a CMP field that is mapped to the same CMR field. For example, a parent's primary key is embedded as part of child's CMR field. If the CMR field setter is used, the container will still do the database SELECT.	7.0 SP3 8.1 SP1
CR094871	O_ITEM table (ItemEnt) caused a deadlock in SPECjAppServer. This deadlock only occurred with deployment descriptors that would be used for a single-server configuration, not for a multiple-server configuration. This deadlock was caused by different orderings of the primary keys in two different transactions for the SQL statement that was used for read verification (for the verify-rows feature). This problem was resolved with a code fix.	8.1 SP1
CR095141	The CoreHealthMonitor was holding the ExecuteThreadManager lock while performing significant work, resulting in deadlocks and Administration Console freezes. The code was changed so that CoreHealthMontor now uses ExecuteThreadRuntimeMBean to get a list of stuck threads and avoids logging from all places in the ExecuteThreadManager if ETM lock is held.	7.0 SP3 8.1 SP1
CR095173	The idle-timeout-seconds element determines 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 to use this element to determine how long to wait before removing passivated EJBs from the disk. However, some users wanted stateful session beans to remain on disk longer than idle-timeout-seconds. In other words, they want to specify how long stateful session beans stay idle in the cache and how long they stay idle on disk using two different elements. WebLogic Server 7.0 Service Pack 3 introduced the new element session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk. This element is also available in WebLogic Server 8.1 Service Pack 1.	7.0 SP3 8.1 SP1
CR096800	When WebLogic Server 6.1 throws an EJB exception to a WebLogic Server 8.1 invoker, the invoker received a serialization error. This is because WebLogic Server 6.1 shipped with the wrong serial version unique identifier (SVUID) for EJBException. WebLogic Server 8.1 SP1 identifies when it is communicating with WebLogic Server 6.x and accepts and sends the incorrect SVUID over such connections. The earlier resolution attempt along these lines that shipped with 8.1 was flawed.	7.0 SP3 8.1 SP1
CR097155	There were several issues with the default-dbms-tables-ddl feature: It did not create the ddl file when the EJBCompiler was run It was not clear where the ddl file was placed once it was created If the ddl file already existed, it was modified These problems were resolved by modifying the code so that the ddl file is now created at compile time. A message indicates the location of the ddl file when it is written, and if the ddl file already exists, it is overwritten.	8.1 SP1
CR098343	JDBC connections were not returned to the pool when a transaction was distributed over two server instances. The JDBC attribute KeepXAConnTillTxComplete was set to true. This sequence of events led to the problem: 1. Start a user transaction on one server instance 1. 2. Put a JMS message into a persistent queue. The JMS server and queues are on server instance 2. 3. Update an EJB on server instance 2. 4. Commit the transaction. No error messages were generated. The updates were performed and the message was placed in the JMS queue. However, some connections remained 'in use' in the EJB connection pool. After repeating the sequence of steps several times, the connection pool ran out of connections. The problem did not occur if the actions were executed on a single server instance, or if the JMS message was placed in the queue outside the transaction scope. The problem was solved with a code change to release the connection in the aftercompletion callback.	6.1 SP6 8.1 SP1
CR098548	A compliance warning has been added indicating that corruption of a Blob Clob may occur if a bean is using optimistic concurrency, has any fields that are mapped to Blob/Clob DBMS columns, and no timestamp or version column has been specified. This warning also recommends the addition of a timestamp or version column.	8.1 SP1
CR098798	When the EJB compiler was unable find a method specified in a transaction attribute setting, isolation level setting, method permission setting or an idempotent method setting, the error message produced did not contain the particular EJB on which the method could not be found. The error message was augmented to contain this information.	8.1 SP1
CR100010	An expired license.bea file resulted in a NullPointerException when attempting to deploy an EJB, rather than an exception indicating a problem with the license. This problem was resolved by modifying the code so that no deployments can be attempted after failing the license check, and a message indicates a problem with the license.	8.1 SP1
CR100719	Appc previously did not take alt-dd descriptors into account when invoking the underlying module compilers. The module compilers now use alt-dd descriptors if they are defined in the application.xml descriptor of the EAR. Command-line options were also added to appc to support application-level alt-dds.	8.1 SP1
CR100822	The behavior of clustered message-driven beans has changed to optimize performance. Previously, only standard cluster load-balancing algorithms were used when an MDB connected to JMS, so that JMS connections were balanced across the cluster. This has been augmented so that, when possible, an MDB steers its JMS connection toward the same JVM that is hosting the messages from which the bean receives connections. This reduces the number of hops made by the MDB when it is accessing the resource.	7.0 SP3 8.1 SP1
CR100890	ejbc now recognizes EJB QL identifiers with acceptable UNICODE names. ejbc warns if any non-standard characters are used in an identifier but allows them to be used. Continued use of non-standard characters in an identifier may result in non-portable applications across J2EE containers.	8.1 SP1
CR101248	CMP beans were leaking JDBC connection pools. The problem was occurring when ejbFindByPrimaryKey() called releaseResources(). A change was made to the RDBMSCodeGenerator so that, if ResumeTransaction fails, WebLogic Server releases resources to avoid a potential JDBC connection leak. This resolved the problem.	7.0 SP3 8.1 SP1
CR101446	In some cases, the EJB compiler was generating an interface that illegally declared methods as final. This problem was resolved by modifying the code generator to not declare interface methods with a final modifier.	8.1 SP1
CR102308	The Administration Console reported incorrect values for waiters for entity beans. The problem was solved by adding a waiterCurrentCount attribute that is incremented when a client starts waiting for a lock, and decremented when the lock acquired or the client times out.	6.1 SP6 8.1 SP1
CR102565	An incorrect javac CLASSPATH may have caused compiler errors in appc. This problem was particularly likely if one version of an EJB class existed in the system CLASSPATH and a different version existed in the JAR file. This problem may also have affected compilers other than appc. This problem occurred because of an incorrect ordering of the JAR file in the system CLASSPATH for the appc invocation. This problem was resolved by modifying the code so that the CLASSPATH passed to javac lists the system CLASSPATH before the PATH to the JAR file being compiled.	8.1 SP1
CR103108	EJB runtime counts that were of type long were not being synchronized, resulting in corrupt and/or incorrect count results. This problem was resolved with a code fix.	8.1 SP1
CR103226	Relationship caching for CMP is now supported for SQLServer 2000. Using nested relationship caching in SPECjAppServer 2002 using SQL Server 2000 used to cause the following SQL Server 2002 error: java.sql.SQLException: [BEA][SQLServer JDBC Driver][SQLServer]Query contains an outer-join request that is not permitted. This problem was resolved by modifying the outer join syntax to handle multiple database types, and by adding a <database-type> tag to the weblogic-rdbms-jar file. This tag indicates the database type of the underlying DBMS. For SQL Server 2000, specify the <database-type> as SQLServer2000. Note: SQL Server 7 should be specified in the <database-type> tag as SQLServer.	8.1 SP1
CR103393	A bug in the CMP code generator sometimes resulted in generated code that would not compile when a CMP field was also a CMR field. In particular, an array was being accessed with an invalid index (the index was null). This problem was rare and only showed up when the EJB compiler was invoked. This problem was resolved by ensuring that the code generator always used a valid array index.	8.1 SP1
CR103341	New convenience functionality for CMP beans using Oracle sequences was added. The tag <create-default-dbms-tables> will now operate on Oracle sequences on systems that are being used in development mode.	8.1 SP1
CR104046	With delay-database-insert-until set to Commit, the Optimistic concurrency version column was not being initialized when a "multi-table" bean was created. The code was changed so that RDBMSCodeGenerator.perhapsAssignOptimisticField() now returns generated code that sets the version column for all the tables that the CMP bean is mapped to.
CR104256	CMP Bean creation failed if any of the primary key field values were Java primitives and if any of these primitive key field values were set to a value equal to the default value for that field type. For example, if a bean had a primary key field of type Java primitive 'int' and the value of the primary key field was '0', then CMP bean creation would fail. The CMP container now allows the setting of Java primitive default values for primary key fields to be recognized and for EJB creation to proceed. This fixes a bug in the container. No other side effects are expected.	8.1 SP1
CR104610	By default, appc would fork a new process for compiling. In some cases (large EARs, for example), this process required customers to allocate a lot of memory to the JVM heap to successfully compile, and sometimes a java.lang.OutOfMemoryError would occur anyway. This problem was resolved by adding an explicit -J option to the wlappc ant task's runtimeFlags option. Customers can now pass a memory size to the new process, such as runtimeFlags="-J-ms64m -J-mx256m". Additionally, the default for appc was changed to "inline compilation". Therefore, appc will no longer fork a new process for compiling by default. For example, in WebLogic Server 8.1 GA: <wlappc forceGeneration="true" compiler="javac" runtimeFlags="-ms64m" lineNumbers="true" verbose="true" debug="true" keepgenerated="true" source="${dist-dir}/ejb_${name}.jar"> <classpath refid="ejbc-classpath"/> </wlappc> In 8.1 SP1: <wlappc forceGeneration="true" compiler="javac" runtimeFlags="-J-ms64m" lineNumbers="true" verbose="true" debug="true" keepgenerated="true" source="${dist-dir}/ejb_${name}.jar"> <classpath refid="ejbc-classpath"/> </wlappc>	8.1 SP1
CR104979	This change affects the following EJB callback methods on the following bean types: ejbCreate, ejbRemove—for stateless session beans and message driven beans. ejbPassivate—for stateful session beans when ejbPassivate is called due to a cache timeout. The security principal that is active when these methods are called will be anonymous except if any of the following are done: 1. For those beans which have a run-as role specified, a run-as principal has been designated according to the rules for designating a run-as principal. In these cases the run-as principal will be active. 2. If the bean is new for this service pack: <create-as-principal-name> or <remove-as-principal-name> or <passivate-as-principal-name> are specified for the corresponding EJB callback methods, then the specified principal is active during the EJB callback method. Note that principals specified using this method will take precedence over the more general run-as role principal assignment that is specified using (1) above. If any operations performed as part of these EJB callbacks require more permissions than anonymous would have, then an appropriate principal must be set using one of the methods (1) or (2) above.	8.1 SP1
CR107455	When read-only beans were used, OutOfMemoryErrors occurred. This problem occurred because multiple duplicate entries were being created for the same bean in the lastLoadMap. The duplicate entries were being created by an unnecessary call to initLastLoad() during getBeanFromRS(), even though lastLoadMap was already initialized by the call to cache.get(). This problem was resolved by removing the unnecessary call to initLastLoad().	8.1 SP1

Installation

Change Request Number	Description	Release Fixed
CR098373	The WebLogic Server installer did not provide users with the ability to exit the installer when it was determined that the available space was not adequate for product installation. Instead, the installer only provided users with an option to specify another directory. This problem was resolved by providing an option for users to exit the installer when it was determined that the available space was not adequate for product installation.	8.1 SP1
CR101452	The name of the JDK directory was hardcoded in the config.cmd and config.sh scripts. This problem was resolved by replacing the hardcoded JDK directories to %JAVA_HOME%\bin\java and %JAVA_HOME%\bin\javaw.	8.1 SP1

Internationalization

Change Request Number	Description	Release Fixed
CR099768	If the catalogs listed on the command line do not have any translations, l10ngen exits abruptly but does not provide an error message indicating the reason. This problem was resolved by modifying the code so that if none of the catalogs have translations, a warning is issued. If any catalogs have translations, then the translations are processed, but no warnings are issued for those that do not have translations.	8.1 SP1
CR102646	When attempting to convert I18N message files to WebLogic Server message catalogs, the use of the Loggable class caused an error like the following to be written to the server log (rather than the appropriate message): <Apr 1, 2003 1:31:35 PM PST> <Error> <Unknown> <000000> <Unable to access undefined message, id=900017> This problem occurred because the Loggable class attempted to look up the message catalog class name based on the message ID, which would not work properly if there were issues with the classloader. This problem was resolved by modifying the code so that the message catalog class name is now passed into the constructor of the Loggable class.	8.1 SP1
CR107052	Internationalization characters in the InternalRequestDispatcher's response were garbled because the String content was created without the charset. This problem was resolved by creating the String with the appropriate charset, thus ensuring that the String appears in the correct encoding. The change should cause no side-effects.	8.1 SP1

J2EE

Change Request Number	Description	Release Fixed
CR091939	In weblogic.Deployer, an application would always use the deployment descriptor with which it was originally deployed. In other words, you could not change the deployment descriptor when the application was redeployed using the -redeploy flag. (You could only change the deployment descriptor if you first used the -undeploy flag.) This problem was resolved by modifying the code to allow the switching of deployment descriptors at update time. The behavior of the -redeploy flag now works the same way as an -undeploy followed by a -redeploy.	8.1 SP1
CR096215	Any war file containing a WEB-INF/web-services.xml deployment descriptor will now have its associated Web Services compliance checked when compiled by appc. This additional checking was added to help identify application errors more quickly during development.	8.1 SP1
CR098671	A split-directory EAR could not be deployed with a module-level alt-dd deployment descriptor. This problem was resolved by a code fix. For more information about using module-level alt-dd deployment descriptor, see the "Module" table under Application Deployment Descriptor Elements in Developing WebLogic Server Applications.	8.1 SP1
CR101002	When an EAR was deployed security roles defined in the application.xml file but with no corresponding security-role-assignment entries in weblogic-application.xml, these security roles were not visible from the WebLogic Server Administration Console when right-clicking the deployed enterprise application and selecting "Define Scoped Role...". This problem was resolved by modifying the code so that all security roles defined in application.xml are viewable in the Administration Console (even those without assignments in weblogic-application.xml).	8.1 SP1
CR102293	wlcompile supports a nested javac element that you can use to specify flags on javac. For example, you can specify deprecation warnings on javac as follows: <wlcompile srcdir="${srcdir}" destdir="${destdir}"> <javac deprecation="true" /> </wlcompile>	8.1 SP1
CR102306	The wldeploy command did not support application-level alt-dd deployer arguments. Attempts to use such arguments would result in a build failure. This problem was resolved by adding support to wldeploy for application-level alt-dd deployer arguments. This means that split-directory EARs can now be deployed with application-level alt-dds.	8.1 SP1
CR105317	When specifying preprocessor names on the command line as shown below, any spaces before or after the classname were interpreted as part of the classname, and therefore, an otherwise legitimate class would not be found. -Dweblogic.classloader.preprocessor="com.dirig.preprocessor.DirigBEAClassProcessor, ppclass.MyPP1 ,ppclass.MyPP2 " This problem was resolved by ensuring that any such spaces are not interpreted as part of the classname.	8.1 SP1

JDBC

Change Request Number	Description	Released Fixed
CR090255	Version 9.2.0.2 of the Oracle Thin driver, which shipped with the product, produced a NullPointerException when the addBatch and setNull methods required data conversions. This problem was resolved by updating the Oracle Thin driver to version 9.0.2.3.	8.1 SP1
CR090365 CR090366	Version 9.2 of the Oracle Thin driver, which shipped with the product, did not allow a BLOB and a long raw to coexist in the same table. The following exception would be encountered: java.sql.SQLException: Protocol violation This problem was resolved by updating the Oracle Thin driver to version 9.0.2.3.	8.1 SP1
CR092453	In WebLogic Server 6.1 SP04, with Oracle Thin XA with the CLASSES12.zip from Oracle 9.2, a stateless session bean calling EJB caused XAER_PROTO after "Configuration Changes saved to the repository" message appeared. START SLEEP 2: After updating the value to 1... DONE SLEEP 2: After updating the value to 1... START SLEEP 2: After updating the value to 2... DONE SLEEP 2: After updating the value to 2... START SLEEP 2: After updating the value to 3... DONE SLEEP 2: After updating the value to 3... START SLEEP 2: After updating the value to 4... DONE SLEEP 2: After updating the value to 4... START SLEEP 2: After updating the value to 5... DONE SLEEP 2: After updating the value to 5... Current value is 5 <Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0 The problem caused by a known problem in Oracle client 9.2.0.[01], that is solved in 9.2.0.2. WebLogic Server implemented a code change to work around the 9.2.0.[01] issue.	6.1 SP5 8.1 SP1
CR094729	The JDBCConnectionPoolRuntimeMBean.getStatementProfiles method did not filter results by poolName for the MBean instance it was called against. If you called the getStatementProfiles method, the results included statements for all connection pools for which tracing had been activated. This was incorrect because the JDBCConnectionPoolRuntimeMBean instance is specific to a single connection pool. This problem was resolved by modifying the JDBCConnectionPoolRuntimeMBean.getStatementProfiles method to correctly filter results by poolName for the MBean instance it is called against.	7.0 SP3 8.1 SP1
CR099872	The message for the Exception during commit of transaction stack trace exception contained the connection pool name, but not the data source name. <Exception during commit of transaction Xid=39:74a54046e2c2bb30(5962554),Status=Rolled back. [Reason=ja vax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the EnableTwoPhaseCommit property on the corresponding JDBCTxDataSource property, to true. Pool = CatPhase1] ... The stack trace content was enhanced to include the name of the data source.	6.1 SP6 8.1 SP1
CR100877	The JTS driver attempted to create remote connections in single-server SpecJAppServer runs. This problem occurred only if a connection to the database for the transaction had already been opened, and the getConnection method was called again when the transaction timed out and was rolled back. In addition, this problem: Occurred infrequently. Resulted in no impact to the behavior of the application. Occurred as a result of a rollback race condition. Could have negatively impacted performance. This problem was resolved by modifying the code so that the transaction status is checked before a remote connection is made.	8.1 SP1
CR101419	Fail-over for DataSources and TxDataSources in a cluster was not working. This problem occurred because the DataSources and TxDataSources were not built as clusterable, and was resolved by building them as clusterable.	8.1 SP1
CR101709	DB vendors (such as Oracle) execute SQL DDL operations within a new local transaction. However, if the AutoCommit flag for the connection was set to false (as is the case when a connection is obtained from a WebLogic Server TxDataSource), the local transaction was not committed, and remained active on the connection. When running with the Oracle 9.2.0 Thin driver, subsequent XA operations performed on this connection failed with an XAER_PROTO, due to the currently active local transaction. This is because starting with this version, Oracle Thin driver started checking for active local transactions when asked to perform XA operations on connection objects. WebLogic Server can now circumvent this problem by rolling back any active local transactions on a connection when it is being returned back to the WebLogic Server JDBC connection pool. This defensive behavior can be enabled by setting the new WebLogic Server JDBC connection pool attribute RollbackLocalTxUponConnClose to true.	8.1 SP1
CR101822	Setting the isolation level to Connection.TRANSACTION_READ_COMMITTED for Oracle Thin Driver failed, with an exception indicating that the Isolation Level "2" could not be mapped. This isolation level is now properly recognized and passed to the Oracle driver.	8.1 SP1
CR102364	Clicking the Test Pool button on the Testing tab in the Administration Console after creating an Informix JDBC connection pool might have resulted in the following errors: <Error> <JDBC> <BEA-001112> <Test "select count(*) from ITEMS" set up for pool "informixPool" failed with exception: "java.sql.SQLException: Database not selected yet.".> <Error> <JDBC> <BEA-001111> <Unable to verify the test "select count(*) from ITEMS" set up for pool "informixPool". Connections will not be tested.> Note: This problem only occurred for some Informix configurations. This problem was resolved by modifying the code so that the configuration works properly for Informix JDBC connection pools.	8.1 SP1
CR102698	Attempts to create a connection pool with weblogic.Admin CREATE_POOL resulted in the following exception: ./wlg-create-pool.sh No permission to create ConnectionPool Start server side stack trace: weblogic.common.ResourceException: No permission to create ConnectionPool at weblogic.jdbc.common.internal.JDBCService.createPool(Ljava.util.Properties;Lweblogic.secur ity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at weblogic.jdbc.common.internal.ConnectionPool.createPool(Ljava.util.Properties;Lweblogic.se curity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at ... Research revealed that WebLogic Server was requiring aclName—which is deprecated—as an attribute. A code fix resolved the problem.	7.0 SP3 8.1 SP1
CR103321	The getConnectionsTotalCount() method of JDBCConnectionPoolRuntimeMBean did not behave as expected. Instead of returning the total number of JDBC connections in the pool since instantiation, it returned the maximum number of connections since instantiation. The problem was resolved with a code fix in the method.	8.1 SP1
CR104103	RowSets failed to serialize a CLOB column to XML, resulting in an exception similar to the following: java.io.IOException: No XML Schema type mapping found for JDBC type: 2005 This problem was resolved by modifying the code so that a CLOB is appropriately mapped to an XML schema type.	8.1 SP1
CR104522	The CachedRow.containsKey(Object) method always returned an inverted value. This problem was resolved with a code fix.	8.1 SP1
CR104523	DatabaseMetaData.getDriverVersion() was returning an outdated version string. A code fix resolved the problem.	7.0 SP3 8.1 SP1
CR107609	If a RowSet had to look up the DataSource itself (instead of it being set from outside), an application was forced to set the username and password. This was due to a problem in the cleanup processing for RowSets. The security check that occurs when JNDI credentials are used reduced performance by about 40% in some cases. This problem was resolved by fixing the problem in the cleanup processing.	8.1 SP1
CR108006	When multiple transactional (JTS) JDBC connections were used in a remote application during a single transaction, a NullPointerException could be seen on the remote client if any of the connections were closed and any other connections were used after that. This problem occurred because, while all RMI connections in the same JTS transaction must actually represent the same underlying JTS connection, a mistaken optimization was added, which supplied the same RMI connection for multiple connection requests within a transaction. Closing any one of these would also close what the application thought was any other, supposedly independent one. The solution was to remove the optimization, and to always return distinct RMI connections to separate remote connection requests within a given JTS transaction.	8.1 SP1

JMS

Change Request Number	Description	Release Fixed
CR097038 CR102656	When a source JMS bridge destination was not running in the same WebLogic Server 8.1 domain as the Message Bridge, then a trusted security relationship must have be established between the domains. Otherwise, the Messaging Bridge must have been configured to work in synchronous mode (Asynchronous Mode Enabled = No). This problem has been resolved so that non-trusted domains also work when using asynchronous mode communications.	7.0 SP3 8.1 SP1
CR098280	The session creation method behavior has been changed when using a XAQueueConnection or XATopicConnection object to create a non-XA Session. Prior to this change, the behavior was as follows: XAQueueConnection.createQueueSession creates a XAQueueSession XATopicConnection.createTopicSession creates a XATopicSession In both cases, the user-specified acknowledge mode and transacted flag were ignored and replaced with the AUTO_ACKNOWLEDGE mode and a transacted setting of false. Whereas, the new behavior causes the XAQueueConnection.createQueueSession and XATopicConnection.createTopicSession methods to behave exactly the same as the corresponding methods on QueueConnection and TopicConnection, as follows: QueueConnection.createQueueSession creates a QueueSession TopicConnection.createTopicSession creates a TopicSession XAQueueConnection.createQueueSession creates a QueueSession XATopicConnection.createTopicSession creates a TopicSession Furthermore, the user-specified acknowledge mode and transacted flag settings will be honored for each of these four methods. The four connection methods listed above behave differently if the XAServerEnabled flag is enabled on the connection factory. If this flag is enabled, then all four methods will create an XAQueueSession (or XATopicSession) session if invoked on the server, and a non-XA QueueSession or TopicSession session if invoked on the client. The resulting session will honor the user-specified acknowledge mode, but it will ignore the transacted flag since the resulting session supports XA. Note that in previous versions of WebLogic Server, connection objects that were created from a connection factory with the XAConnectionFactoryEnabled flag enabled behaved as if they were XAQueueConnection or XATopicConnection objects. With the new behavioral change, this behavior is now invisible unless you explicitly cast the connection factory to XAQueueConnectionFactory or XATopicConnectionFactory and called one of the createXA methods. Prior to this change, if you set the XAConnectionFactoryEnabled flag on your connection factory, you would have noticed different behavior from the createQueueSession and createTopicSession, even if you did not cast the connection factory to one of the XA connection factory classes.	7.0 SP3 8.1 SP1
CR098975	WebLogic Server sometimes failed to boot after you undeployed a distributed destination. This occurred when you deleted the distributed members and the distributed destination itself, but did not delete the underlying physical destinations. The following sequence of Administration Console actions caused this problem: 1. In the Configuration -> Members tab of a distributed destination, click the trash can icon to remove a member. 2. When prompted, do not delete the member's underlying physical destination. 3. Click Remove to delete the member. 4. If necessary, continue deleting all the members of the distributed destination. 5. Delete the distributed destination. If you had shut down the server at this point, you would not be able to reboot it. The problem was resolved by creating a JMS template for distributed destinations at the domain level. This prevents the template from being deleted when a user deletes a distributed destination member but does not delete the underlying physical destination represented by the member. This way, when WebLogic Server boots, the JMS template that the physical destination is referencing still exists so the boot does not fail.	8.1 SP1
CR100663	A new debug flag "DebugJMSMessagePath" was added to trace the JMS message in the server and more debugging messages were added. When the new DebugJMSMessagePath flag is turned on, the JMS message inside the server is tracked and a debug message is logged informing the message's path along with the JMSMessageID, if available. This flag can be turned in two ways as shown below: In the config.xml: <ServerDebug Server="name of the server" DebugJMSMessagePath="true" /> In the server startup command-line as: -Dweblogic.Debug.DebugJMSMessagePath=true	8.1 SP1
CR101076	The messaging bridge was enhanced to log all JMS header attributes when -Dweblogic.Debug.DebugMessagingBridgeRuntime is set to true.	8.1 SP1
CR101298	If a long idle JMS JDBC connection was marked as "bad" (when for example, if a firewall time-to-live expires) JMS attempted to use the now bad connection, and would fail. The failure would either be immediate or would take upwards of 8-10 minutes to return, depending on tuning parameters. This problem was resolved by modifying the code so that if JMS is idle, the database is pinged every 5 minutes to maintain the connection.	7.0 SP3 8.1 SP1
CR101585	A JMS Client Session that was never committed or acknowledged would result in a memory leak. This problem was resolved by properly handling rollback and recovery when unacknowledged messages exist.	8.1 SP1
CR101594	When the WebLogic Server licence file did not include a license for JMS and a JMS Server was configured and targeted to a WebLogic Server instance, the server booted without the JMS Server, but did not indicate the reason for the JMS Server's failure to start in the server log file. This problem was resolved by logging an error in this case.	8.1 SP1
CR101804	When undeploying a JMS server by setting the JMS server's target to "none" in the Administration Console, redeploying the JMS server by setting its target back to the original WebLogic server instance resulted in a NullPointerException, and the redeploy failed. This problem was more likely to have occurred when JMS templates were used. This problem was resolved.	8.1 SP1
CR102234	ASSERTION FAILED messages were printed to the bridge server log when a server was killed. This problem occurred because the bridge adapter code closed both the source connection and the target connection, when one of these connections may already have been destroyed and removed from the pool. This problem was resolved by modifying the bridge adapter code so that it does not attempt to close a bad connection.	8.1 SP1
CR102284	The performance of the JMSHelper extension methods was improved.	8.1 SP1
CR102649	Errors [J2EE:160054] and [J2EE:160062] frequently occurred in the case that an application was using JMS connection pooling, where the session was opened in ejbCreate() and closed in ejbRemove(). This problem occurred because the EJB was returned to the pool before the transaction was complete, and the JMS session was still associated with the old transaction. This problem was resolved.	8.1 SP1
CR102656	Using a messaging bridge for asynchronous messages between non-trusted domains resulted in security error messages. The code was changed to handle message passing between the domains with allowable security credentials in this case.	8.1 SP1
CR102749	JMS JDBC stores may have deleted durable subscriptions over time. If a durable subscription record was accidentally deleted, its associated messages were also deleted on the next reboot of WebLogic Server. This problem was fixed by keeping track of handles for durable subscriptions so that wrapping handle values would not re-use an existing handle.	8.1 SP1
CR103375	Shutting down a server resulted in the following exception: weblogic.jms.common.JMSException: Failed to remove temporary destination because JMSServer is shutdown or suspended ... This problem occurred because attempts to remove temporary destinations are made while the server is in the shutting down state, and therefore these attempts cannot be completed. This problem was resolved by modifying the code so that a JMSException is not thrown when attempts to remove a temporary destination are made during a server shutdown, and the temporary destinations are successfully removed.	8.1 SP1
CR105337	Under load conditions, a test JMS application was encountering the following exception: java.lang.OutOfMemoryError weblogic.jms.common.TransactionRolledBackException: at weblogic.jms.backend.BEConsumer.expireTimeout(BEConsumer.java:1620) at weblogic.jms.backend.BEXATranEntryBlockingConsumer.startRollback(BEXATranEntryBlockingConsumer.java:72) at weblogic.jms.backend.BEXAResource.rollback(BEXAResource.java:1205) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:1400) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:664) at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:365) at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.java:1521) at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.java:2142) at weblogic.transaction.internal.TransactionImpl$1.execute(TransactionImpl.java:1656) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:211) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:198) weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.rollbackAfterRecover(FESession.java:1773) at weblogic.jms.frontend.FESession.recover(FESession.java:1373) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) at com.ncr.crm.framework.jms.DemoMessageConsumer.run(JmsMemoryLeakDemo.java:163) at java.lang.Thread.run(Thread.java:479) ----------- Linked Exception ----------- weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.recover(FESession.java:1219) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) at... Research revealed that the WebLogic JMS garbage collection functionality was slow to reclaim memory when dealing with long linked lists; the code was changed to break up the lists. This resolved the problem.	7.0 SP3 8.1 SP1
CR105403	When trying to deploy an MDB on a stand-alone server, deployment fails if the license does not have the "Clustered JMS" component. License checking has been corrected.	8.1 SP1

JNDI

Change Request Number	Description	Release Fixed
CR091837	Some customers had problems with the amount of time RMI stubs took to failover, if the destination server became unavailable. This amount of time varied with the operating system and the operating system version. This problem occurred because the socket creation from a client was taking too long to fail. This problem was resolved by providing the -Dweblogic.client.socket.ConnectTimeout flag, which sets the Socket.connect() method timeout in seconds.	8.1 SP1
CR101433	A deadlock occurred in the serialization of JNDI results. This problem occurred because the hashtable containing environment arguments (which is used to create the initial context) was being shared by different threads. This problem was resolved by using a workaround for a Sun bug, which involved cloning the hashtable containing environment arguments so that the hashtable is not shared by different threads.	8.1 SP1
CR103711	When one-phase deployment was used for an application, all ejb-ref lookups from within that application were resulting in a JNDI lookup. To improve performance, the ejb-ref values are now cached.	8.1 SP1
CR105462	When obtaining a new initial context via WLInitialContextFactory and then closing it repeatedly, a memory leak occurred in the JNDI client, and an Out of Memory exception was thrown. This problem occurred because the TransactionHelper class has a stack of TransactionHelperImpl objects. Objects were pushed into the stack when creating new contexts, but were not popped when the context was closed. This problem was resolved by modifying the code to pop the objects from the TransactionHelper when a context is closed.	8.1 SP1

JTA

Change Request Number	Description	Release Fixed
CR097013	A subcoordinator server was not recovering in-doubt transactions automatically after server down, requiring manual rollback or commitment by the DBA. Research revealed that the subcoordinator code was losing track of remote participants after server restart. A checkpoint was added to the code to properly track remote participants.	7.0 SP3 8.1 SP1
CR099830	JTA Migration sometimes failed with a NullPointerException or ConnectException after a transaction was propagated among two servers in cluster. NullPointerException <Feb 28, 2003 6:38:44 PM JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [serverB] fails. java.lang.NullPointerException at... ConnectException <2003/02/27 13:11:20:JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [server1] fails.> java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination at... Research revealed that the code created a race condition between the notification of when the server was dead and when the information for that server was cleaned from the cache. If the notification that the server was dead came after the cache has been cleared, then the remaining Managed Server would get a NullPointer Exception when it tried to look for the location of the tlog of the dead Managed Server. A code fix resolved the problem.	7.0 SP3 8.1 SP1
CR102358	The following debug message was printed continuously every 5 seconds when JTARecovery debug was turned on: <Mar 29, 2003 1:09:15 PM EST> <Debug> <JTA> <BEA-110027> <ResourceDescriptor[JMSConnectionPool]: checkRecovery: > This message is no longer printed.	8.1 SP1
CR102400	The transaction manager could generate a NullPointerException when trying to contact a remote server that is unavailable. This problem was resolved by a code change.	8.1 SP1
CR102738	An internal API, which was causing a ServerMBean lookup to fail, was changed. This change caused the Transaction recovery process to not recognize changes in a server's listen address. This problem was fixed. Additionally, code was added to ensure that asynchronous retries are attempted until new server information is obtained from the Administration Server. This ensures that the Transaction recovery process completes when the sub-coordinator server comes back up, without having to restart the coordinating server.	7.0 SP3 8.1 SP1
CR103556	When a jndi.properties file existed in the classpath that had a server URL pointing to a different server than the server being booted, a javax.naming.NameAlreadyBoundException was thrown when the transaction manager attempted to bind its TransactionManager object into the local JNDI tree. The exception was thrown because the bind operation was performed on the remote server's JNDI context in which a TransactionManager object already existed. This problem was resolved by a code change to ignore the jndi.properties file while binding objects into the local JNDI tree.	8.1 SP1
CR103601	If an object passed in the "equals" method of weblogic.transaction.internal.XidImpl was not an instance of XidImpl (for instance, it was of type String), then this exception is thrown: java.lang.ClassCastException: java.lang.String at weblogic.transaction.internal.XidImpl.equals(XidImpl.java:114) at test.main(test.java:9) The problem was solved with a code fix to check and report type mismatches.	6.1 SP6 8.1 SP1
CR106174	If all but one participating resources in a transaction respond to prepare with the XA_RDONLY flag, the transaction manager should issue a one-phase commit to the pending participant. However, the TM was unnecessarily writing a commit record for this scenario. The code was changed so that, before writing a log record, it checks to see how many participants require 2nd phase; if one does, the write is skipped. This resolved the problem.	7.0 SP3 8.1 SP1
CR106177	While processing remote beforeCompletion callbacks, the TM resumes the transaction context prior to invoking the registered objects. However, statically registered resources are not enlisted when the transaction is resumed on the thread. The code was changed so that Enlistment is performed on such resources to allow beforeCompletion logic to perform additional updates as part of the transaction. This resolved the problem.	7.0 SP3 8.1 SP1

JVM

Change Request Number	Description	Release Fixed
CR101608	The JVM has a bug whereby it is possible for it to crash while reading an FVD-described class under IIOP. This problem was made worse by a bug in WebLogic Server, whereby it was possible to trivially provoke the problem. This CR refers to the WebLogic bug so that it is no longer trivially possible to cause this crash. However, the bug in the JVM still exists and is only fixed in J2SE 1.4.1_03 (and 1.3.1_09). BEA recommends upgrading to 1.4.1_03 when it becomes available.	8.1
CR105703	Starting in WebLogic Server 8.1, jDriver makes a new JDK 1.4 feature, ByteBuffer, to improve performance. java.nio.charset.CharsetDecoder is also used to decode the bytes in ByteBuffer that are returned from an Oracle server. Unfortunately, CharsetDecoder does not properly decode single byte data. This problem was resolved by adding more international codesets to work around this JDK bug. The codesets include: Shift_JIS, SJIS, windows-31j, MS932, EUC_JP, EUC-JP, ISO-2022-JP, ISO2022JP, EUC_KR, EUC-KR, windows-949, MS949, EUC_CN, EUC-CN, windows-936 MS936, GBK, Big5, windows-950, MS950, Big5_HKSCS, Big5-HKSCS These names are based on JDK 1.4 internationalization.	8.1 SP1

Localization

Change Request Number	Description	Release Fixed
CR108583	The messageid="DefaultMigratableSuffix" of ja/JP/ManagementText.xml was translated to a Japanese String, resulting in an inability for customers to delete a server that was created with the Configuration Wizard. This problem occurred because this String, which is used in a String comparison, should not have been translated in the catalog. This problem was resolved by removing the Japanese translation of the String.	8.1 SP1

Node Manager

Change Request Number	Description	Release Fixed
CR093664	The comment at the beginning of nodemanager.properties that documents the syntax of this file only included SSL configuration information. It now includes descriptions for other commonly used properties.	8.1 SP1

Plug-Ins

Change Request Number	Description	Release Fixed
CR096625	The Apache plug-in sent a X_WEBLOGIC_FORCE_JVMID header to a WebLogic Server instance in a cluster. However, X_WEBLOGIC_FORCE_JVMID should only be sent when the server list is non-clustered and the current server does not yet have a JVM ID. This problem was resolved by modifying the code so that X_WEBLOGIC_FORCE_JVMID is only sent when the server list is non-clustered and the current server does not yet have a JVM ID.	7.0 SP3 8.1 SP1
CR097202 CR103161	A customer needed to determine a browser's cipher strength on the WebLogic side, in a configuration that included a plug-in with 128-bit step up certs between WebLogic Server and the browser. The browser had 40-bit or 128-bit strength. The customer used the following code to obtain the browser's cipher strength: (Integer)httpRequest.getAttribute("javax.servlet. request.key-size") However, the value returned was always 128 (although the browser was set to use a cipher size less than 128-bit). This problem occurred because HTTPS_KEYSIZE determines the strength of the connection that is made. Because 128-bit certs were used on the plug-in, 128 was returned, regardless of the strength used by the browser. When the request was directed to WebLogic Server, 40 or 128 was returned, depending on the browser strength. The plug-in does not modify the HTTPS_KEYSIZE or HTTPS_SECRETKEYSIZE headers. To meet this need, two new headers were implemented: WL-Proxy-Client-Keysize and WL-Proxy-Client-Secretkeysize. Both headers values can be obtained using request.getHeader().	6.1 SP5 8.1 SP1
CR100361	The READ_ERROR exception did not differentiate between reading from a client and reading from a back-end server. (In contrast, there were two different WRITE_ERROR exceptions: WRITE_ERROR_TO_CLIENT and WRITE_ERROR_TO_SERVER.) This problem was resolved by introducing the following new exception types: READ_ERROR_FROM_CLIENT—error when reading data from client READ_ERROR_FROM_SERVER—error when reading data from backend server READ_ERROR_FROM_FILE—error when reading from temporary file which stores post data WRITE_ERROR_TO_FILE—error when writing post data to the temporary file	6.1 SP5 8.1 SP1
CR101222	After fail-over from a primary server to a secondary server for NSAPI and Apache did not recover the failed primary server after the time specified in MaxSkipTime had elapsed. This problem occurred because the bad primary server had not been reset. This problem was resolved by resetting the primary server after the MaxSkipTime had elapsed.	8.1 SP1
CR101596	In the ssl_certchain_verify_callback method, SSLNoErr was returned as the error condition for some failure cases of certification validation. This included cases where the CA certificate had basic constraints that were not marked as critical and the strict setting was enabled (instead of the default "strong" setting), and if the certificate was not marked as being a CA. This problem was resolved by returning X509CertChainInvalidErr for these failure cases (instead of SSLNoErr).	6.1 SP5 8.1 SP1
CR102616	The NSAPI plug-in now supports dynamic DNS lookups on a DNS name when the name returns a list of IP addresses from the DNS server and the plug-in is configured with WebLogicHost = 'DNS name'.	7.0 SP3 8.1 SP1

RMI/RMI-IIOP

Change Request Number	Description	Release Fixed
CR095810	You could not use callbacks through a firewall when using the thin client .jar files (wlclient.jar and wljmsclient.jar) and IIOP or IIOPS. Callbacks did work when using tunneling. Since Bi-Directional IIOP was already supported in the thin-client when tunneling was used, this problem was resolved by generalizing the code so that BiDir could be used with standard IIOP as well as over HTTP.	8.1 SP1
CR097787	Although thin-client IIOP implemented an asynchronous "PeerGone" mechanism, this mechanism did not wakeup pending requests with an exception when a network partition occurred. This problem was resolved by modifying the code so that when BiDir is used, the "PeerGone" mechanism signals an exception on the socket.	8.1 SP1
CR101776	There were no dynamic debug flags for thin clients. This problem was resolved by adding the following debug flags for thin clients: -Dweblogic.debug.client.iiop=true -Dweblogic.debug.client.startup=true -Dweblogic.debug.client.http=true -Dweblogic.debug.client.security=true -Dweblogic.debug.client.ots=true -Dweblogic.debug.client.cluster=true -Dweblogic.debug.client.ssl=true -Dweblogic.debug.client.dgc=true	8.1 SP1
CR102875	When attempting to deploy from ant (wldeploy) on a WebLogic Server instance using the IIOP protocol, the server produced a NullPointerException in weblogic.corba.utils.MarshaledString. This problem occurred because WebLogic was erroneously returning null when retrieving a repository ID from a stub that had been cached by a previous lookup. This problem was resolved by initializing the type ID to the result of the info.getRepositoryId method in cases where the type ID is null.	8.1 SP1
CR103388	WebLogic RMI now supports arrays of primitives.	7.0 SP3 8.1 SP1
CR105892	When using JMS with the IIOP protocol, abnormal disconnection by a client was not being properly detected in the server. This causes problems with stateful information associated with the client, like the JMS client identifier. Abnormal disconnection is now detected and handled appropriately.	8.1 SP1
CR106521	Customer could not pass Any's containing enums to or from CORBA servers. This problem was resolved by fixing the marshaling of enums inside Any's.	8.1 SP1
CR106750	Client-server applications with clients connecting to WebLogic Server over IIOP and invoking server-side logic through EJBs may have experienced intermittent IIOP errors. Specifically, these were CORBA/IIOP MARSHAL and indirection errors in the read_value() method during thin client access. This problem was resolved with a code fix.	8.1 SP1
CR108332	When using a thin client (wlclient.jar), customers may have encountered a marshalling exception that indicated there had been an IIOP stream corruption. This problem occurred when IIOP or T3 was specified as the protocol in multiple minor versions of J2SE 1.4, but not when weblogic.jar was in the client classpath. This problem occurred because of issues with the encoding and decoding of custom marshaled valuetypes and in the way WebLogic Server kept track of indirections when marshaling valuetypes. These issues have been resolved.	8.1 SP1
CR109032	Accessors with checked exceptions were not mapped properly in the IDL, resulting in the wrong IDL being generated. This problem was resolved by modifying the IIOP name mangling code so that it now checks whether accessors (getFoo()) and mutators (setFoo()) throw checked exceptions. If they do, then they are not mangled to IDL attributes (that is, just treated as standard functions).	8.1 SP1

Security

Change Request Number	Description	Release Fixed
CR097038 CR102656	When using the Messaging Bridge, non-trusted domains only worked when using synchronous mode communications. This problem has been resolved so that non-trusted domains also work when using asynchronous mode communications.	7.0 SP3 8.1 SP1
CR098843	The weblogic.management.runtime.ExecuteThread.getUser method always returned null. This problem occurred because there was no way to obtain the current user for a given thread, and was resolved by adding code that does this.	8.1 SP1
CR100783	The ImportPrivateKey utility produced the following message when the wrong private key password was entered: ASN.1: Lengths longer than 32 bits are not supported. That is, rather than indicating a problem with the password, the error message described a problem with the key length. This problem was resolved by modifying the error message to be more appropriate.	8.1 SP1
CR101531	The memory usage of the Embedded LDAP server was reduced by decreasing the size of a buffer used for logging. This reduced the total memory usage by 1.8 million bytes.	8.1 SP1
CR101770	The SSL Login Timeout attribute was unintentionally dropped from the WebLogic Server Administration Console. Support for the attribute was added back into the Administration Console.	8.1 SP1
CR101785	A UsernamePasswordLoginModule LoginModule was added for use by the IIOP thin-client. This class has the same API as that of the weblogic.security.auth.login.UsernamePasswordLoginModule class, but in this implementation, there is a new property called authOnLogin. When true, this property forces the login method to perform authentication (rather than on the first invocation). The default for this new property is false.	8.1 SP1
CR102164	The MBean implementations for the WebLogic Authentication provider and LDAP Authentication providers threw a weblogic.management.utils.InvalidPasswordException if the password was not valid. This behavior was inconsistent with the weblogic.management.security.authentication.UserPasswordEditor's changeUserPassword and resetUserPassword methods, which do not declare a InvalidPasswordException exception. This problem was resolved by removing the weblogic.management.utils.InvalidPasswordException and changing the Authentication providers' MBean implementations to throw a weblogic.management.InvalidParameterException when a password is not valid.	8.1 SP1
CR102221	The SSL closeWriteHandler method produced an IOException when the output stream had already been closed by an application. This problem occurred because the closeWriteHandler method did not check whether the WriteHandler was already closed, and attempted to write an alert to the output stream. This problem was resolved by adding this check.	8.1 SP1
CR102251	In 6.x, the t3 protocol sends authenticated user object between clients and servers. In 7.x and higher, the t3 protocol sends authenticated subject object (which extends the authenticated user object) between clients and servers. When a 7.x server communicates with a 6.x client, it converts any authenticated subjects back to authenticated users before sending them to a client. If the client was communicating with both 8.1 servers and 6.1 servers, it received an authenticated user when it created a context to a 6.x server. When it created a context to a 8.x server, it received an authenticated subject. Depending upon which context was created last, an authenticated subject or authenticated user would be sent to the client. If the context to the 8.1 server was created last, then the client identity was an authenticated subject, which would be passed to both the 6.1 and 8.1 servers. When the authenticated subject was passed to the 6.x server, the 8.1 client attempted to convert it into an authenticated user. The code to do this was only intended to be used on the server-side, so it was failing with an exception that eventually caused an assertion failure. When run with a 6.1 client, things worked correctly, as the client always received an authenticated user. This problem was resolved by modifying the code so that conversions from an authenticated subject to an authenticated user can be called on the client side.	8.1 SP1
CR102443	Attempts to use one Weblogic Server instance as a LDAP server to another WebLogic Server instance that had a LDAP Authentication provider configured failed. The server acting as the LDAP server threw a NullPointerException, while the server configured to use external LDAP hung. This problem was occurred because user and group DNs did not match the hierarchy in the embedded LDAP server for the other domain. This problem was resolved by modifying the code so that an informative error is returned when the credentials supplied are invalid.	8.1 SP1
CR104191	URLResource converted the context path to lowercase on Windows systems, causing a case mismatch between the context path used by Web applications and the WebLogic Security Framework when re-deploying a Web application with security constraints. As a result, security constraints that were removed from the Administration Server were not be propagated to the Managed Servers in the domain. This problem was resolved by adding a verification to ensure that the case of both context paths match.	8.1 SP1
CR104502	utils.der2pem wrote out an extra new line if the number of characters was an exact multiple of the line width, resulting in an invalid .pem file. This problem has been resolved.	8.1 SP1
CR104713	When a WebLogic Server instance was configured for two-way SSL and a WebLogic Identity Assertion provider was configured with the AuthenticatedUser X.509 token type, a ClassCastException was thrown while the server was authenticating the client connecting over SSL. This exception indicated that there was a problem with DefaultIdentityAsserterProviderImpl (the Weblogic Identity Assertion provider). This problem occurred because a token of the wrong type was being passed to the WebLogic Identity Assertion provider. This problem was resolved by ensuring that an array of certificates is passed to the WebLogic Identity Assertion provider.	8.1 SP1
CR105809	Please review the security advisory information at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-33.jsp.	7.0 SP3 8.1 SP1
CR106027	When logging into the Administration Console as a Monitor, a user could still have access to the 'Configure new Application' screen. This constituted a security hole, because it allowed a monitor to upload a file to any place the WebLogic server can see. The problem was resolved with a code fix.	7.0 SP3 8.1 SP1
CR108958	Currently WebLogic Server allows a JCE provider to be configured and used for SSL unless it is determined that the JCE provider is not working with Certicom. If the latter is the case, WebLogic Server adds it to the list of JCE providers known to cause problems. When Certicom discovers that the installed JCE provider is in this list, it ignores it and uses the Jsafe implementation instead. The IBM JCE provider has been added to this list, so it is now ignored by the Certicom SSL implementation, but is still available for other applications.	8.1 SP1

Servlets & JSPs

Change Request Number	Description	Release Fixed
CR088670	When returning a license error, WebLogic Server produces a 403 page that explains the problem. However, this message has a content-type of x-weblogic/internal, when it should have a content-type of text/html. This caused an "open with application or download file" prompt on Mozilla. This problem was resolved by modifying the content-type to be text/html.	8.1 SP1
CR092778	When using JISAutoDetect encoding (which is used to accept Shift-JIS, EUC-JP and ISO-2022-JP for input streams without code/configuration modification) with an HTTP request, an UnsupportedEncodingException was thrown, starting with the following lines: java.io.UnsupportedEncodingException: JISAutoDetect at sun.io.Converters.getConverterClass(Converters.java:102) at sun.io.Converters.newConverter(Converters.java:133) at sun.io.CharToByteConverter.getConverter(CharToByteConverter.java:62) at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding(ServletRequestImpl.java:344) ... This problem occurred when a JSP/servlet called request.setCharacterEncoding("JISAutoDetect"). This problem was caused because ServletRequestImpl.java used sun.io.CharToByteConverter, instead of sun.io.ByteToCharConverter. CharToByteConverter is for an output converter, while JISAutoDetect is only available for an input stream. This problem was resolved by changing to ByteToCharConverter, which accepts JISAutoDetect.	6.1 SP5 8.1 SP1
CR093209	A new installation of WebLogic Server threw a NullPointerException when a successfully deployed Web application with a property set to java protocol was accessed. The browser returned Error 500--Internal Server Error. The problem did not occur with an upgrade installation. <Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP> <[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with Exception java.lang.NullPointerException at weblogic.servlet.JSPServlet.service(JSPServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCon ext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:235) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)> Analysis revealed an error in ZipSource.getURL(). The problem was resolved by adding logic to check for a null value of source.getURL().	6.1 SP5 8.1 SP1
CR093625	In WebLogic Server 6.1 SP3 and SP4, servers misdirected output for JSP includes in JSP pages. The problem was resolved with changes to the servlet engine to unify handling of includes, forwards, wrapped-responses, and JSP BodyTags.	6.1 SP5 8.1 SP1
CR094190	According to the JVM specification, the size limit for a method is 64K. Some WebLogic Server customers have JSPs with many body tags, for which the generated Java code exceeded the 64K limit for the __jspService method. The problem was solved by a code change. Now, when an empty BodyTag of the form <my:tag ... /> is encountered, the generated code that would normally set up scope for the body is replaced by a single call to a static method in StandardTagLib.java. This tricks the BodyTag into thinking it is being invoked as usual from the JSP source.	6.1 SP5 8.1 SP1
CR094488	A new capability was added to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add AuthCookieEnabled="true" to the WebServer element in config.xml: <WebServer Name="myserver" AuthCookieEnabled="true"/> This will cause an new secure cookie to be sent to the browser when authenticating via an HTTPS connection. Once set, the session can access other security-constrained HTTPS resources only if the cookie is sent from the browser. Note: If authenticating via plain HTTP, the secure cookie will not be set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie will not be verified (since it will not have been sent from the browser). This allows the browser to access non-protected HTTPs resources without the user logging in.	6.1 SP5 8.1 SP1
CR095981	<charset-mapping> in weblogic.xml was ignored when compiling JSP files with precompile=true. As a result, some of double byte characters were garbled because of the mismatch between the character's encoding specified in <charset-mapping> and in the compiled classes. Analysis revealed an error in the precompiler. The problem was solved with a code fix.	6.1 SP6 8.1 SP1
CR097719	In WebLogic Server SP02, SP03, and SP04, when getting certain POST requests from WAP devices, a Web application encountered a java.util.ConcurrentModificationException: <29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at weblogic.utils.enumerations.IteratorEnumerator.nextElement(IteratorEnumerator.java:25) at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML(XMLSwitch.java:347) at ... Analysis revealed that when a charset is associated with the request's content-type, the code read the data again using the encoding, and reset the query parameters, in the application. The application already has the enumeration object and iterates it (request.getParameterNames), and then tries to get the value of the parameter (request.getParameterValues(k)). At that point, the query parameters are wiped out and getParameterValues method tries to set it, resulting in the exception. The problem was resolved by a code change to set query parameters after they are wiped, so that the data can be read again when a charset is associated with the request's content-type.	8.1 SP1 6.1 SP5
CR097759	There was no timestamp associated with VM thread dumps. This problem was resolved by modifying the code so that a message of the following format is printed before a VM thread dump (applies only to thread dumps taken with the weblogic.Admin thread dump command): THREAD DUMP from JVM taken at 'Mon Mar 24 16:26:13 2003'	8.1 SP1
CR098955	If logRotationBeginTime was a past date and the interval between logRotationBeginTime and today's date was large, calculation of the rotation time was flawed, due to improper casts of long to int. This has now been resolved.	5.1 SP14 8.1 SP1
CR100068 CR110324	You could not use JSTL tags in JSPs that included Japanese characters. When the JSP was executed, an error starting with the following lines would occur: java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x82) was found in the CDATA section." ... This problem occurred because of the following, conflicting conditions: 1. The page encoding of JSPs is defined by Shift_JIS, as in: <%@ page pageEncoding="Shift_JIS" %> 2. Using multibyte characters (Japanese) in JSPs. 3. Using JSTL tags. This problem was resolved by modifying the encoding of the byte stream returned from the weblogic.servlet.jsp.StandardTagLib.makeXMLStream method to UTF-8.	7.0 SP3 8.1 SP1
CR100172	When multiple chunked requests were posted to a servlet, a number of the requests failed with a NumberFormationException, starting with the following lines: <ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException: ... This problem occurred because the code incorrectly attempted to detect the end of the chunk at the wrong place. This problem was resolved by modifying the code so that it reads until the end of the stream, and detects the end of the chunk correctly.	7.0 SP3 8.1 SP1
CR100188	The AuthCookie feature did not work for certificate authentication. (AuthCookie is a secure cookie used to make HTTP to HTTPS transitions secure.) This capability was added in WebLogic Server 6.1 SP5 to allow a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. This problem was resolved with a code fix.	8.1 SP1
CR100260	When an HTTP request was proxied by a WebLogic proxy to a cluster using the non-default network channel, the cluster list returned was with respect to the default channel. Thereafter, the plug-in started proxying to the default channel, instead of the original network channel, which may not have been reachable. This problem was resolved by modifying the code so that the dynamic server list is aware of non-default network channels.	8.1 SP1
CR100570	While saving changes for weblogic.xml from WebLogic Builder, it created extraneous entries in the weblogic.xml file for the deployment descriptor MBeans. The extra entries were defaults and did not need to be added to the weblogic.xml file. This problem was resolved by modifying the code so that the entries are only written to the weblogic.xml file if the default values have been changed.	8.1 SP1
CR101996	Use of xmlx tags with request and response wrappers resulted in ClassCastExceptions since the tags internally cast to the internal request and response implementations. This problem was resolved by unwrapping the request and response instances to the original internal representation. Use of the xmlx tag may have also produced an IllegalStateException indicating that an attempt was made to use getWriter after getOutputStream. This problem was resolved by modifying the code to appropriately reset the output state prior to calling getOutputStream.	8.1 SP1
CR102057	Including a static resource in a request with no buffer size (for example, response.setBufferSize(0)) could lead to an infinite loop. This problem was resolved by guarding against this case.	8.1 SP1
CR102062	The ServletContext.getResourcePaths method returned incorrect results when called in a WAR file, and in the case of split-directory deployments, the Set returned by this method only contained the results from the srcdir (it did not contain the results from the outputdir). This problem was resolved by a code fix.	8.1 SP1
CR102077	weblogic.servlets.internal.InternalRequestDispatcher throws a StringIndexOutOfBoundsException if given a URI whose length is 0 (for example, an empty HTML file). This problem was resolved by guarding against this condition.	8.1 SP1
CR102499	If an attribute was added to the request using the Web application classloader and if the request gets delegated to a child classloader of the Web application's classloader, upon request.getAttribute(), the Web application container was trying to deserialize the attribute in order to avoid a ClassCastException. This was resulting in Serialization errors. The Web application container code will now be able to detect that the class was loaded by a parent classloader. If true, it will not deserialize. However, if the child places attributes into the request using setAttribute(), this will not work if the class or references within are child scoped only, or the class or references within are not serializable. You can workaround the second problem by pushing and popping the Web application classloader temporarily for setAttributes() in the child classloader.	8.1 SP1
CR102667	A NullPointerException was thrown by a Web application module if the context with the same name was previously deployed using the old deployment model (6.x deployment model). This problem was resolved by ensuring that if present, the old deployment model is handled correctly.	8.1 SP1
CR102763	ExternalDNSName is deprecated for Network Channels (not servers). Customers should make use of the new Public Address for channels, when a firewall is between a proxy Web server and a cluster. Additionally, customers should use paired channels for HTTP and HTTPS. More information is available in the Firewall Between Proxy Layer and Cluster section of Using WebLogic Server Clusters.	8.1 SP1
CR103059	A <url-pattern> value with a single character in a <servlet-mapping> element was not honored in a web.xml deployment descriptor. For example, <url-pattern>*.f</url-pattern> produced a 404 File Not Found error when attempting to access welcome.f , but <url-pattern>*.oop</url-pattern> worked properly when attempting to access welcome.oop. This problem has been resolved so that single character <url-patterns> now work as expected.	8.1 SP1
CR103095	When the authentication method associated with a Web application module was invalid and the Web application module was being deployed, no error message was produced, and the authentication method was defaulted to BASIC authentication without notification. This problem was resolved by modifying the code so that a Web application module with an invalid authentication method will not be deployed, and a message indicating the problem will be displayed in the server log file, as well the Administration Console or stdout (depending on how the Web application module is deployed).	8.1 SP1
CR103192	If clients did not have session cookies enabled, users were not able to log in to secured Web sites over HTTPS. It was possible to workaround this problem by manually disabling the AuthCookie, which up until WebLogic Server 8.1, had been disabled by default. This problem was resolved by automatically disabling the AuthCookie check when the Web application has session cookies disabled.	8.1 SP1
CR103247	WebLogic Server could not locate implicit TLDs when using the split directory feature. This problem occurred because the resourceFinders were being updated after the implicit TLDs were loaded. (The updating of resourceFinders is responsible for adding the srcdir and the destination (outputdir) directories.) This problem was resolved by updating the resourceFinders before the extraction process.	8.1 SP1
CR103925	The setAttribute method only checked for hashCode equality. It now also checks the result of the equals method for the old and new objects.	8.1 SP1
CR104410	When PersistentStoreType was set to "replicated," customers who had successfully deployed an application received an "Internal Server error" message when attempting to access the application from a browser. In addition, the following exception was logged on the server: weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ServletSessionRuntime Action: register, Target: null This problem was resolved by modifying the code so that a session with session monitoring enabled could be successfully created.	8.1 SP1
CR104469	The fastfile.dll file, which is required for native IO for the FileServlet on Windows, was not working with the JRockit JVM. This problem has been resolved.	8.1 SP1
CR105171	'load-on-startup' JSP files were being compiled by weblogic.jspc, even when the <jspServlet> element in weblogic.xml indicated that weblogic.servlet.WlwJSPServlet should be used. This problem was resolved so that the specified compiler will be used.	8.1 SP1
CR106172	The deployment of a Web application with the precompile option set to true in weblogic.xml failed, with a JSLT tag validator error of org.xml.sax.SAXParseException. This problem occurred because when precompile was set to true, the JSP file was not being passed to the method that performs validation. This problem was resolved by modifying the code to properly pass the JSP file to the method that performs validation.	8.1 SP1

System Administration

Change Request Number	Description	Release Fixed
CR080353	Converting the weblogic.properties file using the domain convertor does not produce any entry for weblogic.password.guest=<guestpassword>. Although the conversion is successful, an error similar to the following may be encountered: java.lang.SecurityException: Authentication for user guest denied in realm weblogic This problem was resolved by modifying the code so that a warning indicating how to obtain the old behavior is displayed: <Apr 12, 2003 10:29:30 AM EDT> <Warning> <Management> <BEA-141186> <User Guest has been disabled by default. If you would like to enable Guest, you should do it manually.>	8.1 SP1
CR098920	Improvements were made to message catalog Detail/Cause/Action information, based upon BEA Support's review of existing System Administration catalog messages.	8.1 SP1
CR099404	When using the Security Service Provider Interfaces (SSPIs) to create MBeans to manage your custom security providers, if you attempted to use the same ObjectName for more than one MBean, WebLogic Server wrapped the underlying JMX exception, InstanceAlreadyExistsException, inside a generic MBeanException. In SP1, the true exception is thrown.	8.1 SP1
CR100331	When starting up a server in an empty directory using the following command, the warning message transposed the Domain Name and Server Name: . /bea/wls810/curr2weeks/weblogic/server/bin/setWLSEnv.sh /bea/wls810/curr2weeks/jdk141_02/bin/java -Dweblogic.management.GenerateDefaultConfig=true -Dweblogic.ListenAddress=172.18.136.38 -Dweblogic.ListenPort=7101 -Dweblogic.Domain=rmiiiopStressCluster -Dweblogic.Name=adminServer -Dweblogic.management.password=weblogic -Dweblogic.management.username=weblogic weblogic.Server The incorrect warning message was similar to: <Mar 6, 2003 9:17:24 AM EST> <Warning> <Management> <BEA-140012> <Creating default domain adminServer with default server rmiiiopStressCluster.> This problem was resolved by correcting the warning to: <Mar 6, 2003 9:17:24 AM EST> <Warning> <Management> <BEA-140012> <Creating default domain rmiiiopStressCluster with default server adminServer.>	8.1 SP1
CR101002	Security roles for an EAR that were only defined in application.xml (that is, not also defined in weblogic-application.xml) were not made available to the WebLogic Security Service, and therefore were not visible in the Administration Console. This problem was resolved with a code fix, and these resources now appear in the Administration Console as expected.	8.1 SP1
CR101144	When attempting to log into UDDI after a server reboot, the following exception was thrown: <Mar 25, 2003 11:23:05 AM CST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=1 4133705,name=uddi,context-path=/uddi)] Root cause of ServletException. weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: EmbeddedLDAPConfig Action: read, Target: Credential at weblogic.management.internal.SecurityHelper$IsAccessAllowedPrivilegeA ction.wlsRun(SecurityHelper.java:492) The exact steps to reproduce this problem are as follows: 1. In an empty directory, create and start a WebLogic Server instance. 2. Load http://localhost:7001/uddiexplorer/index.jsp. 3. Navigate to Search Private Registry and click SEARCH. 4. Stop the server, then restart it. 5. Repeat steps 2 and 3 above, and the error will occur. This problem is due to a change to ensure that access to protected attributes is not allowed unless users are granted the Admin security role. This problem was resolved by modifying the UDDI code to run as an identity that has administrative privileges. This way, it can obtain access to the embedded LDAP password attribute it requires.	8.1 SP1
CR101246	For any action that requires reading an encrypted password field (such as attempting to deploy a JDBC connection pool), users of the Administration Console who are granted the Deployer security role received an exception similar to the following: Access not allowed for subject: principals=[DeployerUser, Deployers], on ResourceType: JDBCConnectionPool Action: read, Target: Password This problem was resolved by modifying the code so that users granted the Deployer security role have read access on all the DeploymentMBeans. This means that users granted the Deployer security role will also have read access to encrypted attributes on DeploymentMBeans. The password attribute on the JDBCConnectionPoolMBean was also affected by this change.	8.1 SP1
CR102149	A WebLogic Server instance gave an OutOfMemoryError when receiving 21,000 persisted messages synchronously in a transacted session on Solaris. The garbage collector was slow at reclaiming long lists that are freed. Breaking up the linked lists fixed the problem.	7.0 SP3 8.1 SP1
CR102706	In a cluster, a Managed Server attempting to update an Administration Server may have encountered a java.lang.NullPointerException. This problem occurred because of an issue with the registering of NotificationListeners. This problem was resolved by correcting the processing for registration/unregistration of NotificationListeners to protect against the possibility of a NullPointerException when attempting to unregister a NotificationListener, when no NotificationListener had been previously registered.	8.1 SP1
CR102805	The weblogic.webservice.client.BaseWLSSLAdapter.addIdentity(java.security.cert.X509Certificate[] chain, java.security.PrivateKey privateKey) method is no longer mistakenly marked as deprecated. The other two versions of this method are still correctly deprecated.	8.1 SP1
CR102807	A warning and a java.lang.NullPointerException may have occurred if a server name was not specified when first booting an Administration Server from a newly-created directory. This problem was resolved by modifying the code so that a management error is reported if a server name is not specified when booting an Administration Server.	8.1 SP1
CR102849	Domain log messages file resulted in a synchronous network IO, creating the possibility for deadlocks or other issues to arise. This problem was resolved by modifying the code so that messages are now broadcast to the domain log asynchronously.	8.1 SP1
CR103117	Customers who attempted to upgrade Web Service clients from WebLogic Server 7.1 to 8.1 may have experienced ClassNotFoundExceptions when the client was invoked using the webserviceclient.jar. This problem occurred because the weblogic/webservice/PartFilter.class and weblogic/webservice/core/FaultMessage.class files were missing from the webserviceclient.jar. They have now been added.	8.1 SP1
CR103831	A deadlock condition occurred when the server and domain logs were being rotated at the same instant on the Administration Server. (See also CR102849.) This problem was resolved by modifying the code so that messages are now broadcast to the domain log asynchronously.	8.1 SP1
CR103935	After the error messages were printed to the domain log file, the server logging service was shut down. If the problem occurred, not all log messages were printed to the server log file. This problem occurred on both the Administration Server and the Managed Server(s). This problem occurred because in selecting the log file to rotate to, a log file that already existed on the file system would be chosen. Therefore, any attempt to rotate would result in a failure. When log files are rotating at a fast rate, it is possible that the file handle is still not released. As such, this problem was resolved by determining the oldest and latest files based on last modified timestamps, and offsetting the rotation size if any failure is encountered.	8.1 SP1
CR104008	The weblogic.Admin SHUTDOWN and FORCESHUTDOWN commands can now retrieve user credentials from a boot identity file. This enables you to invoke these commands from a script without storing unencrypted user credentials in the script. For more information, refer to SHUTDOWN and FORCESHUTDOWN in the WebLogic Server Command Reference.	8.1 SP1
CR104966 CR105251 CR105252	The HTTP log rotation time format was not consistent with the format indicated in the online help. If the format specified in the online help was used, a parse error would be seen the next time the WebLogic Server instance was started, and it would not start. If the expected date format (MM-dd-yyyy-k:mm:ss) is not specified, the Administration Console now indicates the problem. The online help has been corrected to indicate this format.	8.1 SP1
CR105198	The following exception was displayed during startup of cluster instances after an Open LDAP Authentication provider was added to a default (active) security realm: com.rsa.jsafe.JSAFE_PaddingException: Could not perform unpadding: invalid pad byte This problem was resolved by having the Managed Server obtain the Administration Server's Encrypted Service and perform the proper Encryption.	8.1 SP1
CR105777	Exception propagation was not working properly because RemoteException was not being treated as a valuetype for rapid caching. Caching only real valuetypes fixed the problem.	7.0 SP3 8.1 SP1
CR120295	Some logging methods were inadvertently publicized. In the WebLogic Server 8.1 API Reference (Javadoc) for the weblogic.logging.WLLogRecord MBean, the setter methods should not have been made public. The attribute values in this MBean are precomputed and set internally; they should not be modified. In addition, in the API documentation for the weblogic.logging.WLLevel MBean, the constructor should not have been made public. The WebLogic logging services support a fixed set of levels, so creating your own WLLevel is not supported. You can extend the java.util.logging.Level class which is handled after appropriate mapping to WLLevel by the WebLogic logging service.	8.1 SP1

Tools

Change Request Number	Description	Release Fixed
CR069568	The EJB 2.0 DTD allows for multiple roles and multiple methods to be defined inside one method-permission element. While WebLogic Builder allowed users to define multiple roles, it only allowed one method. This problem was resolved by modifying WebLogic Builder so that users can specify both multiple roles and multiple methods in one method-permission element.	8.1 SP1
CR093246	A new tag called <allow-remove-during-transaction> was added to the weblogic-ejb-jar.xml deployment descriptor. This tag was added for stateful session beans and is the child of the <stateful-session-descriptor> tag. However, the tag was not surfaced in WebLogic Builder. This problem was resolved by adding the 'Allow remove during transaction' check box to the Advanced Pane of a Session in WebLogic Builder.	7.0 SP3 8.1 SP1
CR096719	WebLogic Builder did not expose pool settings for entity beans. This problem was resolved by adding a Pool Panel for entity beans to the Tuning sub-node.	7.0 SP3 8.1 SP1
CR099865	Setting a default transaction value (default-tx) on a single bean using the <container-transaction> tag would result in the default transaction value being set the same way for all the beans in the same JAR. This problem was resolved by modifying the code so that setting the default transaction value on a single bean did not affect the same setting for other beans in the JAR.	7.0 SP3 8.1 SP1
CR099913	The automatic key generation frame in WebLogic Builder did not enable/disable all fields consistently. For example, if you opened a JAR that did not have an <automatic-key-generation> tag and loaded the Automatic Key Generation tab, the check box would be unchecked, but you could still enter a value. This problem was resolved by modifying the code so that the fields are uniformly disabled.	7.0 SP3 8.1 SP1
CR102990	WebLogic Builder no longer allows users to delete a role if it is being used in a method permission.	8.1 SP1
CR103200	If a Java source file that did not end in the .java extension was provided to source2wsdd, it would fail with the following error: [source2wsdd] source2wsdd: Illegal package name This was problematic since the convention for EJBGen source code files that are in split directories is for the suffix to be .ejb. This problem was resolved by modifying source2wsdd so that it would accept either a .java or .ejb suffix.	8.1 SP1
CR105436	java weblogic.marathon.ddinit.WebInit stageDir was failing to generate servlet components in weblogic.xml and web.xml. A regression in the codeline cause the problem. This was fixed and the problem was resolved.	7.0 SP3 8.1 SP1
CR108254	wlcompile failed when calling EJBGen if the classpath contained spaces. This problem occurred because when wlcompile forked EJBGen, it did not quote the classpath. As a result, if the classpath contained spaces, some of the elements were misinterpreted. This problem was resolved by making sure the classpath is treated correctly.	8.1 SP1

Utilities

Change Request Number	Description	Release Fixed
CR101046	weblogic.BuildXMLGen overwrote an existing build.xml file without warning. This problem was resolved by adding the following warning message: weblogic.utils.compiler.ToolFailureException: Build File already exists, use -file to specify alternative build file name.	8.1 SP1

WebLogic Workshop

Change Request Number	Description	Release Fixed
CR102094	The script used to start the WebLogic Workshop sample server, WL_HOME\samples\workshop\startWebLogic.cmd was not installed in the WebLogic Server 8.1 release. Therefore, you could use the Windows Start Menu selection to start the sample server because it referred to this missing file. This problem has been fixed.	8.1 SP1

Web Services

Change Request Number	Description	Release Fixed
CR085000	A StackOverFlowError occurred during the serialization of a java.lang.Object. This problem was resolved by using Object.toString() for instances of the class java.lang.Object.	8.1 SP1
CR087303	When processing the following WSDL file, the clientgen ant task created invalid classes: wsdl:message name="UploadCBProfileRequest"> <wsdl:part name="body" element="tns:TRAMSDATA"/> <wsdl:part name="authHeader" element="tns:AuthenticationHeader"/> </wsdl:message> <wsdl:portType name="RelMgrPortType"> <wsdl:operation name="uploadCBProfile"> <wsdl:input message="tns:UploadCBProfileRequest"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RelMgrSOAPBinding" type="tns:RelMgrPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http";/> <wsdl:operation name="uploadCBProfile"> <soap:operation soapAction="" style="document"/> <wsdl:input> <soap:body parts="body" use="literal"/> <soap:header wsdl:required="true" message="tns:UploadCBProfileRequest" part="authHeader" use="literal" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> </soap:header> </wsdl:input> </wsdl:operation> </wsdl:binding> The resultant generated task contained duplicate uploadCBProfile() arguments. Research revealed that the code was adding header parts to message even if that part was already there. A code fix resolved the problem.	7.0 SP3 8.1 SP1
CR094458	It is now possible to configure Web Service security requirements on a per operation basis for both requests and responses.	8.1 SP1
CR096558	This version of WebLogic Server uses a newer version of SOAP 1.2 specification (W3C Candidate Recommendation 19 December 2002).	8.1 SP1
CR097887	Web Service deployment descriptors and WDSL did not support all XML encodings. This may have resulted in the following error when using servicegen: [servicegen] java.io.CharConversionException: Unconvertible UTF-8 character This problem was resolved by using the weblogic.webservice.i18n.charset property to support encodings for Web Service deployment descriptors and WSDL.	8.1 SP1
CR098050	When deserializing a xsd:string to a java.lang.String, certain characters, for example '/', were causing the resulting String to be truncated. This problem was resolved by modifying the String deserializer to handle multiple character data events.	8.1 SP1
CR099028	A soap header with a simple type used the wrong namespace (schema namespace). This problem was resolved by fixing the soap header to use the target namespace of the Web Service.	8.1 SP1
CR099030	A one-way call to a WebLogic Server instance used to wait until the end component invoke was complete. Now the client returns after sending the request.	8.1 SP1
CR100386	javax.xml.rpc.Call.SESSION_MAINTAIN_PROPERTY was not supported. In other words, nothing was done with this property if it was set on the client, which violated section 13.7 (Session Management) of the JAX-RPC 1.1 specification. This problem was resolved by adding support for this property.	8.1 SP1
CR100528	If you defined two Web Services using the same serviceNames and serviceURIs, as in: service serviceName="SessionFoo" serviceURI="ejb20test" service serviceName="SessionFoo" serviceURI="ejb20test" both nodes would be merged into one Web Service (with a merged offering of operations). However, if you defined two Web Services using different serviceNames and the same serviceURIs, as in: service serviceName="SessionFoo" serviceURI="ejb20test" service serviceName="SessionBar" serviceURI="ejb20test" only one of the Web Service's operations would show up under ./ejb20test. This problem was resolved by adding a check in servicegen to be sure that the same serviceURI is not used in more than one Web Service. If it is, you will now get a build error.	8.1 SP1
CR100807	The default method for Web Service back end components was not being called, therefore, the server-side dispatcher was not working properly. This problem was resolved with a code fix.	8.1 SP1
CR100932	Default type mappings are now able to load the types.xml file from the classpath.	8.1 SP1
CR101149	When JMS transport was enabled and a browser was used to test a Web Service with multiple operations using different transports, the test page would display all operations in one section and did not distinguish between them. This problem was resolved by fixing the test page so that it is now possible to distinguish between operations using different transports.	8.1 SP1
CR101160	In WSDL, it is possible to describe SOAP faults than contain complex types. This was not supported in the WebLogic container. This problem was resolved by implementing sections 5.5.5 and 4.3.6 of the JAX-RPC specification.	8.1 SP1
CR101369	The SOAPFaultException faultactor and faultstring are no longer reversed.	8.1 SP1
CR101416	Javax.xml.rpc.Service.getProxy( <stub-class> ) did not work correctly when one XML type was mapped to many Java types. This is fixed by using both Java and XML types to lookup for codecs.	8.1 SP1
CR102139	Web Services security now includes timestamps on signed messages. The security portion of the Web Service deployment descriptor has been extended to allow timestamp processing to be configured.	8.1 SP1
CR102328	A ClassNotFoundException was thrown while attempting to build a Web Service. While building the Web Service using the servicegen utility, an error starting with the following lines would occur: java.lang.ClassNotFoundException: weblogic.management.descriptors.WebElementMBean at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) ... This problem occurred because WebLogic Server was not able to locate the weblogic.jar and webservices.jar files when they were not added to the system's CLASSPATH. This problem was resolved by modifying the code so that WebLogic Server always loads classes from the thread's context classloader.	8.1 SP1
CR102686	The asynchronous Web Service client failed and printed the following debug information when only the webserviceclient.jar was in the client's classpath: java.lang.ClassNotFoundException: weblogic.kernel.Kernel Note: This problem was not encountered if weblogic.jar was also in the classpath. This problem was resolved by preventing the debug information from being printed, and by including weblogic.kernel.Kernel in the webserviceclient.jar.	8.1 SP1
CR102772	Adding a SOAP Header block with child elements, in a client-side handler without using a namespace prefix: (via SOAPEnvelope.createName(String localName) and SOAPHeaderElement.addNamespaceDeclaration("","http://identifier.company.com/Context/v1";) ) caused the SOAPHeader.getChildElements(javax.xml.soap.Name) method to return an empty Iterator against that SOAP Header block inside a server-side handler. This problem was resolved so that you can now add default namespaces by using SOAPHeaderElement.addNamespaceDeclaration("","http://foo.bar/" ).	8.1 SP1
CR102745	The weblogic.webservice.binding.jms.ConnectionPool.getInstance().close() method, which is required only for light clients using JMS transport because of a bug in the SDK, has been added to the Javadocs.	8.1 SP1
CR102985	If a reliable request was made to a Web Service that did not exist, a SOAP fault exception was returned. The behavior of the sender was not deterministic in this case. This problem was resolved by modifying the code so that 1. 1. If there is a SOAP fault, a delivery failure is reported. 2. If there are no reliability headers in the response, the request is retried. 3. If the status is DUP or OK, the message is removed from the queue.	8.1 SP1
CR103111	A SOAP message was always treated as platform default encoding when it was encrypted and decrypted. This problem was resolved by allowing SOAP messages to have a specified encoding in the handler of the secure message. Web Service applications and clients that use WS-Security can now exchange non-ascii characters by specifying an encoding. The method of specifying an encoding is the same as for a non-secure SOAP message, except the setAcceptCharset() method in weblogic.webservice.binding.BindingInfo is ignored. If no encoding specified, UTF-8 is used.	8.1 SP1
CR103394	Optional parameters could not be set to null from a Java client using the stub generated from WebLogic Workshop. The optional parameters were always sent with default values. This problem was resolved by modifying the code so that optional parameters are not written or sent in the SOAP request from the client to the Web Service unless the value of the optional parameter(s) in the client is set in the client that uses the generated stub.	8.1 SP1
CR103791	java weblogic.webservice.autotype did not handle arrays of user types as a Java type. For example, the first statement shown below would work, but the second would not: java weblogic.webservice.autotype -destDir /tmp/z88 -javaTypes 'foo.bar.tests.SomeBean' java weblogic.webservice.autotype -destDir /tmp/z88 -javaTypes '[Lfoo.bar.tests.SomeBean;' This problem was fixed by correctly loading Array classes.	8.1 SP1
CR104187	A serialization problem occurred when sending a SOAP message to a Web Service generated using wsdl2service from GenericDataService.wsdl. This problem was resolved by modifying the code so that nested model types with maxOccurs set to a value greater than 1 work properly.	8.1 SP1
CR104719	Implementing a Web service with the following signature: public void echoDom(Document doc) resulted in a compile error. This problem was resolved by disallowing void to be added to type-mapping for document style at build or runtime, preventing the writing of void part for document style, and avoiding using the wrapper element in the Document serializer for document style.	7.0 SP3 8.1 SP1
CR104989	java weblogic.webservice.autotype failed to generate serialization/deserialization classes for complex types that contained only references to named model groups. This problem was resolved so that the classes are generated.	8.1 SP1
CR105353	Adding useSOAP12="true" to the web-services.xml file of a Web Service caused a javax.management.InstanceAlreadyExistsException to be generated during deployment of the Web Service. This problem was resolved with a code fix.	8.1 SP1

XML

Change Request Number	Description	Release Fixed
CR095744	The XMLCacheRuntimeMBean and XMLCacheCumulativeRuntimeMBean interfaces, which were not being used, have been deprecated and are now excluded from the Javadoc.	8.1 SP1
CR100798	In XMLDsig signed messages, the syntax for X509SerialNumber was invalid. This problem occurred because X509SerialNumber was base64 encoded instead of just a String, and the problem was resolved by making this modification.	8.1 SP1
CR102397	The Xerces parser always attempted a call to System.getProperty(). This would throw an exception in an Applet, which does not have permission to retrieve properties. The following partial exception could be observed in an Applet making a JMS call: ----------- Linked Exception ----------- java.rmi.MarshalException: failed to marshal connectionCreate(Lweblogic.jms.dispatcher.DispatcherWrapper;); nested exception is: java.rmi.UnexpectedException: Failed to parse descriptor file; nested exception is: java.security.AccessControlException: access denied (java.util.PropertyPermission weblogic.apache.xerces.maxentityrefs read) [...] The code was modified so that the parser does not attempt to read system properties with Applet clients.	6.1 SP6 8.1 SP1
CR103083	Lookups on xsd:include'd types did not work for backward references. This problem was resolved by modifying the code so that if necessary, lookups properly went back up the include chain.	8.1 SP1
CR103109	For user-defined strings of simple type, the autotyper failed. The resulting generated code contained unqualified references to java.lang.String. This problem was resolved by making every usage of any class use the full package name.	8.1 SP1