geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: potenial problem with GBean attribute processing
Date Fri, 28 Jul 2006 21:33:55 GMT
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