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 you're integrating apples and oranges ;)I think we want seemless integration here
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
