I am sorry, I mean for encodings. We should improve the warnings, and
design and plan
how to handle non utf-8 separately.
On April 21, 2017 at 13:28:09, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:
Otto, are you referring to the 80% plus case of encodings or the compiler
warnings i
Otto, are you referring to the 80% plus case of encodings or the compiler
warnings in general? I'm not sure I agree about leaving the encoding as is,
but I do agree that we should split the work out from the other javac
compiler warnings. Right now we're at the whim of the OS default when we
haven'
Until there is a use case supporting changing to other then the 80% plus
case, this should not be changed.
or a customer requirement etc. This would need some design and discussion
time as well to map out all the
implications for the complete pipeline.
I think configurable charset should be separ
Nick,
You're not off base at all. This is exactly the push back I wanted to hear.
I wasn't really sure if what I was proposing was the proper way of going
about it. My understanding of charsets is limited, and I've usually just
defaulted to UTF-8. That being said, right or wrong, my thought proces
I think Nick brings up some good points. Would there ever be a reason to
not use UTF8 as the default from parsing a message on? All the tools we
use for analytics work with UTF8 (am I wrong?).
The only case I can see needing a configurable charset would be if a
message coming from a sensor were
Personally, I think it makes sense to have an inbound/outbound charset
setting for the parsers. We should generally standardize on UTF-8 across
Metron and its topologies, but accept potentially different charsets from
the inbound sensors. That is to say, standardize the defaults for the
things we d
Per (2), I think it makes sense to make the charset configurable, but with
the proposal of 3 separate settings, wouldn't things blow up horribly if
the Parsers are producing UTF-8, but Enrichment is expecting UTF-16? They
are not even speaking the same language, no?
This makes me think that we ne
First off, I would absolutely love to see the warnings reduced and the
quality of our code improved. I'm in favor of all four of the points, and
I think it's a good start towards weeding out a lot of issues.
So regarding question 1:
That awkwardness comes about because org.simple.json is all unt
Hello everybody,
Currently our build has a significant amount of warnings (most from the
error prone plugin). A lot of this has been documented here:
https://issues.apache.org/jira/browse/METRON-617
I want to continue to work on this Jira. I really want to reduce the number
of warnings in our bui
