[ http://issues.apache.org/jira/browse/GERONIMO-2241?page=all ]
Joe Bohn updated GERONIMO-2241:
-------------------------------
Component/s: core
> Duplicate attributes created in config.xml for gbean
> ----------------------------------------------------
>
> Key: GERONIMO-2241
> URL: http://issues.apache.org/jira/browse/GERONIMO-2241
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: core
> Affects Versions: 1.1.1
> Environment: windows xp
> jetty and tomcat
> Reporter: Joe Bohn
> Assigned To: Joe Bohn
> Fix For: 1.1.1
>
>
> Here is the text from a dev list post. For the post responses see:
> http://marc.theaimsgroup.com/?l=geronimo-dev&m=115412195529876&w=2
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
