This script outputs the product breadcrumb required for edocs documentation. > Known and Resolved Issues > WebLogic Server Known and Resolved Issues The following sections describe known problems in WebLogic Server 10.0 and later Maintenance Packs, as well as problems that were resolved in version 10.0 and subsequent Maintenance Packs. Entries include a description of the problem, and a workaround or solution where appropriate. A notation in the Fixed In column indicates that the problem has been resolved. For information about new and changed functionality in WebLogic Server 10.0, see What’s New in WebLogic Server 10.0 .

Administration Console

Apache Beehive Support

Cluster

Connector (Resource Adapter)

Console Extensions

Core Server

Deployment

Examples

Installation

Java EE

JSP and Servlet

Java Virtual Machine (JVM)

Monitoring

Node Manager

Operations, Administration, and Management

Protocols

Security

Spring Framework on WebLogic Server

Upgrade

Web Applications

Web Logic Scripting Tool (WLST)

Web Server Plug-Ins

Web Services and XML

WebLogic Tuxedo Connector

Miscellaneous

Disclaimer This section also provides information about issues planned to be resolved in WebLogic Server 10.0 Maintenance Pack 2 (10.0 MP2), in advance of the general availability of WebLogic Server 10.0 MP2. For final information about resolved issues see the Release Notes that will be published when 10.0 MP2 becomes generally available. Note: WebLogic Server 10.0 MP2-specific information is subject to change, and patches for 10.0 MP2 CRs are currently neither integrated with the latest available version of WebLogic Server nor available for download. After a page flow completes in the Administration Console, it forwards to a different page, typically a table. Pressing the browser back button at this point results in an attempt to load the last JSP file in the completed assistant. At this point, all of the context for this assistant is discarded. Workaround or Solution: BEA recommends that you do not use the browser back button to step back into an assistant once changes are cancelled or finished, and that you do not go back to a previous step in an assistant. Instead, use the navigation links and buttons in the Administration Console. Some WebLogic Server Administration Console pages did not work correctly in a proxy server environment. In some circumstances, pages were constructed with incorrect URLs. Workaround or Solution: The URL construction method has been corrected and the WebLogic Server Administration Console now works correctly when accessed from a browser behind a proxy server. In the Administration Console Online Help, the Search button always returns “0 documents found.” Workaround or Solution : Search the Administration Console Online Help that is published at
http://edocs.bea.com/wls/docs92/ConsoleHelp/ Enter your search query in the text box that is in the upper right corner of the document. To search for text that appears only in the Online Help, include the following string with your query: docs92/ConsoleHelp For example, the following query finds all instances of “SNMP” in the Administration Console Online Help: SNMP docs92/ConsoleHelp To archive configuration files, the following two parameters need to be configured appropriately: <archive-configuration-count>10</archive-configuration-count> <config-backup-enabled>true</config-backup-enabled> However, the Administration Console did not enable you to configure the parameter config-backup-enabled. Workaround or Solution : You can now configure these parameters in the Administration Console on the Domain: Configuration: General page, in the Advanced section. The WebLogic Server Administration Console did not provide the ability to monitor connection details for a Jolt Connection Pool. This feature was present in previous versions of WebLogic Server. Workaround or Solution : You can now use the Administration Console to view details for each Jolt Connection Pool connection. Click on a connection pool entry in the monitoring table to display a page with details for each connection. In the Administration Console Online Help, links to other WebLogic Server documents point to http://docs-stage/wls/docs92/ , which is the wrong URL root. Workaround or Solution : After you click on a link to a WebLogic Server document, in your Web browser’s address field, change docs-stage to edocs.bea.com . For example, the following is the correct URL for the ServerMBean entry in the WebLogic Server MBean Reference: http://edocs.bea.com/wls/docs92/wlsmbeanref/mbeans/ServerStartMBean.html The Deployment Control page in the WebLogic Server Administration Console supports navigating into the modules, Web Services, and EJBs within a deployment. When a deployment was expanded, the ability to navigate to previous or next pages in the deployment control table was disabled and the page number information was incorrect. Workaround or Solution : The Deployment Control page was updated to resolve these paging issues. Administrators are now able to navigate to other deployments regardless of whether any deployments on the current page are expanded. Clicking on the Release Configuration button while editing the settings for a Server/Cluster/Virtual Host whose name includes non-ASCII characters caused the console to display "The object that you were viewing has been deleted, ..." due to the name being garbled. Solution: This issue has been fixed. The WebLogic Server Administration Console includes pages which can be used to test web applications, resource connectors, Web Services, and other deployments. Test pages are include for EJBs, but the test points for these listed EJBs are never available. The omission of these EJB test points does not imply that the EJBs are not reachable or working. Administrators can use the console’s EJB monitoring pages to monitor the activity and status of their deployments. There was no method to set the ShowArchivedRealPathEnabled attribute of WebAppContainerMBean in config.xml file from Administration Console. This problem has been resolved by adding a check box named Archived Real Path Enabled on the Domain > Configuration > Web Applications page. 10.0 MP1 When you export or import a large JMS queue using WebLogic Administration Console, the system used to raise OutofMemory error. This problem has been resolved. 9.2 MP1 10.0 MP1 WebLogic Administration Console was not allowing the user to create more than 100 WTC Import/Export services. This problem has been resolved. 10.0 MP1 It was not possible to set the WeblogicPluginEnabled attribute of ClusterMBean from Administration Console. This problem has been resolved by providing a check box in Advanced Settings of the Cluster > Configuration > General tab that sets WeblogicPluginEnabled attribute of ClusterMBean. 10.0 MP1 java.util.MissingResourceException used to occur when you change the log level using Administration Console. Workaround: Edit the config.xml file manually. This problem has been resolved. 10.0 MP2 Some of the links in the “Understanding JMS Resource Configuration” online help topic point to http://docs-stage/wls instead of http://edocs.bea.com/wls . This problem is causing a 404 error. To access the correct information, substitute edocs.bea.com for docs-stage in your web browser. Unreachable server was not removed from the secondary server list and WebLogic Server was trying to replicate session to a server that has been disconnected from the network. This problem has been resolved. 10.0 MP2 Administration console extension writers who wished to use the ButtonBar or ButtonBarButton tags in a console extension were unable to specify a resource bundle to customize or localize labels for buttons, due to the absence of a bundle attribute in the tags. Workaround or Solution : The ButtonBar and ButtonBarButton tags in console extensions now support the bundle attribute. WebLogic Portal requires that any explicit Skeleton URI references be fully qualified relative to the webapp. The documentation and some of the console extension examples that we have provided have sometimes used relative references to these skeletons. For example: <netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="singlelevelmenu_children2.jsp"/> should have been correctly specified as: <netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="/framework/skeletons/default/singlelevelmenu_children2.jsp"/> Workaround or Solution: The WebLogic Server Administration Console portal configuration has been updated to use fully qualified references. For this release, relative skeleton URI references will continue to work. Warnings will be logged for any console extensions that do not use fully qualified skeleton references in their look and feel files. Any console extensions that you have written should be updated to use fully qualified skeleton URIs, as these relative references may no longer function correctly in a future release. The cluster messaging receiver that receives and dispatches multicast messages was using the WebLogic Server thread pool. The receiver never released the thread and continued to use it forever. This is expected behavior but the thread was reported as hogging. Solution: The cluster messaging receiver has been moved to its own dedicated daemon thread outside of the thread pool to prevent the reporting of the hogging thread. Deploying a deprecated WebLogic Server 8.1 application scope startup or shutdown class on WebLogic Server 9.x resulted in a DeploymentException while activating after deployment. Startup and shutdown classes registered in the weblogic-application.xml descriptor were being required to extend the WebLogic-specific class weblogic.application.ApplicationLifecycleListener . Solution : Startup and shutdown classes registered in the weblogic-application.xml descriptor are no longer required to extend the WebLogic-specific class weblogic.application.ApplicationLifecycleListener . On Solaris 9 or later, with JDK 1.5, any set operation on a half-closed socket throws a SocketException . This delayed the server in accepting new connections on the same port and also caused the server socket to be recycled if the maximum backoff time between failures reaches its maximum. Solution: WebLogic Server no longer throws an exception in connection with a set operation on half-closed sockets. When using the -Dweblogic.iiop.useJavaSerialization flag in a call over IIOP, org.hibernate.LazyInitializationException used to occur. This problem has been resolved. 10.0 MP2 The security-permission element is available in the weblogic.xml and weblogic-ejb-jar.xml deployment descriptors, but is not available in the weblogic-application.xml descriptor. Therefore, in an Enterprise application, you can only apply security policies to JAR files that are EJBs or Web applications. Will not fix The weblogic.Deployer tool interprets any extra string values between command-line arguments as a file specification. For example, if you enter the command: java weblogic.Deployer -activate -nostage true -name myname -source c:\myapp\mymodule the tool attempts to activate a file specification named “true”, because the -nostage option takes no arguments and “true” is an extraneous string value. If you deploy an application to a cluster and one or more clustered servers are unavailable (for example, servers partitioned from the cluster due to a network outage), the deployment operation may appear to hang. In addition, the partitioned servers may not deploy the application even after they successfully rejoin the cluster. Workaround or Solution : Reboot the partitioned servers after they rejoin the cluster. If a deployment plan has overrides of non-configurable elements, WebLogic Server does not currently reject the elements or fail to parse them. Workaround or Solution : Use configurable elements that use these annotations: @configurable @dependency @declaration @dynamic Will not fix If you deploy a web app with virtual hosts as targets, you cannot then change the targeting information unless you redeploy the entire web app with new target information. Workaround or Solution : Redeploy the web app with new targets information. ClassLoader.getResources() was only returning the first matching entry in an application. Solution : ClassLoader.getResources() now returns all the matching entries found in the application. Some OS and NFS combinations result in deployment failures or configuration updates with an exception like: weblogic.management.DeploymentException: Attempt to operate 'distribute' on null BasicDeploymentMBean Workaround or Solution :

