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)
Joe
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 <[EMAIL PROTECTED]> 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
GVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB
+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB
+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAEArVToThqcjvbXFD5C2uUmpwdAADQUVT
</attribute>
<attribute
name="keyPasswords">{Simple}
rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZ
GVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB
+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
