(copied from a message I sent direct to Bill)
Bill,
I couldn't figure out how to add a comment to the task, so I'm
just emailing you.
> I think we want seemless integration
here
I think you're integrating apples and oranges
;)
What you've described does not match the current
behavior of the ObjectStreamPersistenceManager. Are you saying that the
jboss-service.xml files should be dynamically modified? I think that
this adds unneeded complexity.
Here is how I currently use MBean Persistence in my
applications.
---
jboss-service.xml - describes the initial
(deploy-time) configuration of the bean, and the location of the corresponding
XMBean descriptor xml.
*-xmbean.xml - describes the signature of the
metadata for the MBean. Includes the persistence configuration.
Specifies the persistence type (ObjectOutputStream) and the persistence store
name.
/$Persistence_Dir/$Persistence_Store_Name.oos - the
file where the MBean Server stores the record of the dynamically changing
state of the MBean.
---
Exchange XML for ObjectOutputStream and .xml for .oos
in the above, and I believe we have a production-ready MBean Persistence
mechanism.
MBean persistence and MBean deployment are two
separate mechanisms/concepts. This separation of concerns is *very*
important, IMO, to preserve flexibility and
ease-of-use/development.
There are all sorts of things that need to go into a deployment
descriptor that have little to do with the persistent state of the MBean, and
vice versa. Although I see the motivation for a "Grand Unified
Descriptor", I don't see a rationale for it.
I think a use case would really help here. For example, I
don't see an individual in the "deployment" role ever touching the
deployed archive. Rather they would use the JMX Console to
modify the MBean attributes, which would be recorded in the MBean
Persistence Store (XML, JDBC, OOS, whatever), and that would be the extent of
their configuration work. In the case of an extreme server failure
(uncommon), they could hack the store directly when the server was off-line
(XML files, JDBC Tables...).
Although this case is relatively uncommon, I believe this is one
example where the separation of concerns mentioned above is useful. If I
get the server into an inconsistent state and, as a result, it fails at
restart (the inconsistency is reloaded), then, I can always delete the
Persistence Store. When the server restarts, it returns to a
clean-slate (deploy-time) state. If, as you seem to be suggesting,
the (inconsistent) state has been stored in the deployment
descriptors themselves, however, this clean-slate is not possible.
One must go through each descriptor until the erroneous state information
is found. Then it must be manually corrected. Since the MBean
persistence engine will be writing to these files automatically, it may not be
apparent how to do this.
Could you explain further the behaviour you would like to see in
MBean Persistence?
- Matt
