+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 <[email protected]
<mailto:[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]
<mailto:[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
<tel:%2B420%20532%20294%20320%20ext.%208262320>
>> mobile: +420 728 626 363 <tel:%2B420%20728%20626%20363>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [email protected]
<mailto:[email protected]>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
<mailto:[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
<tel:%2B420%20532%20294%20320%20ext.%208262320>
mobile: +420 728 626 363 <tel:%2B420%20728%20626%20363>
_______________________________________________
infinispan-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
