[jboss-dev-forums] [Design of Management Features on JBoss] - Re: Applying persisted changes.

[scott.stark@jboss.org]

"emuckenhuber" wrote : 
  | I think that will simplify things for the attachment persistence.
  | Last week i was briefly looking into something similar. It's basically not that obvious, as IMHO parts of what ServiceMetaDataICF and BeanMetaDataICF are doing should be moved out.
  | On the other hand looking at the connection factory ICFs - those actually only do operations on the ConnectionFactoryMetaData itself, which should be fine.
  | 
  | So i think that one of the goals should be to have a clearer separation between the metaData operations and the extension behavior.
  | Although refactoring ICFs totally out of this process could be quite hard. Maybe creating something new but similar for the extension behavior could be easier?
  | 
  | Leaving the meta data operations in the responsablitly of the ICFs (setValue, getValue). On top of that the extension behavior like overriding the moClass, getting the values from the MBeanServer or the MCBean... Also adding and creating a new attribute to the meta data e.g. ServiceAttributeMD could be done by the extensions.
  | Is similar to what you have in mind?
The ICF behavior needs to be separated out into the type/metadata driven aspect of creating the MO skeleton and subsequent population. The value read access of the ICF is an extension of the current ManagedObjectPopulator default implementation. 

There is a disconnect between the ManagedDeployment/ManagedComponent and the DeploymentUnit/component DeploymentUnit that is what the KernelDeploymentManagedObjectCreator is essentially working around. In general we need to be doing something like:
1. Create the ManagedObject metadata from attachments and extensions based on metadata
2. Create the ManagedDeployment/ManagedComponent/ManagedObject skeletons. This view should work even without a sever with default values coming from the ManagedProperty metadata
3. Provide a full runtime view with stats, operations via a population step.

Getting to this abstraction for 5.1 is not possible. What we can do in the next week is what I'm trying to figure out today.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225706#4225706

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225706