On 25 Mar 2009, at 14:08, Brian Stansberry wrote:
Mircea Markus wrote:
Manik Surtani wrote:
On 25 Mar 2009, at 13:19, Adrian Cole wrote:
tough call.. the jmx user may not have access to the log to see the
warning anyway.
I would prefer an info notification of coarse registration events then
warn or trace depending on whether the name is overloaded. That would
seem more grep friendly for unixy folks who scrape logs for things. I
think a mandatory index would me simpler in that case, although
slightly confusing for folks who don't have more then one.
+1 on the mandatory index.
I think mandatory indexes would confuse users, as they configured an jmxDomain in clear text and see an different on the server. Even more, they might want to enforce an domainName for other reasons (e.g. thay have other modules expose under that domain name etc).
I would like the user to be aware of the fact that there is an conflict and take action, rather than dig through logs first and then curse the developer who wrote the code.
Then an ConfigurationException is the best approach.
What about:
1) forbid a registration under same domain. Cache won't start as registration is done at startup, an exception will be thrown.
Yup
2) add an configuration attribute named forceAutoIncrement (default=false). The user would have to manually enable it.Also, the error message at 1) would inform him about this attribute, so the change should be quite straight
Perhaps call this "allowDuplicateDomains"? Default to false as you say, but if this is true, always use a counter so that the first instance would be <jmxDomain>:0?
I think an option to name the manager is needed. I'll be running multiple managers in the same AS, and people are going to need to be able to access them by name, not by a number that varies based on what order the managers are started in.
This is your jmxDomain. You have a single <global /> section per cache manager.
The issue is the overlap when you have multiple cache managers which happen to have the same name.
Cheers
Manik
--