My guess at why this is the case is that if the DAS is up, it may not
have finished reading the keystore. For example, if an SSL listener is
configured or changed after the DAS is up, the DAS may read the keystore
at that time. If the master-password is changed while the DAS is up
(thus changing the keystore file), then a DAS that was previously
started with a different master password won't be able to read the file.
As a minimum, changing the master password would generate an
UnprocessedChangeEvent, but since it is a local command, it doesn't even
communicate with the DAS to generate the event. I suppose that
change-master-password could have been a remote command, but that would
completely change the implementation at this point.
For consistency, I would recommend just requiring the instances to be
down to change the master password.
Tom
On 12/17/2010 1:01 PM, Bhakti Mehta wrote:
> FYI This is in context to this issue
> http://java.net/jira/browse/GLASSFISH-14990 and this wiki
> http://wikis.sun.com/display/GlassFish/3.1+Master+Password
>
> Bhakti Mehta wrote:
>> Hi all,
>> I wanted to know about the following if you have history for it.
>>
>> change-master-password command requires the DAS to be down before
>> changing the password. Do you know why was that case.
>>
>> For change-master-password to work with instances would we require
>> that the instances be down?
>>
>>
>> Please can you comment. I will follow up with more questions as I
>> understand the code better
>> Regards,
>> Bhakti