When trying to get data from a REST (mobile) service I get the following error:
java.lang.RuntimeException: org.apache.cxf.interceptor.Fault: null while invoking public void SysUser.fv_system_SysUserRBE__ReadSysUserRBE_GET(java.lang.String) with params [com.progress.adapters.rest.message.impl.RestRequestMessageImpl@d4f234].
Does anyone have a clue what causes this?
OE 11.3.1 on Win7 x64
Is any security mode enabled for this REST Application ?
nope, I'm using /WEB-INF/appSecurity-anonymous.xml
Start simple :-)
Could you please check any exception trace logged in REST service log and broker log files.
I have seen this before when there is an issue with the generated .paar file. It has the definitions for the Web application. Assuming you are still testing this within your Developer Studio, then can you check if there is a .restoe file located in %DLC%\servers\tomcat\webapps\MyMobileWebService\WEB-INF\adapters\MyMobileWebService\stagingDir\ ? The .paar file is extracted into this directory.
Let us look at the appserver logs. Do you see any exception in the restbroker1.server.log while executing the business logic.
this post as spam/abuse.
REST Log file would be the first place to start with. Then look at the broker logs.
1. Please look at %DLC%\servers\tomcat\webapps\MyMobileWebService\WEB-INF\adapters\logs\*.log
2. If the log doesn't give substantial information increase the logging level by opening %DLC%\servers\tomcat\webapps\MyMobileWebService\WEB-INF\adapters\runtime.props and setting serviceLoggingLevel to 4
Restart Tomcat and try to invoke the method again. See if the log gives any clue now.
If this doesn't give any information, look at restbroker1.server.log and restbroker1.broker.log in the AppServer WRKDIR (assuming you are connecting to broker named restbroker1).
@donicello: although there's no staging dir, I did find the .restoe file in the System.paar file (in the %DLC%\servers\tomcat\webapps\MyMobileWebService\WEB-INF\adapters\System). In this file I found:
<pidl:operation name="bfv.system.SysUserRBE..ReadSysUserRBE" pattern="www.progress.com/.../request-response">
<pidl:input messageLabel="filter" req="false" type="java:String"></pidl:input>
<pidl:output messageLabel="dsuser" req="false" type="java:Object"></pidl:output>
This is pretty much what I expect.
The staging directory should be created(if the tomcat server is running). If it is not created then it means that your service is not started properly. Can you access your service WADL information from the browser
URL - http://localhost:8980/<Servicename>/rest
There's however a staging dir in %DLC%\servers\tomcat\pdsoe\WEB-INF.
BTW, the AppServer is never reached, so there's no point in raising the AppServer logfile.
Yes, http://localhost:8980/<Servicename>/rest returns the wadl
Then the only place left out for traces would be the REST Application logs. Can you please look at the log file in webapps/<REST Service>/WEB-INF/adapters/logs
if you do not see anything even in the REST Application logs, then you can try redeploying the Application and invoke the service.
Here's some more information that might help you troubleshoot.
In 11.3.1, in order to make deployment faster, PDS OE deploys the .war file into %DLC%\servers\tomcat\pdsoe folder and not in the %DLC%\servers\tomcat\webapps folder.
So when you publish "MyMobileWebService" from PDS OE you must see MyMobileWebService folder and MyMobileWebService.war in %DLC%\servers\tomcat\pdsoe. There will also be a configuration descriptor (refer tomcat.apache.org/.../deployer-howto.html ) in %DLC%\servers\tomcat\conf\Catalina\localhost with the name MyMobileWebService.xml
You must look for logs, paar and staging dir into %DLC%\servers\tomcat\pdsoe\MyMobileWebService folder. This will your doc base.
You have mentioned that you found a .restoe file in the System.paar file (in the %DLC%\servers\tomcat\webapps\MyMobileWebService\WEB-INF\adapters\System ). Something looks wrong here.
You should have MyMobileWebService folder either in %DLC%\servers\tomcat\webapps or %DLC%\servers\tomcat\pdsoe. Not in both the locations. So, delete MyMobileWebService.war and folder from %DLC%\servers\tomcat\webapps. Restart tomcat and send you invoke request.
Verify that %DLC%\servers\tomcat\pdsoe\MyMobileWebService\WEB-INF\adapters folder has a logs folder which contains a MobileWebService.log (you can look at its content). By your post I understand that you .paar is named System.paar. So you must have a stagingDir inside %DLC%\servers\tomcat\pdsoe\MyMobileWebService\WEB-INF\adapters\System folder (when the Tomcat is running). If it is not there, look at the %DLC%\servers\tomcat\pdsoe\MyMobileWebService\WEB-INF\web.xml and search for your paar name under following context-param :
Since, you got a _wadl output at /rest, it means that the staging dir must be created. The application log at %DLC%\servers\tomcat\pdsoe\MyMobileWebService\WEB-INF\adapters\log will tell you whether the REST Adapter was able to process REST request and extract the parameter values properly (you might want to increase the serviceLoggingLevel to 4 for a detailed log).
Also, there must be no %DLC%\servers\tomcat\pdsoe\WEB-INF folder, so I guess you meant %DLC%\servers\tomcat\pdsoe\MyMobileWebService\WEB-INF..
Thanks for clearing that out. In all my attempts it has become a bit of a mess so I started all over. To no avail, I still get the original message. I raised the logging level but basically the same information is displayed. Just before the Java stack trace there are the following two lines:
2014-01-22 12:00:44.106 [DEBUG][REST] Entering route :: ExecuteIN
2014-01-22 12:00:44.106 [TRACE][REST] Unloading OESpringSecurityContext in RestBinding
The 500 error is a general response that can originate from a number of sources, including simply not being able to connect to the AppServer. There is a sequence of debugging checks that starts with the web server and proceeds through the REST service and down to the AppServer. If the information supplied so far has not helped you find the source of the 500 response, perhaps it is time to take this off-line with technical support who can do a more detailed end-to-end evaluation and debugging of your environment.