Hi Magnus,
Not sure if this is the right group for this question and I did not code this 
part for a long time, and not sure if fully understood the issue, but can you 
map higlighting to Map<String, HightlightDetails>?

Also, not sure if using this in example in your tests, but you are missing 
quote for docId_0 field.

HTH,
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/



> On 23 Nov 2017, at 12:30, Magnus Ebbesson <magnus.ebbes...@findwise.com> 
> wrote:
> 
> Hi,
> 
> 
> We're started to migrate our integration-framework to move over to JavaEE 
> JSON-B as default json-serialization /deserialization framework and now the 
> highlighning component is giving us some troubles. Here's a constructed 
> example of the JSON response from Solr.
> 
> {
>  "responseHeader":{
>    "status":0,
>    "QTime":8,
>    "params":{
>      "q":"queryword",
>      "indent":"on",
>      "rows":"1",
>      "wt":"json"}},
>  "response":{"numFound":123,"start":0,"docs":[
>      {
>        "title":"some text.. Queryword some more text..",
>        "id":"docId_0"}]
>  },
>  "highlighting":{
>    docId_0":{
>      "title":["some text.. <b>queryword</b>.. some more text"]}
> 
>   }
> 
> }
> 
> 
> The JSON-B Spec (JSR- 367 Java API for JSON Binding ("Specification") 
> Version: 1.0) specifically details that when JSON Binding implementation 
> during deserialization encounters key in key/value pair that it does not 
> recognize, it should treat the rest of the JSON document as if the element 
> simply did not appear, and in particular, the implementation MUST NOT treat 
> this as an error condition.
> 
> 
> docId_0 being a dynamic key for the highlighting-response we're unable to 
> pick up and with doc-ids being totally dynamic, creating any kind of known 
> mapping for an object isn't feasible.
> 
> 
> Are there any ideas on how to solve this without having to implement a 
> custom-parser into our framework for this specific use case?
> 
> Solr-J has been ruled previously due to policies and we've used Jackson 
> Any-type in the previous version of the framework, but it has been now been 
> replaced by JSON-B standards..
> 
> 
> BR
> 
> Magnus Ebbesson
> 
> 
> 

Reply via email to