geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Move blocker GERONIMO-1960 to 1.1.1?
Date Wed, 24 May 2006 19:32:04 GMT
I agree that we should address this in 1.1.1.  Another problem I ran into today is when a deployment

fails and the artifacts are left in the repo but are unusable requiring a manual removal of
the 
items.  I need to see if there is an existing JIRA.

Matt

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