Just send a pull request and we can provide comments there? I think the idea is good, but based on the feedback, seems like there's different opinions on the output format? Maybe you could pass the format as a class that decides what the output should be, e.g.
Formatter<Properties> f = new PropertiesFormatter(); configuration.mkOutput(f); Properties p = f.getOutput(); Don't pay attention to the actual names, but more into the idea of the user being able to provide a formatter on how the configuration should be presented: properties, XML, JSON, YAML…. Formatter would need some extra callback for the element, value to cache them, so that when getOutput() is called, it can return what's needed. Cheers, On Nov 22, 2013, at 4:21 PM, Michal Linhard <[email protected]> wrote: > I've tidied my previous commit a bit and created JIRA: > https://issues.jboss.org/browse/ISPN-3750 > > I'm leaving out the CLI changes for the time being. With this the commit > is really small, unintrusive and easy to review... > https://github.com/mlinhard/infinispan/tree/t_ispn_3750 > > I'm not sure how we vote for features, but could you upvote it if you > like it ? > Sorry for spamming again, but it would really make my PerfRepo process > easier ... > > m. > > On 11/20/2013 10:54 AM, Michal Linhard wrote: >> reflection based toProperties() proposal (based on config normalizer >> used in PerfRepo reports) >> >> https://github.com/mlinhard/infinispan/tree/t_flatconfig_reflection >> >> >> On 11/19/2013 07:37 PM, Mircea Markus wrote: >>> On Nov 19, 2013, at 4:39 PM, Dan Berindei <[email protected]> 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. >>> +1. I think an reflection based approach (toProperties implemented in the >>> base config class and iterating over all defined fields) should be easy to >>> implement and solve the problem . >>> >>> Cheers, >> > > > -- > 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 -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
