Dain Sundstrom wrote:

Nope, as I said, I removed /partial/ wildcards - stuff like "test?omain" - full wildcards (i.e. "*" or no value) operate as before. Do you really see a need to keep that, and if so wouldn't it be better in a more flexible query mechanism similar to JMX's QueryExp?


I personally dislike the JMX QueryExp objects, and the Kernel has never supported them. If you want to explore a QueryExp system because you find it useful, please do. I like the current features of the ObjectName queries and don't want to have that functionality removed.


So this is based on a personal preference for a rather arcane mechanism that is not actually used by anyone rather than any real technical reason?


I treat a /missing/ domain as a wildcard, which is exactly what we did before. An empty domain as in ":x=x" is not a wildcard but an exact match to the domain "". It specifically does not match the default domain unless that just happens to have been set to "" as well (and the default default domain is "DefaultDomain").


From, my understanding, and I could be wrong. The name ":x=x" should be queried as "<default-domain>:x=x" according to JMX. If I was not doing that in the non-jmx based registry it was a bug.


You might indeed be wrong. I just got through fixing issues here in MX4J.

Anyway, here is my formal -1 roadblock.


To what and why?


Removal of domain query functionality and splitting of the name and pattern. I don't see any reason to remove this functionality.


Removal of a feature that adds complexity for little value that we both agree no-one is using? How is this different from removing WaitingException?


Same with splitting the name - that's not removing functionality, its refactoring the API to make it easier to use by eliminating the overlap between values and patterns (given, even in JMX, patterns proved inadequate and lead to the introduction of QueryExp).

KISS, right?
--
Jeremy

Reply via email to