You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Michael Vorburger (Jira)" <ji...@apache.org> on 2020/01/05 16:39:00 UTC
[jira] [Created] (FINERACT-819) Enable "normal" (usual) JSON
mapping to request Java objects
Michael Vorburger created FINERACT-819:
------------------------------------------
Summary: Enable "normal" (usual) JSON mapping to request Java objects
Key: FINERACT-819
URL: https://issues.apache.org/jira/browse/FINERACT-819
Project: Apache Fineract
Issue Type: Improvement
Affects Versions: 1.4.0
Reporter: Michael Vorburger
Based on experience/observation while attempting to implement FINERACT-726 via [https://github.com/apache/fineract/compare/develop...vorburger:FINERACT-726_Auth] :
In Fineract as is it does not seem to be easily possible to "just" write a JAX RS *Resource API class with a method which instead of {{@QueryParam}} or {{String apiRequestBodyAsJson}} like everywhere else in existing code simply accepts a regular POJO class such as {{AuthenticateRequest}} - which is how JAX RS (or even Spring MVC) is typically used; that fails with:
{noformat}
A message body reader for Java class org.apache.fineract.infrastructure.security.api.AuthenticationApiResource$AuthenticateRequest, and Java type class org.apache.fineract.in
frastructure.security.api.AuthenticationApiResource$AuthenticateRequest, and MIME media type application/octet-stream was not found.
The registered message body readers compatible with the MIME media type are:
application/octet-stream ->
com.sun.jersey.core.impl.provider.entity.ByteArrayProvider
com.sun.jersey.core.impl.provider.entity.FileProvider
com.sun.jersey.core.impl.provider.entity.InputStreamProvider
com.sun.jersey.core.impl.provider.entity.DataSourceProvider
com.sun.jersey.core.impl.provider.entity.RenderedImageProvider
*/* ->
com.sun.jersey.core.impl.provider.entity.FormProvider
com.sun.jersey.core.impl.provider.entity.MimeMultipartProvider
com.sun.jersey.core.impl.provider.entity.StringProvider
com.sun.jersey.core.impl.provider.entity.ByteArrayProvider
com.sun.jersey.core.impl.provider.entity.FileProvider
com.sun.jersey.core.impl.provider.entity.InputStreamProvider
com.sun.jersey.core.impl.provider.entity.DataSourceProvider
com.sun.jersey.core.impl.provider.entity.XMLJAXBElementProvider$General
com.sun.jersey.core.impl.provider.entity.ReaderProvider
com.sun.jersey.core.impl.provider.entity.DocumentProvider
com.sun.jersey.core.impl.provider.entity.SourceProvider$StreamSourceReader
com.sun.jersey.core.impl.provider.entity.SourceProvider$SAXSourceReader
com.sun.jersey.core.impl.provider.entity.SourceProvider$DOMSourceReader
com.sun.jersey.json.impl.provider.entity.JSONJAXBElementProvider$General
com.sun.jersey.json.impl.provider.entity.JSONArrayProvider$General
com.sun.jersey.json.impl.provider.entity.JSONObjectProvider$General
com.sun.jersey.core.impl.provider.entity.XMLRootElementProvider$General
com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$General
com.sun.jersey.core.impl.provider.entity.XMLRootObjectProvider$General
com.sun.jersey.core.impl.provider.entity.EntityHolderReader
com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider$General
com.sun.jersey.json.impl.provider.entity.JSONListElementProvider$General
com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy {noformat}
To move forward/unblock FINERACT-726, I've gone for the {{String apiRequestBodyAsJson}} approach there, and then using {{GSON}} code to parse the JSON explicitly, but that approach, used in other Resource classes in Fineract as well, seems kind of really dumb, to me.
Perhaps in the future we can figure out the problem above, and switch to the simpler more standard programming model everywhere.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)