Raymond
There are two sets of issues here:
* How to support SCDL extensibility elements
* How to support import.sdo as an instance of that
As seed for discussion of the second, I don't think @Reference is the
right way to declare access to a HelperContext - this seems more like
a resource. Specifically, I think using @Reference or <reference> in
the component type will result in SCDL that is not semantically valid
by SCA rules even if it happens to work in Tuscany and I think that's
a problem. This is probably a big enough issue that it warrants its
own thread.
In terms of extension, I think we need to look at the protocol
between the controller and the runtime. That is based on a concept of
a PhysicalChangeSet (PCS) contaning:
* resource definitions (e.g. for scopes, classloaders, or other
runtime-specific things)
* component definitions
* wire definitions
So the question really is about how does a SCDL extension map to one
of those definitions and I think there are a couple of patterns for
that:
1) the element extends the function of the containing model object
in that case it is not really generic and would be handled by the
Generator for the container
2) the element creates one of the definitions above independent of
the containing model object
this is just a regular Generator acting on the extension object
and adding a definition to a PCS
3) the element does something in the context of the containing model
object
again just a Generator, but one that needs to be passed the parent
With that in mind, I think we end up with a API more like:
interface Generator<M extends ModelObject, P extends ModelObject> {
void generate(M modelObject, P parent, GenerationContext
context) throws Something;
}
class GenerationContext {
property Map<RuntimeId, PhysicalChangeSet> changeSets;
}
Generator implementation may also need access to a physical model
that tracks the state of each physical runtime so that they can
determine what the current runtime context is. This would be updated
based on change events sent back from the runtime as it applied
various PCS messages. That though is getting off topic :-)
--
Jeremy
On Mar 16, 2007, at 10:16 AM, Raymond Feng wrote:
Hi,
We had discussions on this ML before on how to support SCDL
extensibility elements which are not part of the base SCDL model
and are used in SCDL for <xsd:any/>.
Let's use <import.sdo> as an example to illustrate my proposal.
1) ImportSDOLoader is a StAXElementLoader to load <import.sdo>
element into ImportSDO model object.
2) The model object is attached to the parent model object which is
CompositeComponentType in this case. We can use
ModeObject.getExtensions() to keep the models loaded from the
extensibility elements.
3) Add a GenericBuilder interface and GenericBuidlerExtension in
SPI as follows:
public interface GenericBuilder<S extends SCAObject, M extends
ModelObject> {
S build(SCAObject parent, M modelObject, DeploymentContext
deploymentContext) throws BuilderException;
}
4) Change the Buidler and BuilderRegistry interface to support
GenericBuilder.
5) Create an ImportSDOBuilder which will create HelperContext from
the ImportSDO model.
6) When the BuilderRegistery builds Component/Service/Reference, we
look at the extensions for the corresponding model objects and try
to run the GenericBuilders against the objects in
ModelObject.getExtensions().
7) The ImportSDOBuilder creates a AtomicComponent to wrap
HelperContext. and register it in the composite so that the
component impl can use @Reference (autowire=true) to get access to
this HelperContext.
If we agree I'm on track with the overall direction, I'll work on it.
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]
