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