Dain,
I like your give-them-what-they-want attitude. Rest assured that I am *very* aware
of "config file hell" and am likewise motivated to avoid complexity.
Please note that the current XMBean deployment involves at least *two* config files
already. If the goal is to have only one, then perhaps the XMBean descriptor needs to
be merged with jboss-service.xml?
> Ok. How do you see the options?
To be honest, there are too many possibilities to enumerate here.
> 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).
Sure. Well, the text guys are ok about the status quo, right? Or do they want a
text-based dynamic interface to the JMX Server? ;)
> Anyway having a single config file has a big advantage, portability.
Hmm. So you're saying that one file is more portable than two? I'm not sure that I
buy that, especially if they are colocated or otherwise linked. In fact, when one big
file with two distinct parts is separated into two files, I think it becomes *more*
portable because it allows one to move only the relevant file, if needed.
> You can check it into CVS, you can copy it to another machine.
Again, CVS is happy to take 2...n files. These are attributes of all files AFAIK.
>You can
> configure it with the GUI undeploy the admin screen (security and all)
> and still be able to config the system with vi.
Now here is the beginning of a relevant use case. One admin uses the GUI, another
uses the file system exclusively. We need to keep them in synch, right?
GuiGuy browses the web to the relevant bean and modifies an attribute. The server
then saves that to the persistence store. FileSystemGuy then browses the filesystem
to the persistence store for that bean and also makes a change. On XMBean.load(),
that change takes effect.
Just as there is only one url for each mbean, there is one file system location for
the record of its state. GuiGuy knows just where to look, and so does FileSystemGuy.
So where's the beef? Yeah, FileSystemGuy may be used to looking at jboss-service.xml,
but he doesn't have to look there anymore (Yea!). The *only* place he needs to go for
server state records is the persistence store. State information in jboss-service.xml
is thus used for default (deploy-time) values only.
This is not confusing (at least not to me). I may not be explaining it correctly,
however, so feel free to throw some questions my way.
>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.
I just don't agree with this at all. "Your way right away" may work at Burger King,
but I don't think it works for creating lasting software. You're not an admin, but
they're not software architects either.
I fully respect this point of view, but also respectfully disagree. What if they all
wanted to jump off a bridge? ;)
If this approach is required, then perhaps someone else should take this task. The
existing architecture aupports multiple persistence managers anyway...
- Matt
-----Original Message-----
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Mon 1/13/2003 2:59 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [JBoss-dev] MBean persistence?
On Monday, January 13, 2003, at 01:26 PM, Matt Munz wrote:
> Dain,
>
> 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.
>
>> 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.
>
> 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...
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 :).
>> The admins I spoke with were willing to accept this. It is a common
>> 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.
>
> I 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.
Ok. How do you see the options?
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.
>> They
>> want to be able to goto one file and know what is going on.
>
> Could you elaborate on this? Why would they be looking at files at
> all?
>
> 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? ;)
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.
> 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
<<winmail.dat>>
