12 Oracle WebLogic Server

12.1.1 Oracle WebLogic Server Version Number

Oracle Fusion Middleware 11g contains Oracle WebLogic Server 11g. The version number of Oracle WebLogic Server is 10.3.1.

12.1.2 Oracle ojdbc14.jar File Has Been Changed to ojdbc6.jar

The Oracle ojdbc14.jar file has been changed to ojdbc6.jar, for use with JDK 5 or 6. As a result, any explicit references you make to ojdbc14.jar must be changed to ojdbc6.jar.

12.1.3 Strong Password Enforcement May Cause Issues With WLST Offline Scripts

With the implementation of strong password enforcement (8 character minimum with one numeric or special character) in this release of WebLogic Server, existing scripts could potentially encounter issues.

Workaround

Use either of the following workarounds to bypass the new password restrictions.

• Set the BACKWARD_COMPAT_PW_CHECK environment variable to true.

• Include the -Dbackward.compat.pw.check=true option when invoking WLST.

Oracle recommends that you change passwords to comply with the new password requirements, as this variable and option will be removed in a future release of WebLogic Server.

12.1.4 In Turkish Locale MDS Initialization Fails

Any applications that use an MDS repository cannot be deployed or run with the JAXB version bundled with WebLogic Server as null values are returned for attributes named id.

Workaround

Start the server in English locale.

12.1.5 adf-config.xml Property Names Translated

When using the German, Spanish, or Portuguese(Brazil) language settings, the property names jndi-datasource and partition-name are translated in the adf-config.xml file in the wsm-pm application causing the following error: WSM-04509: cannot initialize the connection to the data store.

Workaround

Use one of the following workarounds to replace the translated the property names to english names which allows the schema to verify the adf-config.xml file:

Workaround 1: Replace <property name="JNDI-Datenquelle" value="jdbc/mds/owsm"/> with <property name="jndi-datasource" value="jdbc/mds/owsm"/> and replace <property name="Partitionsname" value="owsm"/> with <property name="partition-name" value="owsm"/> in the adf-config.xml file directly in the deployed environment. Restart the SOA server.

Workaround 2: Replace <property name="JNDI-Datenquelle" value="jdbc/mds/owsm"/> with <property name="jndi-datasource" value="jdbc/mds/owsm"/> and replace <property name="Partitionsname" value="owsm"/> with <property name="partition-name" value="owsm"/> in the adf-config.xml file inside of wsm-pm.ear, then redeploy it using the Administration console. This does not require a server restart.

Workaround 3: Before running the Configuration Wizard CIE, you can replace mds.partition.name=Partitionsname with mds.partition.name=partition-name and replace mds.jndi.ds=JNDI-Datenquelle with mds.jndi.ds=partition-name in the config_de.properties file in com.bea.cie.config.de_6.0.0.0.jar, com.bea.cie.config.pt.BR_6.0.0.0.jar, and com.bea.cie.config.es_6.0.0.0.jar files.

12.1.6 Administration Server Reports a 'Too Many Open Files' Message on the Enterprise Manager Console

The WLS Administration Server reports a Too Many Open Files message on the Enterprise Manager console when the maximum number of file descriptors configured for the Administration Server is less than 65535.

Workaround

Increase the number of file descriptors within the shell and restart the WLS Administration Server within that shell. The command to increase the number of file descriptors (nofiles) differs across Operating Systems and shells but it's usually done with the ulimit command on UNIX platforms so consult the man pages for ulimit.

For example:

$ ulimit -n 65535

12.2.1 Cached JDBC Information is not Displayed

Information about cached JDBC statements is not displayed on the JDBC Monitoring pages.

12.2.2 Pressing Browser Back Button Discards Context

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

Oracle 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.

12.2.3 Administration Console not Updating the Request URL

Under some circumstances, the Administration Console does not automatically update the request URL to follow administration port configuration changes.

If you have the Automatically Acquire Lock and Activate Changes Console option enabled (which is the default for development mode) and change the Console's address (for example, turn on the domain wide administration port, create an administration channel, or change to the SSL listen port), the Console will not automatically redirect to its new address. Instead, the browser will display an error.

Workaround

