In ADF 10.1.3, applications like the SRDemo sample customize the default way bundled exceptions are reported to JSF by providing a custom error handler class as well as overriding various methods of the FacesPageLifecycle class. You can remind yourself about the steps that are required by reading section 20.8 Handling and Displaying Exceptions in an ADF Application in the 10.1.3 ADF Developer's Guide. Getting your custom error handler and page lifecycle classes to be used at runtime also require additional code and classes to achieve. Since this seemed like too much work for solving pretty basic customization use case, in 11g we've tried to simplify the situation.
Now, in ADF 11g you can implement any kind of custom exception reporting with a single class: a custom error handler. The easiest way to implement it is by extending the default DCErrorHandlerImpl class. Instead of requiring you to write code to get your custom exception handler class to be used, instead you can now select the root node of the DataBindings.cpx file in the Structure Window and use the Property Inspector to set the ErrorHandlerClass property to the fully-qualified name of the error handler you want it to use (which must have a default constructor). By overriding the reportException() method of the error handler class, as well as the new getDisplayMessage() method, you can implement any kind of error reporting customizations you like. The reportException() method gets called to report any exception that occurs. If necessary, this method can be overridden to analyze the exceptions reported.
ADF constructs an instance of the custom error handler for each BindingContext that is created. Since ADF, in addition, serializes simultaneous web requests from the same logical end-user session, you can safely assume that multiple threads will not be using the same error handler at the same time. That said, one useful way to write a threadsafe custom error handler is to use the setProperty() API on JboException to allow the exception objects themselves to store any hints you might need later during the phase when exceptions get translated to JSF FacesMessage objects for showing to the user.
For example, an overridden reportException() method in your custom error handler can call the setProperty() API on any JboException to set custom properties on the exception object itself. You could then consult the property using the companion JboException.getProperty() in your overridden getDisplayMessage() method to decide whether or not a given JboException should be reported to JSF or not. The overridden getDisplayMessage() is responsible for returning the message that will be reported to JSF for each exception that occurred, and simply returning null is the way your custom error handler can signal that a given exception should not be reported to the client (typically because it was just wrapping another more interesting exception).
We hope this will dramatically simplify a very common usecase in applications you build with ADF 11g. You can experiment with this new feature in the JDeveloper 11g Technology Preview 3 release at http://www.oracle.com/technology/products/jdev/11/index.html and report any feedback you have in the 11g Tech Preview Discussion Forum,
12:58:09 PM 
|