Run statd() and lockd() processes on every NFS client that accesses a remote NFS volume.

If multiple servers that share the same domain root are started with different user Ids of same group, set the correct "umask" for the server processes so that a file created by one server can be opened for read/write by other servers without security exceptions.

WebLogic Server 9.x encountered an error when deploying an application using a WebLogic Server 8.1 weblogic.Deployer client. Solution : This release of WebLogic Server can now handle deployments from a WebLogic Server 8.1 weblogic.Deployer client. While using the WebLogic Administration Console with applications or EJBs deployed on a Managed Server that depend on a deployed library, you may encounter a java.lang.NoClassDefFoundError Workaround: The WebLogic Server Administration Console needs access to any shared library deployments so that Java data types and annotations can be processed. Therefore, all shared library deployments should always be targeted to the Administration Server in addition to any Managed Servers or clusters. WebLogic Server could not deploy more than two versions of an application library. Attempting to do so resulted in an error like: Cannot deploy or redeploy application 'test-app-lib [LibSpecVersion=9.2.0,LibImplVersion=9.2.0.2]' because the maximum number of application versions (2) for application 'test-app-lib' is exceeded Workaround or Solution : The limit on the number of deployed versions has been removed. Now, more than two versions of an application library can be deployed. When you partially redeploy a single module from a set of inter-dependent modules, the deployment operation could throw an exception if any of the dependent modules (such as children) are not included in the partial redeploy list. Workaround or Solution : In development mode, WebLogic Server now traces the dependencies between various modules and, rather than throwing an exception, it automatically deploys any required modules. In some scenarios, redeployment failed with a CannotRedeployException . The exception was caused by the web app’s Module-URI being registered in the AppClassLoaderManager instead of its module-id (context-root). This occurred only during a classloader bounce in WebAppModule . Solution : WebLogic Server now registers a web app’s module-id with the AppClassLoaderManager . If you deploy a web app as an archive war file, then context.getRealPath() returns null. This behavior can lead to certain failures in cases where the web app is dependent on the path. Solution: Use the <show-archived-real-path-enabled> flag to specify that context.getRealPath() returns the path of the resource from the Server's internal webapp extraction directory for archived web applications. The flag can be configured in two ways:

At domain level in config.xml . For example:

<web-app-container>
<show-archived-real-path-enabled>true
</show-archived-real-path-enabled>
</web-app-container>

At the web app level in weblogic.xml . For example:

<container-descriptor>
<show-archived-real-path-enabled>true
</show-archived-real-path-enabled>
</container-descriptor> The value of <show-archived-real-path-enabled> set in the web app has precedence over the value set at the domain level. The default value of this property is false. Note that, if this path is used to dynamically copy some content to this directory location, the content will end up in the Server's internal web app extraction directory. When the web app is recompiled for any reason, the web app may be re-extracted and previously copied content will be lost. In the interest of faster server startup, a remote deployer EJB used only by WebLogic 9.0 or 9.1 weblogic.Deployer clients is no longer started by default. If you use 9.0 or 9.1 weblogic.Deployer with default settings, an error message will be displayed: While trying to lookup 'weblogic.remote.Deployer' didn't find subcontext 'remote'. Resolved 'weblogic' Workaround or Solution : If you require deployment from a 9.0 or 9.1 weblogic.Deployer using the -remote option, you need to set the DeploymentConfigurationMBean.RemoteDeployerEJBEnabled attribute to true. To set this attribute using the WebLogic Server Administration Console, on the Domain: Configuration: General tab, click Advanced and check Enable Remote Deployer EJB. WebLogic Server was invoking weblogic.application.ApplicationLifecycleListener callbacks with an internal kernel identity instead of the anonymous user identity. Workaround or Solution : WebLogic Server now invokes these ApplicationLifecycleListener callbacks with the anonymous user identity. As part of this change, the user identity will be different for the execution of these callbacks. If your implementation of these callbacks is depending upon the permissions of the internal kernel identity, then the callback implementation may encounter errors when run with the anonymous user identity. You should either modify the callback implementation to use a different identity or specify a deployment principal name on the application deployment MBean. An application deployed to an individual managed server in a cluster was not removed from the staging directory during undeployment. This could cause errors if the application was later targeted to a different individual server in the cluster. The deployment could fail with the following error: An error occurred during activation of changes, please see the log for details. [Deployer:149257]Rejecting attempt to distribute application, 'webapp_900', while the application is running. Solution : WebLogic Server now ensures that the application and stage files are removed if the application is no longer targeted to any cluster members. WebLogic Server would fail to apply deployment plan overrides if a default namespace was not set in the weblogic.xml descriptor. This would result in a VALIDATION PROBLEMS WERE FOUND error. Solution : WebLogic Server was modified to inherit the namespace from the parent attribute when merging deployment plan overrides with the weblogic.xml descriptor. Performing a partial build through WebLogic Workshop could result in a deployment error, due to a partial redeploy. Solution : This has been fixed by reconciling WebLogic Server 8.1-style MBeans in the compatibility processor of the DynamicUpdateOperation . Changes made to the deployment plan while one managed server is down were not propagated to the managed server when it was brought back up. WebLogic Server was not using the file timestamps when determining whether to download the archive and plan files during startup of the managed server. Workaround or Solution : WebLogic Server’s startup has been modified to use the plan and archive timestamp. If the plan or archive are out of date, then WebLogic Server downloads new versions when the managed server starts up. WebLogic Server ignored the deployment order attribute when specified in a startup class element in config.xml . Since the deployment order was ignored, WebLogic Server ran startup classes based on the order of the startup class name and the load before app deployments property value. Workaround or Solution : If deployment order is specified, it will no longer be ignored and will be used to determine execution order for startup classes. In a multi-clustering ALSB domain, when you change a Business Service configuration (for example, Web Service URL modification), the managed servers which are not part of the ALSB cluster fall into the SUSPENDED state. This problem has been resolved. 10.0 MP1 The retirement operation which was executed when an Administration Server was restarted, used to fail with UnreachableHostException . As a result of this failure, both (old and new) versioned applications became active. This problem has been resolved. 10.0 MP2 The primary key in an Oracle table is a CHAR but the query field in the SQL table is a VARCHAR2. Change database schema from CHAR to VARCHAR2. Using CHAR as a primary key is not recommended for the Oracle database. Will not fix A Messaging Proxy Service still receives and routes messages after it has been deleted if the user sends the messages to it. Workaround : Do not use the JMS destination to which the deleted Messaging Proxy Service was listening. In Ejbgen, there is no counterpart for the select-first-sequence-key-before-update tag that is found in weblogic-cmp-rdbms-jar.xml . Solution: The Ejbgen annotation @AutomaticKeyGeneration now includes a selectFirstSequenceKeyBeforeUpdate attribute (whose type is Constants.Bool ). This attribute can be used to specify the behavior of automatic primary key generation. If selectFirstSequenceKeyBeforeUpdate is set to Constants.Bool.TRUE , when the EJB container needs to fetch the sequence value from a database, it generates the primary key from the current value + 1 in the sequence table, and updates the value in the table with the current value + the key-cache-size . By default, select-first-sequence-key-before-update is set to false. There is no annotation for EJB3 beans or Ejbgen that enables creation of a clusterable timer. Workaround : Create a weblogic-ejb-jar.xml file and put the <timer-implementation> element and corresponding values into the file. Creating EJB 3.0 stateful session beans is much more expensive in terms of performance than creating equivalent EJB 2.1 stateful session beans. Workaround : Most of the performance difference can be regained by setting the system property weblogic.ejb30.enableproxypool=true . This system property is set to false by default. Note that it is not safe to turn on this flag if the bean has interceptors associated with it that contain state. Kodo components send log messages by default to the .out file of the server the bean is deployed to, rather to a log file. Workaround : Configure the component can be configured to log to a particular file.

