Hi Sebastien,
Thanks for the suggestion. Going by the ProviderExtesionPoint way...
- first I'd prefer load the definitions.xml instead of creating
programmatically so that we don't have to touch the code for every change to
the definitions.
- every module that has its own definitions.xml must define it in a unique
path so that the file does not get lost when we are making the
tuscany-sca-all jar file in the distro.
So, given that every module HAS to define its definitions.xml in a unique
path I am wondering if it would just enuf for each module then to just about
publish the path for this in a file similar to the ones in
META-INF/services. So even when this file is aggregated by the shade plugin
when making the tuscany-sca-all jar, we still have the location paths of all
definitions.xml. Is this a viable alternative ?
Thanks
- Venkat
On Tue, Feb 26, 2008 at 8:48 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > First, thanks a ton for all the comments / opinions.
> >
> > I agree, META-INF/services is not the right place for this. I suppose
> > META-INF is ok because the definitions.xml does contain meta-data about
> > binding and implementation types. For example, the definitions.xml in
> the
> > binding.ws.axis module will define a binding type that will describe the
> > mayProvides and alwaysProvides intents. Or, isn't this metadata at all
> ?
> >
> > Yes, the point is that definitions.xml can be a part of any contribution
> and
> > hence can be anywhere. Infact, the samples / demos have the
> > definitions.xml in the resources directory only.
> >
> > The issue is with the definitons.xml in the tuscany modules. They need
> to
> > be loaded when the runtime is started and hence need to be explicitly
> > searched for and loaded. Whereas in the case of contributions, the
> > definitions.xml get processed like any other artifact in the
> contribution.
> >
> > So, the bottom line is how do we identify these various definitions.xmlin
> > the various tuscany modules ?
> >
>
> I think the main issue is that you're trying to use an SCA contribution
> based mechanism in non SCA contributions.
>
> I think we should do the following:
>
> - Definitions.xml is metadata, so is .composite, .componentType, etc,
> none of them should be under META-INF, we should give a good example in
> our own code, i.e. place them out of META-INF.
>
> - Either use proper SCA contributions and the capability of the Tuscany
> runtime to load them, and use definitions.xml files in these
> contributions.
>
> - Or, if these are not SCA contributions, use the extension point
> mechanism we're using everywhere else. For example do something similar
> to what we do for XML schemas used for validation, as follows...
>
> a) define a DefinitionProviderExtensionPoint
> interface DefinitionProviderExtensionPoint {
>
> void addDefinitionProviderExtensionPoint(DefinitionProvider provider);
> void removeDefinitionProviderExtensionPoint(
> DefinitionProvider provider);
>
> }
>
> b) define a DefinitionProvider
> interface DefinitionProvider {
> Definition getDefinition();
> }
>
> c) register the DefinitionProviders as we register all extensions.
>
> d) in a DefinitionProvider load definitions.xml from wherever you want
> and however, or even better just create that model in code.
>
> class MyDefinitionProvider implements DefinitionProvider {
>
> Definition getDefinition() {
> // load or create the Definition model
> ...
> return definition;
> }
> }
>
> Hope this helps.
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
