[infinispan-dev] configuration toProperties

[Galder Zamarreño]

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 <mlinhard at redhat.com> 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 <dan.berindei at gmail.com> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org