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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
