At my current client we've been working on building an ADF Fusion
application template that includes bits 'n' bobs required for all of
our applications beyond what JDev creates out of the box via the
Application Wizard.  For example by default we setup our package
structures in the Model and ViewController projects (ie. the Model is
split into AM/EO/VO packages), page templates and skins in our
ViewController and so on.

We'd also like to consider standard HTTP error pages.  Readers will be
familiar that the JEE web.xml supports an "error-page" option for
capturing certain HTTP error codes (ie. 404 Page Not Found) and
redirecting to an appropriate error page (ie. your equivalent of an
ADF fail-whale page ;-).

A question to readers is what HTTP error codes have you found
necessary, if at all, to configure in the web.xml for an ADF
application?

Currently we see the need for a 404 Page Not Found custom page, plus
for secure applications a 403 Forbidden, but aren't overly sure what
other HTTP error codes (http://www.w3.org/Protocols/rfc2616/rfc2616-
sec10.html) should we include?  What other HTTP error codes are likely
to occur in an ADF application?  Maybe 408 Request Timeout?

Anybody any thoughts they'd like to share please?

Cheers,

Are you only interested in covering errors in the 4xx range (user errors)?
To be on the safe side, I'd include a 500 error page. Among other things,
you can display a time stamp (somewhere not too intrusive but that your
customer support reps could ask a user about) that you can match up with
the logs to help kill bugs. Of course, you might want to only enable this
in your production environment; the stack trace you can configure your
development servers to return is more useful still.

My thought is that that, plus your list, is enough to cover.

While 401 is the proper error code for an authorization failure, I don't
think ADF security ever returns it; it (incorrectly, IIUC) returns 403 for
authorization failures (403's supposed to be for attempts to access
resources that aren't open to *anyone* via the protocol, such as directory
listings when directory browsing is turned off). Of course, you might want
to make your 403 page cover 401 too, in case the issue ever gets fixed.

408 might be important if, say, you allow the user to upload large files.
Otherwise, normal requests probably won't time out frequently. (This is
not to be confused with browser-based *response* timeouts, which can
happen any time your server is slow.)

Best,
Avrom

A slightly wider consideration is that if you're deploying to the web
and have a separate web tier (e.g. OHS) then you'll want at least a
404 page at that level too (in case your user hasn't even reached the
app server - of course if you're running as the root app then that may
not matter so much).

Good things for a 404 page are a "report this link as broken"
function, or if it's a more general web app perhaps a redirect to a
search page; though just a logo/message is better than leaving it as
default.

Simon

On Oct 2, 3:57 am, Chris Muir <chriscm...@gmail.com> wrote: