The following sections describe known problems in WebLogic Server 9.2 and later Maintenance Packs, as well as problems that were resolved in 9.2 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 9.2, see What’s New in WebLogic Server 9.2.
When importing security data that was exported using releases of WebLogic Server prior to 9.2, BEA recommends:
If the older domain can not be upgraded, the original domain should be booted and instead of using the Export feature in the realm, use the Migration > Export tab for each provider and export the security data into a file. To import the security data into a provider in a new security realm, use the Migration > Import tab for each provider. |
|||||
The Administration Console uses the JMX management interfaces to interact with WebLogic Server. WebLogic Server supports several MBean servers that provide access to management features from different perspectives. Although these MBean servers may be disabled in the WebLogic Server configuration files, the Administration Console requires these MBean servers during operation and will not run successfully without them.
|
|||||
After a page flow completes in the Administration Console, it forwards to a different page, typically a table.
|
|||||
You can use the Administration Console to shut down the Administration Server, but as the Administration Console attempts to refresh itself, it often encounters a problem displaying the page because the Administration Server is no longer available to service requests. This failure manifests itself in different ways, depending on the timing, machine load, and other deployments.
|
|||||
Message-Driven Beans (MDB) may specify adapter-jndi-name in the deployment descriptor to indicate that the MDB is receiving messages from a resource adapter rather than from JMS. Such a binding entails configuring an ActivationSpec object that is passed to the resource adapter during deployment.
The Administration Console does not provide a way to view or configure the Resource Adapter that an MDB is bound to.
|
|||||
When a role or policy condition is created or modified in the Administration Console, you must click the Save button before leaving the role/policy editor page. Otherwise, all the changes made during the creation or modification of the condition(s) that are displayed get lost when you return to the same page.
|
|||||
Specifying Jakarta Commons Logging in the system classpath prevents the Administration Console from initializing.
The problem occurred when a user specified a class in the system classpath that was already used by the Administration Console. The classloader could load versions of the classes that were potentially incompatible. Specifically, the version of Struts used internally by the Administration Console was certified with a particular version of Log4j and Commons logging. However, when a newer version of Commons logging was specified in the classpath, the Administration Console failed to initialize because Struts failed to initialize classes needed by the Administration Console.
|
|||||
After you enable the administration port from the Administration Console and click the Activate button, the Administration Console is not reachable until the URL used to communicate with the Administration Console is changed to HTTPS and the administration port number.
|
|||||
Sets the maximum allowed duration (in milliseconds) of XA calls to XA resources. This setting applies to the entire domain.
The maximum duration (in milliseconds) that an XA resource is marked as unhealthy. After this duration, the XA resource is declared available again, even if the resource is not explicitly re-registered with the transaction manager. This setting applies to the entire domain.
Maximum number of concurrent requests to resources allowed for each server in the domain. |
|||||
If you register custom MBeans in a WebLogic Server MBean server, you can use roles and policies along with the WebLogic Security Service to protect your MBeans. Note the following restrictions:
|
|||||
When you create a security provider (any provider such as PKI credential mapper, auditing provider, authentication provider, and so on), the creation assistant takes the name of the provider and then returns to that provider's configuration summary page, which shows the newly added entry. However, the creation is not yet complete. You need to enter provider-specific details for it to be a valid provider configuration.
|
|||||
The JMX MBean server only allows security management operations on the runtime bean tree. The Administration Console also prevents security management operations while a pending configuration change is in progress. For example, if an authentication provider configuration is changed, the Administration Console prevents the creation of a new user for that authentication provider until the configuration change is complete, which typically requires a server re-boot.
|
|||||
Web Services deployed in a Web library module did not show up in the WebLogic Server Administration Console. The problem was caused by the way in which the Administration Console attempted to look-up library modules. In some circumstances, the library module deployments did not appear.
The code that queried for library modules was updated and modifications were made to the Targetting tabs in the Administration Console in an effort to consolidate targetting functions.
|
|||||
The Chooser control in the Administration Console was not disabled in Mozilla if an Edit lock was not acquired. Some Web browsers do not treat the
Disabled attribute in the same manner as Internet Explorer does.
|
|||||
The Administration Console did a
-redeploy instead of an -update of an application regardless of whether dynamic property changes are supported or not. This means, for example, that changes to dynamic properties in resource adapters result in a full redeploy of the resource adapter/application instead of simply an update.
|
|||||
The Administration Console does not honor the value specified for the
Retire Timeout Text field when updating applications that have the version as Weblogic-Application-Version in the MANIFEST.MF file. In addition, the label for the Retire Timeout Text field is showing that the time specified is in minutes but it is actually honoring the retire timeout in seconds.
|
|||||
When the Administration Console is used to export a security realm's data to a directory and then import that data into another security realm, the two security realms need to have the exact same set of security providers (same type and same name).
If the second realm has a provider with the same name but a different default import format, the Administration Console should prevent the import. Instead, the Administration Console exported the data using the default format of the first provider and then imported the data using the default format of the second provider. For example, if the first security realm has a provider of type
DefaultAuthorizer named DefaultAuthorizer , the Administration Console exported the data in the DefaultAtz format. If the second realm has a provider of type XAXMLAuthorizer named DefaultAuthorizer , the Administration Console imported the data in the XACML format. In this case, the XACMLAuthorizer silently dropped the data instead of reporting an error.
The Administration Console now records the format of the exported data and imports the data using those formats. Also, the Administration Console reports whether or not a provider has successfully imported the data.
When exporting and importing security data with WebLogic Server 9.2, the Administration Console prevents importing data from a security realm whose security providers support different formats.
If data is exported from a security realm created with a release prior to WebLogic Server 9.2 and then imported into a 9.2 domain, the formats from the original provider are not available and the Administration Console will try to import the data using the default format of the security providers in the new security realm. Security data can be dropped if the new security provider does not report an error stating it can't import the data using its default format.
|
|||||
|
|||||
If a security role or security policy definition has three or more conditions and the first condition is removed, the action fails with an exception. Similarly, if a security role or security policy definition has three or more conditions and all of them are removed, the action fails with an exception.
If you want to remove only the first condition, move the second condition up to the first position, and then remove the original first condition.
Similarly, if you want to remove all the conditions, remove all the conditions except for the first condition, then move the first condition last.
|
|||||
If a user of Weblogic Server 9.1 used the Administration Console to change the domain's user lockout security policy (on the Domain->Security->Policies-> User Lockout tab), the new security policy was ignored and the previous security policy (which defaults to the
Admin security role) was used instead.
The Administration Console in WebLogic Server 9.2 correctly sets the domain's user lockout security policy. However, if the domain’s user lockout security policy was changed using WebLogic Server 9.1 and the domain was then upgraded to WebLogic Server 9.2, the domain will still use the previous user lockout security policy (which defaults to the
Admin security role).
|
|||||
Search the Administration Console Online Help that is published at
http://download.oracle.com/docs/cd/E13222_01/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
|
|||||
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.
|
|||||
To increase the value of Accept Backlog, follow the instructions provided in
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/taskhelp/tuning/TuneConnectionBacklogBuffering.html
|
|||||
In the Administration Console Online Help published at
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/pagehelp/Corecoreserverchannelconfiggeneraltitle.html, as per the description for the configuration option,
Listen Port , a value of -1 indicates that the network channel should obtain this value from the server's configuration.
|
|||||
The Web Services Reliable Messaging example has two known problems which cause the example to not work correctly. The example 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 .
To workaround this problem, update the example WS-Policy file (called
To workaround this problem, update the |
If the initial capacity and the max capacity are changed in the same edit session and the new value for the initial capacity is larger than the value for the max capacity, the update will fail. This failure occurs because WebLogic Server checks the new value for the initial capacity against the value for the max capacity.
|
|||
EJB batch-enabling for Oracle uses some Oracle-specific, non-standard JDBC methods when creating prepared statements. If these statements are cached in the pool, the non-standard behavior of these statement remains for any subsequent user. One chief symptom is that a subsequent standard update call that should succeed will return 0, meaning no row was updated. In fact the call is never sent to the DBMS but is batched in the statement, waiting for a special batch call, or many more
executeUpdate() calls until the non-standard set batch number is reached.
|
|||
WebLogic Server 9.2 supports additional databases for the Singleton Server feature. In addition to Oracle, which was the only previously supported DB, release 9.2 now also supports Sybase, MsSQL, Informix, DB2, and MySQL. BEA supports any version that is supported by WebLogic Server in general. DDLs to create the tables are provided for all of the vendors.
|
|||
Overloaded state missing from the JDBC Data Sources Monitoring: Statistics Console Help page and the
JDBCDataSourceRuntimeMBean of the WebLogic Server MBean Reference.
|
|||
Managed Servers perform schema validation of the configuration files (
config.xml and system resource files) at startup. This validation prevents the Managed Server from being at an earlier version and from participating in a rolling upgrade.
|
|||
A Managed Server is booted in MSI mode if the Administration port specified does not have HTTP enabled or HTTP Tunnelling Enabled. The
getAdminHttpURL() API constructs the URL based on one port. Therefore, the Managed Server can return an HTTP URL with a port on which HTTP is turned off.
A fix was added to the
getAdminHttpURL() method that constructs a URL based on an algorithm that looks at all network channels, in the sequence ADMIN-Http-Https, in order to find a port that has Http Enabled. This algorithm ensures that a Manager Server can connect to an Administration Server using the URL returned by the API.
|
|||
A serial version uid mismatch error occurs when running WebLogicMBeanMaker or
weblogic.Upgrade on the AIX operating system. The detailed exception is as follows:
|
|||
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 .
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.
|
|||
Information on how to configure domains to enable inter-domain transactions (that is, all participating domains run on WebLogic Server 9.x, 8.x, 7.x, and 6.x domains or a combination of 9.x, 8.x, 7.x and 6.x) is incorrect in the Administration Console Help.
The information required to configure domains to enable inter-domain transactions is located online. See
Configuring Domains for Inter-Domain Transactions in Programming WebLogic JTA.
|
|||||
If a
boot.properties file was in the WebLogic Server domain root directory, WebLogic Server would copy it to the security directory and then delete it from the domain root directory.
This problem has been resolved. WebLogic Server checks whether the
weblogic.system.BootIdentityFile property indicates that the boot.properties file is in the domain root directory. If the file exists in that directory, it is not copied to the security directory and not deleted from the domain root directory.
|
|||||
In WebLogic Server 9.0, the security framework was modified to write AuditAtnEventV2 authentication events. However, audit providers implemented on WebLogic Server releases prior to WebLogic Server 9.0 sometimes used to encounter binary compatibility issues because they were not implemented to process AuditAtnEventV2 events.
This problem has been resolved. Custom audit providers written to pre-WebLogic Server 9.0 interfaces can be configured and executed on WebLogic Server 9.2 installations.
|
|||||
In some cases, WebLogic Server would raise a weblogic.management.utils.CreateException and a netscape.ldap.LDAPException: error result (68) exception - to WebLogic Portal running on a managed server. This used to occur because of a timing issue between the managed server and its administration server regarding a security policy change: in this case, the creation of a new role. When this situation occurred, the managed server would attempt to create the new role in the WebLogic Server-embedded LDAP even though it already existed.
|
|||||
Changes made to LDAP policy on a managed server were being saved locally if the administration server was not available. But the changes could not be updated to the administration server or distributed to other managed servers, after restarting the administration server.
This problem has been resolved. An AdminServerListener checks the availability of the administration server before the policy modification operations are saved on a managed server. When the administration server is not available, an error is displayed and the policy modification operation fails. This ensures that the managed servers have synchronized LDAP policy data.
|
|||||
If a large number of roles are involved in the domain, the WebLogic Server policy cache may grow to a size greater than the JVM configured maximum size and result in an
OutOfMemory exception.
To avoid the exception, you can increase the JVM maximum heap setting or decrease the WebLogic Server policy cache maximum size default of 5000 entries. To adjust the WebLogic Server policy cache, set the
weblogic.security.ldapPolicyStoreCacheCapacity property to the desired size.
|
|||||
The following note is missing in WebLogic Server 9.2 javadocs for
ActiveDirectoryAuthenticatorMBean interface.
|
|||||
WebLogic Server 9.2 failed to start after rebuilding and installing a custom authentication provider that had deployed successfully on WebLogic Server 8.1.
In WebLogic Server 9.2 if you had two or more PrincipalValidators configured in a security realm which validated the same base Principal type or any derivations of a common base Principal type, the server would abort starting.
This problem has been resolved. Though a one-to-one relationship between PrincipalValidators and direct base principal types is enforced, as it was in prior releases of WebLogic Server, a realm can have a PrincipalValidator which validates a type that is a sub type of the Principal type associated with another PrincipalValidator.
|
|||||
Group Membership Lookup Hierarchy Caching provided by the SQL Authenticator was not working properly. A problem with detection of cyclical group membership definitions for DBMS authentication providers was preventing all groups of a member's membership hierarchy from being placed in the membership cache and in the Subject.
|
|||||
Two versions of the Spring Framework are certified for this release of WebLogic Server: 1.2.8 and 2.0. The following two tables list the known and resolved issues for the two versions separately.
Require a mechanism to validate incoming SOAP requests from an untrusted client. WebLogic Server now provides a mechanism to validate the incoming request to WebLogic Server Web service.
Note that validation is a performance-intensive task and should be used with care. Incoming SOAP requests can be validated in one of the following ways:
|
|||
Non-ASIIC data in a request or attachments may change when you invoke a Web Service through JMS transport.
Allow applications to send a request as a JMS BytesMessage. The default will still be TextMessage, which is the message type that is used in the previous releases. Applications that need to send non-ASIIC data or binary attachments can use BytesMessage. There is a property on the JAX RPC stub to set the JMS Message type. Once you get a port, you can do one of the following to set JMS message type to BytesMessage:
|
|||
A WebLogic Server 8.1 style (version one) conversation service requires that the client explicitly know about and echo the conversation ID. The conversation ID is assigned either by the application, or the client side server, and it is not aware where the service is actually provided. A version two conversational service, started in 9.0 release, relies on WS-Addressing to automatically cause the conversation ID to be echoed back to the service. The conversation ID is assigned on the server side, and it embeds the routing information in it. When an 8.1 style conversation client talks to a 9.x server in a clustered environment, the cluster will not have enough information to route the request to the right server.
The solution is to use the cluster-wide singleton service -- the Path Service -- to record the routing information for 8.1 style conversations.
Additional configuration is required for this to work -- The Path Service has to be configured and deployed on one of the servers in the cluster. It is known that the solution is a scalability and single point of failure regression from 8.1. With the cache capability built-in the Path Service, and server migration solution we have in WLS, the regression is somewhat alleviated.
|
|||
In releases prior to WebLogic Server 9.2,
clientgen could not process arrays that were defined in the WSDL description as a one-dimensional array of another array, as in:
<s:complexType name="ArrayOfArrayOfString">
<s:complexType
|
|||
In releases prior to WebLogic Server 9.2,
clientgen could not handle multi-dimensional arrays whose types were expressed in the form:
|
|||
In releases prior to WebLogic Server 9.2, if the system clock on a client was slightly ahead of the system clock on a server, the following timestamp error message was issued intermittently for small synchronization differences (differences less than the clock precision):
For example, if the clockPrecision setting was set to one minute (default), and the client clock happened to be 40 seconds ahead of the server clock, then this message was thrown 40/60 or 2/3 of the time.
The clockPrecision property was deprecated and replaced by the more intuitive clockSkew property. ClockSkew will not exhibit any of the probabilistic properties (as shown by the 2/3 in the explanation above) of the clockPrecision, but it does represent a similar concept: the allowable difference between clocks of the server and the client.
|
|||
If a Web Service is deployed that uses the
@RolesAllowed , @RolesReferenced , or @RunAs annotations (at the class-level) to specify the roles that are allowed to invoke the Web Service, anyone accessing the Web Service, including its dynamic WSDL, needs to authenticate themselves as a user mapped to that role.
|
|||
If a Web Service is deployed that uses the
@UserDataConstraint annotation to force use of HTTPS, anyone accessing the Web Service, including its dynamic WSDL, needs to specify the trust store that contains the list of trusted certificates, including the trusted certificates of the server.
A client application that invokes the Web Service can list the trusted certificates by defining a Trust Manager in the stub; however, there is currently no way to do this for clientgen.
<clientgen
|
|||
The
@UserDataConstraint annotation is not supported for EJB-Implemented Web services prior to WebLogic Server 9.2.
|
|||
The JAX-RPC 1.1 specification specifies that the Java to XML mapping for byte arrays should be
xsd:base64Binary . However, in releases prior to WebLogic Server 9.2 the generated schema type for byte[] was not compliant with JAX-RPC 1.1.
When using JWSC to start a Java Web Service from a class that contains a method that uses a
byte[] parameter or return type, the generated WSDL types that correspond to the byte[] argument were incorrectly generated, as follows:
<xs:complexType name="ArrayOfbyte_literal">
|
|||
According to the JAXRPC specification, byte[] and Byte[] should be mapped to the xsd:base64Binary type. This mapping was incorrect for RPC-encoded Web Service.
This problem has been resolved. Weblogic Server maps byte[] and Byte[] for RPC-encoded Web Services according to the JAXRPC specification. See
jaxRPCWrappedArrayStyle attribute definition in
Ant Task Reference.
|
|||
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
|
|||
After upgrading to JDK 1.5.0_08 from JDK1.5.0_4 in WebLogic Server 9.2 domain, there is a problem with JWSC ANT.
|
|||
WebService used to fail to honor the optional element
minOccurs="0" . When invoking a WebService with this optional element in the request message following issues were faced.
|
|||
DuplicateElement exception was being raised when a ObjectHolder parameter was set to a specific schema type.
For using XMLBean as a SOAP header, you need to create a holder class for the XMLBean and package it in the generated xml bean jar file. This holder must be in the same root package as XMLBean, and in a
holders subpackage, and named <XMLBean Class>Holder, where <XMLBean Class> is the name of the XMLBean class to be passed as the header IN/OUT param. Use the holder org.t1M1.tml.tMLTransport.holders.TMLHeaderDocumentHolder for holding org.t1M1.tml.tMLTransport.TMLHeaderDocument . In the jws file, use this holder for the header parameter. The holder class is in the format of JAX-RPC holder.
|
|||
When using WebLogic Server 9.2 jwsc-generated WSDL in WebLogic Server 8.1, the following two issues used to happen.
|
|||
When XMLBean was used, the jwsc Ant task used to generate invalid WSDL if primary schema has included schema and referred the types in the included schema. The jwsc task generated a schema section for each of the schema and the types in the included schema were not resolvable from the primary schema.
|
|||
WebLogic Tuxedo Connector cannot re-establish the connection to the second remote domain if there is a network problem between the local domain and the first remote domain.
|
|||||
Prior to WLS 9.2, viewj and viewj32 compilers will not handle any view definition file with missing NULL value; instead they will issue a warning message and stop processing. However, in WLS 9.2 this behavior changed, it will continue generating java file for the view, but the view class will not have field data and access methods for them. The result is that viewj/viewj32 will generate an incorrect java view class.
|
|||||
The implementation of the FML-to-XML and XML-to-FML conversion in WTC only converted a byte array into a string. This could result in a non well-formed document, depending on the original CARRAY field.
CARRAY fields in an FML buffer are now encoded to a base64 string before being converted to XML. Conversely, elements identified as CARRAY fields in an XML document are assumed to be encoded in base64 and are accordingly decoded.
|
|||||
The definition of the WTC Export
ResourceName attributes in the
WebLogic MBean Reference and Console Help is not accurate.
|