tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wesley Acheson <>
Subject Re: Host Manager.
Date Thu, 16 Sep 2010 22:04:47 GMT
Okay thats good feedback a lot more work though.

On Fri, Sep 17, 2010 at 12:01 AM, André Warnier <> wrote:
> Wesley Acheson wrote:
>> The way I've implemented this it does all the normal work of adding
>> the host to the container before trying to persist the file.
>> Now there are a lot of things that can go wrong when trying to write
>> to a filesystem. Maybe the user doesn't have permission to update the
>> file. Maybe the existing file is unparseable for some reason (that one
>> shouldn't really happen). Maybe the security manager stops the user
>> updating the file. etc. etc.
>> So my question is what should be seen in the host manager in
>> everyone's opinion if the file system changes aren't persisted?
>> Some possibilities below:
>> Should it still show success as its been added to the container.?
>> Should the addition to the container be undone (rollback)?
>> Should it show an error? Or two messages 1 for the container 1 for the
>> file?
>> If error messages are shown how much information should be shown to
>> the client, a full stack trace, an informative message such as "update
>> server.xml:FAIL blocked by security manager"
>> Please feel free to pitch in anyone.
> Although I am not really competent, I will use your last phrase above as an
> excuse and pitch in.
> I understand what you are saying about what can go wrong, and I understand
> that conditions after a change may not be the same as when the change was
> started.
> But I find it particularly frustrating when I do a lot of work in an
> application, and when I want to save my work at the end, it comes and tells
> me that it cannot be saved, and does not provide any alternative (*).  I
> would imagine that some of these reasons for not being able to write
> server.xml, can be tested ahead of time, and a warning message provided to
> the user as to that fact, before they start making changes.
> Also, maybe in case server.xml cannot be directly overwritten, an
> alternative path could be requested from the user ? (and/or the file could
> be written first as "", and only renamed in a second step,
> which could fail).
> (*) the popup dialog with a single button "Press OK to reboot" comes to
> mind.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message