Documentum's Java Based software uses Log4j architecture to manager logging. The different levels of logging provided by log4j architecture are the following:
OFF - The OFF has the highest possible rank and is intended to turn off logging.
FATAL - The FATAL level designates very severe error events that will presumably lead the application to abort.
ERROR - The ERROR level designates error events that might still allow the application to continue running.
WARN - The WARN level designates potentially harmful situations.
INFO - The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
DEBUG - The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
ALL - The ALL has the lowest possible rank and is intended to turn on all logging.
Thursday, March 27, 2008
Friday, March 21, 2008
Wednesday, March 19, 2008
Thursday, March 13, 2008
UCF Related Threads
- Stuck threads in InitGAIRConnector UCF servlet:
- Customer wants the InitGAIRServlet to timeout after a configurable amount of time if it has not received a request from the application
- Users randomly get java.lang.NullPointerException and java.util.ConcurrentModificationException in Webtop
- Receiving java.lang.NullPointerException when trying to view a document under the following circumstances:
- User has READ permits to the latest version to a doc
- User has NONE permits to CURRENT version of doc
- User tries to view the latest version - Thread: Error while viewing document in webtop
- Thread: UCF and Firewall
- Thread: Operation failed : Failed to obtain UCF session
- Intermitten UCF error
- Webtop 5.3 SP6[5.3.0.613] Importing an XML document hangs and throws 'java.lang.IllegalStateException: Timed out requesting input'
- UcfSessionManager NonBlockingCleanup
- Client failed to handshake with server within 250 seconds.
- UCF Error
- UCFException when importing document: Failed to skip attachment stream
- UCF House Keeping
- Stuck Threads webtop/com/documentum/ucf/server/transport/impl/GAIRConne
- Logs to collect for UCF problems
- UCF Transport error
- Pre-installing UCF
- UCF runtime problem with failed to connect to server error
- UCF thows java.net.SocketException: Connection reset if passing through a load balancer or firewall
- Why do I get java.io.EOFException while doing UCF operation like viewing file
- UCF is not obeying the proxy configuration
- JRE requirements for UCF client deployment.
Wednesday, March 5, 2008
How can I turn off certificate validation on the client?
How can I turn off certificate validation on the client?
The following configuration works only for WDK-based application versions 5.3 SP2 and later.
Configuring non-server validation mode
In non-server validation mode,UCF will override the Java default implementation of Trust Manager to allow
UCF client to automatically trust certificates used for SSL authentication. Modify ucf.installer.config.xml, which is located in /wdk/contentXfer in your installed WDK application.. Add the following option within the <configuration> element:
<option name="https.host.validation" persistent="false">
<value>false</value>
</option>
Note, you can add the above following the line <option name="file.poll.interval" value="60" /> under <configuration> element:
This configuration will tell the browser client to not validate the SSL certificate on the client side. This can be useful for self-signed SSL certificates.
The following configuration works only for WDK-based application versions 5.3 SP2 and later.
Configuring non-server validation mode
In non-server validation mode,UCF will override the Java default implementation of Trust Manager to allow
UCF client to automatically trust certificates used for SSL authentication. Modify ucf.installer.config.xml, which is located in /wdk/contentXfer in your installed WDK application.. Add the following option within the <configuration> element:
<option name="https.host.validation" persistent="false">
<value>false</value>
</option>
Note, you can add the above following the line <option name="file.poll.interval" value="60" /> under <configuration> element:
This configuration will tell the browser client to not validate the SSL certificate on the client side. This can be useful for self-signed SSL certificates.
Performing a content transfer operation is generating the error "failed to skip attachment stream".
Symptoms:
Performing a content transfer operation results in the following exception for specific formats:
An error has occurred. invokeMethod()failed while calling:OnReturnFromProgress Operation failed:com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream
Cause:
UCF will compress content files during content transfer for all file types unless they have been explicitly excluded from compression. The above exception can be a sign that content decompression has encountered an error.
Resolution:
For the WDK-based web application, open the file\WEB-INF\classes\ucf.server.config.xml. Locate the
Performing a content transfer operation results in the following exception for specific formats:
An error has occurred. invokeMethod()failed while calling:OnReturnFromProgress Operation failed:com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream
Cause:
UCF will compress content files during content transfer for all file types unless they have been explicitly excluded from compression. The above exception can be a sign that content decompression has encountered an error.
Resolution:
For the WDK-based web application, open the file
Logs to collect for UCF problems
Symptoms:
UCF errors prevent users from running content transfer.
Cause:
UCF communication is a very complex process. Since it passes through multiple network devices, there are many reasons that may cause this process to fail. To determine what is the exact cause of the problem, a complete set of logs and the network traffic data is are necessary. Network traffic data reveals complete data and messages between the UCF client and the server, including the network devices that may inject additional data into the communication channel. That information is not revealed by the trace logs.
Resolution:
There are common solutions for the UCF problems: For example, removing the UCF folder in client workstation and cleaning the IE cache and disabling ACS in wdk/app.xml. But sometimes these steps could not fix the problem. The following logs are needed to provide to Engineering for troubleshooting:
On the App Server side:
Open file/WEB-INF/classes/ucf.server.config.xml, change the option "tracing.enabled" from false to true. The App server must be recycled during scheduled maintanence hours for this option to take effect.
On the client side:
- Close all browser windows.
- Open C:\Documents and Settings\\Documentum\ucf\\shared\config\ucf.client.config.xml, change the option "tracing.enabled" from false to true.
- Open C:\Documents and Settings\\Documentum\ucf\\shared\config\ucf.client.logging.properties, change the line ".level=WARNING" to ".level=ALL"
- Under C:\Documentum\Logs, remove files named ucf.*
- Launch a new browser instance.
- Log into Webtop.
- In the browser window, launch Java Console from its Tools menu, and in the console window press key 5.
- In browser window, press ctrl+N to open a new window.
- In the new browser window, access: http://host:port/webtop/wdk/tracing.jsp, and check the following options "HTTP_MANAGER", "UCF_MANAGER", "Tracing is enabled for current session".
- Launch Ethereal or Wireshart (network sniffer) and start to capture all the network traffic between this client workstation and the web server/app server.
- In the first browser window, reproduce the problem.
- Record the time the problem takes to be reproduced and see if there is any time difference between the client workstation's clock and the web server/app server machine's clock.
- Collect the log files under C:\Documentum\Logs
- Collect the traces in Java Console.
- Collect the network traffic data file generated by Ethereal/Wireshark.
Download from http://www.wireshark.org/download.html.
Put the filter as tcp port xxxx or host ipaddress to capture all the traffic.
On the Web Server/App server side:
- Collect the wdk.log* and trace.log* under $DOCUMENTUM_SHARED
- Collect the web server logs.
- Collect the app server logs.
UCF errors prevent users from running content transfer.
Cause:
UCF communication is a very complex process. Since it passes through multiple network devices, there are many reasons that may cause this process to fail. To determine what is the exact cause of the problem, a complete set of logs and the network traffic data is are necessary. Network traffic data reveals complete data and messages between the UCF client and the server, including the network devices that may inject additional data into the communication channel. That information is not revealed by the trace logs.
Resolution:
There are common solutions for the UCF problems: For example, removing the UCF folder in client workstation and cleaning the IE cache and disabling ACS in wdk/app.xml. But sometimes these steps could not fix the problem. The following logs are needed to provide to Engineering for troubleshooting:
On the App Server side:
Open file
On the client side:
- Close all browser windows.
- Open C:\Documents and Settings\
- Open C:\Documents and Settings\
- Under C:\Documentum\Logs, remove files named ucf.*
- Launch a new browser instance.
- Log into Webtop.
- In the browser window, launch Java Console from its Tools menu, and in the console window press key 5.
- In browser window, press ctrl+N to open a new window.
- In the new browser window, access: http://host:port/webtop/wdk/tracing.jsp, and check the following options "HTTP_MANAGER", "UCF_MANAGER", "Tracing is enabled for current session".
- Launch Ethereal or Wireshart (network sniffer) and start to capture all the network traffic between this client workstation and the web server/app server.
- In the first browser window, reproduce the problem.
- Record the time the problem takes to be reproduced and see if there is any time difference between the client workstation's clock and the web server/app server machine's clock.
- Collect the log files under C:\Documentum\Logs
- Collect the traces in Java Console.
- Collect the network traffic data file generated by Ethereal/Wireshark.
Download from http://www.wireshark.org/download.html.
Put the filter as tcp port xxxx or host ipaddress to capture all the traffic.
On the Web Server/App server side:
- Collect the wdk.log* and trace.log* under $DOCUMENTUM_SHARED
- Collect the web server logs.
- Collect the app server logs.
EMC Technical Support Policy regarding third party load balancer vs UCF
UCF-based content transfer activities (import, export, check in/out) breaks when a third party load balancer product is placed between the browser and the application server that hosts the WDK application. However, if the browser is used to connect to the application server directly, bypassing the load balancer, UCF activities go through without a problem.
Cause:
Incompatibility or misconfiguration of the third party load balancer causes UCF activities to fail.
Cause:
Incompatibility or misconfiguration of the third party load balancer causes UCF activities to fail.
Friday, February 29, 2008
When using the UCF Invoker for performance testing why do I see Check in / Check Out failures with UCF Registry Exception?
Symptoms:
Check in / Check Out Operations fail with Registry Exceptions like the one below:
[2006-03-06 11:20:59,388|ERROR|ExecuteThread: '199' for queue: 'weblogic.kernel.Default'|com.documentum.fc.common.DfLogger|error|60 ] Operation failed : com.documentum.ucf.common.contentregistry.RegistryException: An error occurred when performing operations on windows registry. Windows error code: "2"; error message: "The system cannot find the file specified.
"
com.documentum.web.contentxfer.ContentTransferException: com.documentum.ucf.common.contentregistry.RegistryException: An error occurred when performing operations on windows registry. Windows error code: "2"; error message: "The system cannot find the file specified.
"
at com.documentum.web.contentxfer.ucf.UcfContentTransport.postProcess(UcfContentTransport.java:106)
at com.documentum.web.contentxfer.ContentTransferService.execute(ContentTransferService.java:340)
Cause
Because all virtual users on a single load generator are sharing a single registry to record checkout and check-in data, it is possible that some users will collide as they try to update the registry simultaneously.
Resolution
Modify the registry.mode in the C:\Documents and Settings\
You can also modify globally via ucf.installer.config file located under wdk\contentXfer and set registry mode to file instead of windows.
After making above change restart the server and delete the UCF installation from the client.
How to enable combined dmcl and dfc trace?
1. Make sure that you have added the following lines to dfc.properties file found in the documentum/config directory.
#
# Specifies whether to enable or disable trace.
#
dfc.tracing.enabled = on
#
# Specifies whether to record the parameter information of methods, if any,
# while tracing.
#
dfc.tracing.recordParameters = on
#
# Specifies whether to record the return value of methods, if any, while tracing.
#
dfc.tracing.recordReturnValue = on
#
# Specifies whether to record timing information while tracing.
#
dfc.tracing.recordTiming = off
#
# Specifies whether to record thread information while tracing.
#
dfc.tracing.recordThreading = on
#
# Specifies whether to output multiple trace outputs on to a single line or not.
#
dfc.tracing.compactMode = on
#
# Specifies how many levels deep the method calls need to be traced.
# Valid values: 0 and above.
#
dfc.tracing.stackDepth = 100
#
# Specifies whether to combine the trace of dmcl along with other traces.
#
dfc.tracing.combineDMCL = on
2. Save the dfc properties file.
3. The DFC logs will be created within the documentum/logs directory. These will be fairly large!
4. Once you have collected the required log, disable the tracing again by setting dfc.tracing.enabled = false
and afterwards save the properties file.
#
# Specifies whether to enable or disable trace.
#
dfc.tracing.enabled = on
#
# Specifies whether to record the parameter information of methods, if any,
# while tracing.
#
dfc.tracing.recordParameters = on
#
# Specifies whether to record the return value of methods, if any, while tracing.
#
dfc.tracing.recordReturnValue = on
#
# Specifies whether to record timing information while tracing.
#
dfc.tracing.recordTiming = off
#
# Specifies whether to record thread information while tracing.
#
dfc.tracing.recordThreading = on
#
# Specifies whether to output multiple trace outputs on to a single line or not.
#
dfc.tracing.compactMode = on
#
# Specifies how many levels deep the method calls need to be traced.
# Valid values: 0 and above.
#
dfc.tracing.stackDepth = 100
#
# Specifies whether to combine the trace of dmcl along with other traces.
#
dfc.tracing.combineDMCL = on
2. Save the dfc properties file.
3. The DFC logs will be created within the documentum/logs directory. These will be fairly large!
4. Once you have collected the required log, disable the tracing again by setting dfc.tracing.enabled = false
and afterwards save the properties file.
Webtop gets stuck saying: "initializing plug-in".
When you try to open a document from Webtop, Webtop gets stuck saying: "initializing plug-in".
Cause : The browser that has the problem does not have the Java VM active.
Resolution :
In Internet Explorer 6 do: Tools => Internet Options => Advanced tab and scroll down to about the middle of the option list.
If Microsoft's JVM is installed, there will be a section in this list called "Microsoft VM". Make this active by checking it.
If a Sun JVM is installed, there will be a section in this list called "Java (Sun)". Make this active by checking it.
After you have made these changes, restart your browser and Webtop should work as expected.
Cause : The browser that has the problem does not have the Java VM active.
Resolution :
In Internet Explorer 6 do: Tools => Internet Options => Advanced tab and scroll down to about the middle of the option list.
If Microsoft's JVM is installed, there will be a section in this list called "Microsoft VM". Make this active by checking it.
If a Sun JVM is installed, there will be a section in this list called "Java (Sun)". Make this active by checking it.
After you have made these changes, restart your browser and Webtop should work as expected.
Friday, February 22, 2008
Why does loading the content transfer applet page cause WDK to hang?
The applets are not damaged, this is a known bug in IE when you upgrade to a new package on top of an old one results in a Damaged status display. See the Microsoft knowledge base article http://support.microsoft.com/support/kb/articles/Q243/0/40.ASP?LN=EN-US&SD=gn&FR=0&qry=damaged&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=JAV
What has actually happened is this client is attempting to view a different version of WDK then it previously viewed, and cannot update the applet.
So, to fix this, delete "Da Library" as well as "Documentum Content Transfer Applets" from the Downloaded Program Files folder.
Additionally, it might be necessary to delete any Documentum related cookies from the cookie folder.
Alternatively, update your 1.0.1 to 1.0.1a which addresses this problem.
What has actually happened is this client is attempting to view a different version of WDK then it previously viewed, and cannot update the applet.
So, to fix this, delete "Da Library" as well as "Documentum Content Transfer Applets" from the Downloaded Program Files folder.
Additionally, it might be necessary to delete any Documentum related cookies from the cookie folder.
Alternatively, update your 1.0.1 to 1.0.1a which addresses this problem.
Why does checkout fail generating a Java exception with WebTop/WDK ?
When performing a checkout/edit operation in WebTop/ WDK you may receive a java exception similar to the following :
com.documentum.web.contentxfer.applet.registry.RegKeyException:
Registry Error: com.ms.lang.RegKeyException: open error
com.ms.lang.RegKeyException: open error at
com/ms/lang/RegKey.pRegOpenKey (RegKey.java) at com/ms/lang/RegKey.(RegKey.java) at
com/documentum/web/contentxfer/applet/registry/RegistryWin32. at
com/documentum/web/contentxfer/applet/registry/ClientRegistry.getClientRegistryLocalMachineat
com/documentum/web/contentxfer/applet/ContentXferRegistryHelper.getCheckoutDirectoryat
com/documentum/web/contentxfer/applet/CheckoutApplet.addObjectsToRegistry at
com/documentum/web/contentxfer/applet/EditApplet.executeImplat
com/documentum/web/contentxfer/applet/MicrosoftExecutionMgr.execute at com/documentum/web/contentxfer/applet/SecureApplet.execute at
com/documentum/web/contentxfer/applet/SecureApplet.init at
com/ms/applet/AppletPanel.securedCall0 (AppletPanel.java) at
com/ms/applet/AppletPanel.securedCall (AppletPanel.java) at
com/ms/applet/AppletPanel.processSentEvent (AppletPanel.java) at
com/ms/applet/AppletPanel.processSentEvent (AppletPanel.java) at
com/ms/applet/AppletPanel.run (AppletPanel.java) at
java/lang/Thread.run (Thread.java)
This error is generated because the content transfer applets have tried to read a registry key that does not exist.
The solution is to manually create this missing registry key.
Launch Regedt32 and you need to create the following key :-
HKEY_Local_Machine/Software/Documentum/Common/CheckoutDirectory
The value for this key should point to the directory that you wish to use as the checkout directory for the content.
com.documentum.web.contentxfer.applet.registry.RegKeyException:
Registry Error: com.ms.lang.RegKeyException: open error
com.ms.lang.RegKeyException: open error at
com/ms/lang/RegKey.pRegOpenKey (RegKey.java) at com/ms/lang/RegKey.(RegKey.java) at
com/documentum/web/contentxfer/applet/registry/RegistryWin32. at
com/documentum/web/contentxfer/applet/registry/ClientRegistry.getClientRegistryLocalMachineat
com/documentum/web/contentxfer/applet/ContentXferRegistryHelper.getCheckoutDirectoryat
com/documentum/web/contentxfer/applet/CheckoutApplet.addObjectsToRegistry at
com/documentum/web/contentxfer/applet/EditApplet.executeImplat
com/documentum/web/contentxfer/applet/MicrosoftExecutionMgr.execute at com/documentum/web/contentxfer/applet/SecureApplet.execute at
com/documentum/web/contentxfer/applet/SecureApplet.init at
com/ms/applet/AppletPanel.securedCall0 (AppletPanel.java) at
com/ms/applet/AppletPanel.securedCall (AppletPanel.java) at
com/ms/applet/AppletPanel.processSentEvent (AppletPanel.java) at
com/ms/applet/AppletPanel.processSentEvent (AppletPanel.java) at
com/ms/applet/AppletPanel.run (AppletPanel.java) at
java/lang/Thread.run (Thread.java)
This error is generated because the content transfer applets have tried to read a registry key that does not exist.
The solution is to manually create this missing registry key.
Launch Regedt32 and you need to create the following key :-
HKEY_Local_Machine/Software/Documentum/Common/CheckoutDirectory
The value for this key should point to the directory that you wish to use as the checkout directory for the content.
How do you set the content transfer mode to http or ucf for WDK/Webtop 5.3?
In WDK and Webtop version 5.3 applications you have the option to choose which content transfer mode the application uses.
per the Documentum 5.3 System Migration Guide:
Specifying Which Content Transfer Mode Your Application Uses
You can choose to continue using the 5.2.x content transfer mechanism, or you can
specify that your application use the new UCF content transfer mechanism. To set the
application-wide content transfer mechanism and compression for content transfer
operations on the client, use the and . elements in
the WDK application configuration file, app.xml.
The element sets the content transfer mechanism for the
application. Valid values for this element are: http (pre-5.3 applications) or ucf
(5.3 applications). If one or more of your custom components extend pre-5.3 applet
components, specify ucf.
For information about the app.xml file, see the section named "Configuring an
Application," in the Web Development Kit and Client Applications Development Guide
For a detailed description of the content transfer-related elements, see Chapter 8, Content
Transfer, in the Web Development Kit and Client Applications Development Guide.
For example you would update the WDK application's app.xml to change the content transfer mode:
For a default Webtop 5.3 install on a default Tomcat install, you would update the file:
C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\webtop\wdk\app.xml.
It is a good practice to make a backup before making any changes.
Update the element to your choice of http or ucf.
http
ucf
You will need to restart your application server.
With the 5.3 release, WDK now supports three modes of content transfer:
- HTTP (Zero footprint) -- This mode of content transfer requires no applets downloaded to your Web browser.
- UCF (Unified Client Facilities) -- This is the recommended mode of content transfer in WDK 5.3
- Content Transfer Applets (included for backwards compatibility with previous releases)
Notes on http mode:
- HTTP 1.1 needs to be enabled in IE (Tools-->Internet Options-->Advanced,. Use HTTP 1.1)
- What browser OS is used? If running on XP, the pop-up blocker needs to be disabled for the WDK/Webtop host for this to work.
You can add the WDK/Webtop host to the list of trusted sites.
Other References : Documentum 5.3 System Migration Guide WDK/Webtop Release Notes
per the Documentum 5.3 System Migration Guide:
Specifying Which Content Transfer Mode Your Application Uses
You can choose to continue using the 5.2.x content transfer mechanism, or you can
specify that your application use the new UCF content transfer mechanism. To set the
application-wide content transfer mechanism and compression for content transfer
operations on the client, use the
the WDK application configuration file, app.xml.
The
application. Valid values for this element are: http (pre-5.3 applications) or ucf
(5.3 applications). If one or more of your custom components extend pre-5.3 applet
components, specify ucf.
For information about the app.xml file, see the section named "Configuring an
Application," in the Web Development Kit and Client Applications Development Guide
For a detailed description of the content transfer-related elements, see Chapter 8, Content
Transfer, in the Web Development Kit and Client Applications Development Guide.
For example you would update the WDK application's app.xml to change the content transfer mode:
For a default Webtop 5.3 install on a default Tomcat install, you would update the file:
C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\webtop\wdk\app.xml.
It is a good practice to make a backup before making any changes.
Update the
You will need to restart your application server.
With the 5.3 release, WDK now supports three modes of content transfer:
- HTTP (Zero footprint) -- This mode of content transfer requires no applets downloaded to your Web browser.
- UCF (Unified Client Facilities) -- This is the recommended mode of content transfer in WDK 5.3
- Content Transfer Applets (included for backwards compatibility with previous releases)
Notes on http mode:
- HTTP 1.1 needs to be enabled in IE (Tools-->Internet Options-->Advanced,. Use HTTP 1.1)
- What browser OS is used? If running on XP, the pop-up blocker needs to be disabled for the WDK/Webtop host for this to work.
You can add the WDK/Webtop host to the list of trusted sites.
Other References : Documentum 5.3 System Migration Guide WDK/Webtop Release Notes
What can cause UCF import and checkin operations to fail in Webtop?
If you can view/export/checkout a file in Webtop, but fail to import/checkin a file and receive the following error message:
==
[2006-01-27 13:55:34,620|ERROR|http-8080-Processor25 |com.documentum.fc.common.DfLogger|error|60 ] invokeMethod() failed while calling: onOk
ucf session wait timeout : ucf session wait timeout
java.lang.IllegalStateException: ucf session wait timeout
at com.documentum.web.contentxfer.ucf.UcfSessionManager.newSession(UcfSessionManager.java:396)
at com.documentum.web.contentxfer.ucf.UcfSessionManager.getSession(UcfSessionManager.java:118)
at com.documentum.web.contentxfer.ucf.UcfContentTransport.getUcfSession(UcfContentTransport.java:194)
==
This can be caused by the strict security settings in your Internet Explorer. Please open Tools->Options->Security tab in IE, and enable the following two options:
==
Allow paste operations via script
Scripting of Java applets
==
When performing checkin/import operations, we need JavaScript and the Applet to be able to interact with each other.
==
[2006-01-27 13:55:34,620|ERROR|http-8080-Processor25 |com.documentum.fc.common.DfLogger|error|60 ] invokeMethod() failed while calling: onOk
ucf session wait timeout : ucf session wait timeout
java.lang.IllegalStateException: ucf session wait timeout
at com.documentum.web.contentxfer.ucf.UcfSessionManager.newSession(UcfSessionManager.java:396)
at com.documentum.web.contentxfer.ucf.UcfSessionManager.getSession(UcfSessionManager.java:118)
at com.documentum.web.contentxfer.ucf.UcfContentTransport.getUcfSession(UcfContentTransport.java:194)
==
This can be caused by the strict security settings in your Internet Explorer. Please open Tools->Options->Security tab in IE, and enable the following two options:
==
Allow paste operations via script
Scripting of Java applets
==
When performing checkin/import operations, we need JavaScript and the Applet to be able to interact with each other.
Why does the Java applets fail to run properly in DA?
When the Java applets fail to run properly in Documentum Administrator (DA), object types, user names, folders, etc.. will not work properly.
One reason the Java applets fail could be because DA shortcut points to a 3.5.x RightSite installation and it needs to point to a 4i install of RightSite.
DA does not check the version of RightSite on the server where it is being installed to see if it s a 4i version of RightSite. It will install successfully on a server where 3.5.x RightSite is installed and will set up the DA shortcut (URL) pointing to the local 3.5.x RightSite installation e.g.
"C:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE" http://claudius/rs-bin/RightSite.dll/camain?view=ca&type=caframe
In this case the version of RightSite on CLAUDIUS is 3.5.2.1 and DA fails to run properly from that URL.
To fix this point the DA Shortcup (URL) to a machine with a 4i version of RightSite e.g.
"C:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE" http://batfish/rs-bin/RightSite.dll/camain?view=ca&type=caframe
One reason the Java applets fail could be because DA shortcut points to a 3.5.x RightSite installation and it needs to point to a 4i install of RightSite.
DA does not check the version of RightSite on the server where it is being installed to see if it s a 4i version of RightSite. It will install successfully on a server where 3.5.x RightSite is installed and will set up the DA shortcut (URL) pointing to the local 3.5.x RightSite installation e.g.
"C:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE" http://claudius/rs-bin/RightSite.dll/camain?view=ca&type=caframe
In this case the version of RightSite on CLAUDIUS is 3.5.2.1 and DA fails to run properly from that URL.
To fix this point the DA Shortcup (URL) to a machine with a 4i version of RightSite e.g.
"C:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE" http://batfish/rs-bin/RightSite.dll/camain?view=ca&type=caframe
What are the requirements to install and use the Documentum web client Java Appl
The Java applets used by the Documentum web clients need to be installed on the browser client machine. To install the applets, the user must have permissions to write to the local system (See details below). The Internet Explorer browser should automatically install the required applet on an as needed basis. Most of the applets are signed and sticky, so they will only need to be installed once for that version.
Please see the Documentum product Release Notes for the certified and supported browsers, browser versions, OS platforms and the certified Java (Microsoft JIT vs. Sun JRE) needed on the browser client.
If the browser is using the Microsoft JIT Compiler, the applet install will be show as installed in the C:\WINNT\Downloaded Program Files directory.
If the browser is set to use the Sun JRE plug-in, it will install the applet to the local users JRE cache under that user's profile. See the Sun Java Plug-in Control panel tool to clear and check for the location of this cache. By default, I would expect to see this under the local users profile, for example C:\Documents and Settings\dmadmin\.jpi_cache
Names for different applets used by the Documentum products:
- "RightSiteApplet"
Used for checkout, export and import/checking actions with RightSite and the RightSite Clients (Intranet Client, WebPublisher, iTeam)
- "DA Library"
This is used for some client functionality in Documentum Administrator such as Administering users and groups.
- "Documentum Content Transfer Applets"
This is used WDK and Webtop and similar function as the RightSiteApplet.
- "TemplateEditor"
Provides the WebPublisher editor functionality in the browser and the later versions will only run with the Sun JRE plug-in.
----------
Notes on using the MS JIT Compiler:
To use the applet for the first time, it must first be installed. The user installing it must have the permissions to modify the HKEY_CURRENT_USER registry hive and to write to the local directories used for checkout & export actions. This includes writing to "Downloaded Program Files" folder on the browser host. To test for applet installation problem using the MS JIT Compiler, log on to the NT-based computer as either a local Administrator group or local Power User group member with the appropriate permissions to write to the HKEY_LOCAL_MACHINE registry hive.
If the browser is set to use the MS JIT Compiler, you can check for details on the applet status, size and version. To do so, you can find this location from the browser. Click Tools, Internet Options. From the General tab, click the Settings button, then the View Objects button. If you know this location, you can use Windows Explorer to the appropriate directory. This is typically C:\WINNT\Downloaded Program Files. To see the details from the Explorer interface, click the menu item "View" then click "Details".
For additional information on applet install issues on Windows NT Systems, see the Microsoft Knowledge Base Article - 273855 "PRB: Installing Java Applet Through Java Package Manager Fails on Windows 2000 Computer" http://support.microsoft.com/default.aspx?scid=kb;en-us;273855
Also see Microsoft Knowledge Base Article - 241163 "How to Publish ActiveX Controls in Windows 2000 Using IntelliMirror" (Note this article is reference in the above article) http://support.microsoft.com/default.aspx?scid=kb;EN-US;241163
Note: There may be alternatives available with using third party software to 'push' installs to the end user machines with the necessary permissions.
Please see the Documentum product Release Notes for the certified and supported browsers, browser versions, OS platforms and the certified Java (Microsoft JIT vs. Sun JRE) needed on the browser client.
If the browser is using the Microsoft JIT Compiler, the applet install will be show as installed in the C:\WINNT\Downloaded Program Files directory.
If the browser is set to use the Sun JRE plug-in, it will install the applet to the local users JRE cache under that user's profile. See the Sun Java Plug-in Control panel tool to clear and check for the location of this cache. By default, I would expect to see this under the local users profile, for example C:\Documents and Settings\dmadmin\.jpi_cache
Names for different applets used by the Documentum products:
- "RightSiteApplet"
Used for checkout, export and import/checking actions with RightSite and the RightSite Clients (Intranet Client, WebPublisher, iTeam)
- "DA Library"
This is used for some client functionality in Documentum Administrator such as Administering users and groups.
- "Documentum Content Transfer Applets"
This is used WDK and Webtop and similar function as the RightSiteApplet.
- "TemplateEditor"
Provides the WebPublisher editor functionality in the browser and the later versions will only run with the Sun JRE plug-in.
----------
Notes on using the MS JIT Compiler:
To use the applet for the first time, it must first be installed. The user installing it must have the permissions to modify the HKEY_CURRENT_USER registry hive and to write to the local directories used for checkout & export actions. This includes writing to "Downloaded Program Files" folder on the browser host. To test for applet installation problem using the MS JIT Compiler, log on to the NT-based computer as either a local Administrator group or local Power User group member with the appropriate permissions to write to the HKEY_LOCAL_MACHINE registry hive.
If the browser is set to use the MS JIT Compiler, you can check for details on the applet status, size and version. To do so, you can find this location from the browser. Click Tools, Internet Options. From the General tab, click the Settings button, then the View Objects button. If you know this location, you can use Windows Explorer to the appropriate directory. This is typically C:\WINNT\Downloaded Program Files. To see the details from the Explorer interface, click the menu item "View" then click "Details".
For additional information on applet install issues on Windows NT Systems, see the Microsoft Knowledge Base Article - 273855 "PRB: Installing Java Applet Through Java Package Manager Fails on Windows 2000 Computer" http://support.microsoft.com/default.aspx?scid=kb;en-us;273855
Also see Microsoft Knowledge Base Article - 241163 "How to Publish ActiveX Controls in Windows 2000 Using IntelliMirror" (Note this article is reference in the above article) http://support.microsoft.com/default.aspx?scid=kb;EN-US;241163
Note: There may be alternatives available with using third party software to 'push' installs to the end user machines with the necessary permissions.
Subscribe to:
Posts (Atom)