[infinispan-dev] configuration toProperties

[Dan Berindei]

I think the properties format is too closely tied to your particular use
case - in general having a long prefix on every line would actual settings
harder to see than in a structured format like XML/JSON/YAML, not easier.
And if the cache name is repeated on every line, you can't easily compare
the configuration of two nodes or of two caches - all the lines would be
different.

I'm also not sure about implementing
toProperties()/append(StringBuilder)/etc. in every configuration class
instead of using reflection. We already have a lot of changes to make when
we add/modify a setting, I'd rather not make that even harder than it is.



On Tue, Nov 19, 2013 at 5:18 PM, Michal Linhard <mlinhard at redhat.com> wrote:

> No need for java.util.Properties, the main feature I want is
> - Configuration displayable as collection of flat key-value properties
> - Hierarchy (e.g. l1 is under clustering) is expressed via extending the
> prefix and dividing by dot '.'
>
> but it would be usefull if the outputformat was easily parceable, using
> common Java SE means
> one advantage of not using string as output value and keeping a
> collection like java.util.Properties
> that you can easily combine more of the configs (give them different
> prefixes) and sort them in the end
>
> that's what I do in PerfRepo:
> config.node01.cache.clustering...
> config.node01.global...
> config.node01.jgroups...
> config.node02.cache.clustering...
> ...
>
> m.
> On 11/19/2013 03:25 PM, Sanne Grinovero wrote:
> > I love the idea, especially as it happened to me to try to help
> > someone who was running Infinispan configured via other means (like
> > the AS7 configuration format), and it's always hard to understand how
> > it's actually configured without knowing all the implicit default
> > values, on a specific version (as defaults evolve too).
> >
> > But do you really need an output in the form of java.util.Properties ?
> > Wouldn't a descriptive string not be more suited? The API could be the
> > well known toString() method on the configuration; we'd enforce the
> > internal components to fullfill some internal contract like
> > "appendTo(StringBuilder sb);" to make sure it's always maintained
> > correctly.
> > Also, I'd add an option which logs the fully defined configuration on
> > cache start at INFO or DEBUG level.
> >
> > Sanne
> >
> > On 19 November 2013 13:47, Michal Linhard <mlinhard at redhat.com> wrote:
> >> please refer to the branch, I've rewritten the original config:
> >> https://github.com/mlinhard/infinispan/tree/t_flatconfig
> >>
> >> On 11/19/2013 02:45 PM, Michal Linhard wrote:
> >>> Hi,
> >>>
> >>> This is a configuration output format feature proposal.
> >>>
> >>> I'd like to be able to flatten the infinispan cache configuration to
> >>> flat properties style so that two configurations can be easily
> comparable
> >>> in a view that displays sorted matching properties side by side to
> >>> quickly spot differences.
> >>>
> >>> This is useful in our internal PerfRepo app where I do it so far by
> >>> reflection, by patching the server or a radargun plugin by special
> >>> addon, but this can lead to numerous errors. It would be much simpler
> >>> and less error-prone process if we had it integrated in the upstream
> code.
> >>>
> >>> I proposed adding a method configuration.toProperties() that flattens
> >>> properties of a configuration object
> >>> (org.infinispan.configuration*Configuration) and produces
> >>> java.util.Properties. The nested configuration objects under the main
> >>> Configuration would recursively add their properties under an extended
> >>> property prefix.
> >>>
> >>> I also added a possibility to specify --format=properties in the info
> >>> command of the CLI so that the server responds with the property style
> >>> configuration of the specific cache...
> >>>
> >>>
> https://github.com/mlinhard/infinispan/commit/d8360f7850b67956adfa29aca86dae9dfad5c22d
> >>>
> >>> (I didn't implement toProperties in all objects, cause it's quite a lot
> >>> of changes that would be made in vain in case you don't like this
> >>> approach, the commit just demonstrates how I'd like to go about it.)
> >>>
> >>> These properties would also be exposed via JMX as (example values)
> >>>
> jboss.infinispan:type=Cache,name="testCache(dist_sync)",manager="default",component=Cache
> >>> attribute "configurationProperties"
> >>>
> jboss.infinispan:type=CacheManager,name="default",component=CacheManager
> >>> attribute "globalConfigurationProperties"
> >>> that could be converted by any JMX client back to java.util.Properties
> >>>
> >>> WDYT?
> >>>
> >>> m.
> >>>
> >>
> >> --
> >> Michal Linhard
> >> Quality Assurance Engineer
> >> JBoss Datagrid
> >>
> >> Red Hat Czech s.r.o.
> >> Purkynova 99 612 45 Brno, Czech Republic
> >> phone: +420 532 294 320 ext. 8262320
> >> mobile: +420 728 626 363
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Michal Linhard
> Quality Assurance Engineer
> JBoss Datagrid
>
> Red Hat Czech s.r.o.
> Purkynova 99 612 45 Brno, Czech Republic
> phone: +420 532 294 320 ext. 8262320
> mobile: +420 728 626 363
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131119/942f85fb/attachment-0001.html