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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org