Dennis, why would you propose it to be in a format that can be read back? It wouldn't be as simple, and you'd have to face all the complexities of supporting different version formats, etc.. Unless you've come across use cases for a JSON-like configuration?
I'd go for Properties or the simple toString(appender) because we can implement and maintain it without complexity, or the reflections based idea. (No strong opinion, I see the value of having the framework automatically adapt to changes but I suspect it would lead to a complex framework for no big value). Sanne On 19 November 2013 17:55, Michal Linhard <mlinh...@redhat.com> wrote: > Important part of this is expressing the Configuration state as it was > constructed in the JVM, either by parsing or programmatically and not > omitting any of the attributes (properties) btw reflection is another > way to go, I just wasn't sure what is the preferred way and where I'd > put the reflector code. > > current toString() method actually does that but it's neither easy to > read by human eye nor to parse. > on a first look it's quite close to JSON structure, but missing some > markup that would enable correct parsing > > configuration XML doesn't tell me much when it comes to question which > settings were used in a test. > first of all, the XML format can omit certain elements and leave the > configuration to default values > second, two different commits on the master branch may interpret the XML > in a different way and instantiate Configuration with different values > > I just wanted to clarify that I'm not looking to replace XML > configuration format > or create something that the Configuration could be read from (ISPN > can't read back current toString method's format either) > I want a more expresive output format to introspect the Configuration > object more closely. > > the flat key/value structure is indeed closely tied to the comparison > use case. > in case we don't want that I'd at least propose some parsable > "normalized" format with one-to-one Config<->Formatted_config_string > mapping. > > m. > > On 11/19/2013 06:06 PM, Dennis Reed wrote: >> +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 <mlinh...@redhat.com >>> <mailto:mlinh...@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 <mlinh...@redhat.com >>> <mailto:mlinh...@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@lists.jboss.org >>> <mailto:infinispan-dev@lists.jboss.org> >>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > _______________________________________________ >>> > infinispan-dev mailing list >>> > infinispan-dev@lists.jboss.org >>> <mailto:infinispan-dev@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@lists.jboss.org >>> <mailto:infinispan-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
