thanks, Shalin! We have survived by passing our custom structure string in
Json. Still to be tested for performance.
On Sat, Aug 8, 2015 at 5:22 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:
> Or use the XsltResponseWriter :)
>
> On Sat, Aug 8, 2015 at 7:51 PM, Shalin Shekhar Mangar
> <shalinman...@gmail.com> wrote:
> > No, I'm afraid you will have to extend the XmlResponseWriter in that
> case.
> >
> > On Sat, Aug 8, 2015 at 2:02 PM, Dmitry Kan <solrexp...@gmail.com> wrote:
> >> Shalin,
> >>
> >> Thanks, can I also introduce custom entity tags like in my example with
> the
> >> highlighter output?
> >>
> >> Dmitry
> >>
> >> On Fri, Aug 7, 2015 at 5:10 PM, Shalin Shekhar Mangar <
> >> shalinman...@gmail.com> wrote:
> >>
> >>> The thing is that you are trying to introduce custom xml tags which
> >>> require changing the response writers. Instead, if you just used
> >>> nested maps/lists or SimpleOrderedMap/NamedList then every response
> >>> writer should be able to just directly write the output. Nesting is
> >>> not a problem.
> >>>
> >>> On Fri, Aug 7, 2015 at 6:09 PM, Dmitry Kan <solrexp...@gmail.com>
> wrote:
> >>> > Shawn:
> >>> >
> >>> > thanks, we found an intermediate solution by serializing our data
> >>> structure
> >>> > using string representation, perhaps less optimal than using binary
> >>> format
> >>> > directly.
> >>> >
> >>> > In the original router with JavaBinCodec we found, that
> >>> > BinaryResponseWriter should also be extended. But the following
> method is
> >>> > static and does allow extending:
> >>> >
> >>> > public static NamedList<Object> getParsedResponse(SolrQueryRequest
> >>> > req, SolrQueryResponse rsp) {
> >>> > try {
> >>> > Resolver resolver = new Resolver(req, rsp.getReturnFields());
> >>> >
> >>> > ByteArrayOutputStream out = new ByteArrayOutputStream();
> >>> > new JavaBinCodec(resolver).marshal(rsp.getValues(), out);
> >>> >
> >>> > InputStream in = new ByteArrayInputStream(out.toByteArray());
> >>> > return (NamedList<Object>) new
> JavaBinCodec(resolver).unmarshal(in);
> >>> > }
> >>> > catch (Exception ex) {
> >>> > throw new RuntimeException(ex);
> >>> > }
> >>> > }
> >>> >
> >>> >
> >>> >
> >>> > Shalin:
> >>> >
> >>> > We needed new data structure in highlighter with more nested levels,
> >>> > than just one. Something like this (in xml representation):
> >>> >
> >>> > <lst name="highlighting">
> >>> > <lst name="doc1">
> >>> > <arr name="snippets">
> >>> > <snippet>
> >>> >
> >>> > <id>id1</id>
> >>> >
> >>> > <contents>Snippet text goes here</contents>
> >>> >
> >>> > <other params/>
> >>> >
> >>> > </snippet>
> >>> >
> >>> > </arr>
> >>> >
> >>> >
> >>> > </lst></lst>
> >>> >
> >>> > Can this be modelled with existing types?
> >>> >
> >>> >
> >>> > On Thu, Aug 6, 2015 at 9:47 PM, Shalin Shekhar Mangar <
> >>> > shalinman...@gmail.com> wrote:
> >>> >
> >>> >> What do you mean by a custom format? As long as your custom
> component
> >>> >> is writing primitives or NamedList/SimpleOrderedMap or collections
> >>> >> such as List/Map, any response writer should be able to handle them.
> >>> >>
> >>> >> On Wed, Aug 5, 2015 at 5:08 PM, Dmitry Kan <solrexp...@gmail.com>
> >>> wrote:
> >>> >> > Hello,
> >>> >> >
> >>> >> > Solr: 5.2.1
> >>> >> > class: org.apache.solr.common.util.JavaBinCodec
> >>> >> >
> >>> >> > I'm working on a custom data structure for the highlighter. The
> data
> >>> >> > structure is ready in JSON and XML formats. I need also JavaBin
> >>> format.
> >>> >> The
> >>> >> > data structure is already made serializable by extending the
> >>> >> WritableValue
> >>> >> > class (methods write and resolve).
> >>> >> >
> >>> >> > To receive the custom format on the client via solrj api, the data
> >>> >> > structure needs to be parseable by JavaBinCodec. Is this correct
> >>> >> > assumption? Can we introduce the custom data structure consumer
> on the
> >>> >> > solrj api without complete overhaul of the api? Is there plugin
> >>> framework
> >>> >> > such that JavaBinCodec is extended and used for the new data
> >>> structure?
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Dmitry Kan
> >>> >> > Luke Toolbox: http://github.com/DmitryKey/luke
> >>> >> > Blog: http://dmitrykan.blogspot.com
> >>> >> > Twitter: http://twitter.com/dmitrykan
> >>> >> > SemanticAnalyzer: www.semanticanalyzer.info
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Regards,
> >>> >> Shalin Shekhar Mangar.
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Dmitry Kan
> >>> > Luke Toolbox: http://github.com/DmitryKey/luke
> >>> > Blog: http://dmitrykan.blogspot.com
> >>> > Twitter: http://twitter.com/dmitrykan
> >>> > SemanticAnalyzer: www.semanticanalyzer.info
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Shalin Shekhar Mangar.
> >>>
> >>
> >>
> >>
> >> --
> >> Dmitry Kan
> >> Luke Toolbox: http://github.com/DmitryKey/luke
> >> Blog: http://dmitrykan.blogspot.com
> >> Twitter: http://twitter.com/dmitrykan
> >> SemanticAnalyzer: www.semanticanalyzer.info
> >
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
--
Dmitry Kan
Luke Toolbox: http://github.com/DmitryKey/luke
Blog: http://dmitrykan.blogspot.com
Twitter: http://twitter.com/dmitrykan
SemanticAnalyzer: www.semanticanalyzer.info
