geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: potenial problem with GBean attribute processing
Date Sun, 30 Jul 2006 18:05:54 GMT
I don't see any duplicate entries.  You have two attributes  
keystorePassword and keystorePasswords.


On Jul 28, 2006, at 2:33 PM, Aaron Mulder wrote:

> It sounds like a problem with the attribute manager and related code
> to me -- it's responsible for writing config.xml and it should ensure
> that there are no duplicate entries.  Can you create a Jira for 1.1.1
> for this?  We better fix it.
> Thanks,
>    Aaron
> On 7/28/06, Joe Bohn <> wrote:
>> There is either a problem with the attribute processing on gbeans  
>> or the
>> keystore use of this processing, I'm not sure which.
>> The problem is that there are times when an attribute is being set  
>> which
>> result in two entries in the config.xml for the same attribute rather
>> than replacing the current setting.  Here is the scenario.
>> There is an attribute on the keystore instance gbean (the default  
>> one we
>> provide) for the keystore lock password and key passwords.  The  
>> scenario
>> happens with both attributes but I'm most concerned with the keystore
>> lock at the moment so I'll just discuss that one.
>> With a brand new image, the attribute for the keystore lock is set to
>> the default password (which effectively means it is unlocked).  If we
>> lock the keystore the password is then replaced with a null value and
>> this is reflected in the config.xml.  So far, so good.  However,  
>> when we
>> subsequently unlock the keystore, rather than replacing the password
>> attribute with the value again it ends up creating a second entry for
>> the attribute just before the null value entry.  Here is what it  
>> looks
>> like in the config.xml:
>>      <gbean
>> name="geronimo/j2ee-security/1.1.1-SNAPSHOT/car? 
>> ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/ 
>> car,j2eeType=Keystore,name=geronimo-default">
>>        <attribute
>> name="keystorePassword">{Simple} 
>> rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZ 
>> </attribute>
>>        <attribute
>> name="keyPasswords">{Simple} 
>> rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZ 
>> +AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAIJu+zYXdGgTo+dMtBxYduheM0Te6O/ 
>> om49Ln+vWNipopcHQAA0FFUw==</attribute>
>>        <attribute name="keystorePassword" null="true"/>
>>        <attribute name="keyPasswords" null="true"/>
>> It appears that "null" wins out (probably because it is last) and the
>> net result is that the keystore remains locked.  This is not a good
>> thing (see other posts on the keystore processing).
>> So my question is this:  Is this a problem with the way we are  
>> setting
>> the attribute or is it a problem with the attribute processing itself
>> (particularly around the setting and removing of a null value)?  The
>> code that sets the attribute is in FileKeystoreInstance around  
>> line 130.
>> Thanks,
>> Joe

View raw message