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)
Affects Versions: 1.1.1
Environment: windows xp
jetty and tomcat
Reporter: 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
