-
Notifications
You must be signed in to change notification settings - Fork 303
Expose exception handling to AbstractJsonDeserializer API #684
Comments
Thanks for the feedback. I do agree that AbstractJsonDeserializer is not designed well. My suggestion for devon4j would be to do the following:
For oasp4j I would tend to do nothing. If you want to have this simple do not extend |
|
Maybe it would be even better to make the static methods non-static, the private methods protected and add a static get method returning a singleton instance. Also we could instead include that into archetype rather than JSON module. |
See also #198 - Jackson has some historical design flaws that makes it hard to reuse custom mapping logic and compose higher level object mappings out of that. On the other hand from my experiments JSON-B seems to be quite limited as well. |
I like the static methods. The singleton is even not better in regards to testing, so let us take the static methods as is. Let's not put it into the archetype, although it will foster visibility and usage. The discussions in the last years about the non-needed classes in archetype shows the demands of the users. Let's keep it clean and provide hints in the documentation pointing at our util classes. |
…sed for exception/I18N stuff) oasp/oasp4j#684: replaced AbstractJsonDeserializer with JacksonUtil
* #8: fixed build to work with Java8 and Java9-11 #9: fixed dependencies so security also works with Java8 and Java9-11 * #13: removed deprecated code * #14: decoupling from mmm-util-entity (mmm-util-core is still used for exception/I18N stuff) oasp/oasp4j#684: replaced AbstractJsonDeserializer with JacksonUtil * #13: removed more deprecated code * #14: not considered a todo anymore. With dropping this exception support we would lose valuable features and making it optional seems to be overcomplicated. * #14: completed (adapted bean-mapping, moved PersistenceEntity also to basic for simplicity, decoupled web component, upgraded to modularized mmm-util and reduced dependency to mmm-util-exception) * #21: try to cache maven repo to make build more stable
Inheriting the AbstractJsonDeserializer, I would like to throw any processing exception resulting in jackson to understand that deserialization did not work our properly.
Currently, the API of jackson completely hidden behind the abstract method (the API of AbstractJsonDeserializer) to be implemented.
So what is missing is basically, the ability to throw any IOException, which I consider as a bug. Currently, the AbstractJsonDeserializer is not really useful. Even although it took me a while to find the code snippet for reading JSON as a tree. I would now consider it as not useful to just provide parts of the parameters provided by jackson to the API of AbstractJsonDeserializer.
The helper method throws IllegalStateExceptions, but most probably should throw the intended
JsonProcessingException
given by Jackson?The text was updated successfully, but these errors were encountered: