Sacha, I think the counter idea will work fine, given a presupposition that all MBs that a given MB (whose info is to be persisted) depends on also have their MB info persisted.
- Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey Sent: Friday, October 04, 2002 9:52 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically Hello, And what about deployment order? When I was thinking about it (and we exchanged a few e-mails with David), the deployment order issue has poped up. When you have explicit information about dependencies, that's fine but you don't have this all the time i.e. if you create a new topic through jmx-console, the mbean is successsfuly created because the server is running. Nevertheless, at reboot-time, things may go differently. I suggested to use an internal counter in JBoss that increments each time a new service is deployed. As part of the MBean info that is persisted, we could store this id and, when restarting jboss, deploy the mbeans (which have no explict dependency info) in the sequence of their ID. This scheme is simple and support mbeans that are updated/deleted/created. Another option would be to have, for each MBean, a list of "required services". But this was already discussed when we had to deal with dependencies at first. Cheers, Sacha > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Juha-P Lindfors > Envoye : jeudi, 3 octobre 2002 23:19 > A : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] creating persistent MBeans dynamically > > > 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 > ------------------------------------------------------- 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