The business interface doesn't extend java.rmi.Remote .

The invocation of method is via remote proxy through RMI remote call, and there is no generated stub on client side. The local invocation within one JVM will succeed.

The remote call is via t3 protocol, not iiop protocol.

The method in the business interface has generic information; that is, type parameters or a generic type like List<String> as a parameter type.

Workaround or Solution: Make sure you fulfill any of the following conditions:

Write your business interface to extend java.rmi.Remote .

Put the generated stub on the client side when the invocation of method is via remote proxy through a RMI remote call. The local invocation within one JVM will succeed as well.

Make the remote call via the iiop protocol, not the t3 protocol.

Either do not use generic information in the business interface method, or use only generic information declared on the class level of the business interface with the type variable parameterized with raw type. For example:

Interface RootI<T> {
public void hello(T t);
public <S extends Comparable> S testComp(T t, S s);
}

//Business interface
Interface StatelessI extends RootI<String>{
} Though the business interface doesn't extend Remote , whether through remote call or local call, the invocation on StatelessI.hello(String) will work. But remote invocation on StatelessI.testComp() will fail when there is no generated stub on the client side. Extensions to the JPA metadata model can only be specified via annotations, and not via a structure similar to the orm.xml file defined by the specification. Workaround or Solution: To specify Kodo-specific metadata for your object model, either:

use the Kodo-specific annotations, or

convert your XML-based metadata to the JDO metadata format, which does support XML specification of extensions.

