If I follow what you're trying to do correctly, the reason for the bug is
that the context map descriptors are updated but the info reference we
return from getMBeanInfo is not,
in AbstractMBeanInvoker, for setters there's a finally block at the end
that updates the context maps on the return of the invocation:
// TODO: should be fixed by adding invocation return value object
finally
{
ctx.setDescriptor(invocation.getDescriptor());
TCLStack.pop();
}
getMBeanInfo() returns the metadata through invoker.getMetaData() call
which returns the 'info' reference from AbstractMBeanInvoker
/**
* The metadata describing this MBean.
*/
protected MBeanInfo info = null;
Which has not been updated with the change.
So, is this what needs to be done:
finally
{
ctx.setDescriptor(invocation.getDescriptor());
info.setDescriptor(invocation.getDescriptor(), "attribute");
TCLStack.pop();
}
Or did I lose track of what you're trying to do?
-- Juha
On Tue, 20 Jan 2004, Scott M Stark wrote:
> I'm looking into the testcase failure related to ModelMBean persistence
> and the problem as stated earlier is that the attribute
> interceptor/context
> ModelAttributeInfo and descriptor are copies that are detached from the
> ModelMBean. Hence, changes to the attribute do not result in changes in
> the ModelAttributeInfo descriptor fields like value, and
> lastupdatedtimestamp.
> This info is required by the current persistence impl, and also should
> be availble through the MBeanInfo available from the MBeanServer. A
> simple
> testcase illustrates the different behavior between the 1.2.1 JMX RI and
> the JBossMX 1.2 impl:
>
>
> The current JBossMX impl:
> X Descriptor Fields:
> currencytimelimit: 1
> descriptortype: attribute
> name: X
>
> The JMX 1.2RI:
> X Descriptor Fields:
> value: 10
> currencytimelimit: 1
> descriptortype: attribute
> lastupdatedtimestamp: 1074629742102
> displayname: X
> name: X
>
> Testcase method:
> public void testLastModified() throws Exception
> {
> System.out.println("+++ testLastModified");
> MBeanServer server =
> MBeanServerFactory.createMBeanServer("ModelMBeanTest");
> System.out.println("server: "+server);
>
> DescriptorSupport cacheInfo = new DescriptorSupport();
> cacheInfo.setField("name", "X");
> cacheInfo.setField("descriptorType", "attribute");
> cacheInfo.setField("currencyTimeLimit", new Integer(1));
> ModelMBeanAttributeInfo[] attrInfo = {new
> ModelMBeanAttributeInfo("X", "java.lang.Integer",
> "The X attribute", true, true, false, cacheInfo)
> };
> ModelMBeanConstructorInfo[] ctorInfo = null;
> ModelMBeanOperationInfo[] opInfo = null;
> ModelMBeanInfoSupport mbi = new
> ModelMBeanInfoSupport("test.Resource", "Resource POJO",
> attrInfo, ctorInfo, opInfo, null);
> RequiredModelMBean rmm = new RequiredModelMBean(mbi);
> rmm.setManagedResource(new Resource(), "ObjectReference");
> ObjectName name = new ObjectName(":test=testLastModified");
> server.registerMBean(rmm, name);
>
> Attribute x = new Attribute("X", new Integer(10));
> server.setAttribute(name, x);
> ModelMBeanInfo info = (ModelMBeanInfo) server.getMBeanInfo(name);
> System.out.println("ModelMBeanInfo: "+info);
>
> // Display the attribute info descriptors after the set
> ModelMBeanAttributeInfo xinfo = info.getAttribute("X");
> System.out.println("X info: "+xinfo);
> Descriptor xd = xinfo.getDescriptor();
> String[] fields = xd.getFieldNames();
> System.out.println("X Descriptor Fields:");
> for(int f = 0; f < fields.length; f ++)
> {
> String fname = fields[f];
> System.out.println(" "+fname+": "+xd.getFieldValue(fname));
> }
>
> MBeanServerFactory.releaseMBeanServer(server);
> }
>
> The source of this behavior is the use of a copy of the
> ModelMBeanAttributeInfo
> and its descriptors to the ModelMBeanInvoker.initAttributeContexts. The
> only
> way I can see to restore the expected behavior is to use JBoss specific
> subclasses of the javax.management.modelmbean.*Info classes that allow
> for
> accessing their state by reference rather than by copy.
>
> This has to be done for the 3.2 branch usage, I don't know if this is
> what
> we want in head.
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
