Hi,
When I try to register a HelperContext component for the composite from
databinding-sdo extension, I found that I need to access the
ComponentManager which is in the core. Can we promote it to SPI?
BTW, do we still have the distinction of system component or regular
component?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, March 02, 2007 11:27 AM
Subject: Re: How to associate some context with a composite?
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: <[email protected]>
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
