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 Wed, 24 May 2006 18:21:31 GMT
Well, I do feel that it's a pretty serious issue...  Mainly because
it's a hard-to-interpret error at an unfortunate time... The thing is
distributed but not started so it seems kind of like it worked (e.g.
the new thing appears in the console, etc.) but really it didn't.  (I
expect users to be able to understand "error caused deployment to
fail" but not "deployment succeeded but module still isn't running.")
I guess I'm OK if this is deferred, but I don't really want to
de-emphasize it much.


On 5/24/06, 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.
> -dain

View raw message