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)
Message-ID: <4477C0F9.6090206@hogstrom.org>
Date: Fri, 26 May 2006 23:01:13 -0400
From: Matt Hogstrom <matt@hogstrom.org>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Move blocker GERONIMO-1960 to 1.1.1?
References: <20060526162721.15421.qmail@web54401.mail.yahoo.com>
 <74e15baa0605260947m7ef624c4k9ff2a990c4dc4cde@mail.gmail.com>
In-Reply-To: <74e15baa0605260947m7ef624c4k9ff2a990c4dc4cde@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I concur with Aaron that including it is reasonable.

Aaron Mulder wrote:
> This may be no surprise, but I think including it is reasonable.  :)
> 
> Thanks,
>    Aaron
> 
> On 5/26/06, David Jencks <david_jencks@yahoo.com> wrote:
>> I think I've lost the thread and level-of-reply info
>> due to having to use the web interface for mail,
>> sorry.... copying the message I'm replying to...
>>
>> --original message thread...
>> On May 24, 2006, at 12:47 PM, Dain Sundstrom wrote:
>>
>> On May 23, 2006, at 11:26 PM, David Jencks wrote:
>>
>>
>> On May 23, 2006, at 11:04 PM, David Jencks wrote:
>>
>> +1 on excluding this from 1.1.  I agree it's not a
>> blocker.
>>
>> I think client-corba needs a dependency on
>> client-security, I thought it was there.  I'll try to
>> investigate on the plane tomorrow.
>>
>> I expected you to fix this by modifying the
>> ServiceConfigBuilder to check that the gbean reference
>> was satisfied in the ancestor set when it is reading
>> the xml.  This is what the other builders do for e.g.
>> resource-refs, and I think it would be simple and
>> non-invasive.  However, in any case I don't think this
>> is a blocker.... the worst that can happen is that you
>> get an error later rather than sooner, you get
>> essentially the same effect either way.
>>
>> Umm, re this comment, I should think before writing
>> :-)
>>
>> A moment's further thought reminded me that the reason
>> we can check e.g. resource-refs when we process them
>> is that we have a multistep process in the j2ee module
>> builders and when we resolve the references we already
>> know all the gbeans.  This is not the case for service
>> modules so the verify method you added or some other
>> way of introducing 2 steps would be necessary.
>>
>> Bingo!  It took me a few tries to get this patch
>> right.  My first attempt worked just as you suggested
>> above (verify as reading the xml), and I ran into the
>> problem where beans were referring to stuff further
>> down in the file.  My second attempt was to modify the
>> ServiceConfigBuilder to verify after all beans had
>> been added, but I ran into the problem where beans
>> were referring to stuff in modules that hadn't been
>> processed yet.  My final attempt was to put the verify
>> method in DeploymentContext and set it to verify when
>> we call getConfigurationData().  Since this method is
>> only called when the deployment is complete, all
>> gbeans should be available.  The patch does appear to
>> work, but complexity of writing it made me nervous
>> about putting it into 1.1.
>>
>> -----my reply
>>
>> Ok... so I spent most of my plane ride to Florida
>> working on getting MagicGBall working again.  The
>> plans your verifier flagged were indeed very faulty.
>> This makes me somewhat positive towards including this
>> in 1.1.  Anyone else think including it is reasonable?
>>
>> thanks
>> david jencks
>>
>>
>> -dain
>>
>>
> 
> 
>