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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to