geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: potenial problem with GBean attribute processing
Date Fri, 28 Jul 2006 22:23:06 GMT

I created this JIRA for the problem: 
http://issues.apache.org/jira/browse/GERONIMO-2241

Joe

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 <joe.bohn@earthlink.net> 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}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAEArVToThqcjvbXFD5C2uUmpwdAADQUVT</attribute>

>>
>>        <attribute
>> name="keyPasswords">{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+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
>>
> 
> 

Mime
View raw message