Here are some (admittedly contrived) example...
1. Change the page template to add another #FORM_OPEN# tag. When the page is submitted using OHS, it gives an error "ErrorPage protection violation: This may be caused by submitting a page that had not yet finished loading or by manual alteration of protected page items. For further assistance, please contact the application administrator". Which is sort of helpful. ORDS says "ORA-1403 - No Data found".
2. Add a bad INPUT tag to the APEX form in the page template like <input type="text" name="z_flow_id" value="200" id="zFlowId" />
When the page is posted using OHS, the browser shows a HTTP 404 with the following error logged in the OHS error log
[Mon Nov 24 08:53:10 2014] [error] [client xx.xx.xx.xx] mod_plsql: /pls/public/wwv_flow.accept HTTP-404 \nwwv_flow.accept: SIGNATURE (parameter names) MISMATCH\nVARIABLES IN FORM NOT IN PROCEDURE: Z_FLOW_ID\nNON-DEFAULT VARIABLES IN PROCEDURE NOT IN FORM: \n, referer: http://htmldb-dev/pls/public/f?p=200:23:260775414453:::::
But the same page posts just fine using ORDS. So I am confused. Doesn't ORDS also use WWV_FLOW.SHOW/ACCEPT to render/process APEX pages? So why doesn't it choke on a unexpected form item?
3. All ORDS errors appear to be logged in both catalina.out and catalina.yyyy-mm-dd.log. Is there a way to have ORDS errors log to its own logfile?
ORDS does not process PL/SQL calls in exactly the same manner as mod_plsql. mod_plsql forms the PL/SQL block to invoke the procedure just from the request parameters. ORDS validates the request parameters against the actual declared parameters of the procedure and ignores any parameters that are not explicitly declared on the procedure. ORDS does not error on these bogus parameters because there are some edge cases where folks for whatever reason do pass bogus parameters, and do not want to receive an error (for example cache busting by appending bogus parameters to the query string).
Configuring logging varies a lot between application servers, unfortunately you need to consult each application server's documentation and learn about it's approach to logging to understand how to configure it to best match your needs/expectations.
ORDS uses the logging facilities provided by the JRE (Java Runtime), but each application server routes the outputs of these logging calls differently. You can try configuring the logging by configuring the JRE logging as shown here:
But you are probably better off reading the Tomcat documentation, perhaps this link will provide relevant pointers
Colm - Thanks for jumping in.
1 & 2 - Nice! Glad to know exactly how ORDS works differently from mod_plsql. Speaking of "cache busting", I am not sure I understand exactly what type of caching is controlled by the "cache.*" entries in the defaults.xml file. The note next to cache.procedureNameList mentions procedures like p,download_file so it would seem to indicate it applies to custom download of files using wpg_docload.download_file and such but could you please clarify the scope of this feature?
2. Logging - The blog entry you refer has a tantalizing reference to "subsequent posts" but I wasn't able to locate any posts talking about ORDS logging when deployed with Tomcat. But I do see your point about different JEE application servers varying wildly in how they handle logging. Your blog post has a good start and I will review the Tomcat documention to configure it further.
Some more questions, if you don't mind
3. What kind of logging do the "log.*" entries in default.xml refer to" ? The documentation talks about log.procedure, log.messages but I am not sure exactly how to use these entries effectively?
debug.printDebugToScreen=true. This appears similar to the mod_plsql PlsqlErrorStyle directive. It does appear to expose a lot of information on the screen which is of concern in a Production environment but for internal (Intranet) applications it would appear to be easier all around to set it to true and let the users report any errors they on the screen instead of showing a HTTP 404 or HTTP 500 on the browser and digging around in JRE log files on the Tomcat server. Your thoughts appreciated.
5. Are the procedure.* and security.* keys in defaults.xml similar to the Plsql*Procedure and PlsqlExclusionList directives? If so, what is the default value for
security.exclusionList? And the default value for s
ecurity.disableDefaultExclusionList is FALSE so does that mean no PL/SQL procedures in Oracle other than the ones specifically listed in
security.inclusionList will be allowed by ORDS? What is the default value for the
Thank you so much for your help.
Colm - Would you mind looking at my questions 3, 4 & 5 in my last post? Thanks