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

Reply via email to