You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/03/12 19:47:18 UTC
Federating ScopeContainer, was: Change to PhysicalComponentDefinition
On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:
> Firstly, transporting Scope is not enough on its own as there is
> more than one COMPOSITE scope. The builders used to get this from
> the deployment context but with federation it will need to be
> passed to in the PCD. I think instead we should treat
> ScopeContainers as resources and give them IDs like ClassLoaders.
> For COMPOSITE scope the ID can be the URI of the component
> implemented by the composite; for others we can use well known IDs.
> Every component has a scope so I think we can put scopeContainerID
> down in to PCD itself.
Following on with this I'm going to make the following changes to the
ScopeContainer SPI to externalize the idea of a instance of a scope
i.e a ScopeContext:
* add methods startContext(Object id) and stopContext(Object id)
this will place external code in control of the lifecycle of the
scope context so that it can be initiated
by the code that dictates the lifecycle. This will allow us to
avoid having the container register for and
receive events just to detect context lifetime.
* change get and return wrapper to also pass the contextId
* add a Map<Scope, Object> to the WorkContext to associate scope
context ids with the current work
* update the target invoker to get wrappers based on the current work
context and the component's scope
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
WorkContext, was: Federating ScopeContainer
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 17, 2007, at 2:49 PM, Jeremy Boynes wrote:
> Instead, I'm going to move the work context into the invocation
> message so that is available as part of the invocation chain and
> make it the responsibility of the invoker to tunnel that through
> the user component if necessary. That will also make it easier for
> the async processing as the context would automatically be
> associated with the work being enqueued.
This is now done. There is a pairing between the TargetInvoker and
the InvocationHandlers to tunnel context through calls to user POJOs
using a ThreadLocal. Messages between components now carry the
WorkContext in the payload.
I have updated the edge invokers for standalone and itest runtimes to
bind a SimpleWorkContext to the thread before calling launched and
junit components, starting off the invocation chain.
I have not updated the web implementation yet as it is using
JDKInvocationHandlers for the references it stores in the
ServletContext and they require the WorkContext on the thread. This
would mean exposing the tunnel to user code and I think that is a /
bad idea./ Instead, I think we should change the handlers it uses so
that the work context is created there when the user calls the
reference and then passed down the chain.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federating ScopeContainer, was: Change to PhysicalComponentDefinition
Posted by Jeremy Boynes <jb...@apache.org>.
First big chunk of this in r519446. Added groups and refactored the
CompositeScopeContainer
I ran into a problem with the way we are associating IDs with the
thread in a central WorkContext. This makes it necessary for an awful
lot of components to reference the work context just so that can pass
it to other things e.g. all the builders need to reference it so that
they can inject into the components just to they can inject it to the
target invoker so it can get the context id. This seems dumb.
Instead, I'm going to move the work context into the invocation
message so that is available as part of the invocation chain and make
it the responsibility of the invoker to tunnel that through the user
component if necessary. That will also make it easier for the async
processing as the context would automatically be associated with the
work being enqueued.
For now I have temporarily commented out scopes other than composite
- normal service will be resume shortly.
--
Jeremy
On Mar 13, 2007, at 1:55 PM, Jeremy Boynes wrote:
> On Mar 12, 2007, at 11:47 AM, Jeremy Boynes wrote:
>
>> On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:
>>
>>> Firstly, transporting Scope is not enough on its own as there is
>>> more than one COMPOSITE scope. The builders used to get this from
>>> the deployment context but with federation it will need to be
>>> passed to in the PCD. I think instead we should treat
>>> ScopeContainers as resources and give them IDs like ClassLoaders.
>>> For COMPOSITE scope the ID can be the URI of the component
>>> implemented by the composite; for others we can use well known
>>> IDs. Every component has a scope so I think we can put
>>> scopeContainerID down in to PCD itself.
>>
>> Following on with this I'm going to make the following changes to
>> the ScopeContainer SPI to externalize the idea of a instance of a
>> scope i.e a ScopeContext:
>> * add methods startContext(Object id) and stopContext(Object id)
>> this will place external code in control of the lifecycle of the
>> scope context so that it can be initiated
>> by the code that dictates the lifecycle. This will allow us to
>> avoid having the container register for and
>> receive events just to detect context lifetime.
>> * change get and return wrapper to also pass the contextId
>> * add a Map<Scope, Object> to the WorkContext to associate scope
>> context ids with the current work
>> * update the target invoker to get wrappers based on the current
>> work context and the component's scope
>
> Taking this a little further I think we need an additional mapping
> here - a component group. This allows us to partition a Scope into
> groups of component that support a common lifetime. The obvious
> application for this is with COMPOSITE scope where there are a
> group of components whose lifetime is tied to that of a composite;
> a more subtle application would be in conjunction with an EAR
> deployment where we want to relate HttpSession scoped components in
> different web applications. This would also allow us to support
> eagerInit semantics for scope types over and above COMPOSITE.
>
> To support this I'm going to add another two method to
> ScopeContainer: createComponentGroup(Object) and
> removeComponentGroup(Object) and change the register/unregister
> methods to add a component group id so that the container can
> associate the component with the group.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federating ScopeContainer, was: Change to PhysicalComponentDefinition
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 12, 2007, at 11:47 AM, Jeremy Boynes wrote:
> On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:
>
>> Firstly, transporting Scope is not enough on its own as there is
>> more than one COMPOSITE scope. The builders used to get this from
>> the deployment context but with federation it will need to be
>> passed to in the PCD. I think instead we should treat
>> ScopeContainers as resources and give them IDs like ClassLoaders.
>> For COMPOSITE scope the ID can be the URI of the component
>> implemented by the composite; for others we can use well known
>> IDs. Every component has a scope so I think we can put
>> scopeContainerID down in to PCD itself.
>
> Following on with this I'm going to make the following changes to
> the ScopeContainer SPI to externalize the idea of a instance of a
> scope i.e a ScopeContext:
> * add methods startContext(Object id) and stopContext(Object id)
> this will place external code in control of the lifecycle of the
> scope context so that it can be initiated
> by the code that dictates the lifecycle. This will allow us to
> avoid having the container register for and
> receive events just to detect context lifetime.
> * change get and return wrapper to also pass the contextId
> * add a Map<Scope, Object> to the WorkContext to associate scope
> context ids with the current work
> * update the target invoker to get wrappers based on the current
> work context and the component's scope
Taking this a little further I think we need an additional mapping
here - a component group. This allows us to partition a Scope into
groups of component that support a common lifetime. The obvious
application for this is with COMPOSITE scope where there are a group
of components whose lifetime is tied to that of a composite; a more
subtle application would be in conjunction with an EAR deployment
where we want to relate HttpSession scoped components in different
web applications. This would also allow us to support eagerInit
semantics for scope types over and above COMPOSITE.
To support this I'm going to add another two method to
ScopeContainer: createComponentGroup(Object) and removeComponentGroup
(Object) and change the register/unregister methods to add a
component group id so that the container can associate the component
with the group.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org