geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Move blocker GERONIMO-1960 to 1.1.1?
Date Wed, 24 May 2006 21:23:45 GMT
Deploy reduces to distribute+start.  If the distribute fails, the
whole thing fails.  If distribute works but start fails, it's left
distributed but not started.  We could try to undeploy if start fails,
which should be a trivial change -- that's probably at least better
than what we do now.  What do you think?

Thanks,
     Aaron

On 5/24/06, Dain Sundstrom <dain@iq80.com> wrote:
> Don't most people just use the one step "deploy" instead of
> "distribute" then "start".  If I am correct, there should be very
> little difference in the user experience.
>
> -dain
>
> On May 24, 2006, at 11:21 AM, Aaron Mulder wrote:
>
> > 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.
> >
> > Thanks,
> >    Aaron
> >
> > On 5/24/06, Dain Sundstrom <dain@iq80.com> 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
> >>
>
>

Mime
View raw message