We're currently using GWT RPC for serialization on a GWT project but we're currently maintaining two sets of objects - the object that we need to convert for the database to retrieve/save and a version of the object that is safe for GWT RPC serialization (no enums/big decimal, etc.).
We're spending a lot of effort writing code that merely converts from one format to the other format. In addition it's pretty painful to make any changes to the data model because it has to be changed in two places.
I was thinking that we could use a combination of Spring 3.0 MVC and Jackson to replace the RPC calls with JSON calls. If we built JavaScript objects for GWT to hold this JSON data, then it would remove the need for any property conversion code. However we'd still have to maintain two sets of objects - one JavaScriptObject for the client side code and the server side representation.
To eliminate this layer, to take a Java object and have it produce a GWT JavaScriptObject with the JSNI getters/setters exposed. Is there a library out there that could do this automatically?
We eventually dropped GWT and went with a Spring MVC/jQuery solution, but I did find the protostuff library which looked like it could do most of what I was looking for.
Related
I'm trying to implement a logic that serializes and de-serializes a very complex legacy object. The object contains other complex objects inside of it that are spread through various other projects. There are even some JAXB1 objects that are generated from an xsd schemas and are part of the chain.
Right now there is already a working version that uses XStream and this worked for years. But since Java 17 there are issues because of the new restriction for using reflection on private fields from different modules. Exceptions like this started to appear ->
Module {A} does not 'opens {package}' to {B}". One of the things that bothers me is that all of these packages are from some third party libs and I even can't find any objects from them in the model chain.
So I started implementing a new serialization based on the Jackson databind API but right now I'm wondering is it going to solve the issues at all? Does Jackson also use reflection in case to serialize and de-serialize? What is the best way to configure the ObjectMapper and what should I change in the objects that I need to work with in case to make the reflection usage as low as possible?
Right now I've configure the ObjectMapper as:
objectMapper.disable(MapperFeature.AUTO_DETECT_CREATORS,
MapperFeature.AUTO_DETECT_FIELDS,
MapperFeature.AUTO_DETECT_GETTERS,
MapperFeature.AUTO_DETECT_IS_GETTERS);
objectMapper.disable(SerializationFeature.FAIL_ON_EMPTY_BEANS);
and I'm annotating all fields that should be serialized with #JsonProperty but I'm not sure that this is going to help. Okay, I assume I must have getters and setters, but should I also annotate them? Does the annotation has something to do with the reflection usage at all?
My application's vaadin version is upgraded from 7.3.6 to 7.4.6 and my Json code wherever I was using the GSON is starting to break.
I did googling for the same I found the similar issue mentioned in this stackOverflowPost
So should I conclude that elemental.json is not compatible with GSON and org.json was compatible with GSON.
GSON is not GWT compatible, which makes sense since it requires reflection to do its work. Likewise, org.json is meant to be used on a normal JVM.
On the other hand, GWT knows it is running in the browser, so doesn't need to implement its own JSON parser, since the browser already has one. There are several ways to use JSON in GWT, and GSON, org.json, and the built-in JSON parser of the browser all speak the same JSON.
All are compatible with each other, though you can't simply use elemental on the server or GSON on the client, or reuse the same server types on the client.
What specifically is 'starting to break'? What errors do you get, and what does the data that you are trying to send look like?
(Also worth noting, some of the 'json' in the linked post uses ' quotes for properties and strings, which is not legal JSON and should not work in the first place with any proper JSON parser.)
Currently doing some exams and I'm struggling through some concepts. These have all been 'mentioned' in my notes really but I didn't really understand how they all linked together. As far as my understanding is:
SOA - a solution to make service consumers/providers communicate. (as far as I understand this is the umbrella term for everything else)
WSDL - A language that describes the provider service.
SOAP - A XML protocol 'wrapper' used by the services to send messages. Works in conjunction with WSDL as to provide parameters?
REST - A design pattern that is similar to SOAP in function but avoids the XML? (really not sure about this one)
JSON - An alternative to XML that uses javascript? (not sure about this one either)
Looking around in the internet there doesn't seem to be a clear definition of what all of these are and how they interlink.
Imagine you are developing a web-application and you decide to decouple the functionality from the presentation of the application, because it affords greater freedom.
You create an API and let others implement their own front-ends over it as well. What you just did here is implement an SOA methodology, i.e. using web-services.
Web services make functional building-blocks accessible over standard
Internet protocols independent of platforms and programming languages.
So, you design an interchange mechanism between the back-end (web-service) that does the processing and generation of something useful, and the front-end (which consumes the data), which could be anything. (A web, mobile, or desktop application, or another web-service). The only limitation here is that the front-end and back-end must "speak" the same "language".
That's where SOAP and REST come in.
They are standard ways you'd pick communicate with the web-service.
SOAP:
SOAP internally uses XML to send data back and forth. SOAP messages have rigid structure and the response XML then needs to be parsed.
WSDL is a specification of what requests can be made, with which parameters, and what they will return. It is a complete specification of your API.
REST:
REST is a design concept.
The World Wide Web represents the largest implementation of a system
conforming to the REST architectural style.
It isn't as rigid as SOAP. RESTful web-services use standard URIs and methods to make calls to the webservice. When you request a URI, it returns the representation of an object, that you can then perform operations upon (e.g. GET, PUT, POST, DELETE). You are not limited to picking XML to represent data, you could pick anything really (JSON included)
Flickr's REST API goes further and lets you return images as well.
JSON and XML, are functionally equivalent, and common choices. There are also RPC-based frameworks like GRPC based on Protobufs, and Apache Thrift that can be used for communication between the API producers and consumers. The most common format used by web APIs is JSON because of it is easy to use and parse in every language.
WSDL: Stands for Web Service Description Language
In SOAP(simple object access protocol), when you use web service and add a web service to your project, your client application(s) doesn't know about web service Functions. Nowadays it's somehow old-fashion and for each kind of different client you have to implement different WSDL files. For example you cannot use same file for .Net and php client.
The WSDL file has some descriptions about web service functions. The type of this file is XML. SOAP is an alternative for REST.
REST: Stands for Representational State Transfer
It is another kind of API service, it is really easy to use for clients. They do not need to have special file extension like WSDL files. The CRUD operation can be implemented by different HTTP Verbs(GET for Reading, POST for Creation, PUT or PATCH for Updating and DELETE for Deleting the desired document) , They are based on HTTP protocol and most of times the response is in JSON or XML format. On the other hand the client application have to exactly call the related HTTP Verb via exact parameters names and types. Due to not having special file for definition, like WSDL, it is a manually job using the endpoint. But it is not a big deal because now we have a lot of plugins for different IDEs to generating the client-side implementation.
SOA: Stands for Service Oriented Architecture
Includes all of the programming with web services concepts and architecture. Imagine that you want to implement a large-scale application. One practice can be having some different services, called micro-services and the whole application mechanism would be calling needed web service at the right time.
Both REST and SOAP web services are kind of SOA.
JSON: Stands for javascript Object Notation
when you serialize an object for javascript the type of object format is JSON.
imagine that you have the human class :
class Human{
string Name;
string Family;
int Age;
}
and you have some instances from this class :
Human h1 = new Human(){
Name='Saman',
Family='Gholami',
Age=26
}
when you serialize the h1 object to JSON the result is :
[h1:{Name:'saman',Family:'Gholami',Age:'26'}, ...]
javascript can evaluate this format by eval() function and make an associative array from this JSON string. This one is different concept in comparison to other concepts I described formerly.
I am writing a Java EE app to be run within either Glassfish or JBoss, and I've been asked to provide JSON support for our JAX-RS clients.
Of course, simply enabling the JSON media type is simple enough but results in vendor-specific representations of my JAXB annotated models. So I'm looking for a way forward, one that ensures my tests work with both AS servers and that I still leverage JAXB/JAX-RS instead of writing lots of custom code.
I've tried adding a jaxb.properties file to select a specific implementation, but presumably shipping Jackson/MOXy/other JAXB library may conflict with provided libraries?
Any other ideas would be appreciated.
The custom BeanSerializerFactory in http://kyrill007.livejournal.com/2577.html is the only custom solution I found to allow directly throwing persistent beans to JSON via Spring 3.0, and it works, it only serializes non initialized (lazy) attributes / collections (this allows me to use the entity Pojo as a DTO, as I initialize only what I want, and what is not initialized, doesn't get serialized to JSON)
But this worked well with Jackson 1.6, and I wanted to upgrade to Jackson 1.8 to solve the issue with Java Generics (hopefully) and now that custom solution is not compiling.
So my questions are
What is the recomended way to auto serialize Entities to JSON without the need of DTOs
Is there an official Hibernate Aware Jackson BeanSerializerFactory besides the above
I'm starting to fear that if it's that hard to find, maybe my practice is not the best one
What is the recommended way to do RESTful Ajax then with Spring 3.0 MVC and JSON?
The problems to solve are
Not serializing lazy attributes / collections automatially (as the custom code above does)
Supporting Java Generics and some kind of a client side object schema / validation
What works on get should work on save, and allow partial objects graphs to be returned safely
Is there Anything? do I have to manually write DTOs for every Entity?, this is so non productive
While SO has lots of experts, you might consider also asking on Jackson users list. Kirill (author of the blog entry) is responsive, and there are other experts there as well.