Your ideas both seem promising. I'm still not sure about what we want as the primary determinant of which mbeans are present in a restarted server. My impression of your proposals is that they result in the set of mbeans being determined by the deployed *-service.xml files available at restart, but the attribute values determined by the mbean persistence.
This may work fine for packages deployed by a deploymentScanner, but will work less well for packages deployed by directly calling MainDeployer.deploy. Scanning for packages may not be the most useful deployment method... even though right now it is the easiest to use. What if we thought of the mbean server as more or less a database of persistent objects, and the deploy/undeploy/redeploy operations using service.xml files as the insert/delete/update operations? If you deployed a package, those mbeans would stay until you explicitly undeployed them, whether or not the *service.xml file was accessible on server restart. My comments on persisting timestamps over server restarts were based on this idea and attempting to think of how the deployment scanner might work with it. What do you think? thanks david jencks On 2002.06.26 10:10:28 -0400 Paul Ward wrote: > >You are going to have conflicts with our current usage of **-service.xml > >files, since we are abusing them to serve for both telling the server > what > >mbeans we want and what their initial configuration is, and as our only > >form of persistence. If we get real mbean persistence we will need to > >rethink our **-service.xml usage. > > Yes, I've already run into that. For now I'm just leaving the default > values out of my own service files. > > >My preferred approach is to process each **-service.xml file only when > its > >timestamp changes or you provide explicite deploy/undeploy/redeploy > >instructions, something like this: > > There are two things I don't like about that. First, the timestamp may > change without any changes to the values themselves. Second, what if the > user doesn't want the 'new' default values to overwrite what has been > changed through the jmx interface. > > I was thinking more along the lines of adding an Active flag to the > persistence interceptor. It's false at instantiation and is set to true > at the end of the ServiceConfigurator. The active flag could be modified > through a dynamic descriptor and be automatically removed from the > mbeaninfo after it's called by the ServiceConfigurator. Heck, we might > just make it an attribute and leave it in there so users can turn on and > off persistence. > > A second option would be to actually have persistence specified in the > -service.xml and have the ServiceConfigurator set all the attributes then > add the persistence interceptor onto the stack. As soon as the > persistence interceptor is added, it overwrites the defaults with any > persisted values. This would have the added benefit of being able to > turn on persistence per instance instead of just per class. > > What do you think? > > --Paul > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber Inc. > Don't miss the IM event of the season | Special offer for OSDN members! > JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
