Oracle9iAS Portal Developer Kit (PDK)
Portal Tools Release Notes

System Requirements

The following are the recommended and minimum requirements to use and install the Portal Tools version 9.0.2.6.2.

Note:  You may encounter JavaScript errors when using a browser older than what is listed above.

What's New

A complete list of new features is available within the PDK New Features article. 

Known Issues

• Bug#3024053 CHANGE REPOSITORY SETTINGS PERSISTS OLD CLIPPING DEFINITIONS 

  • Changes to the Security Repository settings may not reflect the change immediately.

  • Workaround: Every time you modify the Security Repository settings, you should bounce the OC4J instance to apply your changes. After you bounce the OC4J instance, go to the OmniPortlet Provider Configuration page (host:port/portalTools/omniPortlet/providers/omniPortlet). On this page, the Security Repository Configuration status will say "Not Configured." Click Edit, then click OK to apply the new settings.

• Bug#3015565 USER SPECIFIED CONNECTION INFORMATION IS NOT PERSISTENT. 

  • If a user configures OmniPortlet using repository A, adds named connections and later changes the repository to connect to connection B, any subsequent changes to repository A will hide existing named connections. The issue occurs because every time the repository is changed, a new vault ID is generated.

  • Workaround: Go to the OmniPortlet provider directory, which is the same directory where provider.xml of OmniPortlet exists. In this directory, view the file: vaultIdMappings.properties. This file contains all the vaultID mappings. The format is: username||||SID||||host||||port=vaultId. To retrieve existing named connections, note the appropriate vaultID, and insert it into the <vaultId> tag in OmniPortlets provider.xml file.

• Bug#3024059 :CONNECTION INFORMATION PAGE THROWS ERROR AFTER CHANGING REPOSITORY TARGET 

  • Suppose you configure OmniPortlet using a repository (A), then configure a secured data source to use Repository A. If you change this secured repository to connect to Repository B, the portlets using Repository A will display an error message saying "No Connection Information found." If you try to click Edit Defaults to change the connection information on the Edit Connection page, another error message displays that says "Failed to update repository." 

  • Workaround: Drop the portlet from the page and re-create it. 

• Bug#2993892 OMNIPORTLET TEST PAGE PROXY APPLY HAS NO EFFECT 

  • If the portlet is simultaneously being defined and configured, the changes made to configure the portlet may not be reflected in Define mode. 

  • Workarounds are either:

    • Configure the OmniPortlet Provider first (for proxy/security repository) and then start using it or,
    • After configuring the provider, click OK (instead of APPLY). 

• Bug#2997803 DEFINE LINK SHOWN FOR A OMNIPORTLET AFTER CREATION WHEN VIEWED ON ANOTHER BROWSER

  • When dropping an OmniPortlet on a page through Internet Explorer, a personalization object file is created with the name "_default.dat". Subsequently, accessing this portlet and customizing it using Netscape will create an NLS-specific personalization object file eg: "_default_en_US.dat". Subsequent accesses through IE, however, will try to access the original "_default.dat" personalization file. 

• Bug#2938729 FILTER TAB DOES NOT HANDLE COLUMNS WITH SAME NAME FROM 2 TABLES 

  • Every data source should provide unique names for each column. For example, the SQL statement "select * from emp, dept where emp.deptno = dept.deptno" gives two deptno columns. In this case, OmniPortlet cannot distinguish the between two columns of the same name, and will only pick up the first column.

  • Workaround: Ensure that the data source does not contain duplicate column names.

• Bug#3007147 ERROR WHEN COLUMN NAME SAME AS PARAMETER OR FIELD NAME 

  • OmniPortlet cannot distinguish column, parameter, or field of the same name, and could generate unexpected results.

  • Workaround: Avoid using the column name as a parameter or field name.  Similar to Bug#2938729 (see above).

• Bug#2485361 PARAMETER/COLUMN ## REFERENCE IN DATA URLS ARE CASE-SENSITIVE

  • Names in OmniPortlet are case-sensitive.

  • Workaround: When using ## lexical reference in, for example, a hyperlink, make sure you type column name using the appropriate case. This follows the Oracle Portal model of case-sensitive parameters.

• Bug#2991543 SCROLLING LAYOUT DOES NOT WORK WITH NETSCAPE 4.79 

  • News Layout Scroll type is supported on IE and Netscape 7.0. It does not work with Netscape 4.79.

• Bug#2979975 LIBRARY PATH ON WINDOWS NOT BEING PICKED UP IF NOT IN UPPER CASE

  • Access to uixtags.jar is provided by setting the CLASSPATH in the manifest file in pdkjava.jar.  Any directories that the user creates must be in the same case as defined in the pdkjava.jar manifest file, e.g.,  ../../BC4J/lib/uixtags.jar  

• Bug#2639560 CHART DOES NOT RENDER NUMERIC VALUES WITH COMMAS (100,000 20,000, ETC.)

  • Numeric value from a data source should not contain commas (e.g., 32,789). Otherwise, the value may be considered a text value when used in sorting, and thus will be skipped when the chart is generated.

  • Workaround: Remove commas from numerical values.

• Bug#2411864 DATASOURCE DRIVERS HIDE SSO CHALLENGE

  • The OmniPortlet provider exists and executes in a different tier to the Portal Application and does not have access to the Portal session information.

  • Workaround: Expose files uploaded to Portal as PUBLIC to enable OmniPortlet to access them.  

• Bug#2507823 CUSTOMIZE FREEZES YOUR EDIT DEFAULTS

  • The action of customizing a portlet creates a complete copy of the personalization object file.  Since all properties are duplicated, subsequently modifying the portlet through Edit Defaults will not be reflected in the customized version of the portlet. 

  • Workaround: To pick up the latest changes to the portlet the user must enter the Customize screen for the portlet and select Reset to Defaults. 

• Bug#2638269 WEB CACHE INVALIDATION BROKEN IN OC4J/IAS 903 ENVIRONMENT

  • Due to a change in the behavior of the XML parser between OC4J 9.0.2 and OC4J 9.0.3, whitespace in the XML configuration file is being treated differently between these two versions.  

  • Workaround: Remove unnecessary whitespace from the cache.xml configuration file.

Installation

Follow the instructions within the Installing Portal Tools article.