Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Troubleshoot the XML configuration interface
- Unexpected syntax errors
- Message "XMLC0091E: The servletref attribute is required to create a portlet clone . . . "
- Message "XMLC0049E: Input syntax error ...", followed by "org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'request'."
- Message "LDAP: error code 49 - Invalid Credentials" is misleading
- User data not exported as specified
- Message"XMLC0142E: Unique name unique_name is already used in the portal."
- XML configuration interface tasks result in errors when using HTTP server port
- Cannot use the XML configuration interface if it is externalized in security
- Re-create and browsing a page can result in a duplicate key error
- XML import might fail with out-of-memory error
- WPSconfig command fails when running XML configuration interface
- Problems when exporting or importing policies by using the XML configuration interface
- Problems when transferring Document Manager
- Portlet global state attribute without wire is not exported by XML export
- You cannot delete attributes by using the XML configuration interface
- User and Group import via the XML configuration interface
- ReleaseBuilder ignores deletion of attributes
- Global settings cannot be set in a cluster by using the XML configuration interface
Unexpected syntax errors
Although the XML input file seems to be valid, inexplicable syntax errors are reported, for example unclosed XML tags.
Solution: A possible reason is that your files are being truncated before they are processed by the portal. This can typically occur for the following reasons:
- Your input file contains invalid UTF-8 characters. A good way to check your input files is to view them with Microsoft Internet Explorer. Microsoft Internet Explorer shows errors if your input contains invalid characters.
- Some VI editors of UNIX systems cause problems when handling large files. This depends on the implementation of the VI editor. For example, if you use such a VI editor to modify an XML script with more than 40.000 lines, parts of the file contents might get truncated. Use a different editor to modify such large files.
- You have a problem with your HTTP communication setup, for example, your input is relayed through a HTTP server that truncates it. In this case you can check for communication problems by specifying the -echo command line parameter when you call the XML configuration interface tool. When this parameter is specified, your request is not processed, but simply returned as it is read by the server. If the output is different from your input file, your request was modified somewhere along the communication path.
Message "XMLC0091E: The servletref attribute is required to create a portlet clone . . . "
The attempt to deploy a portlet in a XML request results in the error message given above.
Solution: There is a mismatch between the name, uid and refid attributes that are given in the XML request and those that were specified in the portlet.xml deployment descriptor for your portlet or portlet application. Therefore XML processing tries to create new portlets where it should only update those that have been created as part of the WAR file deployment. Use the Install portlet to deploy your WAR file, export the portlet application (package), and compare the export with your XML request, or compare your XML request with the portlet.xml. Make sure that the names and IDs for portlets and portlet applications are identical.
Message "XMLC0049E: Input syntax error ...", followed by "org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'request'."
The attempt to import an XML file results in the error messages given above.
Solution: Your XML file contains an invalid schema or namespace declaration. Check the request element for typographical errors or missing attributes. The request must have the following form:
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd" ...>
Message "LDAP: error code 49 - Invalid Credentials" is misleading
If you try to connect to the portal with security and LDAP enabled, but if the LDAP server is not available, the following error message is returned in the XML response file:
com.ibm.websphere.wmm.exception.WMMSystemException: The following Naming Exception occurred during processing: "javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]".This message can be misleading.
Solution: The LDAP error message Invalid Credentials means that the user name or password are wrong. It can also mean that the LDAP server is not available at all.
User data not exported as specified
User name data are not exported as specified by the user tag attributes firstname, lastname, or name. The reason is that the values of some attributes of the tag user correspond to settings in included parameter tags. If you include both in your export request, but specify different values for them, then the value set by the parameter tag overwrites the value set by the attribute, and is exported as the attribute.
Solution: Use only one of the two ways to specify the user data, either the attribute or the parameter tag. For more information about this, see the description of the user tag under XML reference, Types of portal resources.
Message"XMLC0142E: Unique name unique_name is already used in the portal."
One or more nested elements were not created properly.
Solution: When you create a nested element, for example a component, with a uniquename attribute, the whole hierarchy upward from that element must also have uniquename attributes. Example XML export request snippet:
<content-node ... <component uniquename="component_1"... <component uniquename"component_2"... <component uniquename"component_3"... . . . . . </component> </component> </component> </content-node>
XML configuration interface tasks result in errors when using HTTP server port
XML configuration interface tasks may result in errors if you do not use the direct port.
Solution: When you process tasks using the XML configuration interface, use the direct port, for example, 10038, rather than going through the HTTP server on port 80.
Cannot use the XML configuration interface if it is externalized in security
If the virtual resource XML_ACCESS that represents access to the XML configuration interface is put under protection of an external security manager, you can no longer use the XML configuration interface.
Solution: If the access rights of WebSphere Portal Express are externalized to an external security manager, such as Tivoli Access Manager, make sure that the XML configuration interface virtual resource is not externalized.
Re-creating and browsing a page can result in a duplicate key error
If you delete a page with an object ID and use the XML configuration interface to re-create the same page with the same object ID, you might receive an error message indicating the operation was aborted because it would have caused a duplicate key value.
Example scenario: You delete a page with an object ID. You use an XML import request to re-create the same page with the same object ID. The import fails with the following message: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint.
Cause: When you delete a page, the portal marks the page for deletion but does not actually delete the page until a later point in time when the scheduled cleanup service runs. Until that time remainders of the deleted page exist in the portal. They can interfere with adding the new page.
Solution: To avoid this, run the cleanup service task before re-creating the page with the XML configuration interface. After you have deleted a page with an object ID, do not re-create the same page with the same object ID without first running the cleanup service task. As an alternative, you can configure the cleanup service for immediate deletion. This deletes portal pages immediately as you run the cleanup task. For more details about how you can use the XML configuration interface to perform a cleanup refer to the XML reference under the task tag. For more details about the cleanup service and how to configure it, refer to Delayed cleanup of deleted portal pages.
When you run the XML cleanup task, the XML configuration interface only schedules the task to be run in WebSphere Application Server and returns. This does not necessarily mean that IBM® WebSphere® Application Server runs the task immediately. To determine when a task started and ended, check the portal log wps_date_time.log for the EJPDE0002I and JPDE0003I messages. These messages confirm that the cleanup task has successfully completed.
Alternate solution option: Another possible option for solution is to set the attribute create-oid="true" for the request tag in your input script. This creates new object IDs for all updated items. The original items remain unchanged.
XML import might fail with out-of-memory error
An XML import of portal resources might fail with an OutOfMemoryError.
Cause: This error results from a limited heap size.
Solution: Proceed by the following steps:
- Open the administrative console.
- Navigate to Servers > Application Servers > yourPortalServerName > Java and Process Management under "Server Infrastructure " > Process Definition > Java Virtual Machine.
- Determine the configured maximum heap size; for example, this might be 512 MB.
- Increase the maximum heap size, for example to 1024 MB.
- Restart the portal.
- Run the XML import script again. The OutOfMemoryError should disappear.
WPSconfig command fails when running XML configuration interface
Occasionally you might encounter an error where the WPSconfig command fails because of a problem running the XML configuration interface.
Cause: Typically this error results from a problem with the host name and port number configuration in WebSphere Application Server that prevents proper operation of the xmlaccess command.
For example, the error message below resulted from an attempt to access an SSO domain that could not be resolved by localhost:
SRVE0017W: A WebGroup/Virtual Host to handle localhost:10038 has not been defined.Solution: To correct this problem, edit the wpconfig.properties file and update the value of the XmlAccessHost property with the full host name of the portal server.
Problems when exporting or importing policies by using the XML configuration interface
When you use the XML configuration interface to work with policies, the following limitations apply:
- The policy-sub-nodes are stored in a separate file. This file can be referenced by an XML script, and that link can be exported and imported by using the XML configuration interface.
- Access control for policies is exported only for the base policy-node, but not for the sub-nodes.
- The portal ReleaseBuilder does not handle policies.
Cause: This is a known limitation.
Solution: To resolve this limitation, you need to add some manual steps to running the XML export and imports:
- After successful export of the policies, copy the separate file that contains the policy-sub-nodes from the source to the target system.
- Optional: If you copied that file to a different directory location, adapt the path given for the separate file with the policy-sub-nodes in the XML export result file.
- After successful import of the policies, configure access control permissions on the sub-nodes manually by using the Resource Permissions portlet.
Problems when transferring Document Manager
When you use the XML configuration interface to transfer a portal configuration that includes the Document Manager application, buttons might be missing from the user interface panels of that application.
Cause: This is a known limitation.
Solution: To resolve this limitation, you need to add some additional steps after performing the transfer by using the XML configuration interface:
- Log in to the WebSphere Application Server Administrative Console.
- Select the Document Manager application. To do this
- Expand Applications.
- Select Enterprise Applications.
- Locate the application that starts with "Document Manager".
- Click Map Security Roles to Users/Groups.
- Assign the Authenticated role to everyone.
- Save your changes.
Portlet global state attribute without wire is not exported by XML export
If you export a portlet that has the global state attribute set, but no wires, the global attribute is not exported. Consequently, this attribute is missing after re-import of the XML script.
Cause: The XML configuration interface does not export the global state attribute of portlets.
Solution: To resolve this limitation, use one of the following options:
- After the XML import, reset the portlet to global state by using the portal administrative user interface. Select Edit page layout > Wires > Manage Actions and set the portlet to global state.
- Before the XML export, create a wire for the portlet. The XML configuration interface exports the wire. The XML import creates the global attribute for all portlets that have a wire.
You cannot delete attributes by using the XML configuration interface
You cannot delete the value for an attribute by using the XML configuration interface.
Cause: This is a known limitation. The XML configuration interface does not allow deletion of attributes.
Solution: You can overwrite the value of the attribute by another value by using the XML configuration interface.
Refer also to ReleaseBuilder ignores deletion of attributes.
User and Group import via the XML configuration interface
The XML configuration interface is not intended to perform the import or migration of large user and group populations.
Cause: This is a known limitation. The XML configuration interface does not allow import of large user groups.
Solution: To migrate or transfer large user groups, use tools provided by your LDAP vendor. If you want to import the Access Control on users and groups, you have to only import the group tag without nested member-user or member-group tags. Modify the XML script accordingly. You can also export groups without the members by setting the attribute export-user of the request tag to the value no-member.
ReleaseBuilder ignores deletion of attributes
If you delete values of fields in the portal administrative user interface, this might result in empty attributes in an XML export file. If you then use ReleaseBuilder to extract the changes between the configurations before and after the deletion of attributes, the difference file does not reflect the deletion of the attributes.
Cause: This is a known limitation. The ReleaseBuilder does not recognize the deletion of attributes. Refer also to You cannot delete attributes by using the XML configuration interface.
Solution: After you have completed the staging process with ReleaseBuilder, delete the attributes on the target portal system by using the same steps as you performed on your source system.
Sample scenario and files: An example scenario and sample scripts are given in the following.
The resulting differential file does not contain the deleted attributes. Sample XML script file snippet export1:
- You create configuration status export1 of your source portal by using the XML configuration interface.
- You modify your source portal by deleting the contents of fields in the portal administrative user interface that lead to attributes without a value in an XML export file.
- You create configuration status export2 of your source portal by using the XML configuration interface.
- You use ReleaseBuilder to extract the changes between export1 and export2.
<client action="update" domain="rel" manufacturer="dilbert" markup="html" markup-version="1.1" name="puppy" objectid="M_CEENUPA000O7002A6CJO0Q1200" ordinal="250" version="1.0"> <useragent-pattern>dogert</useragent-pattern> <client-capability update="set">dish</client-capability> <client-capability update="set">html</client-capability> </client>Sample XML script file snippet export2:<client action="update" domain="rel" manufacturer="dilbert" markup="html" markup-version="1.1" name="" objectid="M_CEENUPA000O7002A6CJO0Q1200" ordinal="287" version=""> <useragent-pattern>dogert</useragent-pattern> <client-capability update="set">dish</client-capability> <client-capability update="set">html</client-capability> </client>From the two exports above, ReleaseBuilder generates the following differential file:<?xml version="1.0" encoding="UTF-8"?> <!-- IBM WebSphere Portal/6.0 build wp600_154 exported on Wed Apr 05 14:24:19 EDT 2006 from xyz --> <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp600_154" type="update" version="6.0.0.0" xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"> <portal action="locate"> <client action="update" objectid="M_CEENUPA000O7002A6CJO0Q1200" ordinal="287"/> </portal> </request>If you use this ReleaseBuilder differential file to update your target portal, the name and version attributes of the client tag are not deleted on the target portal. To complete the update, you have to delete the attributes manually by using the same steps by which you deleted the attributes on the source portal.
Global settings cannot be set in a cluster by using the XML configuration interface
The XML configuration interface fails with the following error when you try to set global settings in a clustered environment.<status element="[global-settings]" result="failed"> <message id="EJPXA0043E">com.ibm.wps.command.xml.XmlCommandException: EJPXA0043E: An error occurred while creating or updating the resource. [global-settings]</message> <message id="EJPEB0002E">com.ibm.wps.command.CommandException: EJPEB0002E: An exception occurred.</message> <message>java.security.PrivilegedActionException: java.lang.NullPointerException</message> </status>Cause: The global settings are stored in the WebSphere Application Server (WAS). For changes to the global settings a WAS API call is invoked. During this call the following exception is thrown in the clustered environment:
Caused by: java.lang.NullPointerException at at com.ibm.wps.services.ServiceHelper$4.run(Unknown Source) at at com.ibm.ws.security.auth.distContextManagerImpl.runAs(distContextManagerImpl.java:2782) ... 43 moreSolution
To configure these settings, configure them directly in the administrative console, or use the normal configuration task update-properties.
Parent topic:
The XML configuration interface
Parent topic:
Search the product documentation for a solutionRelated information
Logging and tracing