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.
