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. 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. 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? 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. 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. 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 -----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
