tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Host Manager.
Date Thu, 16 Sep 2010 22:01:43 GMT
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 "server.xml.new",

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message