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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
