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=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=jBeVCyRkHwIPvavz/17+xjUJf1MC1QlzSxEmcO2kTe43dpL1jhyvEwFxV9YjPve6hs5mpfP0P9hHyVpfrjUChcMiOHQwvCha7vEYlbXrB5rvHSbpniM0lhHgB/0rLjxPndB66ifvF5o6cPkD8oKJTNUm5B8970V+PqPUrwz8Xsc=
  ;
Message-ID: <20060526162721.15421.qmail@web54401.mail.yahoo.com>
Date: Fri, 26 May 2006 09:27:21 -0700 (PDT)
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Move blocker GERONIMO-1960 to 1.1.1?
To: dev@geronimo.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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