> 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).
A question:
Do you mean don't even attempt
- to "actually write" the domain.xml to disk, or
- to modify the memory that represents the domain.xml's contents,
when you can't create the backup file?
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>