On Thu, Oct 4, 2018 at 7:23 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Rémy, > > On 10/4/18 05:26, Rémy Maucherat wrote: > > On Wed, Oct 3, 2018 at 10:27 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > >> Rémy, > >> > >> On 10/3/18 09:48, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> As I talked about during the latest TomcatCon (and the previous > >>> one in London actually ...), there's a cloud aware cluster > >>> members provider that can be contributed to Tomcat. > >>> > >>> The current code is here: > >>> https://github.com/rmaucher/tomcat-in-the-cloud It uses > >>> Kubernetes to retrieve the members of a cluster, rather than > >>> multicast (which isn't available) or static (which is well ... > >>> static) member providers. > >>> > >>> Credits: Maxime Beck and JGroups did the initial code Keiichi > >>> Fujino explained how to refactor it to fit in the Catalina > >>> cluster API and I refactored it as he told me to > >>> > >>> Problems: Only does Kubernetes for now (which is likely ok > >>> since it's now widely available) JSON parser dependency > >>> (org.json) that is likely not ok to have as is in the lib > >>> folder (solutions: package renaming using a script or include > >>> json code in Tomcat) > >> > >> Solr uses this JSON parser which is quite fast, although the API > >> is a little little awkward because of it: > >> > >> https://github.com/yonik/noggit > >> > >> AL2 license > >> > >> I'm not sure it's necessary to have a "streaming JSON" parser as > >> opposed to a more "traditional" one where the whole JSON object > >> is converted into objects before the client code can do anything > >> with them. > >> > > > > The json from Kube is simple. > > > > The org.json parser is very dom like, this event based one looks > > good I guess. Is it worth changing my code ? Given the parser size, > > event based nature and the presence of a "writer", this noggit > > could be worth package renaming (IMO for this one that's the only > > viable strategy as I'm not sure there's much maintenance or use > > going on - maybe it's bug free ;) ). After all, we might need/use > > more json handling in Tomcat in the future (right ?). > > I like the Noggit code because it's insanely small and produces > regular Java objects instead of the nonsense that most JSON libraries > produce, with JSONObject and JSONArray, etc. > > Compare sizes: > > version bytes classes > Noggit 0.8 27948 14 > org.json (unknown) 43895 21 > gson 2.3.1 210856 165 > > If you want to use it in a streaming/progressive/eventing kind of way, > you can. Or you can call the "gimmie the tree" method and get a whole > object tree back. > > The documentation is non-existent AFAICT, so I've had to read the code > to figure out how to use it, which is a little frustrating. > > Ok ! For now I switched to openjson, since it's the same nonsense API as the other one (so no retesting needed for now), without the "no evil" clause. I had read the org.json license actually and thought the evil clause was just for fun, but I guess lawyers aren't amused. Rémy