In Windows platform, the appc compiler used to fail on EJB 3.0 JAR file when the size of the resultant EJB class file was more than 40KB. This problem has been resolved. 10.0 MP1 A runtime exception used to raise when stateless EJB resource was injected into an interceptor by using the annotation @EJB. This problem has been resolved. 10.0 MP2 A runtime exception used to raise when multiple interceptors are configured in ejb-jar.xml deployment descriptor using <interceptor-order> . This problem has been resolved. 10.0 MP2 Unnecessary application recompilation used to happen during deployment and it slowed down the deployment. This problem has been resolved. 10.0 MP2 The Web Services Reliable Messaging example uses an incorrect WS-Policy file. In particular, the file uses an incorrect wsrm namespace and lists the assertions in an incorrect order. To workaround this problem, update the example WS-Policy file (called ReliableHelloWorldPolicy.xml ) to look like the default reliable messaging WS-Policy file included in WebLogic Server, described in Use of WS-Policy Files for Web Service Reliable Messaging Configuration . Pay particular attention to the namespaces and assertion order. The example described in this note is located in WL_HOME /samples/server/examples/src/examples/webservices/reliable , where WL_HOME refers to the main WebLogic Server installations, such as /bea/weblogic92 . The ../xml/stax example contains two files with the same root but different extension: StreamParser.java and StreamParser.jsp . The samples viewer build, however, creates just one corresponding HTML file, rather than two for each type of file. In this case only the StreamParser.jsp file has an equivalent HTML file; the StreamParser.java file does not. The problem occurs because of a setting in the build.xml file that controls the behavior of java2html to generate the files for the documentation. When using java2html, the useShortFileName="true" parameter crops off the file extensions for the source files to create the file names for the HTML output files. If two files have the same name and different file extensions, whichever html file is generated last will overwrite previous ones. Workaround or Solution : Set the useShortFileName parameter to "false" . This setting generates HTML files with the file extensions included in the name. The drawback to this solution is that every link that points to the HTML output file needs to be revised, regardless of whether the files in question were affected by the bug. Will not fix When you start the medrec or samples domains, you may see a warning message like the following: <Warning> <WorkManager> <BEA-002919> <Unable to find a WorkManager with name weblogic.wsee.mdb.DispatchPolicy. Dispatch policy weblogic.wsee.mdb.DispatchPolicy will map to the default WorkManager for the application bea_wls_async_response> This warning message appears in the standard out of the console while starting a WebLogic Server sample application with an asynchronous Web Service deployed. Workaround or Solution : The warning is harmless and can be ignored. The Beehive documentation on the install CD does not contain Web Service Management information, which may result in broken links. Workaround or Solution : Use the Beehive documentation that is on the install CD rather than the documentation on the Apache website. On installation, the installer may incorrectly report "Insufficient disk space". This error is the result of using a version of the UNIX df tool that is incompatible with POSIX. Workaround or Solution : Use a version of df that is compatible with POSIX. An unexpected EOF error occurs when downgrading from WebLogic Server 10.0 MP1 to WebLogic Server 10.0 Product Uninstaller in console mode returns a harmless EOF error and does not return a confirmation message on the successful completion of the downgrade. Platform: Red Hat Linux Workaround or Solution : 10.0 MP1 After downgrading from WebLogic Server 10.0 MP1 to WebLogic Server 10.0, when you uninstall the 10.0 installation, some files in the BEA_HOME directory are not automatically removed. Platform: All Workaround or Solution : Clean up the directory manually. 10.0 MP1 Product upgrade from WebLogic Server 10.0 to WebLogic Server 10.0 MP1 using Smart Update fails When Smart Update is used to upgrade WebLogic Server 10.0 to 10.0 MP1, the upgrade fails with a fatal error on a HPUX 64-bit machine. Platform: HPUX 64 Workaround or Solution : Use the WebLogic Platform package upgrade installer to upgrade from a WebLogic Server 10.0 installation to 10.0 MP1 10.0 MP1 WebLogic Server did not preserve the precedence when merging bean properties between library and application descriptors (when no key is defined for the bean). This merge results in an array of entries from both the library and application descriptors. However, the order of the entries was incorrect. Array entries from the library descriptor occurred before entries from the application descriptor; the library descriptor entries should have occurred after those from the application. Workaround or Solution : WebLogic Server now applies precedence when merging beans from the library descriptor with those from the application descriptor. weblogic.utils.io.ObjectStreamClass did not check the superclass if the readResolve and writeReplace methods were defined in it. Solution : The readResolve and writeReplace methods are now inherited properly. There is a performance degradation in the WebLogic Type 4 JDBC Driver for Oracle getAsciiStream() method call caused by fixes and enhancements to character set support in the driver. In general, the updated driver outperforms the previous version of the driver. Workaround or Solution : Use the getCharacterStream() method instead of getAsciiStream(). The 3.5 version of the BEA-branded driver from DataDirect has failed in long-running tests when JDBC connection pools have the ShrinkingEnabled attribute set to true. Workaround or Solution : For optimal JDBC pool performance and stability, BEA recommends that you set the ShrinkingEnabled attribute to false. The utils.Schema -s option has been removed. The -s option was for the obsolete WebLogic OCI driver, which did not accept the server name in the URL. All supported drivers now take all needed properties in the URL, so the -s option is no longer needed. It was removed because setting the server name in both the -s option and the URL caused problems. Workaround: Using the -s option will result in a warning saying that the -s option is no longer functional. If your connection fails, make sure all DBMS properties are in the URL. Using the JMS WLMessageProducer forward() API on a newly created message causes a JMSClientException. The JMS WLMessageProducer forward() API can only be used on unmodified received messages. Deployment descriptor validation fails when descriptor validation is enabled, and an EAR file contains only JMS modules. Workaround or Solution : Make sure that there is at least one J2EE specification-compliant module in the EAR. Reconnecting transactedSession.commit() or transactedSession.rollback() calls may throw exceptions more than once when reconnecting. When a transacted session allows reconnect — that is, when a WLConnection.getReconnectPolicy() is not none — the first call to session.commit() or session.rollback() will throw an exception after the server WLConnection has reconnected after a failure. This is expected behavior. Unfortunately, the second call to commit() or rollback() may also throw an exception. Afterwards the reconnected transacted session will work normally. There is no support for multi-byte characters in WebLogic Store file and directory names. For instance, when the WebLogic Server name has multi-byte characters, the default store cannot be created, and the WebLogic Server will not boot. Workaround or solution: Create WebLogic Servers without multi-byte characters in the path name and use that path name rather than the default store. Do not use multi-byte characters in the Weblogic Server name. When multiple JMS producers use the same JMS Client SAF instance (within a single JVM), depending on the timing of the JMS SAF client creation, you might receive the following exception: Error getting GXA resource [Root exception is weblogic.jms.common.JMSException: weblogic.messaging.kernel.KernelException: Error getting GXA resource] Workaround or solution: When using multiple JMS SAF client producers, try introducing a small delay between the creation of each new client. When deploying a JMS module, the WebLogic Server Administration Console was not transparently creating the necessary subdeployment targets in the Install assistant with some configurations of JMS Servers for the selected targets. In these cases, some subdeployment targets were not included in the deployment and the console did not provide error messages or the opportunity for an administrator to correct this targeting. Solution: The console now correctly senses when the automatic, transparent targeting of subdeployments was not complete and sufficient for a JMS module. In those cases, the console now displays error messages to the Administrator, and allows them to chose to explicitly deploy each module and subdeployment manually to specific targets. When using the WebLogic Scripting Tool (WLST) offline to generate a JMS module descriptor, for certain JMS Connection Factory Boolean parameters you cannot set the value to false . The following JMS Connection Factory attributes do not have their default value specified in the corresponding JMS Module descriptor schema definition. <allow-close-in-onMessage>
<xa-connection-factory-enabled>
<flow-control-enabled>
<load-balancing-enabled>
<server-affinity-enabled>
<attach-jmsx-user-id> Therefore, the Java default of false for these Booleans is used by WLST offline. So when they are manually set to false , WLST does not persist the values to the JMS module descriptor assuming that setting is redundant. Workaround or solution: After the JMS module descriptor is created using WLST offline, these Boolean attribute values can be edited either manually or modified using the Administration Console. In cases where two servers using JMS distributed topics in a cluster started simultaneously, each creates a new RJVM connection to the other server because it didn't detect an existing connection. WebLogic Server would detect the duplicate connections and close them. This caused JMS hangs. Solution: WebLogic Server now allows duplicate RJVM connections in this case when servers are started at the same instant and the RJVM between the two servers has transmitted and received more than just bootstrap messages. When using DB2 with WebLogic JMS, the JMS backing store table failed to create itself. This problem was caused by the fact that DB2 allows its connections to have a different default schema than that of the logged-in user Solution: This problem has been corrected. Expired messages were not getting redirected to error destinations during server startup. Solution: This problem has been corrected. The JMS 1.1 specification states in section 3.5, table 3-3, that the JMSXDeliveryCount property is set by the "provider on receive", but WebLogic JMS has included this property in the list of property names returned by the JMS API method javax.jms.Message.getPropertyNames() . Workaround or Solution: WebLogic JMS now only returns the JMSXDeliveryCount property name from the JMS API method javax.jms.Message.getPropertyNames() when both the message was delivered via receivers, queue browsers, or the administrative API, and the application hasn't called javax.jms.Message.clearProperties() . Newly created messages, or delivered messages on which javax.jms.Message.clearProperties() has been called, no longer include the JMSXDeliveryCount property name in the list of properties returned by javax.jms.Message.getPropertyNames() . The behavior of standard JMS API message methods for obtaining the JMSXDeliveryCount property value remain unchanged: these methods continue to return a JMSXDeliveryCount value of zero or greater as appropriate (whether or not JMSXDeliveryCount is included in the property name list). A failure used to occur while performing Paging I/O if many threads were waiting for Paging I/O to complete and these threads were blocked. This problem has been resolved. 10.0 MP1 When messages were sent to a destination, which was configured with a JMS quota and if that quota was met then messages were inadvertently getting added to the list of Pageable messages. This used to result in a memory leakage because the messages were retained on the list of Pageable messages until the server was restarted. This problem has been resolved. 10.0 MP1 Any failure detected by a distributed topic used to stop the forwarder and would not resume until the JMSServer was restarted. This problem has been resolved. 10.0 MP1 It was not possible to deploy an MDB while connecting to a foreign JMS provider through WLS foreign server resources configured in a JMS module. This problem has been resolved. 10.0 MP1 A multi-threaded JMS client using different connection protocols on different threads was failing with DispatcherException . This problem has been resolved. 10.0 MP1 10.0 MP2 JMS client occasionally used to hang on a late connection close if the auto-reconnect logic has already been activated for the connection. This problem has been resolved. 10.0 MP1 10.0 MP2 JMS message consumers will not always reconnect after a service migration when an application’s WLConnection.getReconnectPolicy() attribute is set to all . If the consumers do not get migrated, either an exception is thrown or onException will occur to inform the application that the consumer is no longer valid. Workaround or Solution : The application can refresh the consumer either in the exception handler or through onException . Will not fix The page-check-seconds parameter did not work in production mode when its value was specified in an application’s weblogic.xml deployment descriptor file. This value tells WebLogic Server how often it needs to check and recompile or reload changed JSP pages. However, modified JSP files were recompiled as appropriate when the server was started in development mode, but were not recompiled when the server was started in production mode. Solution : The page-check-seconds value is now enforced in production mode when a valid value is specified in a weblogic.xml deployment descriptor file. Multiple calls to response.addHeader() with same standard header name used to return only the last header value set to the client. This problem has been resolved for the standard headers CACHE_CONTROL, ACCEPT-RANGES and PRAGMA. 10.0 MP1 Servlet used to fail with the following exception when HEAD request was used to ping an application. javax.servlet.ServletException: Original response not available This problem has been resolved. 8.1 SP3 10.0 MP1 UnavailableException did not comply with Servlet 2.4 Specifications for permanent and temporary unavailability of the Servlet. This problem has been resolved. 10.0 MP1 WebLogic session ID with url-rewriting-enabled parameter enabled in weblogic.xml was not getting logged with URI in access.log file. This problem has been resolved. 10.0 MP1 The servlet container used to append charset=ISO-8859-1 to the HTTP Header contentType in the response for non-JSP pages with any charset contents. This would result in improper display of multibyte characters. This problem has been resolved. 10.0 MP1 JSPs from web library sometimes used to recompile unnecessarily even though they were pre-compiled and their respective classes were included in web library. This used to cause severe slowdown in server performance. This problem has been resolved. 10.0 MP1 If web.xml contains multiple servlets and the first servlet contains the <jsp-file> element, web container was not calling the initDone() method. This problem has been resolved. 10.0 MP2 Memory leak used to occur during undeploy or redeploy operations when the <wl:cache> tag is present. This problem has been resolved. 10.0 MP1 10.0 MP2 Application threads used to get blocked under a heavy load on weblogic.cache.CacheSystem.waitOnLock() if JSP contained the <wl:cache> tag using the key and timeout attributes with default scope. This problem has been resolved. 10.0 MP2 A JSP file was copied to the application from the library module, modified and accessed. When this JSP file was deleted from the application and accessed, it used to display as a modified/deleted JSP of application rather than displaying as a JSP in library module. This problem has been resolved. 10.0 MP2 Permgen space was not released between deployments if auth filters were used and a memory leak used to occur. This problem has been resolved. 10.0 MP1 10.0 MP2 A runtime exception used to raise after upgrading a WebLogic Server 9.2 MP2 domain to WebLogic Server 10.0 MP1. This problem has been resolved. 10.0 MP1 10.0 MP2 RemoteClientTimeout is now supported for transactional methods as well as non-transactional methods. The RMI client timeout is the greater of tx timeout and RemoteClientTimeout if the method is transactional and tx timeout is set. If the method is non-transactional then the RemoteClientTimeout directly applies. The tx timeout is picked from the EJB deployment descriptor ( TransactionTimeoutMS ) or from JTAMBean.TimeoutSeconds . BEA Oracle XA DatabaseMetaData objects became invalidated if no other work is done in a remote tx. The BEA-branded XA driver for Oracle was mistakenly marked as needing a new XA connection per transaction. Solution: The BEA Oracle XA driver no longer is treated as needing a new XA connection per transaction. Due to a known Sun Microsystems VM bug (513552), a 1.4 Thin Client Applet cannot contact WebLogic Server 9.0 or later. This is because the VM does not distinguish correctly between a client and a server connection. The VM creates a server-type connection and caches it. It then attempts to make a client-type connection, finds the cached connection and tries to use that, but then encounters an error because clients are not allowed to use server connections. Workaround or Solution : None. This issue must be resolved by Sun Microsystems. Vendor fix required Some web applications may experience a performance degradation compared to WebLogic Server 9.2 when running WebLogic Server on JRockit version R26.4 using the default GC algorithm on multi-CPU/core machines. Workaround or Solution : Turning on the JVM flag -Xgc:parallel may fix this problem. The StuckThreadCount attribute of the WorkManagerRuntimeMBean always returned zero, even when there were stuck threads. This information is an important data point when monitoring a running server for which OverLoadProtection or other stuck thread configuration has been specified. Solution: The StuckThreadCount attribute of the WorkManagerRuntimeMBean now returns the correct value. The WLDF harvester looks only at runtime mbeans in the local runtime MBean server. On the Administration Server, the ServerLifeCycleRuntimeMBean instances are registered only in the federated MBean server and not available in the local runtime MBean server. Thus, it is not possible to harvest its attributes or configure watch rules based on their attributes, such as the State attribute. Workaround: It is possible to configure an SNMP monitor on the attributes of ServerLifeCycleRuntimeMBean to receive notifications based on their values. In previous releases of WebLogic Server, the SNMP Agent was monitoring the compatibility MBeanServer. The MBeans had a Location field that was used in the trapServerName variable of the wlsMonitorNotification trap. MBeans in the Runtime MBean Server do not have a Location field. Solution: The trapServerName now uses the name of the server where the agent is running in the domain. For traps based on JMX AttributeChange notifications, the trapMBeanName variable now contains the full ObjectName of the MBean that caused this trap to fire instead of the short MBean name. For all other traps based on SNMPJMXMonitorMBean , the field contains the value of the MonitoredMBeanName attribute in the corresponding configuration MBean. For the SNMPJMXMonitorMBean , the MonitoredMBeanType must be a valid WLS MBean type and the MonitoredAttributeName must be a valid attribute of that MBean type. Similar validation is added for the SNMPAttributeChangeMBean 's AttributeMBeanType and AttributeName attributes. Invalid values will cause errors. Workaround or solution: Use valid attribute values. To speed up running queries on log accessors such as server log, HTTP access log, etc., they are indexed. WLDF used to perform periodic incremental re-indexing to keep these indexes up to date. However, this caused expenditure of CPU cycles even when WLDF accessor was not used. Solution: For better overall performance, WLDF no longer performs automatic incremental re-indexing of log file. Instead, indexing is performed lazily when an access is made, and only when a log rotation has occurred since the last re-index operation. In some cases, especially while using a large value for file rotation file size, index data may not be very recent. That may cause some slowdown while executing queries using the accessor interface. The -C <prop-file> option of the SnmpTrapLogger subcommand of the SNMP command line tool, weblogic.diagnostics.snmp.cmdline.Manager , does not work. As a result, you cannot specify a log config properties file with the SnmpTrapLogger subcommand of the SNMP command line tool. Workaround or solution: None at this time. Because WebLogic Server has changed its SNMP implementation, the DebugLevel attribute on the SNMPAgentMBean has been removed without deprecation. Workaround or solution: If you need debug information for an SNMP agent, use the DebugSNMPToolkit attribute on ServerDebugMBean . On UNIX platforms, port numbers under 1024 are protected to be used only by root. The default values for SNMP UDP and agentX ports are 161 and 705 respectively. If you started WebLogic Server as a non-root user (normal situation) on UNIX with such default port numbers, a bind exception prevented WebLogic Server from starting. Workaround or Solution : If the SNMP agent fails to start, it does not prevent the server from starting any more. Also, the following Error log message is emitted in the server log to help diagnose the problem: Failed to start the SNMP agent. If it failed to bind to the port, check if the port is available or the process has permission to bind to the port. On UNIX platforms, you should configure SNMP ports to port numbers higher than 1023 or start the server as root to avoid port binding errors. When WebLogic Server sends SNMP INFORM notifications, if the receiving manager fails to acknowledge, retries are attempted in a separate thread. Control is immediately returned to the caller with success status. Thereafter, if the manager fails to respond, the failure is not reported. Workaround or Solution : There is not yet a solution for this issue. The failure can be observed if the DebugSNMPToolkit debug is enabled. However, this will produce very verbose output. SNMP OIDs may be non-repeatable in some cases across sessions, leading to possible failures in getting MBean attributes. The underlying SNMP implementation assigns OIDs to customer MBean attributes in the order in which they are entered. If this order changes, the assigned OIDs will change. Workaround or Solution : The attributes are now added in the sorted alphanumeric order. This will help to ensure that OIDs for MBean attributes will be preserved across sessions, as long as the set of MBean attributes does not change. If the set of MBean attributes changes (by operations such as add, remove, rename), then it is possible that the OIDs assigned to MBean attributes may change across sessions. The @unharvestable tag is not being honored at the interface level. If MBean attributes are not explicitly marked as @unharvestable , they are considered to be harvestable and will appear as harvestable in WebLogic Administration Console. Workaround: You can explicitly mark MBean attributes as @unharvestable . The Servlet_Before_Service, Servlet_After_Service and Servlet_Around_Service diagnostic instrumentation monitors fail to weave diagnostic code into a servlet's doGet or doPost methods, if those methods have "protected" access. The doGet and doPost methods do get properly instrumented if they have public access qualifiers. Workaround: Consider making the doGet and doPost methods in your servlet public. The following LogFileConfig APIs and properties were removed in WebLogic Server 10.0 MP1, but not deprecated: com.bea.logging.BaseLogEntry com.bea.logging.BaseLoggerFactory com.bea.logging.BaseLogRecordFactory com.bea.logging.LogFileConfig com.bea.logging.LoggingServiceConfig com.bea.logging.StdoutConfig com.bea.logging.LogFileConfigBean com.bea.logging.LogFileConfigImpl com.bea.logging.LoggingLifecycle com.bea.logging.LoggingServiceConfigImpl com.bea.logging.LogMessageFormatter com.bea.logging.RotatingFileStreamHandler com.bea.logging.StdoutConfigImpl 10.0 MP1 After changing the boot password for a Managed Server and then restarting the server using Node Manager, the restart failed, because the Node Manager did not have access to the new boot user password. It was necessary as a workaround to restart the Managed Server through the WebLogic Server Administration Console so that the new server configuration details would be propagated Solution: The Node Manager now receives updated properties from the Admin Server when a Managed Server’s Server Start fields are changed, and saves those properties to the Managed Server's startup.properties file. When the Node Manager is required to automatically restart a server, it uses that file for the startup properties, and thus has the up-to-date values. The following NodeManager MBean APIs and properties were removed in WebLogic Server 9.x, but not deprecated: DEFAULT_CERTIFICATE_PASSWORD_BYTE_ARRAY getCertificatePasswordEncrypted() getCertificate() getCertificatePassword() getCertificateType() getTrustedCertsFile() setCertificate(java.lang.String) setCertificatePassword(java.lang.String) setCertificatePasswordEncrypted(byte[]) setCertificateType(java.lang.String) setSSLEnabled(boolean) setTrustedCertsFile(java.lang.String) The server migration functionality that existed in the scripted Node Manager has been added to the Java-based Node Manager. Auto migration support for Windows was also enabled in the cluster's configuration. The Java-based Node Manager now supports auto server migration on all WebLogic Sever supported platforms. You can now use the Java-based Node Manager to manage your remote WebLogic Server instances, instead of being required to use SSH/RSH in your environment. When a $CLASSPATH variable was specified in the remote-start arguments when starting a WebLogic Server instance using Node Manager, the variable was not being replaced with the actual value. Solution: The $CLASSPATH variable is now appropriately replaced with the actual value. When using WLST to create managed servers the first managed server was created and started successfully, but subsequent server activation used to fail with FileNotFoundException . Workaround: Do the nmEnroll with the domain directory where the Administration Server and Node Manager are running other than a different directory on the same machine. This problem has been resolved. 10.0 MP2 If non-dynamic changes are made to a domain configuration, then an application is added (e.g., MyApp ), and then the non-dynamic changes are activated, a Management Exception is thrown: [Deployer:149001] No application named 'MyApp' exists for operation start . Workaround or Solution : The error message occurs because when an edit is made to a non-dynamic configuration setting, no edits to dynamic configuration settings will take effect until after a server restart. This is to assure that a batch of updates having a combination of dynamic and non-dynamic attribute edits will not be partially activated. Since the application has not been added to the configuration, the application cannot be activated and the activate fails with the Management Exception. For more information on dynamic versus non-dynamic changes, see Managing Configuration Changes in Understanding Domain Configuration . The command line server startup option -Dweblogic.management.startupMode was not being handled properly, preventing startup in ADMIN mode. Solution : This problem has been fixed. Suspending or gracefully shutting down one managed server in a cluster could cause other servers in the cluster to hang. This problem was caused when ReplicationManager did not mark the suspended or gracefully shutting down server in the cluster as dead and would continuously try to replicate the sessions to that server. This would block all the execute threads in the ReplicationManager and the running server would hang. Solution : This problem has been fixed. WebLogic Server fails with an ImageSourceCreationException when capturing a diagnostic image on a managed server. The error is as follows: <BEA-320127> <An error occurred while generating Image Source configuration as part of the diagnostic image zip file:
weblogic.diagnostics.image.ImageSourceCreationException: java.lang.NullPointerException at
weblogic.management.provider.internal.ConfigImageSource.createDiagnosticImage(ConfigImageSource.java:105) Solution : This problem was corrected by eliminating the NPE error, allowing WebLogic Server to complete the image capture on the managed server. WebLogic Server would require restart on changes to attributes that were actually dynamic. WLS uses annotations to determine if an attribute is dynamic. This affected the ServerStart, SNMPAgent, SNMPAttributeChange, SNMPCounterMonitor, SNMPGaugeMonitor, SNMPLogFilter, SNMPProxy, SNMPStringMonitor, SNMPTrapDestination, and SNMPTrapSource MBeans. Solution: WebLogic Server no longer requires server restart if attributes from these MBeans are changed. An invocation on an MBean in the Domain Runtime MBeanserver failed with a NoAccessRuntime exception as follows: weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[deployer, Deployers], on ResourceType: ServerRuntime Action: execute, Target: lookupApplicationRuntime The user had the appropriate role for the invocation, but WebLogic Server could not retrieve the MBeanInfo for the MBean. This caused the invocation to be denied since the role information is contained in the MBeanInfo. Solution: WebLogic Server now uses the MBean type to look up the MBeanInfo and retrieve the role information, thereby allowing the invocation to succeed. The WebLogicMBeanMaker utility could cause an out-of-memory exception in normal operation. Solution: The WebLogicMBeanMaker utility has a new optional argument, jvmArgs , that you can use to modify the heap size for created subprocesses. For example: jvmArgs="-Xms256m -Xmx512m" See the usage message for the WebLogicMBeanMaker utility for more information. The following ServerMBean APIs and properties were removed in WebLogic Server 9.x, but not deprecated: isIORServletEnabled();
setHelpPageURL(java.lang.String);
setIORServletEnabled(boolean);
setWorkspaceShowUserKeysOnly(boolean); The LogFileMBean now includes a buffer-size-kb parameter. This parameter has a default value of 8 KB; when set to zero or less, it will not buffer the log messages. For example, to set the buffer size for access.log in config.xml : <server>
...
<web-server>
<web-server-log>
<buffer-size-kb>0</buffer-size-kb>
<web-server-log> WebLogic Server did not trim spaces in MDF legal values arguments. For example, the custom security provider MDF file had legal values defined as: LegalValues="PLAINTEXT, PRECALCULATEDHASH, REVERSIBLEENCRYPTED" This resulted in legal values that contained leading spaces, for example, " PRECALCULATEDHASH" instead of "PRECALCULATEDHASH" . Solution: WebLogic Server now trims the leading spaces. Previous releases of WebLogic Server distributed an older version of the javax.management.j2ee.statistics package that did not contain the javax.management.j2ee.statistics.JMSStats class. Solution: This releases of WebLogic Server includes an updated version of the javax.management.j2ee.statistics package. JRockitRuntimeMBean exposes functionality from the JRockit MAPI ProfilingSystem API, which is being deprecated. Consequently, the following JRockitRuntimeMBean methods are deprecated: public boolean isExceptionCountEnabled(Class throwableClass);
public long getMethodTiming(Method method);
public long getConstructorTiming(Constructor constructor);
public boolean isMethodInvocationCountEnabled(Method method);
public boolean isConstructorInvocationCountEnabled(Constructor constructor);
public boolean isMethodTimingEnabled(Method method);
public boolean isConstructorTimingEnabled(Constructor constructor);
public long getExceptionCount(Class throwableClass);
public long getMethodInvocationCount(Method method);
public long getConstructorInvocationCount(Constructor constructor); Memory leak of javax.management.ObjectName objects on the Administration Server used to cause OutOfMemory error on the Administration Server. This problem has been resolved. 10.0 MP1 Memory leak used to occur on the server side when using DeploymentManager from the client. The IIOPServerImpl$ConnectorLister object created during the call DeploymentManagerFactory.getDeploymentManager () was not getting removed on calling the DeploymentManager’s release() method.These objects used to remain until the client process stopped. This problem has been resolved. 10.0 MP1 Upgrading a WebLogic Server 9.2 domain to WebLogic Server 10.0 used to fail when a log filter was assigned to the server log on WebLogic Server 9.2. This problem has been resolved. 10.0 MP2 IIS plug-in used to buffer chunked transfer encoding responses when it should stream the chunks as they are received. This problem has been resolved. Flush chunks immediately as they are received from WebLogic Server when the WLFlushChunks flag is set to true . The default value of this flag is false . 10.0 MP1 The option, -Dweblogic.system.StoreBootIdentity , only works if the appropriate server security directory exists. This directory is usually created by the Configuration Wizard or upgrade tool. However, the appropriate server security directory could be absent in domains checked into source-control systems. On UNIX platforms, when you registered trusted certificates in the CertificateRegistry, SAMLCredentialMapperV2, SAMLIdentityAsserterV2 or SAMLIdentityAsserter security provider, and used the File button in the WebLogic Administration Console to select the pathname of the file containing the certificate, you saw a java.lang.StringIndexOutOfBoundsException and the certificate was not registered. Solution : These security providers have been fixed so that the File button functions correctly. Session replication calls are now restricted to Admin users and the session data is protected as well. If the ReplicationChannel is defined for a cluster, then all calls to the ReplicationManager are allowed over the ReplicationChannel only. If the ReplicationChannel is not defined, and secured replication is enabled for the cluster, then all the calls to the ReplicationManager are allowed only over the default secure channel. If the ReplicationChannel is not defined, and secured replication is not enabled for the cluster, then all the calls to ReplicationManager are allowed only over the default channel. If the session replication call is over a secure channel, then the caller must have Admin roles. If the call is over an unsecured channel, then the caller should not have Admin roles. The following method was published mistakenly in WebLogic Server 9.x and has been removed: weblogic.security.SubjectUtils.getOnePrincipal(javax.security.auth.Subject, java.lang.Class) This method has a Java equivalent: javax.security.auth.Subject.getPrincipals(Class type); Deploying the Spring Pet Clinic sample application on WebLogic Server 10.0 running with JRockit fails due to the failure of OpenJPA. Workaround or Solution: Upgrade JRockit from version R26.4 to R27.2. EJBException occurs when you upgrade the petstore domain from WebLogic Server 7.0.x to 9.x. Workaround or Solution : Prior to upgrading the domain, edit the config.xml file to ensure that the xa-connection-factory-enabled element is set to true for the MyTopicConnectionFactory . The JWS in WebLogic Server 9.2 and later does not support the callback protocol in WebLogic Workshop 8.1. Therefore, a 9.2 or later JWS cannot callback to an 8.1 WebLogic Workshop application or an 8.1 WLI JPD. Also, a 9.2 or later JWS client cannot receive callbacks from an 8.1 WLW application or an 8.1 WLI JPD. Workaround or Solution : Front-end the client side call with a 9.2 Service Control. A Service Control callback to JWS from JPD is not supported. JWS only understands 9.x-style callbacks. The JPD or 8.1 services only support 8.1-style callbacks. Workaround or Solution : Front end a JPD with a JWS and PC (only valid for JPD 9.x endpoints) or make your endpoint service synchronous and use polling (valid for 8.1 services and JPD 9.x endpoints). Weblogic Workshop 8.1 supported returning the java.util.Map type from Web Service operations. The runtime provided a Workshop specific serialization of the Map to and from XML. The schema for that serialization was included in the WSDL for the Web Service. In WebLogic Server 9.2 and later, the java.util.Map type can no longer be returned from Web Service operations. Workaround or Solution : Provide an application-defined type that supports the key/value features provided by java.util.Map . That type must conform to JAX/RPC Java<->XML Serialization rules. If the application-type is going to contain subclasses of type key or value type , then the weblogic.jws.Types annotation must be used to specify the types that could be contained at runtime. WebLogic Web Services (and their clients) that previously returned a java.util.Map will have to be manually updated to use this new application-defined type. WebLogic Server would not upgrade a domain whose name contains a space. The upgrade would fail with an IllegalCharacter exception. Solution : The WebLogic Server domain upgrade now allows spaces in the domain name. In WebLogic Server 9.0, 9.1, and 9.2, there is a constraint on the occurrence of <servlet-mapping> elements in the WEB-INF/web.xml descriptor of web modules. The restriction is that the combination of the two sub-elements <servlet-name> and <url-pattern> is required to be unique, because these two elements form a composite key for the <servlet-mapping> element. This constraint is not visible in the schema, but is enforced by WebLogic Server during parsing. As a result, the violation of this constraint shows up as a weblogic.descriptor.BeanAlreadyExistsException rather than a schema validation error. Workaround or Solution : Make sure that the <servlet-name> and <url-pattern> elements have unique values. The WLST loadProperties command does not support loading a property with a name that contains " . " characters. For example, if the property myapp.db.default is present in the property file, WLST throws a name exception: Problem invoking WLST - Traceback (innermost last):
File "<iostream>", line 7, in ?
File "<iostream>", line 4, in readCustomProperty
NameError: myapp This is a system limitation of Python and the loadProperties command. WLST reads the variable names and values and sets them as variables in the Python interpreter. The Python interpreter uses " . " as a delimiter to indicate module scoping for the namespace and/or package naming. Therefore, the properties file fails because myapp.db.default.version=9i is expected to be in the myapp.db.default package. This package does not exist. Use variable names that do not have periods. This will allow you to load the variables from the property file and refer to them in WLST scripts. You could use another character such as "_" or lowercase/uppercase character to delimit the namespace. As an alternative, you can set variables from a properties files. When you use the variables in your script, during execution, the variables are replaced with the actual values from the properties file. For example: myapp.py
var1=10
var2=20 import myapp print myapp.var1
10 print myapp.var2
20 This will work for one level of namespaces ( myapp.var1, myapp.var2 ). It will not work for top level variables that share same name as the namespace (for example, myapp=oracle and myapp.var1=10 ). Setting the myapp variable will override the myapp namespace. If you need multiple levels, then you can define a package namespace using directories. Create a myapp/db/default directory with a vars.py file as follows: var1=10
var2=20 Then import: import myapp.db.default.vars
print myapp.db.default.vars.var1
10 You may need to add __init__.py files to the subdirectories. Refer to the Python documentation for more information on packages: http://docs.python.org/tut/node8.html The script generated by the WLST configToScript command failed to execute due to a missing lookup method in the SelfTuning MBean. This causes the following error when executing the script: Problem invoking WLST - Traceback (innermost last): in create_WorkManager_80 AttributeError: lookupWorkManager Solution: This problem was corrected by adding the lookupWorkManager method to the SelfTuningMBean . This allows the generated script to complete successfully. The WLST jndi() tree did not use the administration port if one was configured. If connecting as an admin user, this resulted in the following error: User 'principals=[weblogic, Administrators]' has administration role. All tasks by adminstrators must go through an Administration Port. Solution: WLST jndi() now uses the admin port if one is configured. When an ALSB domain was created from an ALSB template, you were not able to navigate within the project browser and the following error used to occur: Message: The current login role is not authorized to use the console action: "/ViewProject" Type: com.bea.wli.common.base.SBConsoleAccessException This problem has been resolved. 10.0 MP1 When an encrypted password was specified for a remote SAF LoginContext in .py script as set('PasswordEncrypted','wlssafadmin'), the encrypted password used to be stored as plain text in wgxt5_s1_m2-jms.xml file under mydomain\config\jms. This problem has been resolved. 9.2 MP1 10.0 MP1 Change Management was not working when an ALSB domain was created from an ALSB template using WLST. This problem has been resolved. 9.2 MP1 10.0 MP1 When DefaultAdjudicator was created using offline WLST scripts, the generated config.xml entries were incorrect and resulted in the server startup failure. This problem has been resolved. 9.2 MP1 10.0 MP1 Requests with certain WebDAV methods such as BPROPPATCH were not being passed through by BEA plug-ins. Solution: WebDAV requests are now passed through by BEA plug-ins. When using HttpProxyServlet in WebLogic Server as the Reversed Proxy Server (RPS) to Ren server, the socket was not getting closed when the browser was closed or navigated to some other site. The HttpProxyServlet used to read responses from the backend even after the client connection was closed. This problem has been resolved. 10.0 MP1 WebLogic Server 9.2 and later does not support JAX RPC handlers in callback Web Services. Workaround or Solution: If JAX RPC handlers were used with Web Services created with WebLogic Workshop 8.1, then such applications must be redesigned so that they do not use callback handler functionality. WebLogic Server 9.2 and later does not support message-level security in callback Web Services. Workaround or Solution: Web Services created with WebLogic Workshop 8.1 that used WS-Security must be redesigned to not use message-level security in callbacks. WebLogic Server 9.2 and later does not support the use of double-byte characters in URLs in Web Services. Workaround or Solution: Web Services created with WebLogic Workshop 8.1 that used double-byte characters in URLs must be redesigned to remove all double-byte characters from URLs. Using a two dimensional XmlObject parameter ( XmlObject [][]) in a JWS callback produces an IllegalArgumentException . Workaround or Solution: There is no known workaround. Using SoapElement[] as a Web Service parameter with @WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE) will always result in an empty array on the client. Workaround or Solution: Do not use the @WildcardBinding annotation to change the default binding of SOAPElement[] to WildcardParticle.ANYTYPE . The SOAPElement[] default binding is set to WildcardParticle.ANY . WebLogic Server does not support chunked-transfer encoding when streaming SOAP messages with attachments. Workaround or Solution: There is no known workaround. WebLogic Server does not support handling of Java method arguments or return parameters that are JAX-RPC-style JavaBeans that contain an XmlBean property. For example, applications cannot have a method with a signature like this:
void myMethod(myJavaBean bean); where myJavaBean class is like: public class MyJavaBean {
private String stringProperty;
private XmlObject xmlObjectProperty; public MyJavaBean() {} String getStringProperty() {
return stringProperty;
}
void setStringProperty(String s) {
stringProperty = s;
} XmlObject getXmlObjectProperty() {
return xmlObjectProperty;
}
void getXmlObjectProperty(XmlObject x) {
xmlObjectProperty = x;
} Workaround or Solution: There is no known workaround. WebLogic Server does not support using a custom exception on a callback that has a package that does not match the target namespace of the parent Web Service. Workaround or Solution: Make sure that any custom exceptions that are used in callbacks are in a package that matches the target namespace of the parent web service. Web Services that define a Callback interface with a mixed-case package name will fail to compile with jwsc . Workaround or Solution: Create the Callback interface in a package with a lower-case name. Editing wsrp-wsdl-template.wsdl requires the following supporting files to be copied from wlp-wsrp-producer-web-lib.war to your web-app:

wlp_wsrp_v11_types.xsd

wlp_wsrp_v1_types.xsd

wsrp_v1_full.wsdl

wsrp_v1_types.xsd

wsrp-wsdl-template.wsdl

wlp_wsrp_v1_bindings.wsdl

wsrp_v1_bindings.wsdl

wsrp_v1_interfaces.wsdl

wsrp-wsdl-full.wsdl

xml.xsd

Clientgen fails when processing a WSDL that uses the complex type http://www.w3.org/2001/XMLSchema{schema} as a Web Service parameter. Workaround or Solution: There is no known workaround. Clientgen did not support a WSDL with nested simple types containing a list of enumerations, throwing an IllegalArgumentException . For example: <s:simpleType name="ABPropertyType">
<s:list>
<s:simpleType>
<s:restriction base="s:string">
<s:enumeration value="Name" />
<s:enumeration value="IsBot" />
<s:enumeration value="IsPartManaged" />
<s:enumeration value="Subscribe" />
<s:enumeration value="Unsubscribe" />
</s:restriction>
</s:simpleType>
</s:list>
</s:simpleType> Solution: Nested simple types containing a list of enumerations are now supported. In the WebLogic Administration Console, policy attachments for Web Services can be specified for "inbound", "outbound" and "both" directions. Any new policies or changes to the direction of the policies were updated in the deployment plan but policies detached from operations were not removed from the deployment plan. Solution: The deployment plan is now updated correctly on deletions. Variables are removed if not referenced by VariableAssignments. References to a bean are removed if a bean is deleted. You can disable chunking of SOAP responses. Once chunking is disabled, responses are cached in the memory buffer. Beyond a specified buffer size, SOAP message chunking is resumed. To disable chunking, set the property weblogic.wsee.NoFlush in the WebLogic Server startup script or while starting up WebLogic Server. For example: -Dweblogic.wsee.NoFlush=true To control buffersize, set the command line parameter weblogic.wsee.http.response.BufferSize . For example: -Dweblogic.wsee.http.response.BufferSize=<buffer size in Bytes> Note that the buffer size should be a multiple of the chunk size, so the actual buffer size is automatically assigned a value that is a multiple of the chunk size, and it can be slightly higher than the user-specified value. You can also configure these properties in a Web Service’s weblogic-webservice.xml file. For example: <weblogic-webservices xmlns="http://www.bea.com/ns/weblogic/90";;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";;>
.....
<port-component>
....
<service-endpoint-address>
....
</service-endpoint-address>
<http-flush-response>false</http-flush-response>
<http-response-buffersize>12288</http-response-buffersize>
</port-component>
</webservice-description>
</weblogic-webservices> Note: These features are currently limited to JAX-RPC Web Services stack. In certain circumstances, the invocation of a WebLogic Web Service configured for reliable messaging will throw the following PersistentStoreRuntimeException error: weblogic.store.PersistentStoreRuntimeException: [Store:280051]The persistent store was not able to create a new record. Workaround or Solution: When starting the WebLogic Server instance to which the reliable Web Service is deployed, set the following property: -Dweblogic.wsee.exclude.properties=weblogic.wsee.ejb.target When Web Service A wants to invoke Web Service B, Web Service A should use the @ServiceClient annotation to do this. If Web Service B needs a custom policy file that is not attached to Web Service B's WSDL, then Web Service A will fail to run. Web Service A will look for the policy file at /Web-Inf/classes/policies/xxx.xml . Since no policy file exists at that location, WebLogic Server will throw a file not found exception. Workaround or Solution: Attach the custom policy file to Web Service B, as in this example: @Policy(uri="CustomPolicy.xml",
attachToWsdl=true)
public class B {
...
} This release of WebLogic Server supports clustering with Secure Web Services. However, the policy format for Secure Web Services must conform to the OASIS WS-SecurityPolicy 1.2. Existing Web Services that use the previous policy format will still not support clustering. Workaround or Solution: Existing Secure Web Services must either be run on a single server or else replace their security policy with one that conforms to WS-SecurityPolicy 1.2 if you want them to work in a cluster. The WebMethod name of a JAX-WS Web Service cannot include non-ASCII or multi-byte characters. This is due to an i18n bug in the com.sun.tools.javac.main.JavaCompiler class. Workaround or Solution: Set the WebMethod name to a value that includes only ASCII characters. Web Service used to fail to honor the optional element minOccurs="0". When invoking a Web Service with this optional element in the request message following issues used to occur:

