One last thought on this. Tomcat used to do this sort of thing with auto files in the conf directory. For example, my 3.2.3 directory has mod_jk.conf and mod_jk.conf-auto. The auto files contain incremental changes to what is in the conf file. This idea worked so poorly that a routine refrain when someone complained about unexpected errors was to "delete all auto files and restart". I'm not sure, but I think Tomcat did away with these auto files in later releases because so many people got tripped up by them. We purposely hand-write our JkMount's to avoid the auto files altogether.
That experience reinforces the suggestion I made below. ----- Original Message ----- From: "Guy Rouillier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 02, 2002 2:00 PM Subject: Re: [JBoss-user] Keeping MBeans in sync with my-service.xml > Ok, thanks to you and Jon, I now understand. I can see the value to such a > persistence mechanism, but I can see issues also. Suppose (I'm making up a > scenario, probably not realistic) you are having problems with an mbean. > Suppose, for example, your database mbean crashes on startup. You copy your > config files to a test machine and when you run that, everything works fine. > Gosh, same config, crashes in production, works fine in test, how's that > possible? Oops, my config files have max connections = 10, but my > production environment got persisted during shutdown with max connections = > 100. > > For this to be manageable, I would think you would need some sort of > centralized config database, and both the config files and dynamic changes > through (e.g.) the JMX console would update that centralized set of config > values. And I will read up on model mbeans, just as soon as I file those > overdue tax returns <gr>. > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 02, 2002 1:23 PM > Subject: Re: [JBoss-user] Keeping MBeans in sync with my-service.xml > > > > You ought to read about model mbeans;-) You can specify persistence > policy > > on an attribute by attribute level, so you can specify that the > > authentication cache is never saved. > > > > As to why a datasouce mbean should be persisted... the contents of the > > associated pool shouldn't be, but we're thinking about using the > > persistence mechanism to restart a server in the "last known state" rather > > than redeploying all the stuff that got it there before it shut down. > This > > would mean that if you say changed the size of the pool through the jmx > > console while the server was running, when it restarted it would remember > > the new value without you having to alter the xml dd that originally > > deployed it. > > > > thanks > > david jencks > > > > On 2002.09.02 12:47:56 -0400 Guy Rouillier wrote: > > > Sounds like your "persistence interceptor" is the same thing as my > > > saveState > > > and loadState, so I think we are on the same wavelength. > > > > > > Such as: I've written an authentication MBean that keeps a hashmap of > > > authenticated users and their permissions. There are timing sensitive > > > processes looking at this hashmap (idle timeout, etc). Thus, I don't > > > want > > > this MBean to persist between shutdowns - I want it to come up cleanly > > > each > > > time - users just log back in again after a restart. I don't even care > to > > > know that this MBean previously existed. > > > > > > Actually, I think most mbeans would work this way. For example, why > > > would a > > > database connection pool mbean care to know that it previously existed? > > > What good would that information do it? > > > > > > ----- Original Message ----- > > > From: "David Jencks" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Saturday, August 31, 2002 12:31 AM > > > Subject: Re: [JBoss-user] Keeping MBeans in sync with my-service.xml > > > > > > > > > > Such as? Would they want the fact of their existence to be saved? > > > > > > > > It's probably going to be done with an mbean persistence interceptor. > > > If > > > > you don't want the state saved, configure the mbean without the > > > persistence > > > > interceptor, or with one that doesn't save attribute values, just the > > > mbean > > > > class. > > > > > > > > thanks > > > > david jencks > > > > > > > > On 2002.08.30 23:52:37 -0400 Guy Rouillier wrote: > > > > > First I've heard of this, but hopefully you'll do this with a > > > saveState() > > > > > and loadState() function that MBeans can choose to ignore. Some > > > MBeans > > > > > don't want their state saved between shutdowns. > > > > > > > > > > ----- Original Message ----- > > > > > From: "David Jencks" <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > Sent: Friday, August 30, 2002 4:01 PM > > > > > Subject: Re: [JBoss-user] Keeping MBeans in sync with my-service.xml > > > > > > > > > > > > > > > > You can't do this now and I don't think it is a good idea to > > > implement > > > > > it. > > > > > > > > > > > > Sascha and I (and previously others) have been discussing how to > > > use > > > > > mbean > > > > > > persistence to save the state of all mbeans in jboss independently > > > of > > > > > how > > > > > > they got there. This would decouple deployment of mbeans with > > > their > > > > > > initial state (handled typically by deploying a *-service.xml > file) > > > > > from > > > > > > persistence of the possibly modified state over server > > > shutdown/restart > > > > > and > > > > > > crashes. With this model, shutting down jboss would not > "undeploy" > > > > > > anything, it would save the state and then remove each mbean. > > > > > Restarting > > > > > > jboss would not "deploy" the packages previously deployed, it > would > > > > > read > > > > > > the state of all the mbeans, recreate, configure, and start them. > > > > > > > > > > > > thanks > > > > > > david jencks > > > > > > > > > > > > On 2002.08.30 15:24:42 -0400 Jon Brisbin wrote: > > > > > > > Is there any way that I can deploy an MBean in JBoss through a > > > > > > > *-service.xml file, then update it's properties in the > > > jmx-console, > > > > > and > > > > > > > *also* keep the deployment file up to date? I didn't see > > > anything > > > in > > > > > > > JBoss to support this notion, but wondered if it would be > > > feasible > > > to > > > > > > > attempt such a thing?? > > > > > > > > > > > > > > ===== > > > > > > > Thanks! > > > > > > > > > > > > > > Jon Brisbin > > > > > > > > > > > > > > [EMAIL PROTECTED] > > > > > > > 417.682.6157 (h/w) > > > > > > > 417.825.3995 (c) > > > > > > > > > > > > > > __________________________________________________ > > > > > > > Do You Yahoo!? > > > > > > > Yahoo! Finance - Get real-time stock quotes > > > > > > > http://finance.yahoo.com > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > > > > cell phone? Get a new here for FREE! > > > > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > > > > _______________________________________________ > > > > > > > JBoss-user mailing list > > > > > > > [EMAIL PROTECTED] > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > > > cell phone? Get a new here for FREE! > > > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > > > _______________________________________________ > > > > > > JBoss-user mailing list > > > > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > > cell phone? Get a new here for FREE! > > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > > _______________________________________________ > > > > > JBoss-user mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > cell phone? Get a new here for FREE! > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > _______________________________________________ > > > > JBoss-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > cell phone? Get a new here for FREE! > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
