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
