On 06/10/2015 13:13, Sebastian Laskawiec wrote:
+1, I like this approach however it may confuse our users a little
bit.
Maybe we should have a flag in configuration (disabled by default) which
would enable persisting changes back into xml?
No, this would go against the WildFly model of doing things. What can be
done is to create a special attribute set to RUNTIME_ONLY, but I'm not
sure I like this.
- Jmx: do we want a writable "capacity" attribute or a resize
operation? And do we want it on the cache mbean or on a new data
container mbean? And should the change affect the configuration
object too, i.e. invoking configuration.eviction().size () should
return the new value? For symmetry with server we should.
+1 for writable attribute. This would fix nicely into configuration
listeners. How about exposing new Configuration MBean with all writable
configuration attributes?
Ideally it would be nice to replicate the same tree structure of the
server configuration model (which also mimics the programmatic API), so
that each cache trait has its own MBean. This would mean for example
having an Eviction MBean as a child of the Cache MBean.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat