Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place.
- Venkat On Sun, May 11, 2008 at 3:37 PM, ant elder <[EMAIL PROTECTED]> wrote: > On Thu, May 8, 2008 at 4:33 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 > > > > What i was thinking of was along the lines of adding Tuscany specific xml > to > the definitions file that replaces everything we currently put in the > meta-inf/services files for binding and implementation extensions, eg > something like: > > <definitions xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; ... > > > <bindingType type="binding.ws" ... > > > <tuscany:binding > > providerFactory="org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory" > > model="org.apache.tuscany.sca.binding.ws.WebServiceBinding" /> > > </bindingType> > > </definitions> > > ...ant >
