Classification: UNCLASSIFIED Caveats: NONE To make it more readable, some text is cut.
... cut ... > > > > The drawback of this approach is that it does not abstract and > promote > > reuse. Each handler and/or component implementation is required to > > develop its own context object and injection extension while an > > abstraction, such as a map<String, Object>, could satisfy most > demands > > and be reused. > > > The "data transfer/context" objects would be developed and created by > handlers and used by component implementations. There's no need for > any injection extensions as the Tuscany runtime would take care of > that. > > One problem with Map<String, Object> is that different handlers could > collide with each other if they happen to use the same String keys > for entries in the Map. Also this type definition isn't sufficiently > unique to allow the type-driven Tuscany injection mechanism to function > correctly. The key collision can be remedied by using hierarchically qualified key names, such as "org.apache.tuscany.axis2-binding.XXX", which makes collision unlikely. In my scheme, the entire application context object (a single one of type say ApplicationContext), which is implemented using Map<String, Object>, is injected into the component implementation and let the component implementation to get what it wants and ignore those it doesn't care. I don't see how it would cause injection difficulty. > > > The shared general context also promote sharing. For example, in JAX- > WS > > framework, certain WS-* related properties that are put in by the > > underlying JAX-WS framework provider or other handlers can and are > used > > in our WS-Security implementation. It promotes reuse. In some case > the > > information that are put in the context by the framework or other > > handlers is not obtainable by our WS-security handlers because of the > > phrases and layers differences. > > > I think this supports my reservations about a shared context. By > requiring each handler to define specifically what state it makes > available to the application, it is always clear what information > will be available, based on the combination of handlers (policy sets) > attached to a service or reference. If something else needs to be > provided, one of the existing handlers must be extended or a new > handler > must be added. I think my original comment was a positive one - sharing and reuse are good and sometimes it is even necessary. Making each handler to define its proprietary "context" prevents sharing and reuse, which is undesirable. As I mentioned earlier, if the isolation is required, the proprietary contexts can still be defined to achieve that. But I think most cases, we simply want to have an existing generic context to be provided and use it. --- cut --- Gang Classification: UNCLASSIFIED Caveats: NONE
