[
https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000277#comment-17000277
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14095:
------------------------------------------------------
This is an example output of the REQUESTSTATUS of a CREATE command using my
JSON patch:
{code:xml}
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">2</int>
</lst>
<lst name="success">
<lst name="127.0.0.1:7574_solr">
<lst name="responseHeader">
<long name="status">0</long>
<long name="QTime">0</long>
</lst>
<str name="STATUS">completed</str>
<str name="Response">
...
</str>
</lst>
{code}
See how "status" turns into a long, which will likely cause ClassCastExceptions
in the client code when used with Javabin. And the solution can't be to deal
with the specific cases where we need an int vs long, since the data that can
be in those internal responses is unknown (and again, subject to change).
I think we can do some work to standarize what the different commands can
return, and replace the NamedList with a typed object to some extent, but
that's a larger task and unlikely to be made backward compatible
> Remove serialization and/or support serialization filtering
> -----------------------------------------------------------
>
> Key: SOLR-14095
> URL: https://issues.apache.org/jira/browse/SOLR-14095
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Robert Muir
> Priority: Major
> Attachments: SOLR-14095-json.patch, json-nl.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Removing the use of serialization is greatly preferred.
> But if serialization over the wire must really happen, then we must use JDK's
> serialization filtering capability to prevent havoc.
> https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
