Hi Yang, do you need to be able to specify this context per contribution or per deployed composite? I.e if a contribution has multiple deployable composites do you need to be able to define different context for each?
...ant On Sat, Jun 5, 2010 at 3:17 AM, Yang Lei <yl.yangle...@gmail.com> wrote: > 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 <cyberf...@gmail.com> 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 >> rf...@apache.org >> 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. >