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...
> 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.
> 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? ;)
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...
- Matt
-----Original Message-----
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Mon 1/13/2003 1:01 PM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [JBoss-dev] MBean persistence?
Jeremy,
Specific comments are inline...
On Monday, January 13, 2003, at 11:33 AM, Jeremy Boynes wrote:
> Like Matt, I have concerns about modifying the files in the deployment
> as well. I think his concerns about division of roles are valid - I'd
> go further and say this needs to be able to handle a split between
> 'deployer' and 'operator/sys admin' as well (where e.g. deployer
> defines which database to use, the sys admin defines the connection
> pool size).
Every place has a different distinction between what a developer and an
admin does. At some places the developers defines the entire db pool,
at some the developer really only specifiec the pool name, and there
are places in between the two.
I am not making the claim that this is the solution for everyone,
especially developers. I am saying that the average admin wants this
feature.
> There are also circumstances where the SAR will be unmodifyable - e.g.
> if it is set read-only on the OS or if it is loaded from an http: URL.
If a attribute is not persistable, then we don't persist it. We should
modify the jmx-console to notify the user if an attribute is persistent
or not.
> One possibility might be to store the local changes as a transform
> applied against the original file e.g. an XSLT.
There are very few developers that understand XSLT, I would guess even
less admins.
> This also has the advantage that local changes don't get lost when a
> new version is received from development. Also the same file can be
> rolled dev->test->stage->prod without needing to modify the deployment
> descriptor each time (one of the biggest compaints I've had from sys
> admins).
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.
-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>>
