geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Bohn (JIRA)" <...@geronimo.apache.org>
Subject [jira] Closed: (GERONIMO-2241) Duplicate attributes created in config.xml for gbean
Date Thu, 10 Aug 2006 17:37:15 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-2241?page=all ]

Joe Bohn closed GERONIMO-2241.
------------------------------


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

        

Mime
View raw message