We are removing the "?" in the syntax and continue on this route of implementation: className followed by the json representation of the properties to initialize the class.
A pull request has been opened regarding this: https://github.com/apache/geode/pull/1327 On Fri, Jan 26, 2018 at 12:38 PM, Jinmei Liao <jil...@pivotal.io> wrote: > Yes, we are debating the necessity of the "?". > > -1 on the non-json syntax though. we don't want to implement a new parser > ourselves to gather the properties. > > As to Nick's point about a generic solution that would cover initializing > not just Declarable, yes, the syntax itself does not lock down to the class > being a Declarable. However you want to configure the object using the > parsed Property, it's up to how we want to interpret this property. Our > current implementation only support using this property if the className > specified is a Declarable, but we can enhance it to support other types as > well. > > > > On Fri, Jan 26, 2018 at 12:15 PM, Swapnil Bawaskar <sbawas...@pivotal.io> > wrote: > >> +1 for ability to pass in simple key-value pairs. >> Would it be possible to loose the "?" between the class name and the json >> though? >> >> Also, since we are essentially trying to pass a java.util.Properties >> object >> to the Declarable, would it be better if we ask the users to pass-in a >> string representation of the properties object? something like: >> --cache-loader=my.CacheLoader{key2=value2, key1=value1} >> A parenthesis around the values may also help in conveying the intention: >> --cache-loader=my.CacheLoader({key2=value2, key1=value1}) >> >> On Fri, Jan 26, 2018 at 10:24 AM Nick Reich <nre...@pivotal.io> wrote: >> >> > This would solve the problem of specifying the parameters for a >> Declarable, >> > but if you provided support for any valid json, you could cover other >> > situations as well, including those with more complicated and possibly >> > nested configuration. If we would ever support such scenarios in the >> > future, I assume that we would want a generic solution that would cover >> all >> > configuration. Is this something that we anticipate needing and if so, >> how >> > would the current proposal cover such situations? >> > >> > On Fri, Jan 26, 2018 at 8:43 AM, Jens Deppe <jde...@pivotal.io> wrote: >> > >> > > This also avoids the other option of implementing this by having >> > associated >> > > 'params' options for each option which can take a Declarable, thus >> > reducing >> > > the proliferation of options - in particular for 'create region'. >> > > >> > > i.e. --cache-listener AND --cache-listener-params. >> > > >> > > Further, this json parameter would not allow for arbitrary json but >> would >> > > be restricted to a simple key/value mapping so that there would be a >> > direct >> > > translation to Declarable parameters in the cache.xml. >> > > >> > > --Jens >> > > >> > > On Fri, Jan 26, 2018 at 8:07 AM, Jinmei Liao <jil...@pivotal.io> >> wrote: >> > > >> > > > Currently, when you want to specify a call-back in gfsh command >> option, >> > > you >> > > > can only pass in the class name, e.g.: >> > > > >> > > > create region --name=regionA --type=PARTITION >> > > --cache-loader=my.CacheLoader >> > > > >> > > > But these callbacks all implements Declarable (CacheLoader, >> > CacheWriter, >> > > > CacheListener, CustomExpiry etc.), i.e they can initialized with >> extra >> > > > properties that can be set when they are declared in cache.xml, but >> > > > currently, our gfsh command doesn't support that. >> > > > >> > > > We are proposing to add the support to configure Declarables in gfsh >> > > > commands by adding json strings at the end of the class name. like >> > this: >> > > > >> > > > create region --name=regionA --type=PARTITION >> > > > --cache-loader=my.CacheLoader?{"key":"value,"key2":"value2"} >> > > > >> > > > (of course, if you don't need to configure your Declarable, you can >> > still >> > > > only specify a className as before). >> > > > >> > > > Comments/thoughts? >> > > > >> > > > -- >> > > > Cheers >> > > > >> > > > Jinmei >> > > > >> > > >> > >> > > > > -- > Cheers > > Jinmei > -- Cheers Jinmei
