Spring MVC 3.0: Avoiding explicit JAXBElement<> wrapper in method arg - spring

I have the following method and want to avoid having to explicitly show the JAXBElement<> syntax. Is there some sort of annotation that would allow the method to appear to accept raw MessageResponse objects but in actuality work the same as shown below? I'm not sure how clear that was so I'll say this: I'm looking for some syntactic sugar :)
#ServiceActivator
public void handleMessageResponse(JAXBElement<MessageResponse> jaxbResponse) {
MessageResponse response = jaxbResponse.getValue();
MessageStatus status = messageStatusDao.getByStoreIdAndMessageId(response.getStoreId(), response.getMessageId());
status.setStatusTimestamp(response.getDate());
status.setStatus("Complete");
}

You can use the unmarshalling transformer described in the reference guide here.
Adapted from the documentation (usable in a chain):
<si-xml:unmarshalling-transformer unmarshaller="unmarshaller" />
This should give you a domain object as the message payload.

Related

Web API - JObject from URI

Web API allows me to capture the body of a POST request in a JObject:
$.post('/api/Query/DoSomething', { Foo: "one", Bar: 4 });
public string Post(JObject data)
{
// data is populated
}
However the same technique does not work with a get request and URI parameters.
$.get('/api/Controller', { Foo : "one", Bar : 4 });
public string Get([FromUri]JObject data)
{
// data is empty
}
Any workaround here?
It doesn't work because a GET request does not have a body, and hence no content type. Therefore, Web API does not know that you have JSON in your URL. You have a few choices:
Pass your data as query string parameters, as is traditionally done in GET requests, and change your method to accept those parameters individually, or in a regular class (POCO).
Change your GET method to accept a string instead of a JObject, then use JSON.Net to deserialize it manually, e.g. JObject obj = JObject.Parse(data);
If you're feeling ambitious, you might be able to implement a custom binder to do this.
My recommendation is option 1. Traditionally, a GET method is just intended to look something up, so you really should only be passing IDs and simple query options anyway. It is unusual to be passing JSON data in a URL. Also the length of URLs can be limited by some browsers. If you find you are needing to pass JSON data, use POST (or PUT) instead.
You can create an object and bind to it using the FromUri.
Check out this solution which I am using https://stackoverflow.com/a/49632564/2463156.

How to enforce Grails command objects have been validated?

