This content has been marked as final.
Show 4 replies
-
1. Re: Unexpected canonicalization of string
alesj Aug 9, 2008 4:36 AM (in response to brian.stansberry)Weird. :-)
I'll have a look. -
2. Re: Unexpected canonicalization of string
alesj Aug 10, 2008 6:29 AM (in response to brian.stansberry)"alesj" wrote:
Weird. :-)
Actually not that weird. :-)
It's the hack we have in order to handle JMX/MBean names as strings,
w/o having to provide canonicalized order to match exact ObjectName.
I've added MockServiceBindingTestCase, which exposes this issue:
- http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/kernel/src/tests/org/jboss/test/kernel/deployment/test/MockServiceBindingTestCase.java
But I guess you'll have to add similar behavior to ServiceMetaDataParser.
Since if some string looks like ObjectName,
it's eventually gonna be used as ObjectName,
hence canonical form is in order - making equal work on ObjectName 'string' representation. -
3. Re: Unexpected canonicalization of string
alesj Aug 10, 2008 9:12 AM (in response to brian.stansberry)"alesj" wrote:
But I guess you'll have to add similar behavior to ServiceMetaDataParser.
Or not. :-)
I think StringValueMetaData should not modify its input.
I've modified AbstractValueMetaData to check at setValue invocation
if it should use the JMXObjectNameFix:public void setValue(Object value) { if (isUseJMXObjectNameFix()) { Object jmxHack = JMXObjectNameFix.needsAnAlias(value); if (jmxHack != null) { this.value = jmxHack; flushJBossObjectCache(); return; } } this.value = value; flushJBossObjectCache(); }
Where StringValueMetaData now returns false on isUseJMXObjectNameFix call.
Non canonicalized string. ;-)assertEquals("jboss.remoting:service=JMXConnectorServer,protocol=rmi", binding.getServiceName());
-
4. Re: Unexpected canonicalization of string
brian.stansberry Aug 11, 2008 12:29 PM (in response to brian.stansberry)Thanks, Ales. :)
"alesj" wrote:
Since if some string looks like ObjectName,
it's eventually gonna be used as ObjectName,
Not in the case that led to this. The string is just a key to look up the binding metadata for a service from the ServiceBindingManager. It can be any arbitary value. But using the MC bean name of a pojo service or the ObjectName of an mbean service is a logical choice.