On 2002.10.03 16:06:36 -0400 Matt Munz wrote: > Juha, > > sometimes design-by-email is not a fast route :) ... > > > all of mbeaninfo should not be always stored. for instance, if I > > instantiate my MMB by using a definition from an URL or db then the > > mbeaninfo is already persisted there and should not be duplicated (only > > the ref to where to locate it is needed). This is to avoid the > confusion > > to users where an mbean seems to be stored in two different locations > (we > > already had this problem with 2.0). If on the other hand you created > the > > mbean info at runtime then obviously you need to persist it. > > Perhaps I'm too simplistic, but I think that the server is either > responsible for MB info persistence, or it isn't.
I agree, and think it is. > > How about this? -- When I register my MB with the server, the server > takes > a peek at the MB's descriptor. If it says "Persist my info", then the > server takes responsibility for persisting the MB info; else, the server > operates as it does now. I agree > > The entity that persists the MB info should be responsible for loading > it > at server start. If MBean info persistence customization is required, I > suppose we can have an MBeanInfoPersistenceManager with store() and > load() > methods similar to the PersistenceManager used to store MBean state, but > is > this really necessary? I hope not. > > Either way, what is the benefit of saving part of the MBeanInfo in > location A, and part of it in location B? Please explain :) > > I don't have the pleasure of knowing 2.0 ;), but I think I kind of know > what you're talking about. Deployment of XMBeans, for example, involves > two > similar files with nonetheless distinct roles. I think it is necessary > to > either separate or merge the ideas of the deploy folder and the MB info > store. I favor the former. It is easy for me to treat files in the > deploy > dir as deployment descriptors, and files in the MB info store as server > state files. yes. Since you can deploy through the jmx console and ant jmx from an arbitrary location, and then remove the deployed files, you can't use the original deployment for anything other than, well, the original deployment. After that it is irrelevant unless you are using one of the timestamp watchers, which although somewhat convenient for some things should not drive any part of the design or functionality of mbean persistence. > > This perhaps could be indicated with appropriate naming conventions, > comments, and documentation. If it is clear that modifications in the > deploy folder will re-deploy the entire application, while the MB info > store > is generated and maintained by the server, I think the confusion will go > away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and > ANT JMX support, people have plenty of ways to modify the state of the > server at runtime. Hacking the files in the store should be considered > at-your-own-risk. These files will be generated by the server and loaded > at > startup only. > > The other option is to say that the deploy folder is the MB info store > (this is kind of how it works today). I don't favor this -- I like to > keep > my peas on one side of the plate, and my mash potatoes on the other side > ;) > There is a way to make this work, if desired, but I believe that the > route > there is to delegate the responsibility for MB info persistence to an > object > other than the MB registry. PLEASE NO!! NO!! NO!! This was the disaster in 2.0. > > Perhaps you have a use case / user story in mind that I can use as a > guide. For my MBs, there is no MB info storage -- adding this mechanism > will give me one and only one location for that state. This is how it > should be in general, I think. > > - Matt It seems to me that we have to store the following for each mbean: object name constructor to use constructor arguments class of the managed resource mbeaninfo values for the attributes. there may be lots of jboss specific info in the mbean info. this may be redundant, since the attribute values are known in mbean info and could be stored there. On the other hand we could take them out and store them separately. If we fixed (specified) the location of persistent storage, we could store all of this info in the mbeaninfo as one thing, and on startup load everything from the persistent store. if we want to be able to have several persistent store locations, we need one place that lists the mbeans and where to find the info for them. I think this is the idea behind Juha's suggestion that we persist the registry, getting a list of ObjectNames, constructors+args, and persistence locations. In this scheme, we could store the mbeaninfos with the object name in the registry, or with the attribute values specific to the mbean. If we do not store the attribute values in the mbeaninfos, we could share them: mbeans that are created referring to the same xml representation of their mbeaninfo could end up sharing the persistent representation of it. I haven't thought very hard about the advantages and disadvantages of where to put the info. However, at the moment I favor storing the object name and persistence location in the registry persistence, and putting the class name, constructor name, constructor arguments, and attribute values in the mbean infos and storing this separately. I'd favor storing the mbean infos in the xmbean xml format: we already know how to read it, we just have to learn how to write it. thanks david jencks > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Juha-P Lindfors > Sent: Thursday, October 03, 2002 10:07 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] creating persistent MBeans dynamically > > > On Thu, 3 Oct 2002, Matt Munz wrote: > > > Juha, > > > > > what you need to persist from the registry is the information to > > > recreate the mbeans > > > > OK. Great. Sorry for the confusion. I think this information is > > essentially the MBeanInfo, the object name, and possibly, a dependency > > indicator (MB foo must be loaded after MB foobar). > > all of mbeaninfo should not be always stored. for instance, if I > instantiate my MMB by using a definition from an URL or db then the > mbeaninfo is already persisted there and should not be duplicated (only > the ref to where to locate it is needed). This is to avoid the confusion > to users where an mbean seems to be stored in two different locations (we > already had this problem with 2.0). If on the other hand you created the > mbean info at runtime then obviously you need to persist it. > > The only changing part in the metadata should be the descriptor which > should be persisted regardless of how the mbeaninfo was loaded to the > runtime system in the first place. So a simple key, value map or a > property file even. The rest of the metadata should remain unchanged > during the lifetime of the MBean. > > > > Could you clarify the following from P. 87 of the spec? > > how an mbean is persisted is really not defined in the spec. > > > > If "the MBean" is (MB info + state), then this clearly states that the > > *entire* MB is written. It is not specified how it is written > (overwrite > or > > write diff). I aggree that this does not make sense > > if the assumption doesn't make sense, and we both agree it doesn't make > sense, then concentrate on the part that *does* make sense ;-) > > > > Well, I'm very interested. The work I do is spec-friendly. An > important > > selling point for us with JBoss is flexibility via spec compliance. > Since > I > > see persistence as an invaluable feature for JMX, having it be a full > > fledged aspect of the spec is important for me. Perhaps if JBoss does > it > > right, it will make its way into the spec eventually :) > > perhaps > > -- Juha > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
