Our admin here thinks that Dain is spot on with this analysis. > From: Dain Sundstrom <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Mon, 13 Jan 2003 11:27:07 -0600 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] MBean persistence? > > Matt, > > I have meet with many system administrators over the past few months, > so I'll try to support their opinion. If there are any admins on this > list, please speak up. > > Simpler console for common tasks > -------------------------------- > The administrator the power of the JMX console, and think it is cool > they can change the behavior of the entire system. On the other hand > they are overwhelmed by the options. Most would like a very simple > static interface that does 80% of the common tasks and the option to > fire-up the full console for hard core hacking sessions. Basically > they would like a static interface similar to the one supplied by > Weblogic and JRun. (I have some ideas here if anyone is interested in > working on this.) > > Persistence in general > ---------------------- > The real problem they see with the JMX console is it does not save > changes. Almost unamiously, they find the console useless because the > changes are not persistent. They usually say that it is a good > developer debugging tool but don't think it will work for > administration. > > Persistence back to the original file > ------------------------------------- > When I get to the above point, I always ask the admins how they would > like the configuration information stored, and everyone has said they > want the original file modified (some suggest a rolling backup first). > They especially don't want this information stored in a binary format > or in a database because it makes the configuration way to hard to get > to. These are text editor (vi and emacs) guys, and binary simply > doesn't cut it. When I suggest that we could write out a new different > xml file that has the configuration changes, they all hated it. They > want to be able to goto one file and know what is going on. > > I really just want to make 80% of the admins happy and I truly believe > that this is the answer, but I admit I could be wrong. > > As for a use case... Say that database connection are being dropped by > the database server way before the specified JBoss stale connection > timeout. The admin wants to go into the running servers via the web > JMX-console and reduce the max connection length. Once they change > this setting in the console they want it to be permanent. They realize > that when the developers release a new version the changes may be > overwritten but they can deal with that, as production changes almost > never live beyond a version. > > I hope I have represented the admins well. What do you think of this > solution? > -dain > > On Monday, January 13, 2003, at 10:46 AM, Matt Munz wrote: > >> (copied from a message I sent direct to Bill) >> >> Bill, >> >> I couldn't figure out how to add a comment to the task, so I'm just >> emailing you. >> >>> I think we want seemless integration here >> >> I think you're integrating apples and oranges ;) >> >> What you've described does not match the current behavior of the >> ObjectStreamPersistenceManager. Are you saying that the >> jboss-service.xml files should be dynamically modified? I think that >> this adds unneeded complexity. >> >> Here is how I currently use MBean Persistence in my applications. >> >> --- >> >> jboss-service.xml - describes the initial (deploy-time) >> configuration of the bean, and the location of the corresponding >> XMBean descriptor xml. >> >> *-xmbean.xml - describes the signature of the metadata for the >> MBean. Includes the persistence configuration. Specifies the >> persistence type (ObjectOutputStream) and the persistence store name. >> >> /$Persistence_Dir/$Persistence_Store_Name.oos - the file where the >> MBean Server stores the record of the dynamically changing state of >> the MBean. >> >> --- >> >> Exchange XML for ObjectOutputStream and .xml for .oos in the above, >> and I believe we have a production-ready MBean Persistence mechanism. >> >> MBean persistence and MBean deployment are two separate >> mechanisms/concepts. This separation of concerns is *very* important, >> IMO, to preserve flexibility and ease-of-use/development. >> >> There are all sorts of things that need to go into a deployment >> descriptor that have little to do with the persistent state of the >> MBean, and vice versa. Although I see the motivation for a "Grand >> Unified Descriptor", I don't see a rationale for it. >> >> I think a use case would really help here. For example, I don't see >> an individual in the "deployment" role ever touching the deployed >> archive. Rather they would use the JMX Console to modify the MBean >> attributes, which would be recorded in the MBean Persistence Store >> (XML, JDBC, OOS, whatever), and that would be the extent of their >> configuration work. In the case of an extreme server failure >> (uncommon), they could hack the store directly when the server was >> off-line (XML files, JDBC Tables...). >> >> Although this case is relatively uncommon, I believe this is one >> example where the separation of concerns mentioned above is useful. >> If I get the server into an inconsistent state and, as a result, it >> fails at restart (the inconsistency is reloaded), then, I can always >> delete the Persistence Store. When the server restarts, it returns to >> a clean-slate (deploy-time) state. If, as you seem to be suggesting, >> the (inconsistent) state has been stored in the deployment descriptors >> themselves, however, this clean-slate is not possible. One must go >> through each descriptor until the erroneous state information is >> found. Then it must be manually corrected. Since the MBean >> persistence engine will be writing to these files automatically, it >> may not be apparent how to do this. >> >> Could you explain further the behaviour you would like to see in >> MBean Persistence? >> >> - Matt >> >> -----Original Message----- >> From: [EMAIL PROTECTED] on behalf of Bill >> Burke >> Sent: Mon 1/13/2003 10:54 AM >> To: [EMAIL PROTECTED] >> Cc: >> Subject: RE: [JBoss-dev] MBean persistence? >> >> >> >> Matt, >> >> I think we want seemless integration here. If the MBean is packaged >> within a SAR, the SAR should be exploded, the XML file modified and >> the SAR re-jared. Same goes with straight XML files or SARS embedded >> within SARs (russian doll). >> >> I'm in the process of creating task lists at SourceForge for each >> project. I can assign you this task? >> >> Thanks for your effort, >> >> XXXXXXXXXXXXXXXX >> Bill Burke >> Chief Architect >> JBoss Group, LLC >> XXXXXXXXXXXXXXXX >> >> >> -----Original Message----- >> From: Matt Munz >> [mailto:[EMAIL PROTECTED]]On Behalf Of >> Matt Munz >> Sent: Monday, January 13, 2003 10:48 AM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] MBean persistence? >> >> >> Dain, >> >>> So Matt are you interested in working on the XML persistence? >> >> Yeah, I suppose I could put some more time into it. It sounds like >> you know a few people that might actually be users of this feature. >> Do you have a use case in mind? >> >> - Matt >> >> -----Original Message----- >> From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] >> Sent: Mon 1/13/2003 10:07 AM >> To: [EMAIL PROTECTED] >> Cc: >> Subject: Re: [JBoss-dev] MBean persistence? >> >> >> >> So Matt are you interested in working on the XML persistence? >> >> -dain >> >> On Monday, January 13, 2003, at 08:32 AM, Matt Munz wrote: >> >>> Dain, >>> >>>> What is going on with MBean persistence? >>> >>> Not much, as far as I can tell. >>> >>>> Can we do this today? >>> >>> Yes, but only by persisting to ObjectOutputStream files. XML / >> JDBC >>> persistence engines have yet to be written. >>> >>>> If not is anyone working on it? >>> >>> I origionally wrote the code that I did to scratch an itch. As >> far as >>> I know, nobody else is using it... >>> >>>> When do you expect to have it finished? >>> >>> I reccommend not going to production with ObjectOutputStream >>> persistence as it is fragile. >>> >>> By reusing the code from the ServiceCreator (unmarshalling) and >> the >>> JMX Console (marshalling), the XML persistence engine should be >> fairly >>> simple to write. >>> >>> - Matt >>> >>> -----Original Message----- >>> From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] >>> Sent: Sat 1/11/2003 1:42 PM >>> To: [EMAIL PROTECTED] >>> Cc: >>> Subject: [JBoss-dev] MBean persistence? >>> >>> >>> >>> What is going on with MBean persistence? >>> >>> I have been at lot of sites lately that are going into >> production with >>> JBoss and the one thing admins always ask for is the >> ability to have >>> changes to the beans in the JMX console to be written back >> out the the >>> XML files. They don't care if the formatting changes or if >> comments >>> are lost, they just want to be able to change and option >> and have it >>> preserved when the server reboots. I love the practicality >> of system >>> administrators. >>> >>> Can we do this today? If not is anyone working on it? >> When do you >>> expect to have it finished? >>> >>> I think this fairly simple feature will make 80% of the >> admins happy. >>> >>> -dain >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.NET email is sponsored by: >>> SourceForge Enterprise Edition + IBM + LinuxWorld = >> Something 2 See! >>> http://www.vasoftware.com >>> _______________________________________________ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> >> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >>> <winmail.dat> >> >> >> >> ------------------------------------------------------- >> This SF.NET email is sponsored by: FREE SSL Guide from Thawte >> are you planning your Web Server Security? Click here to get a FREE >> Thawte SSL guide and find the answers to all your SSL security >> issues. >> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en >> _______________________________________________ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> <winmail.dat> > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
