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.
