Okay thats good feedback a lot more work though. On Fri, Sep 17, 2010 at 12:01 AM, André Warnier <a...@ice-sa.com> 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 "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 > >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
