AutoBean Compile Error: "Parameterization is not simple..." - json

I'm trying to use AutoBean on the server and client to send and receive json data through AppEngines channel API. I don't want to store this data in the datastore. I already have a Proxy for this object that I use for the RequestFactoryServlet (which underneath just uses AutoBean anyways), so this should be doable. Instead of writing up a new Proxy for the object that exactly duplicates the Proxy for the RequestFactoryServlet, I'd like to just use the proxy that I use for the RequestFactoryServlet. The only problem is that I get an error while compiling that comes from my AutoBeanFactory.
Invoking generator
com.google.web.bindery.autobean.gwt.rebind.AutoBeanFactoryGenerator
[ERROR] The com.wmba.wmbaapp.shared.ObjectProxy parameterization is not simple, but the obj method does not provide a
delegate
So I'm not really sure what to do here. It seems like before I added the client side in, it's able to serialize the object into JSON just fine, but for some reason it doesn't like this. It sounds like it wants a delegate from me, but I can't find anything on this from the internet.
Anyone have any ideas?
Note: I also tried the same thing with EntityProxy (which is the base of the RequestFactory framework from what I read on the AutoBean page, but I get the same error).

The issue is that EntityProxy defines the stableId method which is not a getter (name doesn't start with get). That makes it a not simple bean, for which AutoBeans require a real bean instance to be wrapped in the created AutoBean (the delegate, passed as an argument of the type of the AutoBean –ObjectProxy in your case– to your obj method of the AutoBeanFactory).
In other words, AutoBeans expects your obj method to be of the form:
AutoBean<ObjectProxy> obj(ObjectProxy toWrap);
The simplest solution is to not try to reuse the entity proxy with AutoBeans.
You might be able to make it work though by annotating your AutoBeanFactory with:
#Category(EntityProxyCategory.class)
You might have to add #NoWrap(EntityProxyId.class) too, see http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/web/bindery/requestfactory/vm/InProcessRequestFactory.java

It turned out for me that I had a property setter that had an empty parameter list in my Ojbect interface. It didn't have anything to do with the factory, except for the interface the factory was trying to create a proxy for:
interface Factory {
AutoBeans<MyObject> createObject();
}
interface MyObject {
String getProperty();
void setProperty();
}
A bone-headed mistake but held me up with this precise compiler error. Adding the Category annotation as mentioned in the previous answer identified the faulty property setter.

Related

How to define custom handling for a response class in Spring doc?

I've been using arrow-kt and spring together a lot lately. I've actually constructed a bridge between the two with several key features, one of which is a spring controller that returns an Either will automatically unwrap it and either handle the exception (Left) or return the result (Right). My long term goal is to publish this as a library.
My latest obstacle is Swagger, or more accurately springdoc openapi. Obviously it is seeing the Either, but i want it to show only the Right value as the success response type. While I know there are annotations where I can set the response model on each controller method individually, I'm trying to avoid this.
My real goal is to setup some global converter so that wherever Swagger sees an Either it will automatically unpack this. I'm just not super familiar with the customization API in Spring doc, and everything I Google just points me to the ApiResponse annotation solution.
How can I define default handling for this type of response?

How to configure aspnet core json serialization

I reported this issue https://github.com/dotnet/runtime/issues/48816 and the developer that responded posted code explaining how to manually deserialize the function argument. Asp is supposed to have an automated system for this however. So if my function definition looks like:
[Authorize]
[HttpPost]
public async Task<IActionResult> Post(Session session)
{
...
then I am supposed to be able to just use session as a variable from that point without any special deserialization step. This suggests to me that there must be a way to set JsonSerializerOptions(JsonSerializerDefaults.Web) somewhere in a more global way so that it can consume the post data it is getting. Alternatively there might be a different way to serialize the post data differently on the client so that it does not get converted to camel case.
The main question is: what is the correct way to serialize and deserialize data objects for asp.net-core?
To Reproduce
Thanks for Roar S's comment, use [FromBody], it works.

#RequestBody with generic

I have a necessity to deserialize a JSON message into a generic object/interface and not to a specific type.
I went throught this post Interfaces and #RequestBody and tried to implement the same.
But again it failed with the same error
Can not construct instance of XXXXX, problem: abstract types either need to be mapped to concrete types, have custom deserializer, or be instantiated with additional type information
When the control reaches the method, the object is constructed as a linked hash map.
What might have gone wrong? Am I approaching the solution rightly?

Binding JSON to nested Grails Domain Objects

I'm developing a RESTful interface which is used to provide JSON data for a JavaScript application.
On the server side I use Grails 1.3.7 and use GORM Domain Objects for persistence. I implemented a custom JSON Marshaller to support marshalling the nested domain objects
Here are sample domain objects:
class SampleDomain {
static mapping = { nest2 cascade: 'all' }
String someString
SampleDomainNested nest2
}
and
class SampleDomainNested {
String someField
}
The SampleDomain resource is published under the URL /rs/sample/ so /rs/sample/1 points to the SampleDomain object with ID 1
When I render the resource using my custom json marshaller (GET on /rs/sample/1), I get the following data:
{
"someString" : "somevalue1",
"nest2" : {
"someField" : "someothervalue"
}
}
which is exactly what I want.
Now comes the problem: I try to send the same data to the resource /rs/sample/1 via PUT.
To bind the json data to the Domain Object, the controller handling the request calls def domain = SampleDomain.get(id) and domain.properties = data where data is the unmarshalled object.
The binding for the "someString" field is working just fine, but the nested object is not populated using the nested data so I get an error that the property "nest2" is null, which is not allowed.
I already tried implementing a custom PropertyEditorSupport as well as a StructuredPropertyEditor and register the editor for the class.
Strangely, the editor only gets called when I supply non-nested values. So when I send the following to the server via PUT (which doesn't make any sense ;) )
{
"someString" : "somevalue1",
"nest2" : "test"
}
at least the property editor gets called.
I looked at the code of the GrailsDataBinder. I found out that setting properties of an association seems to work by specifying the path of the association instead of providing a map, so the following works as well:
{
"someString" : "somevalue1",
"nest2.somefield" : "someothervalue"
}
but this doesn't help me since I don't want to implement a custom JavaScript to JSON object serializer.
Is it possible to use Grails data binding using nested maps? Or do I really heave to implement that by hand for each domain class?
Thanks a lot,
Martin
Since this question got upvoted several times I would like to share what I did in the end:
Since I had some more requirements to be implemented like security etc. I implemented a service layer which hides the domain objects from the controllers. I introduced a "dynamic DTO layer" which translates Domain Objects to Groovy Maps which can be serialized easily using the standard serializers and which implements the updates manually. All the semi-automatic/meta-programming/command pattern/... based solutions I tried to implement failed at some point, mostly resulting in strange GORM errors or a lot of configuration code (and a lot of frustration). The update and serialization methods for the DTOs are fairly straightforward and could be implemented very quickly. It does not introduce a lot of duplicate code as well since you have to specify how your domain objects are serialized anyway if you don't want to publish your internal domain object structure. Maybe it's not the most elegant solution but it was the only solution which really worked for me. It also allows me to implement batch updates since the update logic is not connected to the http requests any more.
However I must say that I don't think that grails is the appropriate tech stack best suited for this kind of application, since it makes your application very heavy-weight and inflexbile. My experience is that once you start doing things which are not supported by the framework by default, it starts getting messy. Furthermore, I don't like the fact that the "repository" layer in grails essentially only exists as a part of the domain objects which introduced a lot of problems and resulted in several "proxy services" emulating a repository layer. If you start building an application using a json rest interface, I would suggest to either go for a very light-weight technology like node.js or, if you want to/have to stick to a java based stack, use standard spring framework + spring mvc + spring data with a nice and clean dto layer (this is what I've migrated to and it works like a charm). You don't have to write a lot of boilerplate code and you are completely in control of what's actually happening. Furthermore you get strong typing which increases developer productivity as well as maintainability and which legitimates the additional LOCs. And of course strong typing means strong tooling!
I started writing a blog entry describing the architecture I came up with (with a sample project of course), however I don't have a lot of time right now to finish it. When it's done I'm going to link to it here for reference.
Hope this can serve as inspiration for people experiencing similar problems.
Cheers!
It requires you to provide teh class name:
{ class:"SampleDomain", someString: "abc",
nest2: { class: "SampleDomainNested", someField:"def" }
}
I know, it requires different input that the output it produces.
As I mentioned in the comment earlier, you might be better off using the gson library.
Not sure why you wrote your own json marshaller, with xstream around.
See http://x-stream.github.io/json-tutorial.html
We have been very happy with xstream for our back end (grails based) services and this way you can render marshall in xml or json, or override the default marshalling for a specific object if you like.
Jettison seems to produce a more compact less human readable JSON and you can run into some library collision stuff, but the default internal json stream renderer is decent.
If you are going to publish the service to the public, you will want to take the time to return appropriate HTTP protocol responses for errors etc... ($.02)

How to construct objects and related objects from JSON request using Spring

I'm POSTing a JSON request to a Spring 3.0 controller. The method signature is...
#RequestMapping(value="/add", method=RequestMethod.POST)
public #ResponseBody Map<String, ? extends Object> add(#RequestBody Entry)
The JSON looks like this...
{"user":"1"}
The Entry object has one attribute of type User.
When a request is submitted this error is thrown,
org.codehaus.jackson.map.JsonMappingException: Can not construct instance of com.x.y.z.Entry, problem: no suitable creator method found
I'm guessing the error is due to the fact that user on Entry is of type User rather than String ("1" is being passed in on the JSON).
Is there a way of taking the "1" coming in and using it to create a real User object (by looking it up in the database in this case)?
Does Entry have a parameterless constructor?
That's your first place to look. Normally errors of this nature occur because the code is looking for a parameterless constructor to create Entry with.
Your idea, that is to create User as the real user is fine, but it should be done after this method is called, in some other layer or something. You wanna keep things simple by not interfering with the marshalling of the json. You can add onto this with another layer.