This document contains information on the following subjects:
Note: | For updated release notes, consult the BEA documentation web site. |
BEA WebLogic Portal and WorkSpace Studio 10.2 provide tools to build enterprise portal applications.
This release includes the following:
When you install WebLogic Portal 10.2, the required patches in Table 1 are installed automatically. If you uninstall any of these required patches and need to reinstall them, use the information in Table 1 in conjunction with the Smart Update utility to reinstall and apply the patches. For detailed information on using Smart Update, see Installing Patches and Maintenance Packs Using Smart Update on e-docs.
For information about BEA-supported hardware and software configurations, see the supported platform documentation.
Note: | The release version of WLP 10.2 runs on WebLogic Server 10.0 MP2, which includes several software patches. You can expect to see the list of WebLogic Server patches displayed when you run WLP 10.2. |
This release of WebLogic Portal supports the standards listed in Table 2.
This section describes problems that have been identified in BEA WebLogic Portal 10.2. For each problem listed in the following tables, a problem ID called a CR number is specified. These IDs enable BEA and users to monitor the status of issues while solutions are developed. This section groups the known limitations by functional area.
For more information, see the following sections:
Table 3 lists known limitations and workarounds for installing WebLogic Portal.
Uninstalling Weblogic Portal within a domain that includes WebLogic Integration results in removal of domain dependent files.
|
Table 4 lists known limitations and workarounds for upgrading WebLogic Portal and Workshop.
Note: | BEA Workshop for WebLogic has been renamed to WorkSpace Studio. |
Table 5 lists known limitations and workarounds for Workshop framework and development.
Note: | BEA Workshop for WebLogic has been renamed to WorkSpace Studio. |
Table 6 lists known limitations and workarounds for WebLogic Portal framework and development.
The Export/Import Utility creates an additional locale for artifacts imported in a non-English locale
This problem occurs in the situation where the user localizes a book in the library to a non-en_US locale, and then exports the book as a .pinc and imports the .pinc to a destination in the non-en_US locale. Upon importing the resource, scoped to the Library level, the Export/Import Utility creates an entry in the
L10N_LOCALE table for all pages and books in the library rather than only in the main book, even though the other library artifacts were not localized.
|
|||
When async rendering is enabled for a portlet, portlets cannot directly change window modes or states
WebLogic Portal allows portlets to change the current window state and/or mode of a portlet either programmatically, or via parameters added to URLs. When async rendering (either via AJAX or iframes), these mechanisms will not provide a consistent view to the end user. Particularly, the title bar rendered above the portlet will not reflect the change in the mode or state immediately.
|
|||
For a federated configuration in which the consumer is running 8.1.x, the consumer may not recover properly from producer session timeouts.
|
|||
When using GenericURL, its subtypes or the corresponding JSP tags to generate off-site URLs (i.e.: URLs to resources that are not hosted in the web application of the code generating the URL) in a web application that has compression enabled, a URL template with compression disabled must be specified.
GenericURL redirectURL = GenericURL.createGenericURL(request, response);
redirectURL.setDomain("www.yahoo.com"); redirectURL.setPort(80); redirectURL.setPath("/compressedUrl/index.html"); redirectURL.setTemplate("no_compression_template"); |
|||
WebLogic Portal does not support changing the context-root of an existing portal web application with customized portal objects.
|
|||
The Portal 10.0 look and feel files are generally considered to be incompatible with Netscape 7.1 due to an incomplete implementation of modern standards for web-based applications, such as CSS. Because the Portal 10.0 look and feels are based on these modern standards, users of Netscape 7.1 can expect to encounter problems with many aspects of these look and feels. Problem areas include: layouts, multilevel menus and image rollovers.
|
|||
Deprecated versions of the Look and Feels (for example, Classic) do not support the 10.0 AJAX portlet implementation
|
|||
Expression-based visitor roles, which use multiple-user property-set values, may return a false negative, preventing a visitor from correctly assuming the role
|
|||
Portlet render dependencies do not support fully-qualified URLs to reference HTTP addressable resources
A portlet’s render .dependencies file does not support using fully-qualified URLs to reference script, style, and other HTTP addressable resources. For example, a script reference to Google Maps that is defined in a .dependencies file will result in an error such as “The look and feel resource at base path <path> could not be found.”
|
|||
Icons do not to render in Portal Administration Console tools when a space exists in the name of a Portal EAR project
For example, if there is a space in the name of a Portal EAR project, icons in the console do not appear in the Create Desktop wizard and the administration console displays missing icon errors:
|
|||
JSF validation does not work with the portal namingContainer tag and causes IllegalStateException: Client-id
A known problem exists in some versions of JSF 1.1, where the sequence number used to generate IDs for components that do not specify their own client ID is not reset. This eventually results in the IllegalStateException in cases where a MyFaces page is re-rendered and there is no navigational rule defined.
|
|||
If a JSF portlet attempts to integrate JSTL tags with JSF managed beans using
jsp:useBean , different bean instances are used for JSF than for the JSTL tags.
Workaround: This is due to the fact that
jsp:useBean is not aware of the managed bean environment used by JSF. To work correctly, the bean instances referenced by jsp:useBean must first be “primed” by either accessing them from within JSF or explicitly calling to the variable resolver with something like:
|
|||
When an Apache MyFaces is the underlying JSF implementation provider, invalidating the session results in an IllegalStateException
In a JSF portlet that uses Apache MyFaces as the underlying JSF implementation provider, invalidating the session in JSF application logic results in an IllegalStateException following the processing of the JSF action.
|
|||
The
<f:param> tag will not work when using WSRP. This is due to request parameters being unavailable during the pre-render and render life cycle stages. This is true for all portlet types consumed via WSRP. See
Avoid Accessing Request Parameters in Rendering Code.
|
|||
When publishing a portlet, publishing service does not properly reflect themes from publishing contexts
|
|||
<BEA-403302> <An unexpected SQL exception occurred java.sql.SQLException: Data exception -- row already exist in index PK_LEASE on table P13N_LEASE.
|
|||
Asynchronous JavaScript imports via XIE may cause Internet Explorer 7 to hang if referenced script does not exist
If portlet content or render dependencies are loaded via XIE that refer to an external JavaScript resource that does not exist, or may otherwise fail to load, XIE lifecycle processing in Internet Explorer 7+ will hang. This is because XIE attempts to mimic initial browser loading behavior by executing scripts serially, even when such scripts are fetched asynchronously by the browser, as with IE7+. If the attempt to load the script fails (typically because it does not exist), IE7+ halts advancement of the readyState field for that script at “loading” and produces no error message.
|
|||
When building JSF portlets in a Portal Web Project, the default configuration of JSF is not supported. It must be changed to use the Sun RI implementation and the 'server' STATE_SAVING_METHOD.
|
Table 7 lists known limitations and workarounds for content management and search.
Table 8 lists known limitations and workarounds for federation.
When LocalProxy is enabled for WSRP, the client becomes responsible for sending cookies, especially the session cookie.
|
|
When a remote portlet sets the title programmatically, WebLogic Portal will use that title in the titlebar.This functionality is not supported when the remote portlet is minimized. When a remote portlet is minimized, WebLogic Portal will not contact the producer to render the portlet, and hence loses the dynamically set title.
|
|
If WSRP local proxy is enabled and the consumer accesses a producer with the default context path or a context path containing a slash (/), then the consumer request will fail.
|
|
Table 9 lists known limitations and workarounds for collaboration.
Server for a PointBase domain created via the Configuration Wizard fails to boot with - Cannot find the user “WEBLOGIC_GROUPSPACE” if “Run Scripts” is run only for p13nDataSource
When a new domain is created via the Configuration wizard with WebLogic Portal and WebLogic Portal GroupSpace Framework selected under “Generate a new domain configured automatically to support the following BEA Products” and on the “Run Database Scripts” window the “Run Scripts” button is selected only for p13nDataSource the WebLogic Server for the resulting domain may fail to boot with Cannot find the user “WEBLOGIC_GROUPSPACE”.
|
|
The WYSIWYG HTML editor in GroupSpace allows the insertion of links to GroupSpace resources. However, when those resources are deleted, the links in the HTML are not automatically updated. You must manually edit the HTML to replace or remove the broken links. Also, links to GroupSpace resources in the GS Links portlet have to be manually updated when the linked item is deleted.
|
|
The collaboration portlets (Discussion, Tasks, Calendar, etc.) manage a separate database table to track contents of their containers and content repository items. This table can get out of sync when the repository is populated using external tools such as Propagation or Admin Tools.The following symptoms indicate that the table needs to become synchronized with the repository:
|
|
Certain URL formats for RSS feeds are not handled properly by the GroupSpace RSS portlet. Specifically, URLs that contain single quote characters cause problems during the parsing process used by the RSS portlet. This limitation prevents the display of content management RSS feeds when using a URL format that requires the use of single quote characters.
Workaround: Use named Syndication Feeds. Below is an example of a URL for a content management RSS feed that will not work in the GroupSpace RSS portlet due to the use of single quote characters:
http://serverName:7001/appName/SyndicationProducer?searchQuery=cm_createdBy='weblogic'&syndicationStyleName=rss.
|
|
When searching for a GroupSpace element that has multibyte characters in the name and the encoding for the GroupSpace enterprise search is not the default, search results may not be returned
|
Table 10 lists known limitations and workarounds for Production Operations.
The Export/Import Utility provides limited support for localization of portlet instances at an admin level scope
Scoping a book or page with a new locale to the library level is working. When the .pinc is exported/imported in the new locale, the new locale with new title is picked up by the WebLogic Portal Administration Console and L10N tables are updated in the database. However, this is not working for localizing a portlet instance scoped to the admin level. The imported locale is not reflected in the WebLogic Portal Administration Console for the portlet, but the L10N database tables are updated.
|
|
In the Export/Import Utility, locale resource descriptions are not being propagated to the .pinc file
|
|
In the Export/Import Utility, new resources are not imported correctly when first importing in a foreign locale
For example, if you do not have all you resources localized to a specific locale (for example, “es”) and you export a desktop in locale “es”, then the resources that do not have a resource (title) in “es” will do a best match algorithm. That best match could be a title in “en” (English)
|
|
WebLogic Portal Analytics reports for Desktop, Pages, and Portlets with the same title but from different web applications are indistinguishable.
Analytic reports do not identify which WebLogic Portal web application sourced a particular usage event. This means that if the same title is used in multiple web application portlets, multiple reports of that title will exist and there is no way to know which web application is associated with each report.
|
|
Customized and non-customized portlet, page and desktop Titles are not visible when viewing Analytics reports.
When creating a portlet or page in Workshop, by default the resource’s Definition Label will be used in Analytic reports. If a resource’s Title is subsequently customized by the Portal Admin Console, that customization should instead appear in Analytic reports after running the Analytics sync script but it doesn’t.
|
|
Analytic report on a selected web application that has never been accessed shows activities of other non-selected web applications
When multiple web applications in an enterprise application exist and there are activities in all the web applications except one, the Analytics report on the web application that does not have any activities shows results of the all other web applications that do have activity. After the web application is accessed, the Analytics report on the web application shows only its own activities.
|
|
While propagating content management resources, the following error message may be observed in the console or server log files:
This error is caused by a campaign event firing when a content management resource, such as a node or type, is saved by propagation. The scenario service attempts to fetch the profile of the current user (the propagation user) when it does not exist. Propagation of the content resource should still complete successfully. However, it is likely that the event logic is failing to complete successfully.
|
|
Error message regarding the export of WSRP portlet instance data is observed when propagating WSRP portlets between consumers that share a common producer
When propagating WSRP proxy portlets from one consumer to another, where both consumers share a common producer, an error message similar to the following may be observed on the server console or in the server logs:
|
Table 11 lists known limitations and workarounds for WebLogic Portal Administration Console.
This section lists limitations that were fixed in BEA WebLogic Portal 10.2 MP1. For more information, see the following sections:
When attempting to create a desktop in Portal Administration Tool, the
.portal file was missing. This issue occurred when the Portal application created had 'wlp-tools-support-app-lib' entry removed from weblogic.application.xml . The application was then deployed using the following command after HTTP tunneling was enabled:
|
|
During creation of WebLogic Portal databases on DB2 only, an invalid
SQLSTATE code was used in several CREATE TRIGGER statements. On DB2 9.5, this prevented the Configuration Wizard from successfully populating the database. On prior versions of DB2, this caused an uninformative error message to be displayed rather than the intended, informative error message in certain rare cases of referential integrity violation.
|
This section lists limitations that were fixed in BEA WebLogic Portal 10.2. For more information, see the following sections:
Note: | BEA Workshop for WebLogic has been renamed to WorkSpace Studio. |