>
> 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.
>
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 wrote:
> To answer Luciano'
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 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
On Wed, 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" :
>
> Sc
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 contri
