[jboss-jira] [JBoss JIRA] (AS7-3488) Make default-cache attribute of cache-container "eventually required" rather than required.
[
https://issues.jboss.org/browse/AS7-3488?page=com.atlassian.jira.plugin.s...
]
Stan Silvert commented on AS7-3488:
-----------------------------------
Also, relying on batch mode is awkward from a usability standpoint.
Can't we solve the chicken and egg problem?
What if you add a required "default-cache-type" parameter to the add operation?
Then the add operation would just create a cache for the default-cache. The user would
probably need to go back and configure the new cache. But at least you would always
maintain a valid configuration.
So this would execute successfully:
{noformat}/subsystem=infinispan/cache-container=fred:add(default-cache=wilma,default-cache-type=LOCAL){noformat}
And read-resource would immediately look like this:
{noformat}/subsystem=infinispan/cache-container=fred/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
"outcome" => "success",
"result" => {
"aliases" => undefined,
"default-cache" => "wilma",
"distributed-cache" => undefined,
"eviction-executor" => undefined,
"invalidation-cache" => undefined,
"jndi-name" => undefined,
"listener-executor" => undefined,
"replicated-cache" => undefined,
"replication-queue-executor" => undefined,
"start" => undefined,
"transport" => undefined,
"local-cache" => {"wilma" => {
"batching" => false,
"cache-mode" => "LOCAL",
"eviction" => undefined,
"expiration" => undefined,
"file-store" => undefined,
"jdbc-store" => undefined,
"locking" => undefined,
"name" => "wilma",
"remote-store" => undefined,
"store" => undefined,
"transaction" => undefined
}}
},
"response-headers" => {"process-state" =>
"reload-required"}
}{noformat}
Make default-cache attribute of cache-container "eventually
required" rather than required.
-------------------------------------------------------------------------------------------
Key: AS7-3488
URL: https://issues.jboss.org/browse/AS7-3488
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.1.0.Final
Can we remove the restriction that default-cache must be set when you create the
cache-container? That way, I can just make it so the UI
forces them to set that value before calling the start operation. So under that covers,
the console does this:
{noformat}
<!-- user creates a new cache container without specifying default-cache. -->
/subsystem=infinispan/cache-container=X:add
<!-- for top-level cache container attributes, user sets them via write-attribute
-->
/subsystem=infinispan/cache-container=X:write-attribute(name=jndi-name,value=W)
<!-- for nested nested cache-container attributes, user access them as an addressable
resource and sets them via write-attribute -->
/subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=stack,
value=udp)
/subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=lock-timeout,
value=100)
<!-- When user is ready to start the cache-container, prompt for default-cache if not
set. -->
<!-- Then do these two as a batch -->
/subsystem=infinispan/cache-container=X:write-attribute(name=default-cache, value=Y)
/subsystem=infinispan/cache-container=X:start(mode=on-demand)
{noformat}
Any thoughts on this? The answer has great implications on the UI design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira