You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Yang Lei <yl...@gmail.com> on 2010/06/03 06:15:17 UTC
How to pass "context" into contribution processing , binding and
implementation startup
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.
Re: How to pass "context" into contribution processing , binding and
implementation startup
Posted by Yang Lei <yl...@gmail.com>.
>
> Hi Ant,
>
I would need to specify contribution related context data and deployable
composite related context data. Then of course, a deployable composite also
needs to access its defining contribution's context..
> Thanks. Yang.
>
Re: How to pass "context" into contribution processing , binding and
implementation startup
Posted by ant elder <an...@gmail.com>.
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...@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 <cy...@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
>> rfeng@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.
>
Re: How to pass "context" into contribution processing , binding and
implementation startup
Posted by Yang Lei <yl...@gmail.com>.
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 <cy...@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
> rfeng@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.
Re: How to pass "context" into contribution processing , binding and implementation startup
Posted by Raymond Feng <cy...@gmail.com>.
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
rfeng@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.
Re: How to pass "context" into contribution processing , binding and
implementation startup
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jun 2, 2010 at 9:15 PM, Yang Lei <yl...@gmail.com> 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.
>
Do you have more details on what type of information you need on the
context ? Is this something that you need to pass as context, or these
are "extended contribution attributes" ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/