Enterprise Development Kit 5.3- released September 2006, for AquaLogic Interaction 6.1 compatibility

Enterprise Development Kit 5.3- released December 2005, for AIX, Solaris and SUSE Linux

Enterprise Development Kit 5.3- released September 2005, for Windows and Red Hat Linux

These release notes cover all releases of Enterprise Development Kit 5.3, including hotfixes and service packs. For information on a particular release, please go to the appropriate section of these release notes.

Release notes are occasionally updated after the release date. For the most up-to-date release notes, go to http://www.oracle.com/technology/documentation/index.html.

Refer to the Interoperability page in the Product Center at support.plumtree.com for the latest information on supported operating systems, application servers, databases, and browsers.

At the time of release, Enterprise Development Kit 5.3 supports the following:

• Operating Systems: Windows 2000 Server SP4; Windows 2003 Server SP1; Solaris 8 and 9, Red Hat Linux ES 3, SUSE Linux ES 9, AIX 5.3
• Remote Web Application Servers - .NET :
  • IIS 6.0 / .NET 1.1 (worker process isolation mode or IIS 5.0 isolation mode).
  • IIS 6.0 / .NET 1.1 with KB824629
    
• Remote Web Application servers - Java :
  • Apache Tomcat 5.0.28, bundled JDK 1.4.2 *
  • BEA Weblogic 8.1 SP4, bundled JDK 1.4.2 *
  • IBM WebSphere 6.0.1 Windows, bundled JDK 1.4.2
  * The portlet API (com.plumtree.remote.portlet) can be used with JDK 5.0 (1.5) in WLS 9.1 and Tomcat 5.5, but full JDK 1.5 certification is not yet complete.
  The other libraries (e.g. com.plumtree.remote.prc) are known not to work in JDK 1.5.
  
• Runtimes :
  • .NET Framework version 1.1.4322 (EDK .NET only)
    • EDK .NET PRC Collaboration and PRC Content APIs also require .NET Web Services Enhancements 2.0SP3 to use document upload
  • JDK version 1.4.2 or higher (Enterprise Development Kit - Java only)
• Browsers: IE 5.5 and 6.0; Netscape 7.2; Firefox 1.0

Refer to the Interoperability page in the Product Center at support.plumtree.com for the latest information on supported Plumtree products.

At the time of release, Enterprise Development Kit 5.3 supports the following:

• Portal: Plumtree Corporate Portal 5.0.4/5.0.4J, Plumtree Foundation 6.0
  • Portal 4.5WS is supported for AWS/PWS/CWS/Portlet via UDDI
• Collaboration Server: 4.0.2, 4.1.0 (required to use PRC Collaboration API)
• Content Server: 4.0.2, 4.1.0 (required to use PRC Content API)

The product distribution includes the following documents in the Documentation folder. For the most up-to-date documentation, go to http://www.oracle.com/technology/documentation/index.html.

The Enterprise Development Kit 5.3 provides the following new features:

• The Portlet API provides the ability to set Session Preferences for Plumtree Foundation 6.0.
• The Portlet API supports the Credential Vault available in Plumtree Foundation 6.0. For portals prior to 6.0, the Portlet API provides support for Basic Authentication and simple encryption methods for storing user credentials in preferences.
• The Portlet API also provides the following functionality for Plumtree Foundation 6.0:
  • Return the alignment of the portlet in the portal.
  • Return the query string portion of the URL used to access the portal's hosting page.
  • Check to see whether the current user is a guest user.
  • Return the ID of the experience definition to which the accessing user belongs.

The following issues were addressed:

