..snip >> >> 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. >> > Getting access to the service context during reference processing might > be possible if we defer the point where the Message object gets switched > in the thread context. However I'm not keen to see the inbound Message > used as a read-write communication vehicle between application code and > downstream reference interceptors/handlers.
I think I probably agree with this. It's primarily the context that today that gets stuffed in the message headers that we're interested in. > >> 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 >> > I'm not suggesting that any context would be hidden from interceptors. > My concern is to limit what application code can access. OK, makes sense. >The paths of > communication are: > > 1) service handler ----> component implementation > > 2) component implementation ----> reference interceptor/handler > > For 1), the service handler would have full access to the inbound > Message and would use that to create a specialized "data transfer" > object that would be accessible to the component implementation by > injection. > > For 2), the component implementation could modify the same > "data transfer" object and this object would be accessible to the > reference interceptors/handlers. If we defer the point where the > Message object gets switched, the reference interceptors/handlers > would also have access to the inbound Message (as well as to the > under-construction outbound Message) if they need it. Sounds OK, I still haven't got to the bottom of why we need the switch but I haven't looked at all of the end to end picture yet. > > I'm using the term "data transfer" rather than "context" as the > latter term is somewhat overloaded and potentially confusing. Good point. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
