WriteThroughManagedPropertyImpl

[adrian.brock]

What is WriteThroughManagedPropertyImpl doing?

It is the Fields implementation that should be doing this (setting the property
on the attachment).
The ManagedProperty(Impl) is just a wrapper for the Fields to make the api easier to use
at the front end.

There should be a JavaBeanFields implementation, a DomFields, etc.

[starksm64]

Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed.

[adrian.brock]

Its really just for the existing tests and can be moved into the tests layer. The tests were not setup to allow for introduction of a writeback java bean aspect. If the ManagementObject.fieldsFactory is to be useful, then a factory interface that allows the underlying attachment to be passed to the Fields implementation is needed.

I don't know what ManagementObejct.fieldsFactory is?
Are you talking about the annotation or something else?

It should be upto the caller (deployer or overrides) to decide how to generate the fields,
i.e.
1) it is a flattened javabean tree
2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans
3) it is from an MBean definition
4) it represents a XML DOM
5) something else
etc.

The only one I'd implemented was (2) and then that wasn't complete,
e.g. it didn't update the javabean in the setValue().
That is unless you count the crappy MockDomFields in the testsuite. :-)

[starksm64]

I don't know what ManagementObejct.fieldsFactory is?
Are you talking about the annotation or something else?

Yes, its a field in the @ManagementProperty I added.

It should be upto the caller (deployer or overrides) to decide how to generate the fields,
i.e.
1) it is a flattened javabean tree
2) it is a hierarchy of ManagedObjects/MetaValues from the javabeans
3) it is from an MBean definition
4) it represents a XML DOM
5) something else
etc.

Right, which is why I added the ability to describe what the Fields and ManagedProperty implementation are from the annotation.

[adrian.brock]

Right, which is why I added the ability to describe what the Fields and ManagedProperty implementation are from the annotation.

Ok, but I think in general people will want to "mix and match"
the javabean stuff. e.g. flatten everything except this part
or like on other thread, this Collection is to be exposed as a Map.

I don't see a problem with defining a global strategy on the @ManagementObject
but you also need to be able to override it on the @ManagementProperty

[starksm64]

Ok, but I think in general people will want to "mix and match"
the javabean stuff. e.g. flatten everything except this part
or like on other thread, this Collection is to be exposed as a Map.

I don't see a problem with defining a global strategy on the @ManagementObject
but you also need to be able to override it on the @ManagementProperty

Right now in fact its only supported on the @ManagementProperty. It does need to be definable globally to simplify.