Table 4 Known Limitations in WebLogic Portal Framework
Problem ID
|
Description
|
CR125007
|
Credential MBean does not have a tool for editing. The CredentialMBean was added to application-config.xml so that services requiring a plain-text password do not have to store the password on the file system in an unencrypted form.
The CredentialMBean has an encrypted "Credential" attribute that is automatically encrypted/unencrypted when the ApplicationConfigurationMBean (the parent MBean) is persisted/read.
Platform: All
Workaround: As is, the CredentialMBean requires a workaround to be used:
1. Edit application-config.xml by hand to add a Credential.
2. Use the Administration Portal to make a change to some other MBean. This causes an ApplicationConfigurationMBean.persist() .
3. Change the value that you changed in step 2 back to what it was.
Because the persist() method was called, your plain-text credential is now encrypted.
The MBean looks like this:
<Credential Name="LdapPropertyManager" Credential="password"
Username="uid=SomeUserWithReadPermission,ou=people,dc=beasys,dc=com"/>
|
CR177926
|
"<" and ">" characters not rendered correctly when used in Portal titles.
The "<" and ">" characters, when used in titles of Portal objects such as pages and portlets, do not render correctly in a browser because they are special characters that are interpreted and processed rather than displayed literally. The result is that you will not see these titles displayed in the browser.
Platform: All
Workaround: You can display these characters if you escape them; that is, you enter "<" for "<" and ">" for ">". If you do this, your title will appear in the tools as, for example, "<Title>", but it will display in the browser as "<Title>".
|
CR178588
|
Deleting WSRP producers that were created in the IDE leaves .portlet files that are unusable.
If the producer is added in the IDE, .portlet files are generated for the proxy portlets. When the producer is later deleted, the proxy portlet no longer is listed in the Portal Management list of available portlets, but the .portlet file still exists. This leaves a .portlet file that cannot be used due to the fact that the producer was deleted, and if viewed in the .portal gives an invalid registration handle if rendered, and if added to a desktop is not seen.
Platform: All
Workaround: Delete the file manually.
|
CR179773
|
SP2 Upgrade/CM - receive error message when enabling Library Services for BEA repository in an upgraded app.
This limitation was fixed in SP3 but remains applicable for SP2.
When a user upgrades from 8.1 SP2 to 8.1 SP4 or SP2 to SP3 and tries to upgrade their repository to be a managed repository, the following error occurs: "Error getting cache: nodePathCache.BEA Repository" .
Platform: All
Workaround: Although the error message appears, Portal still creates the nodePathCache internally. The only drawback is that you cannot modify the settings of the cache (ttl, size, and so on). If you want to do that, add the correct entry to the app-config.xml and redeploy the application.
The entry you will have to add is as follows:
<Cache MaxEntries="50" Name="nodePathCache.<repositoryName>" TimeToLive="6000"/>
|
CR180105
|
Receive java.io.FileNotFoundException: wsrpKeystore.jks at startup.
The wsrpKeystore.jks file is required by WebLogic Portal for WSRP features.
The configuration wizard places this file in the admin server's domain directory (one directory above the server root directory).
The WebLogic Portal WSRP features require this file to exist at this location (one directory above the server root directory). So in a configuration wizard-generated admin server domain, everything works as it should. But in some other cluster configurations, such as when using NodeManager , whenever the server root directory is overridden, or a domain is created without using the configuration wizard, this file may not exist in this location. In this case, a warning and an exception are reported during server startup.
The error symptom is the appearance of messages during server startup of the following form:
<Apr 26, 2004 3:10:26 PM MDT> <Warning> <WSRP-Security> <BEA-420802> <There was a problem initializing the identity assertion token provider.>
<Apr 26, 2004 3:10:34 PM MDT> <Info> <Security> <BEA-090093> <No pre-WLS 8.1 Keystore providers are configured for server mC for security realm myrealm.>
and java.io.FileNotFoundException: wsrpKeystore.jks (The system cannot find the file specified)
Platform: All
Workaround: Copy the wsrpKeystore.jks file to the server domain directory. Copy the file from a domain that was created with the Configuration Wizard.
|
CR180784
|
NullPointerException during deploy after retargeting.
A NullPointerException is displayed on the server console and log for a WSRP consumer web app on trying to deploy the containing application after the latter's target server/cluster has been changed. This exception does not adversely affect any functionality and can be ignored.
Platform: All
Workaround: None
|
CR181801
|
Servlet response wrappers with custom outputstream/writer cannot be used to render portal/desktops.
If you are using a servlet filter with a response wrapper to filter portals or desktops, and if the response wrapper overrides the getOutputStream() and getWriter() methods to return custom javax.servlet.ServletOutputStream and java.io.PrintWriter objects , you may encounter java.lang.IllegalStateException .
Platform: All
Workaround: Render the content that must be filtered in an IFRAME or a separate browser window.
|
CR183399
|
Portal file caching logic does not work for archived webapps when pageCheckSeconds is set.
WebLogic Portal has the capability to cache the internal representation of a .portal file, which speeds up portal requests. However, this logic does not work if both the webapp is deployed as archived and pageCheckSeconds in weblogic.xml is set to a positive value.
Platform: All
Workaround: Set the value of pageCheckSeconds in weblogic.xml to -1 . This can be a wise thing to do in any case for production mode deployments, as it removes the stale checks for JSP pages.
|
CR192513
|
LdapPropertyManager throws ConfigurableEntitySystemException when credentialMBeanName is uncommented.
When configuring the Unified User Profile for LDAP, the LdapPropertyManager throws the following exception:
"com.bea.p13n.property.ConfigurableEntitySystemException: Error reading ldap configuration".
Platform: All
Workaround: The LdapPropertyManager configuration in the p13n_ejb.jar ejb-jar.xml file was enhanced to permit encryption of the LDAP connection password. The credentialMBeanName environment entry is uncommented by default. If an encrypted password is not needed, comment the section.
A sample of the commented section would appear as:
<!-- env-entry > <description>The name of the Credential MBean in application-config.xml that will be used to store the principal's username and principal's password. The password will be stored in an encrypted form. This is the principal/credential used to bind to the LDAP server. The password will be decrypted before it is used to bind to the LDAP server. Using this entry will override anything set for the config/principal and config/principalCredential. If this entry and config/principal and config/principalCredential are not specified then anonymous bind will be used.
(this entry is optional)</description> <env-entry-name>config/credentialMBeanName</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>LdapPropertyManager</env-entry-value> < /env-entry -->
Should an encrypted password be required, leave the section uncommented and place an additional LdapPropertyManager Credential section in the META-INF/application-config.xml file:
<Credential Name="LdapPropertyManager" Credential="password" Username="uid=ldapadministrator,ou=people,dc=beasys,dc=com"/>
|
CR196690
|
Portlet wizard and Generate Portlet allow portlet types that are not valid for the webapp.
It is possible have a webapp that has just WSRP-Producer installed in and not the full set of portal libraries. In those webapps, you can create new .portlet files, either via the New|File|Portlet menu item or the Generate Portlet right-click menu. Both actions will open the portlet wizard window. There, all of the possible portlet types (jsp/html, page flow, java, struts, and remote) will display and allow you to select them. However, only page flow and struts portlets will work in a WSRP Producer-only webapp.
Platform: All
Workaround: Don't select jsp/html, java, or remote portlets in WSRP Producer-only webapps.
|
CR197762
|
forkRender portlets that include JSPs from a different webapp may behave inconsistently.
Due to thread safety issues regarding the root ServletRequest's context classloader, JSPs that are included from within forkedRenderPortlets that are in different webapps than the portlet may exhibit execution problems due to the incorrect context ClassLoader being in place.
Platform: All
Workaround: Either do not include JSPs from different webapps from forkRender portlets, or do not use forkRender with portlets that include JSPs from different webapps.
|
CR198438
|
Document Structure tab malfunction when working with Look And Feel files.
When working with a Look And Feel, the Document Structure tab can malfunction, causing the CSS class names and their attribute values to cease to render in the Document Structure tree. This happens very infrequently, but does render the Document Structure tab unusable.
Platform: All
Workaround: Close and reopen the Look And Feel file (*.laf ), and the Document Structure tab will return to normal.
|
CR198827
|
Exceptions/warnings thrown when the float button is on a portlet that is part of a desktop.
When a user clicks a float button on a portlet that is part of a desktop, the following error message will be logged:
<BEA-423162> <One or more validation error(s) occurred during parsing /test.portlet. The error(s) were error: The document is not a root@http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0: document element namespace mismatch expected
"http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0";; got "http://www.bea.com/servers/netuix/xsd/jsp/support/1.0.0";;.>
Platform: All
Workaround: None. This message can be ignored.
|
CR199861
|
render:standalonePortletUrl tag creates incorrect link when a portlet using this link is consumed by a remote portal.
The render:standalonePortletUrl tag is used for creating a link that, when clicked, renders the portlet in a new browser window. However, when you host a portlet using this tag on a producer, and then consume this portlet in a remote portal, the link will not open the portlet in its own browser window.
Platform: All
Workaround: The workaround involves creating a backing for the remote portlet created on the consumer side, and some custom code within the portlet JSP. Here are the steps:
a. Create a backing file for the proxy portlet.
b. In the preRender() of the backing file, add the following code:
StandalonePortletURL url = StandalonePortletURL.createStandalonePortletURL(request, response); SimpleStateHolder state = new SimpleStateHolder(); state.addParameter("my_url", url.toString()); request.setAttribute(MarkupRequestState.KEY, state);
c. In the JSP on the producer side, use the following instead of
render:standalonePortletUrl tag to generate a link to float the portlet
<% SimpleStateHolder state = (SimpleStateHolder) request.getAttribute(MarkupRequestState.KEY); String url = (String) state.getParameter("my_url"); %> <a href="<%=my_url%>">Click</a>
|
CR203087
|
Producer data and remote portlets might become unusable if the producer environment is changed to a different location.
When you add producers and create remote portlets, the producer registry (WEB-INF/wsrp-producer-registry.xml ) and the portal framework database tables will contain the address (producer's WSDL address, and addresses of various ports described in the producer's WSDL) of the producer stored. If you move the producer from one environment from another, this data stored may become invalid. If this happens, you might not be able to use those portlets as the producer cannot be contacted at the old location.
Platform: All
Workaround: You can update the database entries by using the com.bea.wsrp.consumer.management.producer.ProducerManager. This API provides methods to obtain and update producer information.
|
CR203935
|
Portal upgrade doesn't work with WSRP Producer-only webapps.
When upgrading from Service Pack 3, WSRP Producer webapps don't automatically have their libraries updated to Service Pack 4. This can cause problems when attempting to communicate to the webapp from the Portlet Wizard or other services.
The normal portal upgrade path, via the Install|Update Portal Libraries at the application level, will not correctly detect non-portal webapps that have WSRP Producer installed. Additionally, reinstalling WSRP Producer to the webapp will not update the library files.
Platform: All
Workaround: Copy the following files into your webapp WEB-INF/lib directory:
<beahome>/weblogic81/portal/lib/netuix/web/netui-adapter.jar
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad
apter.jar
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad
apter-html.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad
apter-naming.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad
apter-nested.tld
<beahome>/weblogic81/portal/lib/netuix/system/ext/web/struts-ad
apter-tiles.tld
<beahome>/weblogic81/portal/lib/wsrp/wsrp-producer.jar
<beahome>/weblogic81/portal/lib/wsrp/adapters/wsrp-jpf-adapter.
jar
<beahome>/weblogic81/portal/lib/wsrp/adapters/wsrp-struts-adapt
er.jar
Redeploy the WSRP Producer webapp, if your server is running.
You will need to upgrade the other parts of your application normally.
|
CR204478
|
onDeactivation portlet events for non-visible portlets may not work with portal tree optimization turned on.
When the "tree optimization" flag in a .portal file is turned on, not all non-visible portlets for a given request are processed. (A non-visible portlet is one that lives on a page that is not displayed for the given request.) This can be a problem if you are trying to catch an onDeactivation event for a portlet — once the portlet has been deactivated, it is no longer visible, and so the system doesn't process it to fire its deactivation event.
Platform: All
Workaround: The safest alternative is to set tree optimization to false for the portal in question. However, if you need tree optimization you can perform this workaround: for each portlet that you want to catch deactivation events for, define a dummy event handler (for example, create a custom event handler with event = "[some arbitrary string]" and set the property "Only If Displayed" to false . This will force the system to process the portlet whether visible or not.
|
CR206920
|
Portlet preferences may not be reloaded from .portlet files by default.
Prior to Service Pack 4, when the server was bounced or redeployed, the preferences in the .portlet file always overrode the preferences in the database, so administrator additions and changes to any portlet preferences were lost on a server restart.
A new option allows you to control the way in which portlet preferences are reloaded on server restart. You implement this control using the "master" attribute on the "propagate-preferences-on-deploy" element in the WEB-INF/netuix-config.xml file.
Possible values for the master attribute are:
file
Provides the same behavior as in previous versions. The preferences in the file system always take precedence. To preserve existing behavior, select this value.
database
In the case of a restart, the values in the database always takes precedence. In the case of a first time startup, the database is seeded from the .portlet files.
both
The default behavior if the attribute is missing. The .portlet preferences are merged with the database preferences, with the database values taking precedence over the .portlet file's values.
The following example shows the element with an attribute value of both :
<customization>
<enable>true</enable>
<propagate-preferences-on-deploy propagate-to-instances="true" master=" both "/> <reload-database-on-redeploy reload="false"/> </customization>
|
CR218066
|
WebLogic Portal 8.1 SP4 - 'Return To Default Page' attribute on Books not working properly when tree optimization is on
When a Book's 'Return To Default Page' attribute is set to true, the portal should display the Book's default page when the Book is the target of a navigation URL. This is not happening.
Platform: All
Workaround: This CR only addresses the nesting of books where the immediate children of the Main Book are books and the return to default only applies when moving between books, not within books. Here is a simple portal hierarchy where each page has a portlet that contains a URL to Book2.
Main Book - Book 2 is the default book for the main book
Book 2 - Return To Default = true with default page = Page 2
Page 2
Page 3
Book 3
Page 4
Page 5
When the above portal is rendered, Book 2 and Page 2 are displayed.
1. The user clicks on Page 3, moving off of the default page
2. The user clicks on Book 3 (which results in Page 4 being displayed and moving into a different book).
3. The user clicks on the URL for Book 2 and Page 2 is displayed
This works as expected as Page 2 is the default for Book 2 and the last active page in Book2 was Page 3.
When the above portal is rendered, Book 2 and Page 2 are displayed.
1. The user clicks on Page 3, moving off of the default page
2. The user clicks on the URL for Book2 and Page 3 is displayed
The reason for this is because Page 3 is within the same book and therefore, the return to default is not applied.
|
CR218066 (Continued)
|
In the following hierarchy where pages are the children of the main book, the Return to Default feature does not apply.
Main Book - Page 1 is the default page for the main book
Page 1
Book 2 - Return To Default = true with default page = Page 2
Page 2
Page 3
Page 6
Book 3
Page 4
Page 5
Using the above hierarchy, the user is returned to the last active page in Book 2.
|
CR223724
|
Campaign - if an error exist in the campaign schema (goals), ensure the exception makes it to the console.
In creating a camping with goals, Workshop does not generate the entire XML required by the xsd. The following needs to be added manually:
<ca:ad-id xmlns:ca="http://www.bea.com/servers/campaign/xsd/campaign/1.1.1";>
</ca:ad-id>
When the customer has not manually added this line, an exception is thrown, but it does not surface on the console. This is very misleading in that the goals do not take effect.
Platform: All
Workaround: None
|
CR225885
|
The RDBMS Authenticator is not supported for XA drivers, Multipools and Driver level load balancing
If you put a XA driver, Server will not boot up.
Platform: All
Workaround: Use a non-XA driver for the RDBMS Authenticator; load balancing is not supported.
|
CR226791
|
Provide a default content repository choice in CM tags
In WebLogic Portal 7.0 there is a "contentHome" parameter available in the Content Management tags that allows you to specify which content repository to use for a query. In WebLogic Portal 8.1, this parameter is available in the Java API (for example, the homeName parameter in ContentHelper), but was deprecated and is ignored in the JSP tags.
In addition, the tags do not provide the ability to specify a content repository to search if no repository parameter is specified; the default behavior is to aggregate across all repositories.
Platform: All
Workaround: Portal 8.1 Service Pack 5 added an optional parameter called "searchPaths" to the <pz:contentQuery> and <cm:search> tags. This parameter can be used to specify a specific repository to use for the content query. Service Pack 5 also adds the ability to set a comma-delimited, default list of search paths, using the "-Dcm.default.search.path=" system parameter. If present, this is used by the <pz:contentQuery> and <cm:search> tags when the "searchPaths" parameter has not been specified in the tag.
|
CR227092
|
Commerce component Price Engine putting high pressure on database
When a discount is used, its use count is incremented in the database. For unlimited use discounts, a customer may not be interested in tracking the number of uses.
Platform: All
Workaround: Set the System Property track.unlimited.discount.usage=false to turn off tracking of usage counts for discounts whose usage limit is "UNLIMITED".
|
CR228941
|
More Datasync repositories being created when application hit for the first time.
The Rules repository is not initialized until a rule the first time it is accessed. This initialization process can be time consuming and the application is unavailable during this time.
Platform: All
Workaround: Change the descriptor for the RulesetPersistenceManager EJB from
<initial-beans-in-free-pool>0</initial-beans-in-free-pool>
to
<initial-beans-in-free-pool>1</initial-beans-in-free-pool>
This will cause the Rules repository to initialize at server startup.
|
CR230071
|
Mandatory pages can be deleted by users
In WebLogic Portal 7.0, the portal administrator had the ability to set a page attribute of mandatory to prevent certain pages from being removed as a result of a user's customizations. In WebLogic Portal 8.1, this functionality is not directly available because users can now utilize visitor tools to remove any pages to which they are entitled
Platform: All
Workaround: To achieve similar functionality to that of WebLogic Portal 7.0, you can use the removePlaceable() method in the PortalCustomizationManager interface to prevent a user from deleting a mandatory page. Keep the following considerations in mind if you plan to use this implementation to enforce mandatory pages:
You must set at least one entitlement per page. When a page is created, no entitlements exist and the default is to grant all privileges on that page. The removePlaceable() method checks for the UPDATE entitlement on the page that contains the book or portlet being deleted.
Because the SP5 Visitor Tools code calls into the PortalEntitlementHelper class, it is recommended that you use this class as the means of obtaining the entitlements for a page:
boolean isAllowed = PortalEntitlementHelper.checkPageDelete(new
CustomizationContext(request.getLocale(), request), <page_definition_id>)
This would require that you make the call, and then add a check in the Visitor Tool code to branch, based on the outcome of this call.
A future release will provide a more robust means of accomplishing this task.
For more information on the PortalCustomizationManager interface, see the WebLogic Portal Javadoc at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/javadoc/index.html.
|
CR235701
|
Description PortalContextAdapter ignores threadSafe attribute.
The threadSafe attribute is treated as always "true" for remote portlets, even if it is set to false in the portlet.
Platform: All
Workaround: None
|
CR235832
|
"Verbose log could not be set, parent folder does not exist" errors occur using the Propagation Tool.
The default setting for the oamDataFilesystemPath element in the web.xml for the propagation.war is d:/propagation/81xDomain/inventories . If a D: drive does not exist, exceptions will be thrown similar to the following:
<Error> <InventoryServices> <machinename> <portalServerFrom> <ExecuteThread: '13' for queue: 'default'> <weblogic> <> <000000> <Verbose log could not be set, parent folder does not exist. logFile: d:\propagation\81xDomain\inventories\view_verbose_D13_H9_M42_S34.log>
These exceptions will be thrown at the following times:
Platform: All
Workaround: Change the oamDataFilesystemPath setting in the propagation.war's web.xml file to an existing drive.
On a Windows system, it could be changed such as:
<context-param>
<param-name>oamDataFilesystemPath</param-name>
<param-value>c:/propagation/81xDomain/inventories</param-value>
<description>Base folder path for runtime data, such as inventory exports.</description>
</context-param>
On a UNIX system, it could be changed such as:
<context-param>
<param-name>oamDataFilesystemPath</param-name>
<param-value>/opt/propagation/81xDomain/inventories</param-value>
<description>Base folder path for runtime data, such as inventory exports.</description>
</context-param>
|
CR236023
|
<cat:catalogSelector> tag does not work after enabling commerce services for a Portal application.
When enabling commerce services to an existing Portal application, not all the files needed to utilize the <cat:catalogSelector> tag are available as part of this installation. The code expects for find a GlobalCatalogSelectors.rls file located in <application>/META-INF/data/catalogselectors/GlobalCatalogSelectors. Also, there is no tooling for creating the GlobalCatalogSelectors.rls file in the 8.x line.
Platform: All
Workaround: The following is an example of a working GlobalCatalogSelectors.rls file for reference.
<?xml version="1.0" ?>
<cr:rule is-complete="true"
xmlns="http://www.bea.com/servers/p13n/xsd/expression/expressions/2.1.1"
xmlns:collection="http://www.bea.com/servers/p13n/xsd/expression/collection/1.0.1"
xmlns:cq="http://www.bea.com/servers/p13n/xsd/content/query/1.1.1"
xmlns:cr="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1"
xmlns:math="http://www.bea.com/servers/p13n/xsd/expression/math/1.0.1"
xmlns:ss="http://www.bea.com/servers/p13n/xsd/expression/schema-support/2.1.1"
xmlns:string="http://www.bea.com/servers/p13n/xsd/expression/string/1.0.1"
xmlns:lit="http://www.bea.com/servers/p13n/xsd/expression/literal/1.0.1"
xmlns:wlcs="http://www.bea.com/servers/p13n/xsd/rules/extensions/2.1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1 rules-core-2_1_1.xsd http://www.bea.com/servers/p13n/xsd/rules/extensions/2.1.1 rules-extensions-2_1_1.xsd">
<cr:name>test</cr:name>
<cr:description />
|
CR236023 (Continued)
|
<cr:conditions>
<multi-and>
<greater-than>
<wlcs:literal>
<wlcs:now />
</wlcs:literal>
<wlcs:literal>
<wlcs:time-instant>1970-01-01T00:00:00-07:00</wlcs:time-instant>
</wlcs:literal>
</greater-than>
</multi-and>
</cr:conditions>
<cr:actions>
<wlcs:add-catalog-query-object>
<wlcs:expression>price > 50</wlcs:expression>
<wlcs:max-results>100</wlcs:max-results>
<wlcs:catalog-manager-name>portalApp.BEA_commerce.CatalogManager</wlcs:catalog-manager-name>
</wlcs:add-catalog-query-object>
</cr:actions>
</cr:rule>
|
CR239172
|
Enabling preRender Forking on Pageflow portlets causes a failure to render content.
A new feature in 8.1 SP5 allows the preRender life cycle phase in portlets to be executed in a separate thread. This is also referred to as preRender forking (see e-docs for details). As of the Service Pack 5 release, this feature was not working correctly for Pageflow portlets. If preRender forking is enabled for a Pageflow portlet the portlet's content will fail to render. That is the portlet frame and title bar (if present) will render but content will not. This issue is being resolved and a patch will be posted under this CR as soon as it is available.
Platform: All
Workaround: Do not use preRender forking in Pageflow portlets.
|
CR225408
|
In 8.1 SP6, Content Query expressions are generated incorrectly due to an order of precedence problem.
In the following expression: (a && (b || c), this gets evaluated/executed as (a && b || c). The order of precedence is not maintained when executing a Content Query expression.
Platform: All.
Workaround: This problem was fixed in 8.1SP6 such that the order of precedence is now maintained when executing a Content Query expression. A system property was added to disable this fix so that the expression is evaluated the same as in 8.1 Service Pack 5 or earlier:
-Denable.content.rule.fix=true
|
CR254373
|
Request parameters are no longer implicitly propagated from one WSRP request to the next.
This issue impacts only customers with a patch for CR 254373.
Prior to the fix for CR254373 the portal framework would add all request parameters to the WSRP navigationState url automatically. This was a violation of the WSRP specification and also caused a problem because the url could get too large. CR254373 removed this bug but it caused a common use case that some users had with pageflows to fail once the fix was supplied. The use case entails submitting a form to a pageflow action, the action forwards to a result.jsp that then displays the form contents by pulling them out of the request. This will work in a standard pageflow but fails when the pageflow is accessed via a WSRP consumer portlet because the submission of the form and the follow up display of the results requires two requests from the consumer to the producer (although it still appears to be a single request from the stand point a user interacting with the consumer). Submission of the form from the consumer to the producer is handled by a performBlockingInteraction() call. When that call completes the consumer then follows up with a getMarkup() request to the producer that returns the markup for the result.jsp page. However since the request parameter are not implicitly propagated from one request to the next the form parameters are no longer present when the getMarkup() request is processed. The pageflow example noted above is one way to demonstrate this issue but it applies to any case where a performBlockingInteraction() call is made.
Platforms: All.
Workaround: This is not really a workaround, but rather the proper way to implement this functionality. Implementers simply need to explicitly propagate the parameters they wish to keep in the request. Referring back to the pageflow example described above there are two simple solutions that could be used to fix the implementation. In the first solution the pageflow action that receives the submitted form can simply pass it along by explicitly including the form in the Forward object that is returned by the action. This can be done using a netui ActionForm object or individual parameter name value pairs can be included as pageInputs in the Forward object. The results.jsp should then retrieve the items in a manner suitable to method used. Another possible solution is for the pageflow to hold onto the desired parameters as part of its state. That is the action that receives the form retrieves the parameters of interest from the ActionForm or request, assigns the values to instance variables and provides access to those value through getters on the pageflow. The result.jsp can then access the values need using those getters.
|