Absolutely.
FWIW; Jame's Error produces mostly all you need.
We added a couple of extensions -- e.g. to return an edit link for
cases like OptimisticConcurrenyException
Cheers,
-- Chris
On May 12, 2008, at 10:26 AM, James M Snell wrote:
One of the things I pushed for in the Atompub WG but didn't get was
a standardized error reporting format. I still think it would be a
good idea.
Remy Gendron wrote:
Hello all,
Your example David is pretty much what I'm looking for:
* Errors and warnings returned as an Atom feed.
* Use of standard 4xx HTTP codes to enable generic processing by
applications not aware of the specifics below.
* Ability to return, in an Atom entry, an application error code
(a:id), a
message id (a:subtitle), a number of message arguments (a:content),
a non
internationalized error message (a:title) and support/debugging
information
(a:summary).
My adapters are based on AbstractEntityCollectionAdapter. Can
anyone suggest
how I can in AbstractEntityCollectionAdapter.postEntry() build and
then
return an error feed? AbstractProvider error handling seems geared
toward
catching exceptions from adapters.
This would simply be a matter of implementing your own
ResponseContext. The easiest way would be to use
EntityProviderResponseContext and implement an EntityProvider to
serialize out the error details.
- James
Could I, in my adapter, manually create the error feed, then use
ProviderHelper.createErrorResponse passing the feed.toXML() as the
message
argument and then throwing a new
ResponseContextException(myHTTPCode)?
Is there a better way to do it to be aligned with the error handling
architecture of Abdera?
Thanks,
Rémy
[EMAIL PROTECTED]
418 809-8585
http://arrova.ca
-----Original Message-----
From: David Calavera [mailto:[EMAIL PROTECTED] Sent: May 6,
2008 03:54
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: Error messages
Hi, this is not about abdera, so sorry by the off topic. I'm doing
something
similar in the(ape.rubyforge.org). I have an atom format report
that shows
me a feed with errors and warnings, the structure is like this:
<feed xmlns="http://www.w3.org/2005/Atom";>
<id>id</id>
<updated>date</updated>
<title> feed title </title>
<author><name>The ape</name></author>
<subtitle>4 errors, 11 warnings</subtitle> # a little summary
<entry>
<id>id</id>
<updated>date</updated>
<title> a sentence that explains what's happening</title>
<content> communication log between the client and the atompub
server
</content>
<category term=" error or warning or info or debug "/> #log type
</entry>
</feed>
On Tue, May 6, 2008 at 1:35 AM, Alexandre Bairos
<[EMAIL PROTECTED]>
wrote:
I'm using something in the lines of
<?xml version='1.0' encoding='UTF8'?>
<error xmlns="http://incubator.apache.org/abdera";>
<code>1400</code>
<message>InvalidArticleTitle</message>
</error>
which Abdera has out of the box with some minor adjustments.
These error elements comes in a http error response, with 400,
500, etc.
Google Gdata has a <reason/> and <input/> subelements.
For Bad request errors, an errors root element would do the trick of
returning multiple errors like in the following snippet:
<?xml version='1.0' encoding='UTF8'?>
<errors>
<error xmlns="http://incubator.apache.org/abdera";>
<code>1400</code>
<message>InvalidArticleTitle</message>
</error>
<error xmlns="http://incubator.apache.org/abdera";>
<code>1401</code>
<message>InvalidArticleBodyLength</message>
</error>
</errors>
Alexandre Bairos
On Mon, May 5, 2008 at 12:57 PM, Remy Gendron <[EMAIL PROTECTED]>
wrote:
Hello all,
I am currently implementing server side validations (for those
interested,
using Spring validation package with Hibernate Validator for the
simple
validations).
Any of you have recommendations/insights as to the returned XML
payload
when
errors are encountered?
I need to return something like a list of error object
designators, the
error codes and a default, non localized human readable error
message.
I was considering returning this as a feed collection, each error
being
wrapped in an entry. Or do you recommend a specific XML schema
for the
errors? Or something else?
Some might say that the error code should be enough. However, I
would
like
to give the caller the opportunity to provide the user with a
minimum of
information when errors are reported.
Thanks,
Rémy
