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