Enter the URL address and protocol in the browser where the administration server is now listening for requests (for example, switch from http://localhost:7001/console to https://localhost:9002/console).

12.2.4 Unsupported Work Manager Configurations Can Be Created

The Administration Console permits the creation of Work Manager configurations that are not supported and do not function as intended. Incorrect Work Manager configurations may result in a number of exceptions being recorded in the server logs, most commonly Validation problems were found exceptions while parsing deployment descriptors.

Workaround

Follow the guidelines described in the online help for Work Manager configurations. Specifically, you can only assign one request class to any given Work Manager, and that request class must be of the same or a broader scope than the Work Manager. You should not assign an application-scoped request class to a global Work Manager, and you should not create more than one application-scoped request class for an application-scoped Work Manager.

Correcting the Work Manager configurations to match the documented constraints resolves these issues.

12.2.5 Server Status Table Reflects Inconsistent Information

The Server Status table on the Cluster: Monitoring: Summary page includes two default columns: Primary and Secondary Distribution Names. These fields do not always reflect all of the replication statistics that are collected and displayed on the Cluster: Monitoring: Failover page, depending on the replication scenario.

Please refer to the Cluster: Monitoring: Failover page for definitive information.

12.2.6 Exceptions When Defining a Security Policy for an EJB

When defining security policies in the Administration Console for an EJB deployment that references types defined in a separate library deployment, exceptions can be observed if that library deployment is not available to the Console.

Workaround

All library deployments should be targeted at the Administration Server as well as any managed servers needed to support referencing applications. This will ensure that when defining policies, the Console will have access to those library deployments so that referenced types can be class-loaded as needed.

12.2.7 Administration Console Does Not Always Reflect External Changes Made in a Deployment Plan

The Administration Console does not always reflect external changes made in a deployment plan. If a change is made in a deployment plan outside of the Console (for example, using Workshop, editing the plan text files directly, or updating a deployment with a new plan using WLST or WebLogic.Deployer) while a Console user is also viewing that deployment plan, the Console user will not see those changes.

Workaround

Navigate to a configuration page for a different deployment, then navigate back to the original deployment again.

12.2.8 Screen Reader Configuration Must Be Changed in Order to Read Link Title Attributes

To improve its level of accessibility to blind users, in certain situations, the Administration Console provides title attributes for links whose purpose or target needs a better explanation than the link text alone provides. The primary case is when links are part of a 'simulated tab' group, and of which 'tab' is currently selected. However, screen reader users need to make a configuration change for these link title attributes to be read instead of the visible link text.

The following instructions are provided for the leading screen reader, JAWS (by Freedom Scientific):

To configure JAWS to read link titles:

1. With WebLogic Server as the active browser window, activate JAWS' Personalized Settings dialog by pressing Insert+Shift+V.

2. For JAWS versions 6.x, 7.x, and 8.x:

   Navigate to the Links With Text Only setting, then select the Title option (toggle through the values by pressing the spacebar).

   For JAWS version 9.x:

   Expand the Links Options node, navigate to the Text Links option, then select the Show Using Title option (toggle through the values by pressing the spacebar).

3. Select Close to save the configuration change.

12.2.9 Oracle OCI Driver Support

The Oracle OCI driver is no longer explicitly listed as a preconfigured driver type in the Administration Console.

Workaround

The Oracle OCI driver remains a supported driver for application data connectivity, consistent with prior releases of Oracle WebLogic Server. However, users must now specify all required configuration properties maually, including the data base username.

12.5.1 ConfigToScript Fails to Create a Domain

If there is no server running when you run a config.py file that was generated by ConfigToScript, it fails to create a domain with the following error:

com.bea.plateng.domain.script.ScriptException: The password must be at least 
8 alphanumeric characters with at least one number or special character.

Workaround

Start the server manually, then run the config.py file that was generated by ConfigToScript. Use the following steps:

1. After config.py fails with the ScriptException, cd to the empty domain directory:

   cd <domain_name>
   

   the default for <domain_name> is WLSTConfigToScriptDomain when you run config.py without starting the server.

2. Start a server and create the initial empty domain:

   java -Xmx512m -XX:MaxPermSize=128m -Dweblogic.Name=AdminServer 
   -Dweblogic.Domain=<domain_name> weblogic.Server
   

   Substitute <domain_name> with the appropriate name of your domain. Enter the desired username and password when prompted.

3. Modify the generated config.py to prompt for a username and password by changing the connect command in the config.py from:

   connect(userName, passWord, URL)
   

   to

   connect()
   

4. Run config.py again.

   java weblogic.WLST config.py
   

   It will prompt you for the username and password you specified in Step 2.

12.5.2 Directory For a Non-Existent Server Name Is Created

If you attempt to connect to the admin server server with a non-existantserver name, a directory for the non-existent server name is created under the domain_name/servers directory.

Workaround

Specify a valid server name when connecting to the administration server.

12.5.3 Abnormal Behavior in Terminal Window After Entering WebLogic Password

After pressing Ctrl-C to terminate the startManagedWebLogic.sh process immediately after entering the WebLogic password, abnormal behavior may be experienced in the terminal window. For example, when pressing Return, the prompt is tabbed instead of going to the next line, and any characters that are entered at the prompt are not displayed in the terminal. This is a development mode issue, and does not occur in production.

Workaround

Either close the current xterm and start a new one, or enter stty echo into the xterm.

12.6.1 New Connection Instances in a Resource Adapter Do Not Take Effect

After creating a new outbound connection instance in a Resource Adapter, the Administration Console displays the message "All changes have been activated. No restarts are necessary." The new connection, however, will not take effect until you restart the server.

Workaround

Restart the server after creating a new connection instance.

12.8.1 Threads Become Stuck While Waiting to Get a Connection

When a machine that is hosting one of the managed servers is abruptly shut down, a network cable is pulled, or its network interface card has issues, and any server attempts communication with that managed server, threads become stuck waiting to get a connection.

Workaround

This can currently be resolved by using a private flag:

-Dweblogic.client.SocketConnectTimeoutInSecs

and setting an appropriate timeout value that will release the thread attempting to make the connection and allow the request to fail quickly.

12.8.2 Using IPv6-Formatted Addresses

When using an IPv6-formatted address for WLS, the URL should include square brackets ('[' and ']') for the host address. Otherwise, WLST may fail to connect to the running server.

Workaround

Add square brackets to the host address. For example:

t3://[fe80:0:0:0:203:baff:fe2f:59e5]:9991

12.8.3 Server Cannot Be Started After a Whole Server Migration

If the Administration Server is down when a Whole Server Migration occurs for a clustered server, and the server migrates to a machine on which it was never run before, the server cannot be started on the new machine.

Workaround

Use one of the following workarounds for this issue:

• Ensure that the Administration Server is up when the server migration is being performed.

• Use a shared disk/NFS for all the migratable servers in the cluster.

12.8.4 Object State is not Retained After Renaming Field

When Fastswap is enabled in a J2EE application, you can make certain types of changes to Java classes during development and expect to see the change without re-deploying, with all instance states of the Java object being retained.

One type of change that does NOT retain the object state is that when a field name is changed, it is treated as follows:

• the field with old name is deleted

• the field with new name is added

Thus, in this case, any state in the old field is not carried over to the renamed field.

Using the Workshop or FastSwap ant task, you may see a FastSwap operation completed successfully message, even when an instance field name change causes a value reset.

Workaround

You should expect an instance value to be reset when you change a field name.

12.8.5 Administration Server or Node Manager Cannot Track the Status of a Managed Server in MSI mode

If you start a managed server by providing an incorrect Administration Server URL from the command line (that is, the Administration Server cannot be reachable at the provided URL), the managed server will start in Managed Server Independence (MSI) mode.

In this case, neither the Administration Server nor Node Manager can track the status of the managed server. The Administration Console will show the status of the managed server as UNKNOWN, but the server will actually be RUNNING in MSI mode.

12.8.6 Multicast Traffic Observed to be Unreliable During or After a Network Partition

During or after a network partition that causes a server migration to take place, multicast traffic has been observed to be unreliable. For example, one node may be receiving multicst traffic, but traffic originating from this node is not received on other nodes in the network. As a result, the migrated servers are not added to the cluster because their heartbeats were not received.

Workaround

Currently, the only known workaround is to use unicast cluster messaging.

12.8.7 JRockit Version Should Be Updated After Installing WebLogic Server

WebLogic Server Release 10.3.1 ships with JRockit version R27.6.2 (JDK 1.6.0_05). Oracle strongly recommends that you download and install the latest available JRockit version (minimum is a version based on JDK 1.6.0_10 or later).

12.9.1 security-permission Element is not Available in weblogic-application.xml

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.

12.9.2 Extraneous String Values Interpreted as File Specification

The weblogic.Deployer tool interprets any extraneous 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.

12.9.3 java.lang.NoClassDefFoundError is Displayed

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.

12.9.4 Deployment Task Is Left in Initializing State

If you start an edit session, install an application, and then undo the changes, a deployment task is not cleaned up appropriately. This task is left in the initializing state and causes issues with future Activate Changes.

12.9.5 The restore Method Does Not Update the DConfig Bean With Plan Overrides

The restore method does not correctly update the DConfig Bean with the plan overrides. For example, given the following steps:

DeployableObject dObject =
     WebLogicDeployableObject.createDeployableObject(new File(appName));
  DeploymentConfiguration dConfig =
     WebLogicDeploymentManager.createConfiguration(dObject);
  dConfig.restore(new FileInputStream(new File(plan)));

the plan does not correctly override the DConfig Bean.

Workaround

Specify the plan when initializing the configuration for the application. For example:

helper = SessionHelper.getInstance(
        SessionHelper.getDisconnectedDeploymentManager());
    helper.setApplication(app);
    helper.setPlan(new File(plan));
    helper.initializeConfiguration();

12.9.6 "config-root <directory> not found" Warning Is Displayed When Applying a Deployment Plan

If you use the administration console to make configuration changes to an application, a deployment plan will be generated. If external descriptors are generated as part of the deployment plan, they are placed in the config root plan directory. This directory will be set in the deployment plan 'config-root' attribute.

If no external descriptors are required, the config root directory will not be created, and a warning is displayed when you apply the deployment plan. This results in the following warning in the server output:

<Warning <WWebLogicDescriptorWL> <BEA-2156000><"config-root" C:\deployments\plan was not found>.

Workaround

Create the plan directory manually.

12.9.7 Application State Is Not Updated If the Server Starts in MSI Mode

A managed server will start in MSI mode if the administration server is not available when the managed server starts. If you start the administration server later, the managed server will connect to the admininstration server. However, the state of each application deployed to the managed server is not updated to reflect the state of the applications on the managed server. Each application's state is displayed as NEW or PREPARED in the WebLogic Server admininistration console.

Workaround

There are two workarounds for this issue:

• Start the administration server before starting the managed server, or

• Redeploy the application after starting the administration server.

12.10.1 Primary Key in Oracle Table is CHAR

The primary key in an Oracle table is a CHAR but the query field in the SQL table is a VARCHAR2.

Workaround

Change the database schema from CHAR to VARCHAR2. Using CHAR as a primary , key is not recommended for the Oracle database.

12.10.2 No Available Annotation That Enables Creation of a Clusterable Timer

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.

12.10.3 Kodo's MappingTool Cannot Generate Schemas

Kodo's MappingTool cannot generate schemas for classes that use BLOBs in their primary key. BLOBs can be used in a primary key, but the schema must be defined manually. Note that support for BLOB columns in primary keys is not mandated by either the JDO or JPA specifications.

12.10.4 Extensions to the JPA Metadata Model Can Only Be Specified Via Annotations

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

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.

12.10.5 Lookup Method Injection Not Supported by Spring

The Weblogic Spring injection extension model doesn't support lookup method injection.

12.10.6 Deserializing a JDO PersistenceManagerFactory in a Managed Environment May Fail

Deserializing a JDO PersistenceManagerFactory in a managed environment may fail. The exception states that the javax.jdo.PersistenceManagerFactoryClass property is missing. Note that serializing a PersistenceManagerFactory should not generally be necessary in a managed environment.

12.10.7 Application Deployment Fails With IllegalArgumentException

When filtering out just the org.apache.openjpa.* packages (but not the com.solarmetric.* and kodo.* packages), deployment of the application will fail with an exception message similar to this:

java.lang.IllegalArgumentException: interface org.apache.openjpa.event.CallbackModes is not visible from class loader

Note that the particular class or interface cited in the exception message may vary.

Workaround

When deploying an application-provided version of OpenJPA, all three Kodo-related packages must be filtered using the prefer-application- libraries directive:

<weblogic-application>
  <prefer-application-packages>
     <package-name>org.apache.openjpa.*
    </package-name>
    <package-name>kodo.*</package-name>
   <package-name>com.solarmetric.*
   </package-name> 
   </prefer-application-packages>
</weblogic-application>

The Kodo and com.solarmetric packages must be filtered even if you want to disable all Kodo features (that is, only use OpenJPA).

Additionally, if you want to provide your own version of openjpa.jar, but use the WebLogic-provided Kodo jar, the application must still exclude kodo.* and com.solarmetric.*, and the application must bundle the Kodo jar from the WebLogic distribution.

Applications may also need to exclude serp.* and bundle their own version of it at some point in the future if new APIs or bug fixes are introduced in that codebase. However, there are no interdependencies with serp as there are between the org.apache.openjpa.*, kodo.*, and com.solarmetric.* packages.

12.10.8 Indexes Not Always Created During Schema Creation

Indexes declared at the class level are not always created during schema creation.

Workaround

Create the indexes manually after running the schema generation tools.

12.10.9 OpenJPA throws an exception when @Id fields are also annotated as @Unique

OpenJPA throws an exception when @Id fields are also annotated as @Unique in some databases. Database primary keys are unique by definition. Some databases implement this by creating a unique index on the column.

Workaround

Do not specify both @Id and @Unique on a single field.

12.10.10 Inserting a Record in the Database Fails When Using WebLogic-Supplied Sybase Driver

When using the Weblogic-supplied Sybase driver instead of the Sybase-supplied JDBC driver, attempting to insert a record in the database for an entity whose ID is auto-incremented can fail, as the default query to fetch the next available identity value always returns zero.

Workaround

Override the lastGeneratedKeyQuery property in the kodo.properties file as shown here:

openjpa.jdbc.DBDictionary: lastGeneratedKeyQuery='SELECT MAX({0}) FROM {1}'

12.10.11 Cache Hit and Miss Counts May Rise Unexpectedly

The cache hit and miss counts may rise unexpectedly when manipulating entities without version data. The extra cache access occurs when the EntityManager closes and all contained entities are detached. Entities without version fields appear to the system to be missing their version data, and the system responds by checking their version in the cache before detachment.

Workaround

Entities with version fields or other version strategies do not cause extra cache access.

12.10.12 Empty Byte Array Field Values Stored as NULL

When trying to persist an empty byte array field within an entity to a Sybase database, the value gets stored as a NULL rather than as bytes. Therefore, the value is retrieved as NULL.

This is a limitation of the Sybase drivers, which convert the empty byte array to a NULL while storing it in the database. This happens with both Weblogic JDBC drivers as well as the proprietary Sybase drivers.

12.10.13 Open JPA Tries to Create a Table Even if the Table Exists

When using the MySQL database, and OpenJPA is configured to automatically run the mapping tool at runtime and create tables within the default schema (for example):

<property name='openjpa.jdbc.SynchronizeMappings' value='buildSchema'/>
<property name='openjpa.jdbc.Schema' value='MySQL database name' />

OpenJPA will try to create the table even if the table already exists in the database. A PersistenceException will be thrown to indicate that the table already exists and the table creation statement fails.

Workaround

To avoid this problem, if you are using the MySQL database, don't configure OpenJPA to automatically run the mapping tool at runtime and specify the default schema at the same time.

12.10.14 EJB Applications Fail During Serialization

EJB applications that use IIOP and send JPA entities from the server to the client will fail during deserialization if the entities are Serializable (but not Externalizable) and do not declare a writeObject() method.

Workaround

Add a writeObject() method to such entity classes. The write object can be trivial:

private void
writeObject(java.io.ObjectOutputStream out)
   throws IOException {
  out.defaultWriteObject();
}

12.10.15 Unable to Serialize a Business Object in the EJB3 Specification

Currently, there is no way to serialize a business object in the EJB3 specification, which is different than a traditional component object.

Workaround

When you need to serialize a business object, first invoke BusinessObject._WL_getBusinessObjectHandle() to get the business handle object, then serialize the business handle object. To recover from this serialization, just deserialize to get the business handle object, then invoke its getBusinessObject().

12.10.16 Maintaining Ready Bean Instances Can Adversely Affect Performance

For entity beans with a high cache miss ratio, maintaining ready bean instances can adversely affect performance.

Workaround

By setting the flag <disable-ready-instances> in the <entity-cache> element of an <entity-descriptor>, the container will not maintain the ready instances in cache. If the feature is enabled in the deployment descriptor, the cache will only keep the active instances. Once the involved transaction is committed or rolled back, the bean instance is moved from active cache to the pool immediately.

12.10.17 Using Generics in EJB Can Cause Problems

Using generics in EJB will cause a problem in the following cases:

1. When the business interface extends java.rmi.Remote, and extends some generic methods from a super class, the deployment will fail.

2. When the business interface doesn't extend java.rmi.Remote, the invocation on the generic business methods will fail.

Workaround

The first case is a limitation in WLS 10.3 or greater.

The second case can be resolved by downloading the needed classes from the server side. If network downloading is disabled, however, the invocation will fail still. If network downloading isn't permitted in the user's environment, it is recommended that you run appc first, then add the generated classes to the classpath of the client side.

12.11.1 Security Configuration in medrec.wls.config

The medrec.wls.config target in SAMPLES_HOME/server/medrec/setup/build.xml has a known issue with respect to security configuration.

12.11.2 HTML File not Created for StreamParser.java File

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

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.

12.11.3 Warning Message Appears When Starting Medrec or Samples Domain

When you start the medrec or samples domains, you may see a warning message similar to this:

<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 output of the Console while starting a WebLogic Server sample application with an asynchronous Web Service deployed.

Workaround

The warning is harmless and can be ignored.

12.12.1 Authentication and Authorization of the Local Client is not Supported

The HTTP PublishSubscribe server does not support authentication and authorization of the local client. The local client has full permissions to operate on channels of the HTTP PublishSubscribe server, which means the local client can create/delete channels and publish/subscribe events from channels.

12.12.2 Event Messages Published by Local Clients Cannot Be Received by Subscribed Clients Connected to Other Servers

In a clustering environment, event messages published by a local client on a server can be received only by subscribed clients connected to the same server. These messages cannot be received by subscribed clients connected to other servers in the cluster.

12.12.3 Event Messages Published By Local Clients Do Not Go Through Message Filters

Event messages published to a channel by a local client will not go through the Message Filters configured to that channel.

12.13.1 The pack and unpack Commands Fail When WebLogic Server Is Not Installed in the Default Location

When the WebLogic Server product is installed in a location other than the default, the pack and unpack commands can fail with a java.lang.ClassNotFoundException.

Workaround

Edit the $WL_HOME/.product.properties file, where $WL_HOME is the directory in which WebLogic Server is installed. Add the following two properties:

weblogic.server.modules.featurejar=MWHOME/modules/features/weblogic.server.
modules_10.3.1.0.jar

WLS_PRODUCT_VERSION=10.3.1.0

Substitute the absolute path to the Fusion Middleware Home directory for MWHOME, using the appropriate file separator. For example, on Microsoft Windows platforms:

weblogic.server.modules.featurejar=D\:\\myMWhome\\modules\\features\\weblogic.
server.modules_10.3.1.0.jar

12.13.2 Installation Fails with Fatal Error

The installer does not verify whether sufficient disk space is available on the machine prior to completing the installation. As a result, if an installation cannot be completed due to insufficient space, the installer displays the following error message and exits:

Fatal error encountered during file installation. The installer will nowcleanup and exit!

Workaround

If this problem occurs, restart the installer using the following command:

$JAVA_HOME/bin/java -jar wls1031_generic.jar -log=log.out -log_priority=debug

The preceding command generates a log of the installation procedure, providing details about the exact cause of the failure. If the cause is indeed insufficient space, the log file indicates it explicitly.

12.14.1 FastSwap May Relax the Access Modifiers of Fields and Methods

FastSwap may relax the access modifiers of fields and methods. Private and protected members may be made public at runtime. This changes the behavior of reflection and may affect reflection-based frameworks such as Struts.

12.14.2 FastSwap Does Not Support Redefinition of the Entity Bean and ejbClass (Session/MDB)

FastSwap does not support redefinition of the Entity bean and ejbClass (Session/MDB). Therefore, any updates to entity classes will cause redefinition errors.

Workaround

After updating an entity class, redeploy the application.

12.14.3 Classpath Order Is Not Guaranteed When There Are Multiple Jars in the Same EAR File

When you have an ear file containing separate jar files, and two or more of those jar files have a class with the same name, it is not possible to predict from which of those jar files WebLogic Server will instantiate the class. This is not an issue if the classes are the same, but if they are different implementations, the results are unpredictable.

Workaround

Currently there is no known workaround for this issue.

12.16.1 stopWebLogic.sh Command Exposes Password

The WebLogic Server system password may appear in clear text while prompted for userid and password when using the stopWebLogic.sh command.

Workaround

Do one of the following:

• Include $JAVA_VM in the java command of the stopWeblogic.sh script.

• Include -d64 in the java command of the stopWeblogic.sh script if you are using a 64-bit Sun JVM.

12.17.1 Deployment Descriptor Validation Fails

Deployment descriptor validation fails when descriptor validation is enabled, and an EAR file contains only JMS modules.

Workaround

Make sure that there is at least one J2EE specification-compliant module in the EAR.

12.17.2 Exception When Multiple JMS Producers Use the Same JMS Client SAF Instance

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

When using multiple JMS SAF client producers, try introducing a small delay between the creation of each new client.

12.17.3 Multi-byte Characters are not Supported in WLS Store File and Directory Names

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

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.

12.17.4 Memory Leak Due to Special Characters in Connection IDs or Subscriber IDs

Certain JMS applications could cause a memory leak on a WebLogic server if periods (that is, dots) or slashes are present inside Connection IDs or Subscriber IDs. This issue typically occurs only for applications that both (a) continuously create and destroy durable subscriptions on topic destinations, and (b) specify a unique string prior to the last '.' or '/' in the Connection ID or Subscriber ID for each new durable subscription, instead of reusing strings from past destroyed subscriptions.

Workaround

Use caution when specifying a period '.' or slash '/' in a Connection ID and Subscriber ID.

12.17.5 C Programs That Use the JMS C Client Library May Experience a JVM Failure

A C program that uses the JMS C client library may crash with a JVM failure. This could be related to a known intermittent race-condition that is only known to occur with certain JVM products, where the likelihood of failure can change based on the JVM version and patch level, operating system, and hardware. Specifically, the JMS C-Client library implicitly attaches C-threads to the JVM, but fails to detach them when it is done with them.

Workaround

The workarounds are:

1. Add code in the client to detach the JVM from any C thread that exits and that has previously called into the JMS C-API.

2. Do not allow any C thread that has previously called into the JMS C-API to exit before the entire process exits.

   Sun 1.5 and later can specifically handle this problem, although it is still recommended to call detach even with the Sun JVM. For more information, see:

   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219874

3. Upgrade to a newer JVM. Version 1.5 and later of the Sun JVM, and version R27.6 of the JRockit JVM do not have this problem, although it is still recommended to call detach even with the updated JVMs. For more information about this issue with the Sun JVM, see

   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219874

12.18.1 JMS Message Consumers Will Not Always Reconnect After a Service Migration

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

The application can refresh the consumer either in the exception handler or through onException.

12.19.1 Deployment Plans Cannot Be Used To Override Two Descriptors

Deployment plans cannot be used to override the following two descriptors during deployment of a web application or a web module: WEB-INF/classes/META-INF/persistence.xml and WEB-INF/classes/META-INF/persistence-configuration.xml. Deployment plans can otherwise be used to override any descriptor.

Workaround

Package WEB-INF/classes/META-INF/persistence.xml and WEB-INF/classes/META-INF/persistence-configuration.xml (if present) along with related class files into a jar file. The jar file must then be placed in the WEB-INF/lib directory of the web application or web module. A deployment plan can be used to override the two descriptors in such a jar file.

12.19.2 Spring Dependency Injection Not Supported on JSP Tag Handlers

With the Spring extension model enabled, WLS 10.3 or greater does not support Spring Dependency Injection (DI) on JSP tag handlers for performance reasons.

Currently, WLS supports Spring DI on most web components, for example, servlets, filters and listeners. Spring DI is not, however, presently supported on JSP tag handlers for performance reasons.

12.19.3 503 Error When Accessing an Application With a Valid sessionid

When a session is persistent and an old version of a servlet context is retired, accessing the application with a valid sessionid will cause a 503 error.

For example, the session-persistent type of a versioned web application is 'file'. A user can access the application successfully. Later, version 2 of the application is redeployed and version 1 is retired. If the same user accesses the application, they will get a 503 error.

12.21.1 1.4 Thin Client Applet Cannot Contact WebLogic Server

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

None. This issue must be resolved by Sun Microsystems.

12.21.2 JRockit JVM Appears to Freeze When Doing Long Array Copies

The JRockit JVM appears to freeze when doing long array copies as part of unlimited forward rolling. This can happen when multiple server reboots occur due to Out Of Memory conditions.

Workaround

When booting the servers, include the following JRockit JVM flag:

-XXrollforwardretrylimit:-1

12.21.3 Using AWT libraries May Cause a JVM Crash

You might encounter a JVM crash when using GUI libraries such as AWT or javax.swing (which often delegates to AWT).

Workaround

Start the server using the following flag:

-Djava.awt.headless=true

12.22.1 MBean Attributes not Explicitly Marked as @unharvestable Appear as Harvestable in the WLS Administration Console

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 the WebLogic Administration Console.

Workaround

You can explicitly mark MBean attributes as @unharvestable.

12.22.2 WatchData Field in an Outgoing Notification is Empty

When a Harvester watch rule variable resolves to multiple metric data points triggers, the WatchData field in the outgoing notification would be empty; normally this is supposed to contain a list of the MBean instances and the actual values of the attributes used to evaluate the rule.

12.22.3 -C prop-file Option of the SnmpTrapLogger Command Does Not Work

The -C prop-file option of the SnmpTrapLogger sub-command 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 sub-command of the SNMP command line tool.

Workaround

Currently, there is no workaround for this issue.

12.22.4 NullPointerException Occurs When Configuring the First WLDF Watch

When configuring the WLDF Harvester for the first time after a server reboot, if you attempt to configure the first WLDF Watch in a WLDF module on an MBean Metric in the DomainRuntime namespace, a NullPointerException occurs. The error occurs because the console is atempting to query the Harvester for the set of MBeans that are available on the server's DomainRuntime MBeanServeer before the Harvester has finished initializing. This occurs only if both (a) the Harvester is not yet initialized and (b) the first Watch created in a WLDF module is being configured for an MBean in the DomainRuntime namespace.

This is not a serious error.

Workaround

Cancel the Watch creation attempt and retry. The NullPointerException error should not occur again.

12.22.5 NullPointerException When Using MethodInvocationStatisticsAction After It Was Added Using a Deployment Plan

If you use a deployment plan to add a new diagnostic monitor to the instrumentation of a deployed application, and the MethodInvocationStatisticsAction action is attached to the newly added monitor, a NullPointerException is thrown while executing the MethodInvocationStatisticsAction action under the following conditions:

1. The application is already deployed.

2. You added a new 'around' diagnostic monitor to the application's instrumentation configuration using the deployment plan.

3. The MethodInvocationStatisticsAction is attached to the newly newly added diagnostic monitor using the deployment plan.

4. The application is exercised so that the MethodInvocationStatisticsAction gets invoked.

This issue happens only when MethodInvocationStatisticsAction is attached to a newly added diagnostic monitor using a deployment plan after the application has been deployed. The issue does not happen if the application is redeployed after you have updated the instrumentation configuration.

Workaround

When MethodInvocationStatisticsAction is to be added ot the application's instrumentation configuration, redeploy the application with the plan rather than only updating the application with the plan.

12.22.6 Complex and Array Type Attributes Have Been Removed From the SNMP MIB

Entries for MBean attributes that are either complex types or arrays of complex types have been removed from the SNMP MIB in WebLogic Server 10.3.1, as SNMP does not support these types natively. Previous versions of WebLogic Server returned Object.toString() for complex type objects, which is not meaningful for any monitoring purpose.

12.22.7 The BEA Prefix in Message IDs Will Be Changed in a Future Release

In an upcoming release of WebLogic Server, the current default prefix for catalog and non-catalog Message IDs will be changed from the current BEA prefix to WL.

Workaround

You should be prepared for this future change. In the interim, here are some guidelines to consider:

• Avoid depending on BEA for Message ID prefixes in scripts, filter expressions, etc.

• For log messages such as the following:

  <Jan 30, 2009 12:51:49 AM CST> <Notice> <WebLogicServer> <BEA-000365> 
  <Server state changed to STARTING>
  

  it is better for you to filter on '000365' and not on the BEA prefix itself.

• Your log parsing scripts should be updated to look for both BEA and WL, instead of filtering only on BEA.

12.26.1 Ant 1.7 rmic Task Incompatibility

Calls to the Ant version 1.7 rmic task automatically add a -vcompat flag, which is not compatible with Oracle WebLogic Server's rmic.

Workaround

Use either of the following workarounds if your rmic call is of the form:

rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
   base="${module_location}/core-legacy-ra/classes"
   classpath="${core.classes}" compiler="weblogic" />

• Add a stubversion

  <rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
     base="${module_location}/core-legacy-ra/classes"
     classpath="${core.classes}" compiler="weblogic"
     stubversion="1.2"/>
  

• Remove the compiler flag

  <rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
     base="${module_location}/core-legacy-ra/classes"
     classpath="${core.classes}"
  

12.27.1 StoreBootIdentity Option Works Only if the Appropriate Server Security Directory Exists

The option -Dweblogic.system.StoreBootIdentity works only 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.

12.27.2 Connections Requiring a NULL Cipher Will Fail Unless AllowUnencryptedNull Cipher is Set to True

WLS allows for a NULL cipher to be used with an SSL connection, which results in data not being encrypted.

In WLS 10.3 or greater, the use of the NULL cipher is now disabled by default. In order for a client to enable the NULL cipher, set the weblogic.ssl.AllowUnencryptedNullCipher system property to true. For example:

-Dweblogic.ssl.AllowUnencryptedNullCipher=true

In WLS 10.3 or greater, client SSL connections requiring a NULL cipher will fail unless this system property explicitly enables the use of the NULL cipher. For NULL cipher to be used, you need to enable NULL cipher on both the server side and client side. If not enabled on both sides, the SSL handshake will fail.

12.27.3 WLS Server Instance Experiences Boot Time Failure with SecurityServiceException

A WLS Server instance can experience a boot time failure with a SecurityServiceException when the RDBMS Security Data Store is configured for a DB2 database using the WLS-supplied DB2 driver.

Workaround

When RDBMS Security Data Store is using the AlternateId connection property for a DB2 database, you must also set the additional property BatchPerformanceWorkaround as true when using the WLS-supplied DB2 driver.

12.27.4 Authentication Failure After Upgrading a Domain From WLS 6.1

After upgrading a domain from WLS 6.1, the WLS Server instance will not boot due to an authentication failure.

Workaround

A system user password must be set up in the WLS 6.1 domain before or after the upgrade process in order for the WLS Server instance to boot properly.

12.27.5 InvalidParameterException Message Generated and Displayed in the Administration Console

After you configure either the Identity Provider or Service Provider services for SAML 2.0 and attempt to publish the SAML 2.0 services metadata file, an InvalidParameterException message may be generated and displayed in the Administration Console.

Workaround

When configuring the SAML 2.0 federation services for a WebLogic Server instance, be sure to enable all binding types that are available for the SAML role being configured. For example, when configuring SAML 2.0 Identity Provider services, you should enable the POST, Redirect, and Artifact bindings. When configuring SAML 2.0 Service Provider services, enable the POST and Artifact bindings. Optionally, you may choose a preferred binding.

12.27.6 Default Web Permissions in weblogic.policy Do Not Work if There Is No weblogic.xml File

If you define your default web application permissions in weblogic.policy, but your web application does not have a weblogic.xml descriptor file, the default web permissions will not take effect, and you may see an AccessControlException.

Workaround

Add a weblogic.xml descriptor file to your application.

12.27.7 Random Number Generator May Be Slow on Machines With Inadequate Entropy

In order to generate random numbers that are not predictable, SSL security code relies upon "entropy" on a machine. Entropy is activity such as mouse movement, disk IO, or network traffic. If entropy is minimal or non-existant, then the random number generator will be slow, and security operations may time out. This may disrupt activities such as booting a managed server into a domain using a secure admin channel. This issue generally occurs for a period after startup. Once sufficient entropy has been achieved on a JVM, the random number generator should be satisfied for the lifetime of the machine.

For further information, see Sun bugs 6202721 and 6521844 at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6202721

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6521844

Workaround

On low-entropy systems, you can use a non-blocking random number generator, providing your site can tolerate lessened security. To do this, add the -Djava.security.egd=file:///dev/urandom switch or file:/dev/./urandom to the command that starts the Java process. Note that this workaround should not be used in production environments because it uses pseudo-random numbers instead of genuine random numbers.

12.27.8 Circular Group Membership Can Cause OracleInternetAuthenticator to Open Many LDAP Connections

If the schema in an OID server has a static group, and the static group contains a uniquemember entry that points back to the static group itself, this creates a circular group membership. Such a circular reference can cause the WebLogic Server OracleInternetAuthenticator to open many LDAP connections to the LDAP server, eventually using up all connection resources.

Workaround

Do not include a static group with a reference back to itself in the LDAP schema.

12.28.1 OpenJPA ClassFileTranformer Does Not Work When Running WebLogic Server on JRockit

The OpenJPA ClassFileTranformer doesn't work when running WebLogic Server on JRockit.

Workaround

Use an alternative method of applying enhancements at build time through an OpenJPA enhancer compiler; do not use the LoadTimeWeaver.

12.28.2 petclinic.ear Does Not Deploy on WebLogic Server

For the SpringSource 'petclinic' sample, the petclinic.war deploys without any problem. The petclinic.ear will not deploy on WLS because it is not packaged correctly. A request has been sent to SpringSource to fix the petclinic.ear packaging.

12.29.1 Domains Created Using WebLogic Server 10.3.1 Cannot Be Run on WebLogic Server 10.3

If you create a domain using WebLogic Server 10.3.1, then roll back to WebLogic Server 10.3, you will not be able to start the servers that you created in that domain. This is a known restriction, as the config.xml file contains references to newer schema definitions (xmlns.oracle.com) that did not exist in WebLogic Server 10.3.

12.30.1 Original Application Version Is Not Retired When Using the Production Redeploy Feature to Deploy a New Version

When using the production redeploy feature to deploy a new version of an application, it is typical to initiate a graceful shutdown of the original application so that all existing sessions continue to be handled by the original version of the application. If, however, you are using jdbc or async-jdbc session persistence, the original version of the application is not retired.

Workaround

You have two options as a workaround:

• If there are no incompatibility issues in the session objects between the two versions fo the application, select the production redeployment with no graceful shutdown (Force stop now). This ensures that the only one application version is active and taking requests.

• If there are incompatibility issues between the two versions of the application, perform a graceful retirement for the old version. Monitor your applications and session table to find the appropriate time to force the retirement of the old version. The session table shows all sessions. When all of the sessions in the table have been reduced (due to timeout or invalidation) to only those from the new version of the application, you can safely retire the old version of the application by forcing a shutdown.

12.30.2 Admininstration Console Fails to Implement session-timeout Changes

If the session-timeout is configured in the web.xml file, any changes made to change the session-timeout using the Administration Console do not take effect.

Workaround

Use a deployment plan to override the session-timeout setting.

12.31.1 Property Names Containing '.' Characters Are Not Supported by loadProperties Command

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, or package naming, or both. 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.

Workaround

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 the 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

12.31.2 Invalid cachedir Created by Jython Causes WLST to Error Out

The default cachedir created by Jython 2.2 is not a valid directory. If you are using Jython directly from weblogic.jar, this causes WLST to error out.

Workaround

There are two workarounds for this issue:

• When invoking WLST, specify the -Dpython.cachedir=<valid_directory> parameter, or

• Install Jython 2.2.1 separately instead of using the partial Jython that is included in weblogic.jar.

12.31.3 WLST returnType='a' Option Returns Child Management Objects

The WLST returnType='a' option should only return attributes from the specified directory. Instead it also returns child management objects. For example:

ls('Server')
drw-   AdminServer
drw-   worker01

ls('Server', returnMap='true', returnType='a')
drw-   AdminServer
drw-   worker01

ls('Server', returnMap='true',returnType='c')
drw-   AdminServer
drw-   worker01

The ls with returnType='a' should not list any child management objects, but AdminServer and worker01 are children.

Workaround

When processing the output from ls(returnType='a'), check to see if the returned entry is a directory.

12.32.1 MOD_WLS_OHS DOES NOT FAILOVER

Currently, mod_wl and mod_wl_ohs only support container level failover and not application level failover. mod_wl_ohs continues to route requests to a down application as long as the managed server is up and running. In the clustered case, requests continue to go to the container where the original session started even when the application is shutdown, typically resulting in the http error 404.

12.33.1 Sparse Arrays and Partially Transmitted Arrays Are Not Supported

WebLogic Server does not support Sparse Arrays and Partially Transmitted Arrays as required by the JAX-RPC 1.1 Spec.

12.33.2 WSDL Compiler Does Not Generate Serializable Data Types

The Web Service Description Language (WSDL) compiler does not generate serializable data types, so data cannot be passed to remote EJBs or stored in a JMS destination.

12.33.3 Use of Custom Exception on a Callback

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

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.

12.33.4 Cannot Use JMS Transport in an Environment That Also Uses a Proxy Server

You cannot use JMS transport in an environment that also uses a proxy server. This is because, in the case of JMS transport, the Web Service client always uses the t3 protocol to connect to the Web Service, and proxy servers accept only HTTP/HTTPS.

12.33.5 Clientgen Fails When Processing a WSDL

Clientgen fails when processing a WSDL that uses the complex type http://www.w3.org/2001/XMLSchema{schema} as a Web Service parameter.

12.33.6 JAX RPC Handlers in Callback Web Services Are Not Supported

WebLogic Server 9.2 and later does not support JAX RPC handlers in callback Web Services.

Workaround

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.

12.33.7 Message-level Security in Callback Web Services Is Not Supported

WebLogic Server 9.2 and later does not support message-level security in callback Web Services.

Workaround

Web Services created with WebLogic Workshop 8.1 that used WS-Security must be redesigned to not use message-level security in callbacks.

12.33.8 Handling of Java Method Arguments or Return Parameters That Are JAX-RPC-style JavaBeans

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

Currently there is no known workaround for this issue.

12.33.9 IllegalArgumentException When Using a Two-Dimensional XML Object in a JWS Callback

Using a two dimensional XmlObject parameter (XmlObject[][]) in a JWS callback produces an IllegalArgumentException.

Workaround

Currently there is no known workaround for this issue.

12.33.10 Using SoapElement[] Results in Empty Array

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

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.

12.33.11 FileNotFound Exception When a Web Service Invokes Another Web Service

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/filename.xml. Since no policy file exists at that location, WebLogic Server will throw a file not found exception.

Workaround

Attach the custom policy file to Web Service B, as in this example:

@Policy(uri="CustomPolicy.xml",
        attachToWsdl=true)
public class B {
  ...
}

12.33.12 Client Side Fails to Validate the Signature on the Server Response Message

When the security policy has one of these Token Assertions, the client side may fail to validate the signature on the server response message.

<sp:WssX509PkiPathV1Token11/>
  <sp:WssX509Pkcs7Token11/>
  <sp:WssX509PkiPathV1Token10/>
  <sp:WssX509Pkcs7Token10/>

In addition, when there are more than two certifications in the chain for X509 certification for <sp:WssX509Pkcs7Token11/> or <sp:WssX509Pkcs7Token10/> Token Assertion, the server side may fail to validate the signature on the incoming message.

A policy such as the following policy is not supported, unless the entire certificate chain remains on the client side.

<sp:AsymmetricBinding>
   <wsp:Policy>
      <sp:InitiatorToken>
         <wsp:Policy>
            <sp:X509Token
               sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>

            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:InitiatorToken>
      <sp:RecipientToken>
      <wsp:Policy>
      <sp:X509Token sp:IncludeToken='. . ./IncludeToken/Never'>
            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:RecipientToken>
   . . .
      </wsp:Policy>
   </sp:AsymmetricBinding>

Workaround

Use either of the following two solutions:

1. Configure the response with the <sp:WssX509V3Token10/> Token Assertion, instead of WssX509PkiPathV1Token11/>. The policy will look like this:

   <sp:AsymmetricBinding>
      <wsp:Policy>
        <sp:InitiatorToken>
           <wsp:Policy>
           <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
              <wsp:Policy>
                 WssX509PkiPathV1Token11/> 
              </wsp:Policy>
           </sp:X509Token>
           </wsp:Policy>
        </sp:InitiatorToken>
        <sp:RecipientToken>
           <wsp:Policy> sp:IncludeToken='. . ./IncludeToken/Never'>
           <sp:X509Token
              <wsp:Policy>
                 <sp:WssX509V3Token10/>
              </wsp:Policy>
           </sp:X509Token>
           </wsp:Policy>
        </sp:RecipientToken>
   . . .
        </wsp:Policy>
      </sp:AsymmetricBinding>
   

2. Configure the response with the WssX509PkiPathV1Token11/> token assertion, but include it in the message. The policy will look like this:

   <sp:AsymmetricBinding>
      <wsp:Policy>
        <sp:InitiatorToken>
           <wsp:Policy>
           <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
           <wsp:Policy>
              WssX509PkiPathV1Token11/> 
           </wsp:Policy>
           </sp:X509Token>
        </wsp:Policy>
        </sp:InitiatorToken>
        <sp:RecipientToken>
           <wsp:Policy>
           <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToInitiator'>
              <wsp:Policy>
                 WssX509PkiPathV1Token11/>
               </wsp:Policy>
           </sp:X509Token>
           </wsp:Policy>
        </sp:RecipientToken>
    . . .
      </wsp:Policy>
    </sp:AsymmetricBinding>
   

When there are multiple certifications in the X509 Certificate chain, WssX509PkiPathV1Token11/> or <sp:WssX509PkiPathV1Token10/> should be used, instead of <sp:WssX509Pkcs7Token11/> or <sp:WssX509Pkcs7Token10/>.

12.33.13 INFO Messages in Server Log for Domains Created Without Web Services-Specific Resources

WebLogic Web Services expects that each WebLogic Server domain will contain specific resources needed to support web services. Some domains, however, are not created with these resources.

For example, creating a default WebLogic Server domain in the configuration wizard (without applying any other templates) will not create the needed Web Services resources.

A domain that doesn't contain Web Services resources will still boot and operate correctly for non-webservice scenarios, and any Web Service scenario that doesn't involve asynchronous request/response. You will, however, see INFO messages in the server log indicating that async resources have not been configured and that the async response service for web services has not been completely deployed.

Workaround

Web Services that use async request/response will not function properly in a domain that doesn't have Web Services resources configured in it. To configure these resources, there are two approaches:

• Use the configuration wizard and apply the wls_webservice.jar template to your domain.

• Manually configure these resources according to the rules given in the online documentation under domain configuration for web services.

12.33.14 Sending async Responses and acks Using a Client Certificate Is Not Supported by Reliable Messaging

Reliable Messaging cannot support sending async responses and acks using a client certificate.

Web Services using async or Reliable Messaging will automatically use the server's SSL certificate when establishing a new connection (back from the receiving service to the sending service) for the purposes of sending async responses, acknowledgments, etc.

12.33.15 xmlcatalog Element Entity Cannot Be a Remote File or a File in an Archive

For the xmlcatalog element in build.xml, the location of an entity must be a file on the local file system. It cannot be a remote file (for example, http:) or a file in an archive (for example, jar:).

Workaround

If necessary, define the remote element as an entity in a catalog file instead.

12.33.16 Catalog File's public Element Is Not Supported When Using XML Catalogs

The public element in a catalog file is not supported when using the XML Catalogs feature. It is not supported to be consistent with JAX-WS EntityResolver implementation. WLS only supports defining the system element in a catalog file.

12.33.17 Local xmlcatalog Element Does Not Work Well

The local xmlcatalog element does not work well due to an Ant limitation.

Workaround

In the ant build.xml file, you have to define a local element above a clientgen(wsdlc) task when you are in the same target, or define the element out of any targets.

12.33.18 JAXRPC Client Does Not Encode the HTTP SOAPAction Header With Multi-byte Characters

The WLS Web Service JAXRPC client doesn't encode the HTTP SOAPAction header with multi-byte characters, but WLS server only supports ASCII for HTTP headers.

Workaround

Change the SOAP action to ASCII in the wsdl.

12.33.19 External Catalog File Cannot Be Used in the xmlcatalog Element of a clientgen Task

An external catalog file cannot be used in the xmlcatalog element of a clientgen task. For example, this snippet of an ant build file will not work:

<clientgen ...
  <xmlcatalog>
    <catalogpath>
      <pathelement location='wsdlcatalog.xml'/>
    </catalogpath>
  </xmlcatalog>

This is a limitation of the Ant XML Catalog.

Workaround

Resource locations can be specified either in-line or in an external catalog file(s), or both. In order to use an external catalog file, the xml-commons resolver library (resolver.jar) must be in your classpath. External catalog files may be either plain text format or XML format. If the xml-commons resolver library is not found in the classpath, external catalog files, specified in <catalogpath> paths, will be ignored and a warning will be logged. In this case, however, processing of inline entries will proceed normally.

Currently, only <dtd> and <entity> elements may be specified inline. These correspond to the OASIS catalog entry types PUBLIC and URI respectively.

12.33.20 Exceptions When Running Web Services Reliable Messaging Under Heavy Load

When running a Web services reliable messaging scenario under heavy load with file based storage that has the Direct-Write synchronous write policy setting, you may encounter IO exceptions similar to the following in the WebLogic Server log:

weblogic.store.PersistentStoreRuntimeException: [Store:280029]The 
persistent store record <number> could not be found

or

Could not load conversation with id uuid:<some ID> -> Conversation read 
failed: 
    ... 
    weblogic.wsee.jws.conversation.StoreException: 
      Conversation read failed: id=uuid:<some ID> 
         weblogic.store.PersistentStoreException: [Store:280052]The 
         persistent store was not able to read a record. 
           java.io.OptionalDataException 

These exceptions are known to occur only when using Web Services reliable messaging. They indicate a failure to read a record from the file store and are considered 'fatal' data access errors.

The underlying issue causing these errors will be addressed in a future release.

Workaround

The following workarounds are available for this issue:

• Change the file store synchronous write policy to Cache-Flush.

  or

• Keep the Direct-Write synchronous write policy and add the following Java system property to your WebLogic server startup scripts:

  -Dweblogic.store.AvoidDirectIO=true
  

With either of these workarounds, you may also want to set the block-size for the file store using the following Java system property:

-Dweblogic.store.BlockSize=block-size

Changing file store settings may lead to some performance degradation, but is necessary for correct operation of Web services reliable messaging under load.

For important information about these settings and additional options, see "Tuning File Stores" in Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.

12.33.21 jwsc Has Been Modified, Resulting in Methods With No @WebMethod Annotation to Be Included in the Service Endpoint Interface

Prior to 11g Release 1 (WebLogic Server version 10.3.1), a JAX-WS JWS that allowed its service endpoint interface to be inferred from the implementation (that is, no explicit service endpoint interface class was declared) would have the implicit service endpoint interface include only those methods that included an @WebMethod annotation (and that annotation did not specify exclude=true). This behavior is incorrect according to the JAX-WS 2.1 specification. JAX-WS 2.1 specifies that the service endpoint interface inferred from the JWS should include all public non-static methods on the JWS, as long as those methods do not have @WebMethod(exclude=true) attached to them.

In WLS 10.3.1, jwsc (and the web services runtime) have been modified to properly generate the implicit service endpoint interface (and resulting WSDL for the service) according to the JAX-WS 2.1 specification. As a result, the implicitly derived service endpoint interface will include all non-excluded public non-static methods on the JWS. In some cases, you may have written JWS implementations that relied on the prior jwsc behavior, assuming that methods with no @WebMethod annotation would not be included in the service endpoint interface and resulting WSDL for the service. With the new jwsc behavior, such methods will be included in the service endpoint interface and resulting WSDL for the service.

Workaround

After installing WLS 10.3.1, Oracle recommends that you evaluate your existing services for the following possible errors:

1. Public non-static methods that are not legal web method declarations (these can cause jwsc to fail when building a service).

2. Public non-static methods that are legal web methods, but were never intended to be exposed publicly on the service.

The two cases are described in detail here:

Case 1: It is possible that some JWS classes will fail to compile in jwsc if a previously excluded method is an invalid web method. The new implicit inclusion of such methods will cause the jwsc task to fail. There are many possible reasons for jwsc to fail compiling of a newly included web method. The most common reason is if a method includes parameter types that are incompatible with JAXB (for example, an interface instead of a concrete class with a default no-arg constructor).

Case 2: Any public non-static methods that are not explicitly excluded will now be represented in the service endpoint interface. These methods may be perfectly legal web method declarations (for example, they compile correctly in jwsc), but may never have been intended as public operations on the service.

Oracle recommends that you inspect any implicitly defined service endpoint interface (and dynamically generated WSDL) for their existing services, and ensure that only the intended methods are exposed.

In either of these cases, simply add the following annotation to the method that you want to exclude from the service's endpoint interface and WSDL:

@WebMethod(exclude=true)

12.34.1 View Classes are not Set on a Per Connection Basis

View classes are not set on a per connection basis.

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

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.

12.35.1 Issues With Search Function in the Samples Viewer

The Search function in the Samples viewer does not work when accessing the Examples documentation by selecting Oracle Weblogic > Weblogic Server > Examples > Documentation from the Windows Start menu, or by clicking the Documentation link at the top of the Examples page.

Workaround

To search the Sample Applications and Code Examples, you must start the Examples server and navigate to http://localhost:7001/examplesWebApp/docs/core/index.html. Click Instructions and then Search.

12.35.2 Japanese Text Diplays in Some Avitek Medical Records Topics

The samples viewer displays the Japanese and English versions of some Avitek Medical Records topics simultaneously.

12.35.3 Some Interfaces to SAML2 Are Not Documented in the MBean Reference

The WebLogic Server 10.3.1 MBean Reference does not document the interfaces to the SAML 2.0 Identity Asserter and SAML 2.0 Credential Mapping provider. Instead, Javadoc for these MBean interfaces is provided in the WebLogic Server 10.3.1 MBean API Reference Guide.

12.35.4 WebLogic Express Is No Longer Available

WebLogic Express is no longer available from Oracle, therefore its description has been removed from the WebLogic Server documentation. All WebLogic Express functionality is available and supported in other Oracle WebLogic Server products. You can upgrade your 10.0 and earlier WebLogic Express applications to WebLogic Server 10.3.x.