+1 to improve gfsh and use jackson consistently for all our json parsing On Wed, May 2, 2018 at 3:49 PM, Patrick Rhomberg <[email protected]> wrote:
> I was under the impression that gfsh console output was intended as a more > "active" interface with an operator. To that end, improved usability and a > more consistent output sounds like a boon to me. > > On Tue, May 1, 2018 at 3:41 PM, Jens Deppe <[email protected]> wrote: > > > Hi All, > > > > I'm working on removing our dependency on geode-json (org.json) in favor > of > > Jackson. Initially this work has revolved around refactoring the internal > > results from gfsh commands (nothing that is user-visible). > > > > I'm now looking at the various gfsh 'data' commands (get, put, query and > > locate) and would very much like them to produce more meaningful, (actual > > JSON), structured results. > > > > For example, a get on a region containing a simple 'User' object produces > > this output. > > > > Result : true > > Key Class : java.lang.String > > Key : jondoe > > Value Class : > > org.apache.geode.management.internal.cli.commands. > > GetCommandIntegrationTest.User > > > > This is not very helpful and only really shows that the value, for the > > given key, actually exists. > > > > Querying a PDX object is more informative: > > > > Result : true > > Key Class : java.lang.String > > Key : jondoe > > Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl > > > > username | hashcode > > -------- | -------- > > jondoe | 38de41a9 > > > > This brings me to the actual question. Although our Java API is backwards > > compatible, the gfsh output has never been considered an 'API' in terms > of > > the structure of it's output text. However, I do want to ask that if we > > start making changes to these commands, to produce actual JSON results, > > will that cause anyone any pain? > > > > Thoughts / comments? > > > > --Jens > > >
