Table 5 Known Limitations and Workarounds for Content Management and Search
|
|
|
|
|
Using a CM IPagedList or ICMPagedResult across multiple requests in conjunction with a dynamic security role
When a Content Management collection (PagedList or PagedResult) is used across multiple requests, and a security role based on request attributes is used to restrict access to the collection contents, the contents are not filtered according to the current per-request request attributes. Instead, the contents are filtered based on the initial request attributes.
Workaround: Create a new Content Management collection for each request.
|
|
|
IDOL Server does not successfully delete an entry from the index when the file is removed from a directory scanned by FileSystemFetch.
Even though FileSystemFetch is configured to delete content from IDOL when an item is removed from the file system, the file is not properly removed from the IDOL Server index.
Workaround: Edit the FileSystemFetch configuration file (FileSystemFetch.cfg):
- To the [Default] section add 'QueryPort=9022' (change the port number to match the QueryPort defined in AutonomyIDOLServer.cfg).
- Do not use relative paths in the
DirectoryPathCSVs entry in your Import job definitions. Only use fully qualified path entries.
|
|
|
Error occurs when a content selector query tries to retrieve a deleted node
If a content selector query tries to execute a query which includes a node that has been deleted AFTER the query results are cached, the user will likely get an error message on the console saying Node Not Found.
Workaround: The only way to fix this problem is to clear the search cache.
|
|
|
It is now possible to distinguish null or empty values from values containing "_" in Autonomy
This release no longer uses "_" to distinguish null or empty values, it uses "_WLP_CM_NO_VALUE_". This fixes an issue in which application property values of "_" were incorrectly considered as having no value.
Workaround: Users must re-index their content to take advantage of this feature. Until content is re-indexed, queries created via IMetadataQuery.buildIsNull and IMetadataQuery.buildIsNotNull will return incorrect results.
|
|
|
Metadata search returns incorrect results for '' or NULL queries in some
In Oracle, the blank character is considered the same as NULL, which means that customers will not be able to differentiate between them if they are using Oracle. However other databases do make that differentiation correctly. In 8.1 all instances of '' were converted to null for every database. BEA has changed that in 9.2 where WebLogic Portal does make that conversion, but it is left up to the database to decide whether that will work or not.
|
|
|
Size of binary node in BEA Content Repository depends on length of timeout set on the system
When adding a binary node to the BEA Content Repository, the maximum supported binary size will depend on the transaction timeout set on the server. The default is 30 seconds but should be set higher if binary sizes larger than 20MB (although this size will depend on many factors including: database vendor, type of binary, speed of machine, OS, etc.) will be used.
Workaround: Set the system timeout to a value larger than 30 seconds.
|
|
|
Shift JIS characters do not get indexed by Autonomy for certain file formats
Shift JIS characters that are used in PDF files (.pdf), Word files (.doc), or Excel files(.xls) do not get indexed at all in Autonomy. This means that if you have any files of those formats in a directory that is to be indexed by the FileSystemFetch utility provided by Autonomy, and those files contain Shift JIS characters, those characters will not be indexed.
This will cause any searches performed by the Enterprise Search portlet to not find any of those files if they contain the Shift JIS charters that were searched on.
Workaround: Any documents that are of the format type in question (.pdf, .doc, and .xls) need to be converted to a .txt or .xml file (which do get indexed correctly).
|
|
|
Any files that have Shift JIS characters in the file name will not be
If a file name contains any Shift JIS characters, Autonomy will not index them. This means that if a file with Shift JIS characters in the file name are placed in a directory to be indexed by the FileSystemFetch utility, it will not be index by Autonomy. Therefore, that file not be returned within the search results provided by the Enterprise Search portlet.
Workaround: Rename any files that contain Shift JIS characters to a name that does not contain Shift JIS characters.
|
|
|
Any files that have Shift JIS characters in the file name will not be downloaded due to Autonomy validation.
If a file name contains Shift JIS characters, Autonomy will not be able to validate them. This means that if a file with Shift JIS characters in the file name are placed in a directory to be indexed by the FileSystemFetch utility, they may be found by doing a search. If this happens and the user tries to download them, they will get an error saying Autonomy was unable to validate them.
Workaround: The Autonomy validation can be turned off by adding the following to your web.xml file:
<context-param> <param-name>com.bea.apps.groupspace.search.enterprise.AutonomyValidationBeforeDownload</param-name> <param-value>false</param-value> </context-param>
This, however, will introduce a security hole as users can spoof the download URL to download files that exist on the server as Autonomy will not be validating the files once this is turned off.
|
|
|
When searching for a GroupSpace element that has multibyte characters
in the name, if the encoding for GS enterprise search is configured other
than default, the search results may not be returned.
If a GroupSpace element is created and has a name consisting of multibyte characters, you can do a search by the title of the element and receive correct results. However, if you configure the encoding for GS enterprise search other than default, the search results may not be returned.
|
|
|
Repository Configuration settings for using CM Full Text Search
WLP 10,x CM full text search only connects to Autonomy during startup if the repository configuration has both of the following settings: fulltext-search-is-enabled=TRUE and search-indexing-is-enabled=TRUE In WLP 9.x, the associated settings were: search-is-enabled=TRUE and search-indexing-is-enabled=TRUE This more accurately reflects the case in which CM full text search is being used for a repository. Since a WLP 9.x full text search application requires search-indexing-is-enabled=TRUE in order to use CM full text search indexing, this setting should already apply.
Workaround: Verify the repo config and update it if necessary.
|
|
|
Using CM Full Text search on Windows 2000 requires pskill to be installed and available in the PATH
On a Windows 2000 host, Content Management Full Text Search requires the pskill utility to be installed and available in the PATH. This is used on a development host to properly shut down the Full-Text Search processes when the domain is shut down. The pskill utility can be found at: http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/PsKill.mspx After installing it, run the pskill command once to accept the license. Make sure it exists on your system PATH, and then restart the server. The scripts can now properly shut down the Full Text Search processes.
Platform: Windows 2000 only.
Workaround: Manually kill the Full Text Search processes.
|
|
|
Renaming nodes in a library services-enabled repository can cause the version name to become out of sync with the node’s name
When library services are enabled, nodes should not be renamed. This can cause incorrect search results to be returned.
|
|
|
CM metadata search using PointBase database and containsall operator can fail
With PointBase, CM metadata searches using the containsall operator, such as color containsall('red','blue') may result in a javax.transaction.HeuristicMixedException wrapping a connection failure java.io.EOFException, due to an underlying PointBase issue.
Platform: Any using PointBase.
Workaround: Use another database, or run multiple 'contains' queries, one per value, and combine results in-memory to produce the same behavior as the 'containsall' operator.
|
|
|
Non-UTF8 Japanese Multibyte character search keywords in Content Management Full Text Search may not return expected results
In full text search in WebLogic Portal Administration Console > Content Management > Search Repository tab, the multibyte search keyword works properly for the Japanese language when using the Japanese UTF-8 encoding. Searches using other Japanese language encodings, such as Shift_JIS or EUC-JP, may not return expected results.
Workaround: Search using Japanese UTF-8.
|
|
|
Intermittent Full Text Search Content Indexing Issue with MySql Server DB
With MySql DB, there is a potential for an intermittent race condition when indexing a node that has been moved or copied. To solve this issue, the ContentExportListerner needs to be changed from asynchronous to synchronous.
Platform: MySQLServer database
Workaround: Use the Administration Console to change the listener registration from asynchronous to synchronous. You can also create a deployment plan; see the following WebLogic Server document: Configuring Applications for Production Deployment.
|
|
|
Sybase does not return any rows (or an error) with a LIKE value >254 characters
Content Management Large String Queries may return incorrect results with Sybase. When using a BEA Repository against a Sybase database, string queries using the CM LIKE operator may incorrectly return 0 rows, if the LIKE operator value has more than 254 characters. For example, a query of the form "svStringType like '*<bigstring>*'" may return no results if <bigstring> contains more than 254 characters. This may prevent Content Management queries from returning accurate results.
Platform: All using Sybase database
Workaround: Avoid LIKE queries with a values larger than 254 characters.
|
|
|
CM FileSystemRepository does not support Workflow transitions using Bulkloader tool
When a managed filesystem repository is used with a bulkloader it throws an error when a node is uploaded with the workflowStatus=4 [published], even though the workflow associated with the node would support that transition. File truncation is possible when this issue occurs.
Workaround: If using a managed filesystem repository, users should not try to publish the content directly when using bulkloader to load contents from a filesystem. Workflow transitions should be execute after bulkloading is complete.
|
|
|
Binary content without a specified character set may fail to render in the Portal Administration Console or using the Content Presenter portlet
If a content node with a binary property is created via the admin tools or the bulkloader tool and that property does not specify a character set with the content type or mime type definition, then that content could fail to render using the content presenter portlet or fail to open in the portal admin tools WYSIWYG editor.
Workaround: Specify a character set with the content type for content node binary properties. For html and UTF-8 characters, use the following form: "text/html;charset=UTF-8". If using the bulkloader, this could be accomplished using the property "encoding" in the corresponding md.properties file for the content. The property should be added to the md.properties file in the form: "encoding=UTF-8" where UTF-8 is the correct character set for the content.
|
|
|
WebLogic Portal does not support using Content Presenter in WSRP
Content Presenter and its portlet instances can not currently be used as WSRP producers in WebLogic Portal 10.0. and 10.0.x.
Workaround: To access Content Presenter instances remotely, use Portlet Publishing.
|
