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.
