Simon, that's pretty much what comes to my mind as well. However, I am still not convinced that the specs says that having the bindingType definition is pre-req to the binding being available. I still feel, what one finds in a definitions.xml is just meta-data about an extension that is already available i.e. presence of this sort of a definition for an extension is consequential to the loading and availability of the extension.
- Venkat On Thu, May 8, 2008 at 9:03 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > On Thu, May 8, 2008 at 4:02 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > 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 > > > > Well we could. We still need to discover the definition.xml files in some > way, for example by putting them in a common place such as META-INF where > the services info is currently stored. Then we need to load the various > extension implementations for each extension. Could we use the services > mechanism to do this for a single extension jar? If so it just seems to be > a > matter of priority. I.e load the defintions.xml first in a Tuscany specific > way. If there is a suitable bindingType etc. then load the various > extension > implementation artifacts again in a Tuscany specific way to make the > extension available. I'm assuming here that the definitions.xml file for an > extension is packaged with the extension jar. > > Simon >
