Hi Andrew,
First, please accept my sincere apologies for not replying, it was an
email management SNAFU on my part. Next time please, metaphorically,
poke me in the ribs, with a direct email if i do not reply in a timely
fashion!
I am not quite sure if JAX-RS currently facilitates all you require
but it does have support returning a response built as appropriate,
so a generic method can be passed a response builder from which it
augments information.
JAX-RS has the Request class:
https://jsr311.dev.java.net/nonav/releases/1.1/javax/ws/rs/core/Request.html
from which pre-conditions can be calculated and thus you can support
deep etags. Deep etags require some degree of application integration
to say how the etag is calculated (as opposed to shallow etags which
can be an MD5 checksum of the bytes of the representation). We discuss
this in the JavaOne 2010 presentation Roberto and I presented on JAX-
RS. It may be possible to remove some of the code required for deep
etag support in say a JAX-RS 2.0 effort, but it can be hard in Java
since functions are not first class citizens, thus partial functions
are not really possible, and one has to resort to the vertically
verbose anonymous inner class mechanism.
Paul.
On Jul 7, 2010, at 2:28 PM, Andrew Robinson wrote:
>
> Hi List,
>
>
> I've just written my first RESTful service app using Spring3's
> @RequestMapping and SimpleJDBCTemplate
> (I didn't find much need for a domain model as the business logic was
> pretty much expressed via SQL)
>
>
> One of the main challenges I faced in building a fully-fledged app was
> factoring out common behaviour across the HTTP verbs.
>
>
>
> QUESTION: Is there anything in the JAX-RS spec, current or planned,
> that
> facilitates this? Has anyone found satisying solutions to this in
> their
> apps?
>
>
>
> The following sorts of issues tend to be common per HTTP verb
>
> HTTP caching headers and behaviour (I'm sending Etags and returning
> HTTP304 to conditional requests for GET where appropriate)
> HTTP Response codes
> Error handling
> Appending standard JSON fragments (such as paging information)
>
>
> In order to be able to send all GET through a "genericGet" method, I
> ended up having to use Java reflection and a Command Pattern in
> order to
> dynamically invoke
> my service methods from my annotated controller methods.
>
>
> This seems in the realm of "Something I wish a RESTful app framework
> would facilitate".
>
>
> I've not seen anything like this in Spring3, and still need to
> properly
> explore CXF, Jersey etc
>
>
> Deep Etag support was also something I had to entirely code myself.
>
>
>
>
>
> thanks
>
> Andrew
>
>
>
>
>
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: 06 July 2010 14:39
> To: dev_at_jsr311.dev.java.net
> Subject: JSR311: EJBException handling spec error
>
> The spec says: "If an ExceptionMapper for EJBException or subclass is
> not included with an appliction, then exceptions thrown by an EJB
> resource class or provider method MUST be treated as an EJB
> application
> exception..."
>
> An "application exception" in EJB means that the thrown exception will
> not automatically cause a rollback and should be propagated as-is.
> Following this JAX-RS/EJBException logic to the letter of the law
> would
> make it impossible for EJB applications to throw exceptions that cause
> transaction rollbacks.
>
> The EJB container wraps unchecked (non applicaton) exceptions within
> EJBException. Unchecked exceptions are required by the EJB
> specification to trigger a rollback unless they are annotated with
> @ApplicationException or ejb-jar.xml equivalent.
>
> The spec should instead just say:
>
> "If an ExceptionMapper for EJBException or subclass is not included
> with
> an appliction, then EJBException thrown by an EJB resource class or
> provider method MUST be unwrapped and processed as described in
> section
> 3.3.4"
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>