geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: potenial problem with GBean attribute processing
Date Sun, 30 Jul 2006 18:37:26 GMT
I wish it were that easy, but it isn't.  There are two attributes that 
are each repeated .... in this order:

keystorePassword  (with value)
keyPasswords      (with value)
keystorePassword  (null value)
keyPasswords      (null value)


Dain Sundstrom wrote:
> I don't see any duplicate entries.  You have two attributes  
> keystorePassword and keystorePasswords.
> -dain
> 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 
>>> +AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAEArVToThqcjvbXFD5C2uUmpwdAADQUVT 
>>> </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