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 development of:

• 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 signed / unsigned assemblies that can be added to a development project.

These release notes cover AquaLogic Interaction Development Kit version 5.4. 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://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, AquaLogic Interaction Development Kit 5.4 supports the following:

• Operating Systems: Windows 2003 Server SP1, Windows 2000 Server SP4, Solaris 8, 9, and 10 (on SPARC), Red Hat Enterprise Linux 3.0-3 (x86), SUSE Linux ES 9, AIX 5.3 (Power 3, Power 4, Power 5)
• 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.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
• Microsoft Internet Explorer 5.5 and 6.0, Netscape 7.2, Safari 1.2 and 2.0.1 (Mac only), and Firefox 1.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 5.4 supports the following:

• AquaLogic Interaction 6.1 and later, 6.0, 6.0 SP1, 5.0.4, 5.0.4J
  • Portal 4.5WS is supported for AWS/PWS/CWS/Portlet via UDDI
• Collaboration: 4.0.2, 4.1.0, 4.2.0 (required to use PRC Collaboration API)
• Publisher: 6.1.0, 6.2.0, 6.3 (required to use PRC Content API)

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

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 5.4 provides the following new features:

• The IDK supports Java 5.0 for all development scenarios including the Portlet API and PRC.

The following issues were addressed:

• None.

• None.

• Publisher 6.3 server-side file leak.  Using IDK to download files from Publisher 6.3 will cause an Axis temporary file not being removed. (Issue #55232)

• 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)
• 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) (Related issue #42816)

• 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)
• The normal .NET IDK assemblies are not strongly named and cannot be referenced from strongly named assemblies.
  Workaround:
  Reference the signed .NET IDK instead. (Issue #37347)
• 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)

• The following general information pertains to the signed IDK:
  • The strongly named .NET IDK assemblies include all assemblies in dotnet_signed\bin. The IDK itself is in Plumtree.EDK_signed.dll. All IDK signed assemblies be used together and none should be mixed with the original .NET IDK assemblies.
  • To use the signed .NET IDK, existing applications bound to the original .NET IDK must be recompiled against the signed assemblies.
  • Using the signed .NET IDK 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 that use the strongly named .NET IDK from Microsoft's Global Assembly Cache (GAC) requires all IDK signed assemblies to be installed in the GAC.
  • The signed .NET IDK 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) IDK must be rebuilt when upgrading to a newer version of the IDK 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 IDK 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 IDK 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 IDK allows partially trusted callers (AllowPartiallyTrustedCallers). For information on partially trusted callers see Microsoft's documentation of AllowPartiallyTrustedCallers. (Issue #44020)

• 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)
• It is possible to publish a content item whose presentation template contains invalid pcs tags that fail IPresentationTemplateManager.validateTemplateText. (Publisher 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 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)
• 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. (Publisher 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. (Publisher 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. (Publisher 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 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)
• 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 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)

• 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. (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.
• 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 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)
• Any DocFetch crawler in IIS6 (Windows 2003) must 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), 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 and 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)
• 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. (Issue #37155) (Related issue #27099)

• 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 IDK functions with ALUI 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 IDK with 4.5WS. For information, search BEA's Developer Center for "IDK Portal 4.5WS". (Issue #37358)