Venkata Krishnan wrote:
Hi,
The Assembly Model specs mentions the 'need' for definitions of metadata
related to implementation and binding extensions types as follows:
"2665 In addition to the definition for the new implementation instance
element, there needs to be an
2666 associated implementationType element which provides metadata about the
new implementation
2667 type. The pseudo schema for the implementationType element is shown in
the following snippet:
2668 <implementationType type="xs:QName"
2669 alwaysProvides="list of
intent xs:QName"
2670 mayProvide="list of
intent xs:QName"/>"
2749 <bindingType type="xs:QName"
2750 alwaysProvides="list of intent
QNames"?
2751 mayProvide = "list of intent
QNames"?/>
This metadata is supposed to be defined in definitions.xml file as defined
on page 57, section title "SCA Definitions".
Since I am having to address the definitions.xml file as part of the policy
framework implementation, I have included model and processors for
implementationType and bindingType elements within the policy and policy-xml
modules. But I guess this has to move out to a place that typically deals
with 'domain' related things in general. Could people share some thoughts
on this please ?
Thanks
- Venkat
ImplementationType and BindingType are policy definitions, so what
you've done - having StAX artifact processors for them in module
policy-xml - makes sense to me. I'm not sure why we'd want to move them
to a domain module, as that would tie unrelated aspects of an SCA domain
together (and that wouldn't be good IMO).
With respect to SCA definitions (contained in definitions.xml), we need:
- a proper Definitions model separate from the policy module (as it can
be used to define shared binding declarations which have nothing to do
with policies - as described in the JMS binding spec)
- a URLArtifactProcessor and StAXArtifactProcessor for definitions.xml
I think we should follow the same pattern as the other models:
- the Definitions model and its factory in a definition module
- the URLArtifactProcessor and StAXArtifactProcessor in a definition-xml
module
The assembly module and the bindings that need to leverage shared
definitions will need to depend on this new definition module so I'd
suggest to it very minimal with just the Definitions model, unless you
want to have to solve circular dependencies issues :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