• Creating a PortletContext with incomplete portal specific HTTP headers (CSP) causes an exception to be thrown when the PT-User-ID field is absent or does not contain a numeric value. It is impossible to create this scenario with the portal. However, the situation will arise when using the Plumtree Service Station if PT-User-ID is not explicitly included in the CSP headers. (Issue #43891)

• The file xerces144.jar is not loaded correctly by the BEA WebLogic 6.1 SP2 or 7.0 SP1 classloader. The EDK was built against xerces.jar v1.4.4, which is not the default XML parser that ships with BEA WebLogic 6.1 SP2/7.0 SP1. If xerces144.jar is placed in the WEB-INF\lib directory of a Web application, BEA WebLogic 6.1 SP2/7.0 SP1 will ignore xerces144.jar and attempt to use its default XML parser, which prevents the EDK from functioning normally. (Issue #17399)
  Workaround:
  Insert the path to the file xerces144.jar at the beginning of the classpath in the WebLogic 6.1 SP2/7.0 SP1 startup scripts. If you have already installed WebLogic as an NT service, you will need to uninstall the service, modify the classpath in the installNTService.cmd file, and reinstall the service. (Issue #17399)
• BEA WebLogic 6.1 SP2 does not load all classes correctly. Note that this version of BEA WebLogic is no longer supported. This is a BEA WebLogic 6.1 SP2 issue; it does not load the classes in the file commons-logging.jar correctly. If this is placed in the WEB_INF\lib directory of a Web application on WebLogic 6.1 SP2, a StringIndexOutOfBoundsException is thrown upon starting the Web application. (Related issues #15943, #15428)
  Workaround:
  Open the commons-logging.jar file with Winzip or another utility and delete the Manifest.mf file. (Issue #22841)
• When using the EDK in IBM WebSphere 4.0.x, activation.jar from the EDK distribution should not be deployed because it conflicts with the activation.jar from WebSphere. Note that WebSphere 4.0.x is no longer supported. (Issue #27106)

• servlet.jar 2.2 or 2.3 must be in the CLASSPATH. When running within a Java web application server, servlet.jar is usually provided to the application. When running as a stand-alone application, servlet.jar must be added explicitly. (Issue #37348)
• Multiple endpoints for AWS/PWS/CWS/SWS/SCI are no longer supported in Java and have never been supported in .NET.
  Workaround
  Prior to version 5.2.0, it was possible to define endpoints in Java by declaring multiple bindings/ports in server-config.wsdd. For instance, multiple CWS endpoints ContainerProviderSoapPort1 and ContainerProviderSoapPort2 could be mapped to different implementations of IContainerProvider. Though it is still possible to use an old server-config.wsdd to create multiple SOAP endpoints for an IWS, this is no longer supported. (Related issue# 42816) (Issue #43508)

• .NET SOAP connections could be closed due to one of the following errors: "System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive." or "The underlying connection was closed. An unexpected error occurred on send."
  Workaround:
  There is a bug in the Microsoft .NET framework that causes random connection failures. See http://support.microsoft.com/default.aspx?scid=kb;EN-US;819450 (Issue #36786)
• The normal .NET EDK assemblies are not strongly named and cannot be referenced from strongly named assemblies.
  Workaround:
  Reference the signed .NET EDK instead. (Issue #37347)
• Building against the .NET EDK causes the warning "dependency could not be found," for the assembly: Microsoft.Web.Services2. As the requirements indicate, this assembly from Microsoft Web Services Enhancements is only needed by PRC Collaboration for Document Upload and the warning can be ignored if this part of the EDK API is unused. (Issue #37773)
• When uploading large files (> 4MB) in .NET using PRC Collaboration, PRC Content, or when using a slow connection, you may need to add settings to your Web.config or machine.config. The .NET EDK has a configuration snippet in app.config that shows the maxRequestLength and executionTimeout parameters. When added to the appropriate section of your Web.config, they can circumvent ASP.NET timeouts and allow large file uploads. You may also need to increase the responseDeadlockInterval attribute in the machine.config of your Microsoft.NET Framework directory.
  The following are the settings that can be added to Web.config or .exe.config:
  

  <configuration>
   <!-- Must configure section handler for microsoft.web.services section -->
   <configSections>
   <section 
   name="microsoft.web.services2" 
   type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration,Microsoft.Web.Services2,Version=2.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" />
   </configSections>
   <microsoft.web.services2>
   <messaging>
   <!-- The maximum file upload size supported by ASP.NET. The size specified is in Kilobytes. 
   A value of -1 means there is no limit. The default is 4096 KB (4 MB). -->
   <maxRequestLength>-1</maxRequestLength>
   <!-- The maximum number of seconds that a request is allowed to execute before 
   being automatically shut down by ASP.NET. A value of -1 means 
   there is no limit. The default is 90 seconds. --> 
   <executionTimeout value="-1" />
   </messaging>
   </microsoft.web.services2>
  </configuration>
  
  

  (Issue #43255)

• The following general information pertains to the signed EDK:
  • The strongly named .NET EDK assemblies include all assemblies in dotnet_signed\bin. The EDK itself is in Plumtree.EDK_signed.dll. All EDK signed assemblies be used together and none should be mixed with the original .NET EDK assemblies.
  • To use the signed .NET EDK, existing applications bound to the original .NET EDK must be recompiled against the signed assemblies.
  • Using the signed .NET EDK in integration web services such as a crawler (CWS) requires that new asmx files from dotnet_signed be used to reflect the new assembly names.
  • Deploying applications which use the strongly named .NET EDK from Microsoft's Global Assembly Cache (GAC) requires all EDK signed assemblies to be installed in the GAC.
  • The signed .NET EDK allows partially trusted callers (AllowPartiallyTrustedCallers).
  • For information on installing strongly named assemblies into the GAC, refer to Microsoft's documentation
  (Issue #38993)
• .NET applications using the signed (strongly named) EDK must be rebuilt when upgrading to a newer version of the EDK if the major or minor version have changed, for example 5.1.0.0 to 5.2.0.0. Refer to Microsoft's .NET versioning policy for more information. (Issue #43855)
• Granting any <trust> level below Full could potentially cause the .NET EDK to throw the following error: System.Security.SecurityException: Request for the permission of type System.Security.Permissions.EnvironmentPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed. ... at com.plumtree.openfoundation.util.XPDateTime
  Workaround
  Normal EDK operation does not exhibit this behavior. Only grant the <trust> level Full if your application encounters this error or if it is required for another reason. The strongly named .NET EDK allows partially trusted callers (AllowPartiallyTrustedCallers). For information on partially trusted callers see Microsoft's documentation of AllowPartiallyTrustedCallers. (Issue #44020)

• Content Server throws a ContentException when attempting to publish a content item with a long name or path.
  Workaround
  Content Server imposes a limit on the length of file paths to published and previewed content items. This is file system and thus OS dependent, though a 255 character limit is common. The file path length is determined by the path to the published content directory, e.g. C:\Plumtree\ptcs\publishedcontent, combined with the full Content Server path to the item including folder and subfolder names. A Content Item nested deep within a folder hierarchy may encounter this problem. Shortening the folder hierarchy or names of folders or content items can prevent the error. (Issue #41597)
• It is possible to publish a content item whose Presentation Template contains invalid pcs tags that fail IPresentationTemplateManager.validateTemplateText. (Content Server issue# 41714) (Issue #43190)
• Attaching a Presentation Template to a Data Entry Template, then storing the Data Entry Template, does not update the client state of the Presentation Template. This means that IPresentationTemplate.isPublishable, getPublishURL, and other methods are no longer accurate in the client copy of the Presentation Template. This is a limitation of the API design and will not be fixed. (Issue #43230)
• A ContentException could be thrown if the WS Content internal Content Server session times out before the portal login token.
  Workaround
  If the Content Server session in the WS Content times out (the default is 24 hours) before the portal login token used by the IRemoteSession, then the PRC Content will return an error. When using the default values for portal login token time-out and Content Server session time-out, this problem will never occur. However, this can occur if the Content Server session timeout is shorter than the portal login token timeout. Simply refreshing the portal login token and creating a new IRemoteSession will refresh the Content Server session and resolve the issue. (Issue #43646)
• Security is not checked properly for IFolderManager.getFolderByUUID and any user can retrieve any folder. The same security bug exists for getDataEntryTemplateByUUID, getPresentationTemplateByUUID and getSelectionListByUUID. (Content Server Issue# 43841, 44000) (Issue #43874)
• IFolderManager.getFolderByPath throws a CSObjectNotFoundException when a user does not have access to the folder. It should throw CSSecurityException. This mismatch of exceptions also occurs for operations such as remove, move, and expire. (Content Server issue# 43693, 44003, 44006, 44007) (Issue #43950)
• IFolderManager.getFolderByPath throws an ArrayIndexOutOfBoundsException when it is called with the root folder path ('/').
  Workaround
  Use IFolderManager.getRootFolder to retrieve the root folder. (Content Server issue# 43840) (Issue #43952)
• Publishable presentation templates are not searchable. Despite the documentation's claim that publishable presentation templates with associated portlet IDs at publish time are searchable, they are not. There is no workaround for this issue. (Issue #44390)

• Rapid creation and removal of Collaboration Server objects causes a NullPointerException from the Collaboration Server when search indexing is enabled.
  Workaround:
  Search is attempting to index Collaboration Server objects that have already been removed. If rapid creation and removal of Collaboration Server objects is required, the search indexing can be disabled by editing Collaboration Server's ptcollab\4.0\settings\config\config.xml. In the section labeled "Search settings" set search enabled="no". WARNING: Disabling search indexing of Collaboration Server objects is not recommended and issues caused by this setting are not supported. (Issue #35222)
• Methods that take a long time to complete can cause SOAP timeouts which will be thrown as exceptions in the EDK. Copy operations continue to be processed by the Collaboration Server, while upload operations are aborted. This will be addressed in a future release. The following methods are known to cause SOAP time-outs depending on network conditions or size of the affected Collaboration Server object structure: IProjectManager.copyProjectContent, ITaskListManager.copyTaskLists, IDocumentManager.copyToFolder, IDocumentManager.checkInDocument, IDocumentManager.insertNewDocument (Issue #35300)
• If a copy operation has not completed after 10 minutes, it is aborted. This is not a bug and will not be fixed. This affects: IProjectManager.copyProjectContent, ITaskListManager.copyTaskLists, IDocumentManager.copyToFolder (Issue #37034)
• For all QueryOrders, the setAscending and isAscending methods do not function.
  Workaround
  Use the QueryOrder constructors' ascending parameter to specify if the results should be ascending or descending. (Issue #37256)
• PRC Collaboration calls result in an exception: Call into WS Portal to authorize login token SOME_LOGIN_TOKEN= failed. Details: java.lang.NullPointerException
  Workaround
  Either Collaboration Server 4.0.2 must be installed or, if using 4.0.1, the 4.0.1.157486 Hotfix must be applied to the Collaboration Server itself (not the EDK client). In Collaboration Server 4.0.1, portal users that do not have read access to the administrative folder in which they reside cannot make PRC Collaboration method calls. A workaround that does not require the hotfix is to grant all users read access to the folder in which they reside. (Issue #44016)

• Users with read-only access to a document folder can create a Web link document. Using IDocumentManager.createWebLinkDocument, a user with insufficient permissions can create a Web link document. (Issue #22513)
• It is not possible to query ACLs on portal document folders. (Related issue #26257) (Issue #26256)
• Querying objects using ObjectClass.Community does not function as expected. When performing object queries using ObjectClass.Community, the community objects reside in their own administrative folder and not the folder in which they visually appear in the portal. This is due to the internal storage of communities in the portal and will not change. (Issue #37349)
• MyPages queries for non-administrator users do not work as expected.
• Addition of setRefreshRate, setExpirationDate, and setDeleteBrokenLinks methods do not work as expected. (Issue # 36206)

• Dates in the search server are only accurate to within four minutes. Using Operator.Equals on Date fields is discouraged. (Related issue #26926)
  Workaround:
  Using GreaterThan/LessThan or a date range is the recommended usage. (Issue #26927)
• Types of search exceptions, which are thrown when executing an IPortalSearchRequest with invalid parameter values, are mismatched between Java and .NET EDK. When calling execute() after some methods of IPortalSearchRequest were called with invalid values, for example, an empty IFilterClause or non-existent fields, the .NET EDK throws a different exception than the Java EDK. (Issue #27160)
• Portal properties of type double are truncated to floats in the search server. Using Operator.Equals on float fields is discouraged. (Related issue #26929)
  Workaround:
  Using a float range is the recommended usage. (Issue #32270)

• Setting Japanese administrative preference values can result in data corruption on BEA WebLogic 6.1 SP2. Note that this version of WebLogic is no longer supported. If a long string of Japanese administrative preference values are set through the portlet API, the values can become corrupted when the EDK is running on BEA WebLogic 6.1 SP2.
  Workaround:
  If administrative preference values are in Japanese, limit the allowable length of the preference values. (Issue #13769)
• The maximum http header size enforced by a Web application server could truncate a portlet's essential http header (CSP) information.
  Workaround:
  Increase the Web application server's maximum header size. (Issue #32446)
• Encrypted portlet preferences and EDK portlets via SSL require Java: JCE classes in JDK 1.3 and below. The remote server must have the JCE classes installed and configured properly.
  Workaround:
  Download the Java Cryptography Extensions (JCE) classes from Sun (java.sun.com) and see the Sun documentation for configuration details. The JCE classes are included in JDK version 1.4 and above. IBM WebSphere contains JCE libraries; see the IBM WebSphere documentation for details on configuring JCE with WebSphere. (Issue #37355)

• Folder metadata is not loaded during a crawl. The method IContainer.getMetaData() is not called during a crawl, and thus folder metadata is not loaded. Folder metadata is visible through the Edit view of the Knowledge Directory. This is a known limitation of the Portal Crawl Provider and is unlikely to change.
  Workaround:
  Add folder metadata by editing each folder in the directory. (Issue #21434)
• .NET Crawlers operating in DocFetch mode must use Document Literal SOAP encoding which can be set in the Crawler Web Service editor. This is a known limitation and will not be fixed. (Issue #29127)
• Crawler (CWS) DocFetch in IIS6 (Windows 2003) needs to be granted special access permissions or it will throw System.UnauthorizedAccessException during a crawl.
  Workaround:
  Find the user or group for anonymous access for the Web Site in IIS Services Manager (Properties- Directory Security- Authentication and Access Control-Edit) - this is usually IIS_WPG. Assign this user/group write privileges to the root directory of the crawler Web site, or the directory that has been assigned as the root directory in DocFetch. (On the folder using Windows Explorer, open Properties, Security, add IIS_WPG). The same user/group (IIS_WPG) must have been explicitly granted read access to the documents that will be retrieved by the DocFetch Crawl. (Issue #36204)
• Crawler DocFetch uses the PRC to decode portal settings, causing '+' to be changed to a space. Encrypted text or Asian character sets could be corrupted by this behavior.
  Workaround:
  Encode any settings that could be decoded via the PRC. Use com.plumtree.remote.util.CSPCodec to perform the setting's encoding before the portal stores the setting, such as in com.plumtree.remote.sci.IAdminEditor.finalize(). Note that the portal performs XML encoding of settings only for values entered in an editor, and does not encode settings that are hidden or otherwise stored directly in the portal. (Related issue #27099) (Issue #37155)

• The portal does not send the number of records to return as set by the Results Per Page parameter in the Portal Search Preferences Page. The portal will return varying values when ISearchQuery.GetMaxReturn() is called based upon the number of concurrent searches requested. (Issue #20551)
• A period ('.') cannot be used when setting the gateway URL prefix for a Search Web Service. Although a period can be used when setting the Gateway URL Prefix for other Web Service objects, this will fail for Search Web Services.
  Workaround:
  Use absolute URLs when setting the gateway URL prefixes on Search Web Services. (Issue #20607)

Logging does not function on Windows machines with multiple network adapters running Windows versions below XP SP2 or 2003 SP1.
Workaround
Upgrade to Windows XP SP2, Windows 2003 SP1 or better, or disable the additional network adapters. (Issue #42420)

• The EDK functions with Plumtree Portal 4.5WS for the AWS, CWS, SCI, and (limited) Portlet API. A UDDI server and SCI implementation that provides additional information to the portal is required to use EDK with 4.5WS. For information, search BEA's Developer Center for "EDK Portal 4.5WS". (Issue #37358)

• The EDK will implement a shutdown() method for AWS post version 5.3.0. There might be an exception thrown by the 6.0 portal for this method not being implemented by the EDK. This exception can be ignored. (Issue # 46026)