To answer Luciano's question: the information are related to my hosting environment for a given contribution or deployable composite, which later I can use to calculate classLoader for the contribution , setting up service endpoint...
Thanks On Thu, Jun 3, 2010 at 12:39 AM, Raymond Feng <[email protected]> wrote: > 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. > > > -- Thanks. Yang.
