You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/05/08 11:43:21 UTC
[DISCUSS] Declaring extensions as being available in the domain
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)
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?
Regards
Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Raymond Feng <en...@gmail.com>.
My understanding is the definitions.xml from the SCA spec can be used to
describe what the bindingType/implementationType always or may provide
certain intents by the nature of the binding. That's why I think the tuscany
extension declaration should be separate from the definitions.xml.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Monday, May 12, 2008 2:34 PM
To: <tu...@ws.apache.org>
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
> On Mon, May 12, 2008 at 10:24 PM, Raymond Feng <en...@gmail.com>
> wrote:
>
>> I share the same concerns as Sebastien raised. Mixing the policy
>> definitions with tuscany runtime extensions in one file doesn't seem to
>> be
>> right. For example, we could have two tuscany extensions to support
>> binding.ws, one is based on Axis2 while the other one is based on CXF.
>> With the current approach, we will see three files:
>>
>> definitions.xml for binding.ws bindingType which is independent of the
>> underlying ws stack
>> two META-INF/services/... files, one for binding-ws-axis2 and the other
>> for binding-ws-cxf
>>
>> With the new proposal, I cannot achieve the pluggability unless we
>> duplicate the bindingType info for binding.ws in two definitions.xml.
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Jean-Sebastien Delfino" <js...@gmail.com>
>> Sent: Monday, May 12, 2008 1:56 PM
>> To: <tu...@ws.apache.org>
>> Subject: Re: [DISCUSS] Declaring extensions as being available in the
>> domain
>>
>>
>> Venkata Krishnan wrote:
>> >
>> > > Hi Ant,
>> > >
>> > > Yes, this sounds good to me - that will make all meta-data related to
>> > > an
>> > > extension available in just one place.
>> > >
>> > > - Venkat
>> > >
>> > >
>> > > > > 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>
>> > > >
>> > > >
>> > IMHO this is mixing different concerns that should be kept independent:
>> >
>> > - domain != runtime
>> > - policy definitions != runtime extensions
>> > - application level definitions != system definitions
>> >
>> > If you don't like the current META-INF/services approach and really
>> > want
>> > to change all that, I'd suggest to come up with a proper extension
>> > mechanism, independent of SCA policy definitions, something like OSGi
>> > for
>> > example would be more suitable for this.
>> >
>> > --
>> > Jean-Sebastien
>> >
>>
>>
> So I get the impression that you don't like this but you neglect to say
> whether you think the spec means this or not. Would be useful to know as
> if
> we think the spec means that we have to do more with the definitions.xml
> file and Tuscany doesn't want to do it then we have to take our concerns
> elsewhere.
>
> Simon
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Simon Laws <si...@googlemail.com>.
On Mon, May 12, 2008 at 10:24 PM, Raymond Feng <en...@gmail.com> wrote:
> I share the same concerns as Sebastien raised. Mixing the policy
> definitions with tuscany runtime extensions in one file doesn't seem to be
> right. For example, we could have two tuscany extensions to support
> binding.ws, one is based on Axis2 while the other one is based on CXF.
> With the current approach, we will see three files:
>
> definitions.xml for binding.ws bindingType which is independent of the
> underlying ws stack
> two META-INF/services/... files, one for binding-ws-axis2 and the other
> for binding-ws-cxf
>
> With the new proposal, I cannot achieve the pluggability unless we
> duplicate the bindingType info for binding.ws in two definitions.xml.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Jean-Sebastien Delfino" <js...@gmail.com>
> Sent: Monday, May 12, 2008 1:56 PM
> To: <tu...@ws.apache.org>
> Subject: Re: [DISCUSS] Declaring extensions as being available in the
> domain
>
>
> Venkata Krishnan wrote:
> >
> > > Hi Ant,
> > >
> > > Yes, this sounds good to me - that will make all meta-data related to
> > > an
> > > extension available in just one place.
> > >
> > > - Venkat
> > >
> > >
> > > > > 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>
> > > >
> > > >
> > IMHO this is mixing different concerns that should be kept independent:
> >
> > - domain != runtime
> > - policy definitions != runtime extensions
> > - application level definitions != system definitions
> >
> > If you don't like the current META-INF/services approach and really want
> > to change all that, I'd suggest to come up with a proper extension
> > mechanism, independent of SCA policy definitions, something like OSGi for
> > example would be more suitable for this.
> >
> > --
> > Jean-Sebastien
> >
>
>
So I get the impression that you don't like this but you neglect to say
whether you think the spec means this or not. Would be useful to know as if
we think the spec means that we have to do more with the definitions.xml
file and Tuscany doesn't want to do it then we have to take our concerns
elsewhere.
Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by scabooz <sc...@gmail.com>.
Responses inline...for some reason my email client is mishandling the formatting, so I'll mark my responses with <dab> </dab>
Dave
----- Original Message -----
From: ant elder
To: scabooz
Cc: tuscany-dev@ws.apache.org
Sent: Tuesday, May 20, 2008 2:03 PM
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
Thanks thats helpful. Let me take this to the extreme so you can point out where it loses the plot to help me understand what you're saying:
The idea is eventually there might be standardized interfaces for all the SCA runtime plug points, many of the Tuscany things for the various SCDL and SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have in org.apache.tuscany.sca namespace might one day be standardized interfaces, just like the org.osoa.sca.* interfaces for application Java implementations to use, and there would be a standard way to define new binidng and implementation extensions in the definitions.xml.
<dab> Yes, that is the idea/theory. </dab>
Anyone could make an SCA contribution that would add a binding or implementation type which once contributed to an SCA domain then other contributions in the domain could use in their SCA assemblies. And this new binding contribution would work in any runtime that supported SCA just like application SCA contributions should.
<dab> yes </dab>
So as a simple example, say a file binding that component service or references could use to read and write to a file system. That could be packaged in a regular jar which has a meta-inf/definitions.xml along the lines of:
<definitions ... >
<bindingType type="binding.file" ... >
...elements and attributes defining the binding.file schema and implementation classes ...
</bindingType>
</definitions>
and all the file binding implementation classes within that file binding contribution jar would implement only standard interfaces, nothing at all Tuscany specific in the contribution.
<dab> Good. Only thing to add at this point is that the spec might decide that the "jar" should be an OSGI bundle. Would such a estriction help, or get in the way? </dab>
The splitting out all the various Tuscany SCDL classes and SPIs points into interfaces happened when we did the 0.90 rewrite so binding and implementation type extensions can now be written using only interfaces, but the pluggablity mechanism is still quite Tuscany specific. So is whats being suggested with this definitions.xml work starting on the road to coming up with a less Tuscany specific way of doing that, it would still be in a Tuscany namespace for now just as the various Tuscany SPI interfaces are, but in the future all this would be defined in some SCA spec , but it would just be a refactor in Tuscany to move to that spec namespace instead of a complete rewrite?
<dab> Bingo. </dab>
Is that anything like what you had in mind?
...ant
On Thu, May 15, 2008 at 7:32 PM, scabooz <sc...@gmail.com> wrote:
I might be the 'they', not sure. This is a very hard email thread to follow so let
me try to articulate some ideas.
First, bindingType and implementationType were introduced by the SCA Policy
FW spec because that spec was the first to need a bit of metadata describing
bindings from a typing perspective so that policy could be provided by the type
and didn't have to be repeated on every binding instance. Implementation types
was an obvious next stop on the journey. The text was driven into the Assembly
spec as the result of a realization that these two concepts would be needed by
SCA extenders who wish to add bindings and new kinds of components into any
SCA runtime that was implemented by some another party. The assembly
spec group decided (rightly IMHO) NOT to dive more deeply into filling out
these concepts in V1.0. It would be more appropriate to tackle these sorts of
issues in a future revision of the technology.
Second, Tuscany is an open community where the plethora of talent enables
new innovative ideas to be explored. These extensibility points are a great
place for Tuscany to experiment with different approaches. I think it would be
fantastic if Tuscany could "finish" the work of the spec group and come up with
a reasonable (and workable) model for extensibility and then propose it to the
spec group. Building on this thought then is the assertion that bindingType
is the starting point for 3rd parties to describe a binding implementation to a
runtime not authored by the binding implementer. It would be naive to think
that the current structure of bindingType, it's containment within a defintions.xml
file or any other related aspect is off limits from change in this experiment.
I'm not clear on what all the issues are that have been raised. I see a lot of
mis-information and some emotion that's hard to sort through.
I saw a strawman that looked like a good start in one of the emails but there
seemed to be resistance that I didn't understand. The SCA bindingType
and implementationType concepts have nothing to do with policy. Policy was
the first functional area that happened to see the need for them.
Dave
----- Original Message ----- From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 13, 2008 2:40 AM
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
Agreed to all that ONLY IF definitions.xml is going to contain things
related to policies only. Though it is at the present moment my belief is
that it could evolve to represent information more than just policy
related
things. This belief of mine is based on the following : -
- the name of the file is 'definitions.xml' and is not
'policy-definitions.xml'
- this is defined in the assembly model specs and not in the PolicyFwk
specs. If its just for policies, I'd reckon that it would have been
defined
completely in the PolicySpecs and only referred to in the Assembly Model
specs. Right now its vice-versa.
Maybe some Specs folks should give us their perspective on this.
- Venkat
Those are good points. Especially the last one as its they that ask for this
in an offline discussion so it would be really good to get their input here.
...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by ant elder <an...@apache.org>.
Thanks thats helpful. Let me take this to the extreme so you can point out
where it loses the plot to help me understand what you're saying:
The idea is eventually there might be standardized interfaces for all the
SCA runtime plug points, many of the Tuscany things for the various SCDL and
SPI interfaces - tuscany-assembly, tuscany-spi etc - that right now we have
in org.apache.tuscany.sca namespace might one day be standardized
interfaces, just like the org.osoa.sca.* interfaces for application Java
implementations to use, and there would be a standard way to define new
binidng and implementation extensions in the definitions.xml.
Anyone could make an SCA contribution that would add a binding or
implementation type which once contributed to an SCA domain then other
contributions in the domain could use in their SCA assemblies. And this new
binding contribution would work in any runtime that supported SCA just like
application SCA contributions should.
So as a simple example, say a file binding that component service or
references could use to read and write to a file system. That could be
packaged in a regular jar which has a meta-inf/definitions.xml along the
lines of:
<definitions ... >
<bindingType type="binding.file" ... >
...elements and attributes defining the binding.file schema and
implementation classes ...
</bindingType>
</definitions>
and all the file binding implementation classes within that file binding
contribution jar would implement only standard interfaces, nothing at all
Tuscany specific in the contribution.
The splitting out all the various Tuscany SCDL classes and SPIs points into
interfaces happened when we did the 0.90 rewrite so binding and
implementation type extensions can now be written using only interfaces, but
the pluggablity mechanism is still quite Tuscany specific. So is whats being
suggested with this definitions.xml work starting on the road to coming up
with a less Tuscany specific way of doing that, it would still be in a
Tuscany namespace for now just as the various Tuscany SPI interfaces are,
but in the future all this would be defined in some SCA spec , but it would
just be a refactor in Tuscany to move to that spec namespace instead of a
complete rewrite?
Is that anything like what you had in mind?
...ant
On Thu, May 15, 2008 at 7:32 PM, scabooz <sc...@gmail.com> wrote:
> I might be the 'they', not sure. This is a very hard email thread to
> follow so let
> me try to articulate some ideas.
>
> First, bindingType and implementationType were introduced by the SCA Policy
> FW spec because that spec was the first to need a bit of metadata
> describing
> bindings from a typing perspective so that policy could be provided by the
> type
> and didn't have to be repeated on every binding instance. Implementation
> types
> was an obvious next stop on the journey. The text was driven into the
> Assembly
> spec as the result of a realization that these two concepts would be needed
> by
> SCA extenders who wish to add bindings and new kinds of components into any
> SCA runtime that was implemented by some another party. The assembly
> spec group decided (rightly IMHO) NOT to dive more deeply into filling out
> these concepts in V1.0. It would be more appropriate to tackle these sorts
> of
> issues in a future revision of the technology.
>
> Second, Tuscany is an open community where the plethora of talent enables
> new innovative ideas to be explored. These extensibility points are a
> great
> place for Tuscany to experiment with different approaches. I think it
> would be
> fantastic if Tuscany could "finish" the work of the spec group and come up
> with
> a reasonable (and workable) model for extensibility and then propose it to
> the
> spec group. Building on this thought then is the assertion that
> bindingType
> is the starting point for 3rd parties to describe a binding implementation
> to a
> runtime not authored by the binding implementer. It would be naive to
> think
> that the current structure of bindingType, it's containment within a
> defintions.xml
> file or any other related aspect is off limits from change in this
> experiment.
>
> I'm not clear on what all the issues are that have been raised. I see a
> lot of
> mis-information and some emotion that's hard to sort through.
>
> I saw a strawman that looked like a good start in one of the emails but
> there
> seemed to be resistance that I didn't understand. The SCA bindingType
> and implementationType concepts have nothing to do with policy. Policy was
> the first functional area that happened to see the need for them.
>
>
> Dave
>
>
> ----- Original Message ----- From: "ant elder" <an...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, May 13, 2008 2:40 AM
> Subject: Re: [DISCUSS] Declaring extensions as being available in the
> domain
>
>
> On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan <fo...@gmail.com>
>> wrote:
>>
>> Agreed to all that ONLY IF definitions.xml is going to contain things
>>> related to policies only. Though it is at the present moment my belief
>>> is
>>> that it could evolve to represent information more than just policy
>>> related
>>> things. This belief of mine is based on the following : -
>>>
>>> - the name of the file is 'definitions.xml' and is not
>>> 'policy-definitions.xml'
>>> - this is defined in the assembly model specs and not in the PolicyFwk
>>> specs. If its just for policies, I'd reckon that it would have been
>>> defined
>>> completely in the PolicySpecs and only referred to in the Assembly Model
>>> specs. Right now its vice-versa.
>>>
>>> Maybe some Specs folks should give us their perspective on this.
>>>
>>> - Venkat
>>>
>>>
>>> Those are good points. Especially the last one as its they that ask for
>> this
>> in an offline discussion so it would be really good to get their input
>> here.
>>
>> ...ant
>>
>>
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by scabooz <sc...@gmail.com>.
I might be the 'they', not sure. This is a very hard email thread to follow
so let
me try to articulate some ideas.
First, bindingType and implementationType were introduced by the SCA Policy
FW spec because that spec was the first to need a bit of metadata describing
bindings from a typing perspective so that policy could be provided by the
type
and didn't have to be repeated on every binding instance. Implementation
types
was an obvious next stop on the journey. The text was driven into the
Assembly
spec as the result of a realization that these two concepts would be needed
by
SCA extenders who wish to add bindings and new kinds of components into any
SCA runtime that was implemented by some another party. The assembly
spec group decided (rightly IMHO) NOT to dive more deeply into filling out
these concepts in V1.0. It would be more appropriate to tackle these sorts
of
issues in a future revision of the technology.
Second, Tuscany is an open community where the plethora of talent enables
new innovative ideas to be explored. These extensibility points are a great
place for Tuscany to experiment with different approaches. I think it would
be
fantastic if Tuscany could "finish" the work of the spec group and come up
with
a reasonable (and workable) model for extensibility and then propose it to
the
spec group. Building on this thought then is the assertion that bindingType
is the starting point for 3rd parties to describe a binding implementation
to a
runtime not authored by the binding implementer. It would be naive to think
that the current structure of bindingType, it's containment within a
defintions.xml
file or any other related aspect is off limits from change in this
experiment.
I'm not clear on what all the issues are that have been raised. I see a lot
of
mis-information and some emotion that's hard to sort through.
I saw a strawman that looked like a good start in one of the emails but
there
seemed to be resistance that I didn't understand. The SCA bindingType
and implementationType concepts have nothing to do with policy. Policy was
the first functional area that happened to see the need for them.
Dave
----- Original Message -----
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 13, 2008 2:40 AM
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
> On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
>> Agreed to all that ONLY IF definitions.xml is going to contain things
>> related to policies only. Though it is at the present moment my belief
>> is
>> that it could evolve to represent information more than just policy
>> related
>> things. This belief of mine is based on the following : -
>>
>> - the name of the file is 'definitions.xml' and is not
>> 'policy-definitions.xml'
>> - this is defined in the assembly model specs and not in the PolicyFwk
>> specs. If its just for policies, I'd reckon that it would have been
>> defined
>> completely in the PolicySpecs and only referred to in the Assembly Model
>> specs. Right now its vice-versa.
>>
>> Maybe some Specs folks should give us their perspective on this.
>>
>> - Venkat
>>
>>
> Those are good points. Especially the last one as its they that ask for
> this
> in an offline discussion so it would be really good to get their input
> here.
>
> ...ant
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by ant elder <an...@gmail.com>.
On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Agreed to all that ONLY IF definitions.xml is going to contain things
> related to policies only. Though it is at the present moment my belief is
> that it could evolve to represent information more than just policy
> related
> things. This belief of mine is based on the following : -
>
> - the name of the file is 'definitions.xml' and is not
> 'policy-definitions.xml'
> - this is defined in the assembly model specs and not in the PolicyFwk
> specs. If its just for policies, I'd reckon that it would have been
> defined
> completely in the PolicySpecs and only referred to in the Assembly Model
> specs. Right now its vice-versa.
>
> Maybe some Specs folks should give us their perspective on this.
>
> - Venkat
>
>
Those are good points. Especially the last one as its they that ask for this
in an offline discussion so it would be really good to get their input here.
...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Venkata Krishnan <fo...@gmail.com>.
Agreed to all that ONLY IF definitions.xml is going to contain things
related to policies only. Though it is at the present moment my belief is
that it could evolve to represent information more than just policy related
things. This belief of mine is based on the following : -
- the name of the file is 'definitions.xml' and is not
'policy-definitions.xml'
- this is defined in the assembly model specs and not in the PolicyFwk
specs. If its just for policies, I'd reckon that it would have been defined
completely in the PolicySpecs and only referred to in the Assembly Model
specs. Right now its vice-versa.
Maybe some Specs folks should give us their perspective on this.
- Venkat
On Tue, May 13, 2008 at 11:32 AM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Yes, I think each of those specific ones should be allowed to have its own
> definitions.xml and bindingType info simply because each of them could have
> their own list what intents it provides inherently. Maybe I am missing the
> alternative here.
>
> - Venkat
>
> On Tue, May 13, 2008 at 2:54 AM, Raymond Feng <en...@gmail.com> wrote:
>
> > I share the same concerns as Sebastien raised. Mixing the policy
> > definitions with tuscany runtime extensions in one file doesn't seem to be
> > right. For example, we could have two tuscany extensions to support
> > binding.ws, one is based on Axis2 while the other one is based on CXF.
> > With the current approach, we will see three files:
> >
> > definitions.xml for binding.ws bindingType which is independent of the
> > underlying ws stack
> > two META-INF/services/... files, one for binding-ws-axis2 and the other
> > for binding-ws-cxf
> >
> > With the new proposal, I cannot achieve the pluggability unless we
> > duplicate the bindingType info for binding.ws in two definitions.xml.
> >
> > Thanks,
> > Raymond
> > --------------------------------------------------
> > From: "Jean-Sebastien Delfino" <js...@gmail.com>
> > Sent: Monday, May 12, 2008 1:56 PM
> > To: <tu...@ws.apache.org>
> > Subject: Re: [DISCUSS] Declaring extensions as being available in the
> > domain
> >
> >
> > Venkata Krishnan wrote:
> > >
> > > > Hi Ant,
> > > >
> > > > Yes, this sounds good to me - that will make all meta-data related
> > > > to an
> > > > extension available in just one place.
> > > >
> > > > - Venkat
> > > >
> > > >
> > > > > > 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>
> > > > >
> > > > >
> > > IMHO this is mixing different concerns that should be kept
> > > independent:
> > >
> > > - domain != runtime
> > > - policy definitions != runtime extensions
> > > - application level definitions != system definitions
> > >
> > > If you don't like the current META-INF/services approach and really
> > > want to change all that, I'd suggest to come up with a proper extension
> > > mechanism, independent of SCA policy definitions, something like OSGi for
> > > example would be more suitable for this.
> > >
> > > --
> > > Jean-Sebastien
> > >
> >
> >
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Venkata Krishnan <fo...@gmail.com>.
Yes, I think each of those specific ones should be allowed to have its own
definitions.xml and bindingType info simply because each of them could have
their own list what intents it provides inherently. Maybe I am missing the
alternative here.
- Venkat
On Tue, May 13, 2008 at 2:54 AM, Raymond Feng <en...@gmail.com> wrote:
> I share the same concerns as Sebastien raised. Mixing the policy
> definitions with tuscany runtime extensions in one file doesn't seem to be
> right. For example, we could have two tuscany extensions to support
> binding.ws, one is based on Axis2 while the other one is based on CXF.
> With the current approach, we will see three files:
>
> definitions.xml for binding.ws bindingType which is independent of the
> underlying ws stack
> two META-INF/services/... files, one for binding-ws-axis2 and the other
> for binding-ws-cxf
>
> With the new proposal, I cannot achieve the pluggability unless we
> duplicate the bindingType info for binding.ws in two definitions.xml.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Jean-Sebastien Delfino" <js...@gmail.com>
> Sent: Monday, May 12, 2008 1:56 PM
> To: <tu...@ws.apache.org>
> Subject: Re: [DISCUSS] Declaring extensions as being available in the
> domain
>
>
> Venkata Krishnan wrote:
> >
> > > Hi Ant,
> > >
> > > Yes, this sounds good to me - that will make all meta-data related to
> > > an
> > > extension available in just one place.
> > >
> > > - Venkat
> > >
> > >
> > > > > 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>
> > > >
> > > >
> > IMHO this is mixing different concerns that should be kept independent:
> >
> > - domain != runtime
> > - policy definitions != runtime extensions
> > - application level definitions != system definitions
> >
> > If you don't like the current META-INF/services approach and really want
> > to change all that, I'd suggest to come up with a proper extension
> > mechanism, independent of SCA policy definitions, something like OSGi for
> > example would be more suitable for this.
> >
> > --
> > Jean-Sebastien
> >
>
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by ant elder <an...@gmail.com>.
On Mon, May 12, 2008 at 10:24 PM, Raymond Feng <en...@gmail.com> wrote:
> I share the same concerns as Sebastien raised. Mixing the policy
> definitions with tuscany runtime extensions in one file doesn't seem to be
> right. For example, we could have two tuscany extensions to support
> binding.ws, one is based on Axis2 while the other one is based on CXF.
> With the current approach, we will see three files:
>
> definitions.xml for binding.ws bindingType which is independent of the
> underlying ws stack
> two META-INF/services/... files, one for binding-ws-axis2 and the other
> for binding-ws-cxf
>
> With the new proposal, I cannot achieve the pluggability unless we
> duplicate the bindingType info for binding.ws in two definitions.xml.
>
I don't think thats quite true, as Venkat said there can be multiple
definitions files and they get merged together so its no problem at all for
each extension to its on extension specific file.
...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Raymond Feng <en...@gmail.com>.
I share the same concerns as Sebastien raised. Mixing the policy definitions
with tuscany runtime extensions in one file doesn't seem to be right. For
example, we could have two tuscany extensions to support binding.ws, one is
based on Axis2 while the other one is based on CXF. With the current
approach, we will see three files:
definitions.xml for binding.ws bindingType which is independent of the
underlying ws stack
two META-INF/services/... files, one for binding-ws-axis2 and the other for
binding-ws-cxf
With the new proposal, I cannot achieve the pluggability unless we duplicate
the bindingType info for binding.ws in two definitions.xml.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@gmail.com>
Sent: Monday, May 12, 2008 1:56 PM
To: <tu...@ws.apache.org>
Subject: Re: [DISCUSS] Declaring extensions as being available in the domain
> Venkata Krishnan wrote:
>> Hi Ant,
>>
>> Yes, this sounds good to me - that will make all meta-data related to an
>> extension available in just one place.
>>
>> - Venkat
>>
>>>>
>>> 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>
>>>
>
> IMHO this is mixing different concerns that should be kept independent:
>
> - domain != runtime
> - policy definitions != runtime extensions
> - application level definitions != system definitions
>
> If you don't like the current META-INF/services approach and really want
> to change all that, I'd suggest to come up with a proper extension
> mechanism, independent of SCA policy definitions, something like OSGi for
> example would be more suitable for this.
>
> --
> Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Venkata Krishnan wrote:
> Hi Ant,
>
> Yes, this sounds good to me - that will make all meta-data related to an
> extension available in just one place.
>
> - Venkat
>
>>>
>> 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>
>>
IMHO this is mixing different concerns that should be kept independent:
- domain != runtime
- policy definitions != runtime extensions
- application level definitions != system definitions
If you don't like the current META-INF/services approach and really want
to change all that, I'd suggest to come up with a proper extension
mechanism, independent of SCA policy definitions, something like OSGi
for example would be more suitable for this.
--
Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <an...@apache.org> wrote:
> On Thu, May 8, 2008 at 4:33 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Thu, May 8, 2008 at 4:02 PM, ant elder <an...@gmail.com> wrote:
> >
> > > On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <
> for.svkrish@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Please find my comments inline.
> > > >
> > > > On Thu, May 8, 2008 at 3:13 PM, Simon Laws <
> simonslaws@googlemail.com>
> > > > 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
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by ant elder <an...@apache.org>.
On Thu, May 8, 2008 at 4:33 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Thu, May 8, 2008 at 4:02 PM, ant elder <an...@gmail.com> wrote:
>
> > On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <fo...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Please find my comments inline.
> > >
> > > On Thu, May 8, 2008 at 3:13 PM, Simon Laws <si...@googlemail.com>
> > > 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
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <si...@googlemail.com>
wrote:
> On Thu, May 8, 2008 at 4:02 PM, ant elder <an...@gmail.com> wrote:
>
> > On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <fo...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Please find my comments inline.
> > >
> > > On Thu, May 8, 2008 at 3:13 PM, Simon Laws <si...@googlemail.com>
> > > 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
>
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 8, 2008 at 4:02 PM, ant elder <an...@gmail.com> wrote:
> On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <fo...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Please find my comments inline.
> >
> > On Thu, May 8, 2008 at 3:13 PM, Simon Laws <si...@googlemail.com>
> > 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
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by ant elder <an...@gmail.com>.
On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan <fo...@gmail.com>
wrote:
> Hi,
>
> Please find my comments inline.
>
> On Thu, May 8, 2008 at 3:13 PM, Simon Laws <si...@googlemail.com>
> 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
Re: [DISCUSS] Declaring extensions as being available in the domain
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Please find my comments inline.
On Thu, May 8, 2008 at 3:13 PM, Simon Laws <si...@googlemail.com>
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.
>
> Regards
>
> Simon
>