You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/05/24 04:55:49 UTC
Move blocker GERONIMO-1960 to 1.1.1?
I finished the patch for GERONIMO-1960 (http://issues.apache.org/jira/
browse/GERONIMO-1960), but I think it may be destabilizing and should
be move to 1.1.1.
I added a verify method to Deployment context which is called from
getConfigurationData(). This method verifies the references and
dependencies on can be resolved. I only try to resolve dependencies
and single valued references. Further, only unresolved reference
patterns are resolved, under the assumption that the deployer created
a resolved pattern correctly. We can not absolute references to
beans in external modules.
A couple of the client plans threw exceptions so I had to patch them
also, which is why I am concerned. The client-security has
unnecessary and possibly incorrect module declarations and the client-
corba plan has a dependency on SecurityService which can't be
resolved since there is no dependency on client-security. I removed
the former and commented out the latter. I am not sure if we need
the dependency on SecurityService in client-corba, and if so, I'm not
sure if we can add a dependency from client-corba to client-
security. David Jencks any help here would be appreciated.
Anyway, I don't think this is issue actually a blocker issue, and
think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal
flops).
-dain
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <da...@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
>>
>
>
>
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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 <da...@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
> >>
>
>
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by Dain Sundstrom <da...@iq80.com>.
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 <da...@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
>>
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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
>
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by Dain Sundstrom <da...@iq80.com>.
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
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by David Jencks <da...@yahoo.com>.
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.
thanks
david jencks
> thanks
> david jencks
>
> On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote:
>
>> I finished the patch for GERONIMO-1960 (http://issues.apache.org/
>> jira/browse/GERONIMO-1960), but I think it may be destabilizing
>> and should be move to 1.1.1.
>>
>> I added a verify method to Deployment context which is called from
>> getConfigurationData(). This method verifies the references and
>> dependencies on can be resolved. I only try to resolve
>> dependencies and single valued references. Further, only
>> unresolved reference patterns are resolved, under the assumption
>> that the deployer created a resolved pattern correctly. We can
>> not absolute references to beans in external modules.
>>
>> A couple of the client plans threw exceptions so I had to patch
>> them also, which is why I am concerned. The client-security has
>> unnecessary and possibly incorrect module declarations and the
>> client-corba plan has a dependency on SecurityService which can't
>> be resolved since there is no dependency on client-security. I
>> removed the former and commented out the latter. I am not sure if
>> we need the dependency on SecurityService in client-corba, and if
>> so, I'm not sure if we can add a dependency from client-corba to
>> client-security. David Jencks any help here would be appreciated.
>>
>> Anyway, I don't think this is issue actually a blocker issue, and
>> think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal
>> flops).
>>
>> -dain
>>
>
Re: Move blocker GERONIMO-1960 to 1.1.1?
Posted by David Jencks <da...@yahoo.com>.
+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.
thanks
david jencks
On May 23, 2006, at 7:55 PM, Dain Sundstrom wrote:
> I finished the patch for GERONIMO-1960 (http://issues.apache.org/
> jira/browse/GERONIMO-1960), but I think it may be destabilizing and
> should be move to 1.1.1.
>
> I added a verify method to Deployment context which is called from
> getConfigurationData(). This method verifies the references and
> dependencies on can be resolved. I only try to resolve
> dependencies and single valued references. Further, only unresolved
> reference patterns are resolved, under the assumption that the
> deployer created a resolved pattern correctly. We can not
> absolute references to beans in external modules.
>
> A couple of the client plans threw exceptions so I had to patch
> them also, which is why I am concerned. The client-security has
> unnecessary and possibly incorrect module declarations and the
> client-corba plan has a dependency on SecurityService which can't
> be resolved since there is no dependency on client-security. I
> removed the former and commented out the latter. I am not sure if
> we need the dependency on SecurityService in client-corba, and if
> so, I'm not sure if we can add a dependency from client-corba to
> client-security. David Jencks any help here would be appreciated.
>
> Anyway, I don't think this is issue actually a blocker issue, and
> think we can safely move it to 1.1.1 (or 1.2 if my 1.1.1 proposal
> flops).
>
> -dain
>