On Mar 2, 2007, at 9:53 AM, Raymond Feng wrote:
Hi, Jim.
Thank you for the suggestion.
If I understand correctly, your idea is to dynamically attach a
HelperContext Component to the composite with "import.sdo". But
isn't it a bit strange that we register a child Component while the
parent (composite) is still being loaded?
Children are no longer attached to their parents (or "registered"
with them) since in a federated environment with sparse component
trees, the parent may be on a different VM. The component has a
"flat" collection of components. Jeremy's post pointed to a few
issues around this we need to resolve.
With the ContributionService, the loaded composite is not
necessarily to be activated to the SCA domain.
I would feel better if we can attach the "import.sdo" metadata to
the composite model and then we register a HelperContext component
(make the HelperContext live) during "build" phase.
Thinking further, making HelperContext as a component will allow
the application code to reference the HelperContext with autowire.
BTW, can @Resource play a role here? HelperContext can be treated
as resource in a way.
Yes that is exactly right I think.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, February 28, 2007 1:56 PM
Subject: Re: How to associate some context with a composite?
Hi Raymond,
Comments inline....
Jim
On Feb 28, 2007, at 1:41 PM, Raymond Feng wrote:
Hi,
In the databinding framework, we need to attach some context
such as the databinding-specific typing system to a composite.
For example, in SDO databinding, we use "import.sdo" to populate
SDO types into HelperContext for the given composite and the
HelperContext will be used later on for data transformation.
What's the best way to achieve this? This is required to get
databinding-sdo back to work in trunk again.
There are some options coming into my mind:
1) Maintain a map keyed by the URI of the composite some where
in the databding-sdo code? (I guess we need to register a
"RuntimeEventListener" to listen on "ComponentEvent" so that we
can respond to the composite lifecycle.)
2) Get the ScopeContainer for the composite, and register a
SystemSingletonAtomicComponent which wraps the composite-scoped
HelperContext?
Any suggestion will be appreciated.
Ultimately, we probably need to think about this in the context of
distribution, the contribution mechanism, and artifact
provisioning to nodes. In the meantime, to get this working, I
would do the following:
Create a loader that autowires ComponentManager (remember to use
@Reference and set autowire="true" in the extension SCDL). The
loader will have access to the component URI through the
deployment context. Create a wrapper for the HelperContext that
implements Component and register it with
ComponentManager.registerJavaObject(URI uri, ServiceContract<S>
service, I instance) (you can also use the overloaded method to
register multiple contract types for autowiring). When the
composite stops, the Component should be notified. I don't think
you need to have implementation instances or deal with
ScopeContainers for this.
Let me know if you need any help getting this to work.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
