Re-reading the original bug report, I think the right solution is to
simply refuse to even *attempt* to change domain.xml if we cannot
create a temporary backup file (a temporary backup file has other
safety benefits too).
Lloyd
On Sep 20, 2007, at 5:50 PM, Kedar Mhaswade wrote:
> Finally, I have been able to fix this problem (reasonably).
>
> All about it can be found at:
> http://wiki.glassfish.java.net/attach/GlassFishAdminReferences/
> 6505045.html
>
> Please go through the background and code changes if you have time
> and let me
> know if you have any comments, by tomorrow 12.00 noon, pacific.
>
> I am planning to check this in then, on GlassFish trunk.
>
> Mark Basler: I leave it up to you to approve the fix for 9.1 UR1.
> If you do
> want to do that, let me know and I can port the changes there.
>
> I have run the tests on my 128M Zip-drive on Mac OS X by observing
> domain.xml go
> to zero-bytes and domain.xml.protect coming to rescue, making every
> attempt
> to persist the domain.xml.
>
> Regards,
> Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>