[aerogear-controller] Error Route responses
by Daniel Bevenius
JSON Responses for Error Routes
We recently added support for routes to be able to produce responses, other
than original MVC forwarding to a view. This addition meant that a route
could specify the media types it produces, and a client could specify the
desired media types using the HTTP Accept header, and get back a response
body with that type.
But this only worked for normal routes and not for error routes which is
what AEROGEAR-515 <https://issues.jboss.org/browse/AEROGEAR-515> has added.
You can now specify that your error routes produce different types:
route()
.on(Exception.class)
.produces("text/html", "application/json")
.to(Error.class).index(param(Exception.class));
route()
.from("/throwException")
.on(RequestMethod.GET)
.produces("text/html", "application/json")
.to(Error.class).throwException();
This would enable you to produce a html response by accessing
throwException<http://localhost:8080/aerogear-controller-demo/throwException>
in
aerogear-controller-demo.
You can also specify that you want the response as *application/json* and
calling the same route as above:
curl -i -H "Accept: application/json" -X GET
"http://localhost:8080/aerogear-controller-demo/throwException"
GET Exception application/json:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Content-Length: 28
Date: Thu, 03 Jan 2013 06:52:56 GMT
"{exception:Demo Exception}"
10 years, 2 months
SwitchYard/Camel Integration
by Daniel Bevenius
AeroGear Camel/SwitchYard Integration
There have been inquiries about how existing services could be exposed
using AeroGear Controller, and this document will try to sort out why
someone would want to do this, and also try to come up with some possible
solutions.
Why would you want to do this?
Currently one can already expose a service as a RESTful endpoint in Camel
using Camel's CXFRS Component <http://camel.apache.org/cxfrs.html>. The
same goes for a service in SwitchYard that can be exposed using the RestEasy
Component<https://docs.jboss.org/author/display/SWITCHYARD/RESTEasy+Bindings>
.
So, a few reasons why users might opt to expose their services through
AeroGear controller:
- Consistent way of exposing enterprise services externally for mobil
developers
- Security
Camel Integration
Using Camel to integrate with existing services is a great option as Camel
has a huge number of components <http://camel.apache.org/components.html>.
There is a SwitchYard Camel component too, so integrating with SwitchYard
would also be possible using Camel. SwitchYard also has a new
RemoteInvoker<https://docs.jboss.org/author/display/SWITCHYARD/Remote+Invoker>
which
could be used for SwitchYard specific services and would be a separate
controller class.
The goal here is to make things as flexibile as possible as it is difficult
to try to account for different types of services. As a suggestion, an
AeroGear Controller route that invokes a service using Camel might look
like this:
public class Routes extends AbstractRoutingModule {
@Override
public void configuration() throws Exception {
route()
.from("/cars/{id}")
.on(RequestMethod.GET)
.to(CarServiceController.class).getCar("direct://input",
param("id"));
}}
CarServiceController.class might look something like this:
public class CarServiceController extends CamelController {
public String getCar(final String endpointUri, final String id) {
return (String) producerTemplate().requestBody(endpointUri,
Long.valueOf(id));
}}
CamelController is very simple and gets injected with a CdiCamelContext and
creates the ProducerTemplate.
public abstract class CamelController {
@Inject
private CdiCamelContext camelContext;
private final ProducerTemplate producer;
public CamelController() {
producer = this.camelContext.createProducerTemplate();
}
protected ProducerTemplate producerTemplate() {
return producer;
}}
We are simply making an instance of
ProducerTemplate<http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel...>
available
to users, and they have access to all the methods of that interface. This
will enable users to send one way messages, request/response messages, and
also prepare the arguments to the service and process the result if needed.
A ProducerTemplate is created from a CamelContext. One can have multiple
CamelContext's per application/deployment but the most common is that each
deployment has one CamelContext. In this case we are injecting
CdiCamelContext.
We could also add additional methods from ProducerTemplate to
CamelController which just delegate, for example:
public abstract class CamelController {
@Inject
private CdiCamelContext camelContext;
private final ProducerTemplate producer;
public CamelController() {
producer = this.camelContext.createProducerTemplate();
}
protected ProducerTemplate producerTemplate() {
return producer;
}
protected Object requestBody(final String endpointUri, final Object body) {
return producer.requestBody(endpointUri, body);
}
//...more methods like requestBody}
This would save subclasses from having to call producerTemplate().
SwitchYard Integration
As mentioned above, SwitchYard has a RemoveInvoker that could be used for
invoking services from a remote client. This could be used in an AeroGear
route:
public class Routes extends AbstractRoutingModule {
@Override
public void configuration() throws Exception {
route()
.from("/server1/{id}")
.on(RequestMethod.GET)
.to(SwitchYard.class).invoke(
"http://localhost:8080/switchyard-remote",
"CarService",
pathParam("id"));
}}
SwitchYard is again very simple:
public class SwitchYard {
public static final String REMOTE_SERVICE =
"urn:com.example.switchyard:remote";
public Object invoke(final String url,
final String serviceName,
final Object payload) throws IOException {
return new HttpInvoker(url).invoke(new RemoteMessage()
.setContext(new DefaultContext())
.setService(new QName(REMOTE_SERVICE, serviceName))
.setContent(payload))
.getContent();
} }
The original gist can be found here: https://gist.github.com/4152998
10 years, 2 months
Status
by Christos Vasilakis
Blockers:
none
This week:
AEROGEAR-725 - filter and query: evaluate usage of NSPredicate
AEROGEAR-763 - ios: API Overhaul for CR1 release (umbrella ticket for the underlying api changes)
-
Christos
10 years, 2 months