We use the following general pattern with Grails controllers and command objects
SomeController {
def someAction() {
SomeCommandObject co = SomeCommandObject.valueOf(params)
if(!co.validate()) {
// return bad request
}
someService.doWork(co)
// return ok
}
SomeService {
def doWork(SomeCommandObject co) {
notTrue(!co.hasErrors(), 'cant have errors') // Commons validation
// do actual work
}
}
Apparently, if co.validate() has not been called, .hasErrors() will always return false. Is there a better way to enforce that .validate() has been called before a command object is passed between application layers? We don't want to pass around invalid command objects but we don't want to force every new method to re-validate the command object either.
Note: We aren't using the default controller/command object creation pattern because we need to do some custom parameter map checking, we use a static valueOf method instead to create the command object. Answers that change that practice are also welcome.
EDIT: A little more info on why we aren't using the 'default' controller/command object creation. Specifically why we aren't doing ..
def someAction(SomeCommandObject co) {
}
We have a requirement to disallow random query parameters, eg. endpoint/object?color=blue. To do that we need access to the parameter map in the command object to verify that it doesn't contain any 'unexpected' parameter keys. As I understand it, the default way would just create a member on the CO named color, and I don't see how to prevent arbitrary members using even custom validators. I'd happily entertain suggestions for doing so, thereby allowing us to use this default means.
Yes; what you can do is pass the command object as a parameter to the controller, and then the command will always be validated automatically.
Also, what you can do, is to make a filter or similar, so that you don't have to check for the hasErrors() each time, but handle all the cases in the same way (for example, by throwing an error, or returning with a specific response).
In an application we created, we had something like:
withValidCommand(cmd) {
// do work
}
Which worked pretty well. But maybe you can come up something even more elegant.
You should be doing this:
def someAction(SomeCommandObject co) {
if (!co.hasErrors()) {
someService.doWork(co)
}
}
By passing SomeCommandObject in as the argument grails will automatically populate it from params and validate. No need to do it manually.

Additional GetXYZ methods in EntitySetController

I want to be able to have additional GetXYZ methods in my EntitySetController derived controller class. For example:
[HttpGet]
[Queryable]
public string GetAirportsWithinRadius(int airportId, int radius)
{
var resultAirports = GetAirportsWithinRadius2(airportId, radius);
return resultAirports;
}
This is what I have for config:
ActionConfiguration getAirportsWithinRadius = modelBuilder.Entity<Airport>().Collection.Action("GetAirportsWithinRadius");
getAirportsWithinRadius.Parameter<int>("airportId");
getAirportsWithinRadius.Parameter<int>("radius");
getAirportsWithinRadius.ReturnsCollectionFromEntitySet<Airport>("Airports");
I want this action to be composable just like the default Get Queryable action, but this would be an alternative that supports all odata parameters but additionally an airportId and radius. This would first filter airports by a radius search (this I know how to do - it's irrelevant to the question) and then return the Queryable so that it can be further filtered by odata params.
Everything I read says this would be an odata action and therefore must be a POST, but Get is also an action and that is a GET, so why not allow extended getters with additional parameters? Am I missing something? How do I accomplish what I want to get done?
I would call this from an ajax client as such:
GET /odata/Airports?$inlinecount=allpages&$top=25&airportId=2112&radius=50
as opposed to a regular odata GET:
GET /odata/Airports?$inlinecount=allpages&$top=25
Thanks
EDIT:
I understand now that this is an odata "function" and it is under consideration as a future feature. Let's forget for second the odata meaning of this. It is essentially a WebApi HttpGet that returns a Queryable, right? So, as long as I don't care about the metadata advertising of this "function", how can I make sure that it is a reachable HttpGet form a route perspective inside of an ODataController? The ODataController needs the MapODataRoute and can I additionally add non odata routes using additional MapHttpRoutes?
I ask this because it seems to me that I should be able to, but all my tries have failed (trying to hit the HttpGet through fiddler). I can find no examples on extending an ODataController with additional non-odata GETs. Can someone help me understand if and how this can be done with the example?:
[Queryable]
public IQueryable<Airport> Get()
{
return db.Airports;
}
[HttpGet]
[Queryable]
public string GetAirportsWithinRadius(int airportId, int radius)
{
var resultAirports = GetAirportsWithinRadius2(airportId, radius);
return resultAirports;
}
You are looking for OData Functions, which is not yet supported out of the box. We have an issue over here. You can up-vote it.
http://aspnetwebstack.codeplex.com/workitem/881

Return JsonNet type JSON from WebAPI in Orchard

In standard MVC I use JsonNet to return JSON that is in camelCase and sucessfully serializes entities that have related entities (which otherwise reports a "cycles" error" using the default serializer).
I'd like to do the same for a WebAPI controller in an Orchard module. By default it returns PascalCase JSON and reports a "cyles" exception when given a list of entities.
Can anyone explain how best to configure the JSON output from within the Orchard module, to mimic what JsonNet would produce?
I've found a workaround, which is to set the JSON formatters settings to camelCase in an ActionFilter:
public class CamelCaseJsonAttribute : ActionFilterAttribute {
public override void OnActionExecuting(System.Web.Http.Controllers.HttpActionContext actionContext)
{
var jsonFormatter = actionContext.ControllerContext.Configuration.Formatters.OfType<JsonMediaTypeFormatter>().First();
jsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
}
}
But this seems inefficient, as it gets set on each request, rather than globally, once.
I'm guessing there is an extensibility point somewhere in a module to set the HttpConfiguration - can anyone tell me one way or the other?
Many thanks.

How do I bind a simple POST value in ASP.NET WebAPI RC?

I have a POST method on one of my API controllers that takes a single string value:
public string Post([FromBody] string foo) {
return(fooOracle.ValidateFoo(foo) ? "success" : "failure");
}
I'm POSTing to this with the body of the post request as:
foo=123412341234
(i.e. it's a regular HTTP POST that you can initiate by submitting a browser form as well as using an HTTP client)
In the release candidate of WebAPI, this has silently stopped working - it just doesn't bind foo any more. To get the code working, I've had to replace the method with this:
public string Post(FormDataCollection form) {
var foo = form.Get("foo");
return(fooOracle.ValidateFoo(foo) ? "success" : "failure");
}
This works, but it's kinda messy and involves rather more plumbing to test than the previous version.
Have I missed some subtle change, or has the [FromBody] binding syntax been deprecated in favour of this rather verbose binding syntax? The attribute is still there but it's really not clear what it actually does in the RC version.
It's actually there is a subtle change that it cannot handle inputs like 'foo=123412341234' but will handle '=123412341234' as the input. Can you make the client send it as later?
If not you could create a wrapper class as below and make your action expect stringwrapper as a parameter rather than String itself.
Class StringWrapper { public string Foo {get; set;} }

Resources