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)
