Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=DiBwyPzs+LZzpJVgUD5QWCsm6NQg5rqE3f3jX8PqeNfGYr7XDj9p8axbExSCpftQ;
  h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <44CA8E4A.6040706@earthlink.net>
Date: Fri, 28 Jul 2006 18:23:06 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: potenial problem with GBean attribute processing
References: <44CA80C8.5070407@earthlink.net>
 <74e15baa0607281433m77d84424qc5d5f6250ee0e662@mail.gmail.com>
In-Reply-To: <74e15baa0607281433m77d84424qc5d5f6250ee0e662@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I created this JIRA for the problem: 
http://issues.apache.org/jira/browse/GERONIMO-2241

Joe

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 <joe.bohn@earthlink.net> 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}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.
>>
>> Thanks,
>> Joe
>>
> 
>