On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi, > > Please find my comments inline. > > On Thu, May 8, 2008 at 3:13 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > In the SCA Policy framework spec there is a section that talks about > > bindingType as it appears in the definitions.xml file(s). It says... > > > > 702 The bindingType element is used to declare a class of binding > available > > in a SCA Domain. It declares > > 703 the QName of the binding type, and the set of intents that are > natively > > provided using the optional > > 704 @alwaysProvides attribute. > > > > I hadn't noticed this before but the implication of these words appears > to > > be that a particular binding is not available for use in a domain unless > > there is a > > > > 709 <bindingType type="NCName" > > 710 alwaysProvides="listOfQNames"? > > 711 mayProvide="listOfQNames"?/> > > > > element in the aggregate definitions.xml file. > > > > I guess this also applies to implementationType (which is defined in the > > assembly spec) and interfaceType and databindingType (which aren't defned > > in > > the assembly spec so I just made them up here) > > > > I am not sure if that's the implication. These defintions are a bit of > meta-data about the binding-types and implementation-types in the domain > and > at the present moment this is restricted to the policy area i.e. the meta > data today only talks about the intents supported in some way by an > extension. I suppose in the future there could be a few other things that > could get added as well. > > Upto now there no information there that is absolutely necessary to get an > extension's basic functionality going. So if its not present nothing > actually comes in the way with the basic functioning of the extension. > However if you were to specify a policy intent which is inherently > supported > by the extension but the type info is missing, then the PolicyFwk will > complain saying it does not have a PolicySet for this intent. The simple > reason being the it does not know that the extension inherently supports > this intent. > > > > > > Currently Tuscany uses the Java services approach to detect and load > > extensions. If an extension is loaded it is available for use. We don't > > check that bindingType, implementationType, etc is declared before making > > an > > extension available. > > > > As it happens some for our extensions include a defintions.xml file, for > > example, > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/ws/axis2/definitions.xml > > . > > And in this particular example a bindingType is defined. However this is > > not > > true of all of our extensions. > > > > Should we enforce the presence of a definitions.xml file in our > extensions > > and enforce that it contains an appropriate ?Type elemenent? On the face > of > > it there seems little benefit to doing this given our Tuscany specific > > scheme for loading extensions. However it would tip our hat to the spec, > > assuming we agree this is what the spec means, and give us a place to put > > other extension configuration information it the need were to arise. > > > > Thoughts? > > > > At the present moment I think its all very fine to load the extension even > if the type info is not present. For instance if an extension has no > intent > that it supports inherently then there is no much need for the type info. > However, if the scope of type info expands further to include more > fundamental things that influence the basic functioning of the extension > then we should probably enforce this for the simple reason that we cannot > bring the extn up without its information. > I think I agree with Venkat, there doesn't seem a whole lot of point making a change that does nothing except stop our extensions working till they contain a definitions.xml. But how about changing the discovery mechanism to use the definitions.xml file instead of the meta-inf/services approach, at least then there would be some value to it and it makes our extension discovery look a little more spec conforming. ...ant
