I would be very interested in that pull request, too.
Changing every exception transport to a textual JSON error seems a proper
alternative. I haven't tried Jackson ObjectMapper on the exception classes
that are present in ES but it should be possible.
Jörg
On Fri, Mar 21, 2014 at 5:18 PM,
I wonder why you are asking for this feature? If its because Java broke
backward comp. on serialization of InetAddress that we use in our
exceptions, then its a bug in Java serialization, hard for us to do
something about it.
You will loose a lot by trying to serialize exceptions using JSON,
If it happened once, then by definition it will happen again. History repeats
itself. ;-)
What exactly would you lose?
You are simply trading one rigid serialization scheme for another more lenient
one.
Yes, you would have to introduce something like Jackson's Object Mapper, but
that seems to
Not trivializing the bug at all, god knows I spend close to a week tracing
it down to a JVM backward incompatibility change, but this happened once
over the almost 5 years Elasticsearch existed. To introduce a workaround to
something that happened once, compared to potential bugs in the
If this is a concern, why not have your client's use the REST api so they
don't need to worry about matching their java version with the java version
of the search cluster?
Thanks,
Matt Weber
On Fri, Mar 21, 2014 at 12:07 PM, kimchy kim...@gmail.com wrote:
Not trivializing the bug at all,
What I'm interested in would be a perspective that ES nodes could
communicate with other ES nodes by transparent (readable) data streams
specified by an ES node protocol, independent of Java serialization. So,
ES nodes in the long run could be implemented in even another language on
the JVM that
We've built our own Elasticsearch Client that has niceties like; OAuth, the
ability to swap Clusters for maintenance, Zookeeper integration, ease of
configuration, retries, etc.
Otherwise we'd have a lot of wheel reinventing going on.
Plus, the Java Client is pretty nice, after all. ;-)
Thanks
