We have defined "Context" for a few stages in the processing: * ProcessorContext for the artifact processors (read/write/resolve) * BuilderContext for the builders (build) * CompositeContext for the runtime (we probably should name it as RuntimeContext :-). We might want to pass it to the runtime providers if necessary. * ThreadMessageContext for the request context on the thread
Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jun 2, 2010, at 9:15 PM, Yang Lei wrote: > > I would like to bring up a requirement on contribution processing, binding > provider start, implementation provider start. > > While trying to integrate Tuscany 2.x into a hosting environment, there are > times I need to know "context" : > > Scenario 1, I need to create my own classLoader of a given contribution. > > When implementing the ModelResolver, the code can access > org.apache.tuscany.sca.contribution.Contribution , however I can not pass a > "context" that is associated with this contribution. So I will either have > to maintain singleton HashMap between the contribution ID to this "context", > or I have to use threadLocal to pass information around. I do not like either > approach. > > One way can solve the problem is to allow the object that I use to start the > contribution(e.g. org.apache.tuscany.sca.node.Contribution) to set some > "context" , and the same "context" will be copied onto the runtime > Contribution object. E.g. add method: java.util.Properties > getContextProperties() in both Contribution classes. > > Scenario 2, for certain bindings I am developing, I also need to know some > "context". This "context" is associated with the deployable composite that > hosting the component. Again if I can not make this "context" available to > the ServiceBindingProvider, I would have to maintain a singleton HashMap or > using threadLocal, which I want to avoid . > > I do see that RuntimeEndpoint , available for the Service BindingProvider, > has method : CompositeContext getCompositeContext(). It seems if the same > "context" set on node.Contribution above can be available to the > CompositeContext, then I have what I need. E.g. adding method > java.util.Properties getContributionContextProperties() in CompositeContext > which return the contribution's java.util.Properties getContextProperties() . > > Of course, there may be other ways achieving it. I would like to start the > discussion. > > Thanks. Yang.
