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/>.
I have done the first cut in sca-java-integration branch to add this
support. Let's use <import.sdo> as an example.
1) ImportSDOLoader is the 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.
3) I added a GenericBuilder interface and GenericBuidlerExtension in SPI.
public interface GenericBuilder<S extends SCAObject, M extends ModelObject>
{
S build(SCAObject parent, M modelObject, DeploymentContext
deploymentContext) throws BuilderException;
}
4) I changed the Buidler and BuilderRegistry interface to support
GenericBuilder.
5) I created 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 SCAObject to wrap HelperContext. I have
tried to register it as a component in the composite so that the component
impl can use @Reference/@Autowire to get access to this HelperContext. The
registerJavaObject() works fine but it's added as a system component. As a
result, the @Autowire doesn't work out.
8) (As a workaround of 7) The result SCAObject will be added to
SCAObject.getExtensions(). For the SDO case, a wrapper of HelperContext is
added to the CompositeComponent.getExtensions().
The sca-java-integration branch is built succussfully with my local changes.
If we agree I'm on track with the overall direction, I can check them in.
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
