On 2002.10.03 17:19:27 -0400 Juha-P Lindfors wrote: > 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.
The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. > > > > 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. True, but the values of attributes are stored in the mbean info objects and can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. I keep waffling on this, but at the moment I think it makes more sense to store the attribute values separately even though this may be more work. david jencks > > 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 > > ------------------------------------------------------- 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
