HI Sebastien, thanks... please see my comments inline. - Venkat
On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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). I am really not able to classify these two as just related to policy implementation alone. From what I understand these two are mechanisms for extensions to publish meta-data in general and not specifically metadata related to their support for policies. I just about inferred this from what the Assembly specs says. While today, we seem to find this a good place to define policy related metadata, I guess in future this is going to be accomodating more. Is this a right train of thoughts ? 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] > >
