geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Move blocker GERONIMO-1960 to 1.1.1?
Date Fri, 26 May 2006 16:47:39 GMT
This may be no surprise, but I think including it is reasonable.  :)


On 5/26/06, David Jencks <> 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

View raw message