On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote:
Dain,Good point. To extend you analogy, if the customer wants a hamburger you don't give them cordon bleu, just because you think they will like it better (which they would :).
First off, thank you for providing much-needed field data for this work.
Your comments on "Persistence in general" are identical to my reasons for working on MBean Persistence in the first place.
Why do they want this specifically? It is important to take "customer" concerns and turn them into needs. Consider cooking at a restaurant. If the customer orders chocolate cake and you don't have it, do you bake a cake just because they "want" it? Perhaps we can give the sys admins chocolat pots de creme instead? They might even like it better...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.
Ok. How do you see the options?The admins I spoke with were willing to accept this. It is a commonI don't see the options this way. Losing stored MBean state across upgrades may end up being an application-specific detail at best. If the MBeans change, then the stored MBean state will likely be out of synch, regardless of where that state is stored. I don't see this as related to the issue of whether or not the mbean state store and the deployment descriptor should be merged.
problem. When I give them the option of looking in multiple places, or
looking in some database, or dealing with lost config options across
upgades, they all chose the last. I personally would have gone for the
second option, but I'm not an admin.
The point about the upgrade problem not being related to the MBean persistence method, I would state as *not necessarily related*. Certain persistence schemes will necessarily create an upgrade problem and some can mitigate it.
Yes. They want it both ways. Some admins hate consoles, and some hate config files. A lot of times you have two admins, one that can't handle file configs and one that can't stand GUIs (even web GUIs). Anyway having a single config file has a big advantage, portability. You can check it into CVS, you can copy it to another machine. You can configure it with the GUI undeploy the admin screen (security and all) and still be able to config the system with vi.Could you elaborate on this? Why would they be looking at files at all?They want to be able to goto one file and know what is going on.
I think we are running into a bit of a jam here, conceptually. They say they want to use the console to make persistent changes. Do they also want to use the filesystem to make changes? Two interfaces for the same device -- are they requesting any others? Why would they hack config files if they have the handy dandy console? ;)
I can think of many possible answers to these questions, but how would the sys admins answer them? Please stick with me on this one. I think that if we can develop a solid use case for these things, we can get to some of the core issues, and perhaps you'll understand my rationale. The use case that you gave before is completely solved by my approach, BTW. Perhaps answering the questions above will help generate a use case that shows why two files is worse than one...I understand your point, and I suggest you go talk with some full time admins, or better watch them work for a day. It will be an eye opener.
One file is a huge benefit to admins. There is nothing worse then picking through the config files, changing something and it has no effect. Then 8 hours to 1 week later you discover that the file is ignored if there is an override somewhere else in the system.
Hey, I'm not an admin, and when a whole bunch of them at different companies tell me they want it a very specific way, I say lets do it. The solution the propose is very simple from a user perspective, as they get it both ways. I don't expect this to be the only solution or the default solution, but it should be an option. I just want to make the admins happy.
-dain
-------------------------------------------------------
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
