>> >> > The difference as I understand it is that only very selected parts > of the invocation context would be exposed to application code > (i.e., what's available via the SCA API plus whatever the handlers > choose to make available), but the entire contents of the > Tuscany-defined generic context (all message headers for example) > would be exposed. > > Simon > >
I agree that a component implementation should get at only that data that is allowed access to by the SCA API. I would argue that interceptors on the message chain should have access to any context that they require to do their processing. I would be very happy if an API were used to provide that to them. Currently the API is provided by the Message object. However we are finding that this is not good enough as we need to, for example, get at the service context in reference processing. If there were a context that allowed interceptors to add information that other interceptors could later retrieve on a thread by thread basis I think that would do the job. I think you are arguing that the Thread storage/manipulation should be hidden behind and API which is OK by me. This API may be different from the API used to expose context to implementation implementers. What I'm not clear on from your comment is what context you would hide from down-stream interceptors. It seems unnecessary to populate a context with information that subsequent processing can't read. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
