AquaLogic Interaction Development Kit (IDK) 6.0 - re-released January 2008 with signed dlls (originally released June 2007 for AquaLogic Ensemble 1.0 compatibility)

AquaLogic Interaction Development Kit (IDK) 5.4 - released January 2007 for Java 5.0 compatibility

AquaLogic Interaction Development Kit (IDK) 5.3 - released October 2006 for AquaLogic Interaction 6.1 compatibility

Enterprise Web Development Kit (EDK) 5.3 - released December 2005 for AIX, Solaris and SUSE Linux

Enterprise Web Development Kit (EDK) 5.3 - released September 2005 for Windows and Red Hat Linux

The AquaLogic Interaction Development Kit (IDK) is used to build custom applications as part of an AquaLogic Interaction architecture. The IDK supports a variety of development tasks including:

• Custom pagelets using the new proxy API, which supports AquaLogic Ensemble 1.0 for all portlet API development scenarios.
• Custom portlets using the portlet API.
• Applications using the SOAP based APIs to access Portal, Collaboration and Publisher servers.
• Integration web services (IWS) that integrate custom authentication, user profile, crawler, and search services into AquaLogic Interaction.

The IDK supports these development scenarios in both Java and .NET by providing JARs and assemblies that can be added to a development project.

These release notes cover AquaLogic Interaction Development Kit version 6.0. Note: The IDK was previously known as the Plumtree Enterprise Web Development Kit (EDK).

Release notes are occasionally updated after the release date. For the most recent release notes, visit http://download.oracle.com/docs/cd/E13174_01/alui/idk/docs60.

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, AquaLogic Interaction Development Kit 6.0 supports the following:

• Operating Systems: Windows 2000 Server SP4, Windows Server 2003 SP1 (or R2) and SP2, Solaris 8, 9, 10 (SPARC), AIX 5.3 (Power 3, Power 4, Power 5), Linux RHEL 3.0-3, 3.0-4, 4 Update 3 (x86), SUSE Linux ES 9, HP-UX 11i V2 (Itanium)
• 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
  • IIS 6.0 / .NET 2.0
    
• Remote Web Application servers - Java:
  • Apache Tomcat 5.5 using JDK 1.4.2 or JDK 5.0
  • Apache Tomcat 5.0.28 using JDK 1.4.2 or JDK 5.0
  • BEA Weblogic 9.2 using the bundled JDK 5.0
  • BEA Weblogic 9.1 using the bundled JDK 5.0
  • BEA Weblogic 8.1 SP4 using the bundled JDK 1.4.2
  • WebSphere 6.0.1 using Java 1.4.2 (AIX only)
• Runtimes:
  • .NET Framework version 1.1.4322
    • IDK .NET PRC Collaboration and PRC Content (Publisher) APIs also require .NET Web Services Enhancements 2.0SP3 to use document upload
  • .NET Framework version 2.0.50727
  • JDK version 1.4.2
  • JDK version 5.0

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

At the time of release, AquaLogic Interaction Development Kit 6.0 supports the following:

• AquaLogic Interaction (ALI) 6.1 MP1 and later, 6.1, 6.0, 6.0 SP1
• AquaLogic Ensemble 1.0
• AquaLogic Interaction Collaboration: 4.2 MP1, 4.2, 4.1 SP1
• AquaLogic Interaction Publisher: 6.4, 6.3, 6.2

The following product documentation is available here: http://download.oracle.com/docs/cd/E13174_01/alui/idk/docs60.

Note: Additional documentation including tutorials and developer guides are available online on the AquaLogic User Interaction Developer Center on BEA dev2dev.

The AquaLogic Interaction Development Kit 6.0 provides the following new features:

• The IDK supports AquaLogic Ensemble 1.0 for all portlet API development scenarios.

The following issues were addressed:

• The IDK dlls are strongly named and can be referenced from strongly named assemblies. If you are using the signed dll version of the IDK, the file Plumtree.openlog-framework_signed.dll must be placed in the bin directory, and the following dlls should be deployed in the GAC: Plumtree.EDK_signed.dll, OpenFoundation_signed.dll, Plumtree.openkernel_signed.dll, Plumtree.pmb_signed.dll and Plumtree.RAT_signed.dll. (Issue #37347, #51086, #56966, #56987, #57042)
  

• When using the IDK from a standalone Java application, the Servlet API JAR version 2.2, 2.3, or 2.4 must be explicitly added to the classpath. (Issue #37348)

• The settings configuration file described in the KB article titled "IDK Proxy Settings Configuration File (IDK 6.0)" is released in Beta in IDK 6.0 and is not yet supported. This feature may be replaced or removed in a future release.

• 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. (Issue #43508)

• The IDK requires WSE 2.0 SP3. Building against the .NET IDK 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 IDK API is unused. (Issue #37773)
• .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)
• When uploading large files (>4MB) in .NET using PRC Collaboration, PRC Content, or when using a slow connection, you might need to add settings to your Web.config or machine.config. The .NET IDK 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)

• Publisher (Content Server) throws a ContentException when attempting to publish a content item with a long name or path.
  Workaround
  Publisher (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:\bea\alui\ptcs\publishedcontent, combined with the full Publisher 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)
• A ContentException could be thrown if the WS Content internal Publisher (Content Server) session times out before the portal login token.
  Workaround
  If the Publisher (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 Publisher session time-out, this problem will never occur. However, this can occur if the Publisher session timeout is shorter than the portal login token timeout. Simply refreshing the portal login token and creating a new IRemoteSession will refresh the Publisher session and resolve the issue. (Issue #43646)
• IFolderManager.getFolderByPath throws an ArrayIndexOutOfBoundsException when it is called with the root folder path ('/').
  Workaround
  Use IFolderManager.getRootFolder to retrieve the root folder. (Publisher issue# 43840) (Issue #43952)
• Publishable presentation templates are not searchable. (Issue #44390)

• Rapid creation and removal of Collaboration objects causes a NullPointerException from Collaboration when search indexing is enabled.
  Workaround:
  Search is attempting to index Collaboration objects that have already been removed. If rapid creation and removal of Collaboration objects is required, the search indexing can be disabled by editing Collaboration's ptcollab\4.0\settings\config\config.xml. In the section labeled "Search settings" set search enabled="no".
  WARNING: Disabling search indexing of Collaboration 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 IDK. Copy operations continue to be processed by Collaboration, 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 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)
• 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 4.0.2 must be installed or, if using 4.0.1, the 4.0.1.157486 Hotfix must be applied to Collaboration itself (not the IDK client). In Collaboration 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)

• It is not possible to query ACLs on portal document folders. (Issue #26256) (Related issue #26257)
• 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.
• IDK does not return the localized name for portal objects (e.g., Knowledge Directory folder object) based on portal’s current localized language setting.  Users must use ObjectProperty.Name to explicitly specify language setting in order to get its corresponding localized name. (Issue #59058)

• 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 that are thrown when executing an IPortalSearchRequest with invalid parameter values are mismatched between the Java and .NET IDKs. When calling execute() after some methods of IPortalSearchRequest were called with invalid values, for example, an empty IFilterClause or non-existent fields, the .NET IDK throws a different exception than the Java IDK. (Issue #27160)
• Portal properties of type double are truncated to floats in the search server. Using Operator.Equals on float fields is discouraged.
  Workaround:
  Using a float range is the recommended usage. (Issue #32270) (Related issue #26929)

• 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)

• 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)

• 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)

• 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)