Hi,
Here's an example I'm from.
1) I use "import.sdo" to configure the SDO type system for a composite. The
SDOImportLoader is added to deal with this SCDL extensibility element.
During "load" phase, it will populate a SDO TypeHelper instance.
2) For references or services with web service bindings in the same
composite, the Axis2 binding extension (or ideally DataBinding interceptor)
has to deal with SDO/AXIOM data transformation. The transformer needs to
access the corresponding TypeHelper instance (runtime context contributed
from the "import.sdo") for the composite.
So the bottom line is that I need to make some extra context (in addtion to
the base SCDL artifacts) available from the deploy phase to the runtime in a
flexible and extensible way so that the target invokers can leverage these
context to drive its invocations.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 15, 2006 10:41 AM
Subject: Re: How to build SCDL model extensions?
On Aug 15, 2006, at 10:24 AM, Raymond Feng wrote:
I don't think we're mixing the model and runtime here.
"MyExtensionDefinition" is the model object, which is the result of the
"load". Now I need to access the corresponding runtime metatdata
"MyExtension" which is supposed to be built from
"MyExtensionDefinition".
Can we step back and look at the use case we are trying to satisfy?
Runtime "metadata" sounds like the "model" to me. Perhaps what you need
is an ObjectFactory which handles this? That's how we handle other
extensions.
The reason I'm asking for this kind of extensibility is that not all the
extensions can be resolved at "load" time. For example, I may need to
resolve the "databinding.sdo" against an "import.sdo".
Can you elaborate?
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 15, 2006 10:12 AM
Subject: Re: How to build SCDL model extensions?
On Aug 15, 2006, at 9:58 AM, Raymond Feng wrote:
As defined by the SCA spec, we are allowed to add extensions to the
SCDL model, for example, we can add "myExtension" to a "composite" as
illustrated below.
<composite ...>
<ns1:myExtension xmlns:ns1="http://my.extension/";>
...
</ns1:myExtension>
</composite>
With the current extensibility story, I can register a loader to load
the "myExtension" XML stanza to creat "MyExtensionDefinition" model
object. Is the CompositeLoader supposed to add the
"MyExtensionDefinition" instance returned from my loader to its
extension map using ModelObject.getExtensions().put(...,
myExtensionDefinition) if it doesn't belong to the base SCDL model?
Assuming the answer is yes, then I would like to register a builder
to create the runtime metadata out of the MyExtensionDefinition
(AFAIK, this extensibility doesn't exist today) and attach it to the
owning SCAObject (unfortunately, SCAObject interface doesn't have the
extensions).
Why would this go on the runtime artifact as it sounds like we are
mixing runtime with model? Wouldn't it be better to handle this in the
model loading?
Does this requirement make sense? It comes out as I investigate the
"import.sdo" story.
Thanks,
Raymond
---------------------------------------------------------------------
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]
