Dain, > and the worst part is we have no control over it at runtime. It is way > simpler. You'll see.
It sounds like you have a vision. Please continue to make the effort to get the rest of us into the loop. I want to "see" also, but I'd prefer to do so sooner rather than later (not after it's done and finished). > The easiest case for me the read ahead configuration in entity beans. > There is no reason for this to be static. In fact it should be > manageable at runtime, and if I'm luck I'll be able to pull it off for > 4.0. Scott tells me there is a similar need to manage security at Great, now we're getting somewhere. Can you pick one of these (perhaps the read ahead), and provide some details? What does the server admin have to do that is particularly time consuming? It may be obvious to you, but I'd love to hear the details on this one. > runtime. There really is no need to shut down an application in > production just to change some configuration data. This is *exactly* what MBean Persistence is supposed to do, IMO. Feel free to reread that last sentence for added emphasis. Why not channel this energy into making MBean Persistence even better? Shouldn't any and all server configuration be done through JMX anyway? Isn't that the point of JMX in the first place? > Even if there is no real need the code is simpler. Simple is the key word. I'm new and all, so feel free to ignore me, but this whole thing just sets off my KISS alarm system -- it actually sounds rather complicated. - Matt ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development