On Thu, 3 Oct 2002, Matt Munz wrote: > > 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.
there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. > 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. sure. > The entity that persists the MB info should be responsible for loading it > at server start. yes, but an MBean loads its own state based on that metadata > 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? no idea, I'm not sure how you got there > Either way, what is the benefit of saving part of the MBeanInfo in > location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) > 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. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) > 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. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. > 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. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- 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
