geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject potenial problem with GBean attribute processing
Date Fri, 28 Jul 2006 21:25:28 GMT

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:

       <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.


View raw message