Kbase P95780: Installation of Fathom Management remote monitoring breaks functionality of Web Services
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/14/2007 |
|
Status: Unverified
FACT(s) (Environment):
OpenEdge 10.0B
Fathom Management 3.0A
Web Services
SYMPTOM(s):
Installation of Fathom Management remote monitoring breaks functionality of Web Services
Unable to deploy new Web Service after enabling Fathom Management remote monitoring
java.rmi.ServerError: Error occurred in server thread; nested exception is:
java.lang.IncompatibleClassChangeError
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:349)
Unable to update Web Service after installation of Fathom remote monitoring
Unable to query Web Service Adapter instance after installation of Fathom remote monitoring
java.rmi.ServerError: Error occurred in server thread; nested exception is:
java.lang.NoClassDefFoundError: org/apache/soap/util/xml/XMLJavaMappingRegistry
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:349)
CAUSE:
Bug# 20040929-026
CAUSE:
Bug# 20051110-054
FIX:
Upgrade to OpenEdge Management 3.1B. If that is not possible at this time there are two workarounds that could be implemented.
Workarounds:
As a workaround, disable Fathom Management remote monitoring through "fmconfig -disable". Once this is done, the AdminServer and Java Servlet Engine need to be restarted for the WSA to function properly again.
- OR -
Make another directory called %DLC%\java\extwsa which contains the original jar files (before Fathom Remote Monitoring was enabled).
Enable Fathom Remote Monitoring (fmconfig -enable -host ...).
Change all the references pointing to %DLC%\java\ext, to %DLC%\java\extwsa in the AdminServerPlugins.properties and JavaTools.properties (found in %DLC%\properties).
Copy the classpath content of the PluginPolicy.WSA section in AdminServerPlugins.properties and prepend it to the classpath of the PluginPolicy.Progress.AdminServer section.
If you start the AdminServer from the Windows services, then you would have to add -DSONICMQ_XBOOTPATH="-Xbootclasspath/p:." to the Chimera string in the registry.
The exact location is:
[HKLM]\SOFTWARE\PSC\AdminService\10.0B\StartupCmd. For example:
"c:\Progress\oe100b\bin\jvmstart" -a
"c:\Progress\oe100b\properties\AdminServerPlugins.properties"::PluginPolicy.Progress.AdminServer -o eventmgr -w @{WorkPath} @{JAVA\JREHOME}\bin\java -DInstall.Dir=@{Startup\DLC} -DWork.Dir=@{WorkPath} -DSONICMQ_XBOOTPATH="-Xbootclasspath/p:." -Dadmsrv.jvm=@{JAVA\JREHOME}\bin\java -Djvmstart.debug=0 com.progress.chimera.adminserver.AdminServerType -start -service
If you are using the proadsv.bat script, then you need to include the -DSONICMQ_XBOOTPATH="-Xbootclasspath/p:." parameter, for example:
"%JVMSTRT%" -o stderr -s -m silent -a "%ADMSRVRPROP%"::%ADMSRVRGRP%
"%JVM%" -Dadmsrv.jvm="%JVM%" -DInstall.Dir="%DLC%" -DWork.Dir="%WRK%"
-DSONICMQ_XBOOTPATH="-Xbootclasspath/p:." -Djvmstart.debug=0
ADMSRVRCLASS% %PARMS%