Hi Raymond, I would like to put some points relevant to the idea of propagating the contribution information down the path...
+1 from me for this idea, it would help achieving the context information required for throwing a better exception. I feel, having the composite information at resolve phase helps in other ways, like in case of Spring and Web Implementation module currently we use ComponentPreProcessor technique to access the corresponding component information post resolve phase (while these information is actually required in resolve phase) to do some required processing. So propagating the contribution/composite/component information down the path would be helpful in these scenarios as well. On Thu, Jul 23, 2009 at 10:24 PM, Raymond Feng <[email protected]> wrote: > I'm also keen on capturing the SCA context > (contribution/composite/component/service|reference/binding) as part of the > error messages. It definitely helps us to point to the problem in the > composition at high level. The whole idea of SCA is to hide the plumbing > code and we don't want to leave application developers with only stack > traces. > > Depending on the stage of the processing, we could have different > techniques to produce the "SCA trace". For the build, it is easy as we have > the contribution/composite handy. For the invocation, we can potentially use > an Interceptor to capture the SCA information such as the EndpointReference, > Endpoint. > > The current code doesn't propagate the contribution information down the > path. We might think about if it's worth improving. > > Thanks, > Raymond > -------------------------------------------------- > From: "Mike Edwards" <[email protected]> > Sent: Thursday, July 23, 2009 12:55 AM > To: <[email protected]> > Subject: Re: [2.x] error handling improvements > > > Simon Nash wrote: >> >>> >>>> At the moment I've added appropriate calls to the >>>> ComponentReferenceWireBuilderImpl in order to record the composite, >>>> component and reference being processed. The composite doesn't turn >>>> out to be very useful as the composite being processed always starts >>>> with the top level composite and direct children are implicitly >>>> included and hence are thrown away by this stage. We could make this >>>> more useful by going back to Raymond's scheme of building the included >>>> composites separately but we face the same problem with any included >>>> composites further down the stack. >>>> >>>> I also had to change the structure of the loop in the code to allow me >>>> to get at the component in question. We have many instances where we >>>> create and index of components, services and references. I wonder if >>>> we still need all of them? >>>> >>>> I'm printing out the context in the "method" field of the log >>>> statement. It did make me wonder if the class name is still useful >>>> here. >>>> >>>> I am not convinced that this is the best approach. I think it's better >>> for the runtime code that detects and report the error to maintain >>> the necessary state and put this in the error message. When I get home >>> (tomorrow) I will post an example of what I have in mind. >>> >>> Simon, >> >> In many many cases, the method & class raising the error simply don't have >> the context available to them. Without this context, many error messages >> are almost worse than useless, as I have found in many hours of having to >> step the code in debug mode simply to find out in which composite some WSDL >> or interface class is causing a problem. >> >> Knowing which Contribution / Composite / Component (etc) is involved in >> the error is VITAL >> >> >> Yours, Mike. >> > > -- Thanks & Regards, Ramkumar Ramalingam
