[infinispan-dev] configuration toProperties
Dennis Reed
dereed at redhat.com
Tue Nov 19 12:06:44 EST 2013
+1 to the general idea.
-1 to using Properties format (or *any* new format).
Using any format that ISPN can't directly read back in ties the
functionality only to your specific use case.
But If it's in a configuration format that ISPN can read back in, it
would be much more generally useful.
-Dennis
On 11/19/2013 10:39 AM, Dan Berindei wrote:
> 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
> <mailto: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
> <mailto: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
> <tel:%2B420%20532%20294%20320%20ext.%208262320>
> >> mobile: +420 728 626 363 <tel:%2B420%20728%20626%20363>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> <mailto: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
> <tel:%2B420%20532%20294%20320%20ext.%208262320>
> mobile: +420 728 626 363 <tel:%2B420%20728%20626%20363>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131119/5b92b0cc/attachment-0001.html
More information about the infinispan-dev
mailing list