Deleting this optional element from the request message failed to invoke the Web Service.

When the Web Service client invoked the Web Service with a null value for this optional element, the optional element was added to the SOAP body with an empty value in the SOAP response. The resulting XML would not validate against the schema if it has nillable=false for this optional element.

These problems have been resolved. 10.0 MP1 When XMLBean was used, the jwsc Ant task used to generate invalid WSDL if primary schema had included schemas and had referred types in the included schemas. The jwsc ant task used to generate a schema section for each of the included schema and types in the included schema were not able to be resolved from the primary schema. This problem has been resolved. 10.0 MP1 JAX-WS was not able to process payloads if white space was specified after the SOAP header. This problem has been resolved. 10.0 MP1 WebLogic Server used to raise the following exception when long[] and other primitive data type arrays were used in JAX-RPC callback. NegativeArraySizeException: allocLargeArray This problem has been resolved. 10.0 MP1 Indigo used to require acksTo to be the same address as the address where application messages were sent to. When the addresses were different, a problem used to occur with offered sequence acksTo because that address is different from the application endpoint. This problem has been resolved. 10.0 MP1 Indigo client to WebLogic Server MTOM basic byte array request used to fail with a NullPointerException on the server side when you deref the MTOM attachment from the SOAP message. This problem has been resolved. 10.0 MP1 JAX-RPC MTOM SOAP1.2 Web Service used to fail to receive non-XOP message from a .NET client. This problem has been resolved. 10.0 MP1 WSEE Runtime MBeans was not getting cleared and this used to cause huge redeploy memory leaks. This problem has been resolved. 10.0 MP1 While using UDDI feature with server_only kit (not platform kit) installations you may get UDDIException with the following error: Error in initializing pluggable tModels. Workaround or Solution: Comment the entry, pluggableTModel.file.list , in <WEBLOGIC_HOME>/server/lib/uddi.properties file. 10.0 MP1 On EJB 3.0, there is no way to assign workmanager to that session bean based web service. Workaround or Solution: Call EJB from Web application based web service. It is possible to assign workmanager to Web application based web service using weblogic.xml. This problem has been resolved. 10.0 MP2 When a WSDL was parsed using WsdlFactory, some <wsdl:documentation> elements were missing while some elements were repeated. This problem has been resolved. 10.0 MP1 10.0 MP2 Required attributes were not returned from echo method when used as part of XMLBean types. This problem has been resolved. 10.0 MP1 10.0 MP2 The jwsc ant task used to produce an invalid WSDL when wrapped types, such as BigDecimal[] , were used as parameter types. This problem has been resolved. 10.0 MP1 10.0 MP2 The weblogic.transaction.Transaction class was not included in wls-api.jar. Therefore, the web service project created in Workshop failed to build if the jws import weblogic.transaction.Transaction . This problem has been resolved by including weblogic.transaction.Transaction in the wls-api.jar file. 10.0 MP2 A runtime exception used to raise when a JAX-WS based web service application is started up after deployment. Workaround: Set nillable='false' for the schema elements that are failing. This causes an @XmlElement annotation to be generated for these elements instead of @XmlElementRef so it does not require the factory methods. This problem has been resolved. 10.0 MP1 10.0 MP2 A web service with custom exception used to return NULL for e.getMessage() and e.getCause() methods at the client side. This problem has been resolved. The custom JAXRPC exception returned in the client side of WebLogic Server 10.x was different from WebLogic Server 8.1. A new command line flag, -Dweblogic.wsee.soap.81CustomException=true , has been provided for following the 8.1 style exception in 10.x. 10.0 MP1 10.0 MP2 java.io.FileNotFoundException used to raise when running clientgen with typeFamily set to XMLBEANS_APACHE against WSDL in a jar or war file. This problem has been resolved. 10.0 MP2 Compilation error used to occur when upgrading WebLogic Server 8.1 App containing a JWS file to WebLogic Server 10.0 App. This problem has been resolved. 10.0 MP1 10.0 MP2 A shared WebLogic Tuxedo Connector hash table can cause unexpected behavior in the server if two applications point to the same VIEW name with different definitions. There should be a hash table for the view classes on the connection as well as for the Resource section. Workaround or Solution: Ensure that all VIEW classes defined across all your WebLogic Workshop applications are consistent, meaning that you have the same VIEW name representing the same VIEW class. 8.1 SP2 Will not fix Prior to WebLogic Server 9.2, the viewj and viewj32 compilers did not handle any view definition file with a missing NULL value; instead they issued a warning message and stop processing. However, in WebLogic Server 9.2 this behavior changed. The compilers generate a Java file for the view, but the view class will not have field data and access methods for them. The result is that the viewj and viewj32 compilers generate an incorrect Java view class. Workaround or Solution: Add NULL value for every field in the view definition file. WebLogic Server now packages the standard Ant distribution in WL_Home/modules/org.apache.ant_1.6.5 . If you use the standard WebLogic Server environment scripts created as a part of the installation, you will not need to make any changes to continue using Ant. If instead you directly referencing the Ant jars from the WebLogic Server installation, you will need to modify the classpath to point to the new location of the Ant distribution. The lib/ant-all.jar in that directory has a manifest classpath that refers to all of the other JARs in the lib directory. You should use ant-all.jar rather than ant.jar if you want to maintain the previous behavior, where the manifest classpath of ant.jar was modified to include all of the JARs in the lib directory. The manifest classpath for weblogic.jar no longer contains ant-contrib.jar . As a result, if you use ant-contrib tasks and get an error message like " Could not load definitions from resource net/sf/antcontrib/antlib.xml. It could not be found ", this means that ant-contrib.jar is not on the classpath. If you use WebLogic Server’s setWLSEnv scripts, ant-contrib.jar is added to the classpath; however if you are using your own scripts that previously put weblogic.jar on the classpath, you need to update your scripts to put ant-contrib.jar on the classpath. Workaround or Solution: Either add the standard distribution ant-contrib.jar to the classpath or add the one supplied with WebLogic Server: BEA_HOME/modules/net.sf.antcontrib_1.0b2.0/lib/ant-contrib.jar Some older Ant installations on UNIX may create a file named /etc/ant.conf . This file points to the Ant installation to be used on the machine. Older installations of Ant do not contain all the features required by WebLogic Server. This problem may be evident by errors such as: ant -version java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher Workaround or Solution: Delete the /etc/ant.conf file, or use ant -noconfig . WebLogic Server deployment would fail when deploying Web Services due to Windows restrictions on file path length. This would result in JarFileUtils$PathLengthException errors, causing the deployment to fail. Solution: This problem was corrected by modifying WebLogic Server to eliminate relative path usage and ensure that canonical paths are used internally. Errors from inconsistent Ant versions when using JarBuilder to create a client application. When you use the JarBuilder utility to build a client, you may receive an error like this: Invalid implementation version between Ant core and Ant optional tasks. This occurs because the resulting wlfullclient.jar includes Ant classes that have a version number that is inconsistent with the Ant version you have in your classpath. Workaround or Solution: Add ant.jar from your local Ant installation ahead of wlfullclient.jar in your client classpath. An alternative is to add the Ant module from the WLS installation ahead of wlfullclient.jar on the classpath: $BEA_HOME/modules/org.apache.ant_1.6.5/lib/ant-all.jar When you install version 3 of Smart Update on an existing BEA_HOME, and attempt to use it in command-line mode, an error ("Unsupported product release") occurs and Smart Update exits. Workaround or Solution: Uninstall Smart Update, then re-install Smart Update and select the option "Create a new BEA Home" to install under a separate directory.