dev@jsr311.java.net

Factoring out common behaviour across the HTTP verbs

From: Andrew Robinson <Andrew.Robinson_at_bbc.co.uk>
Date: Wed, 7 Jul 2010 13:28:21 +0100

 
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.