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.xml in
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]
