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 2009/01/09 16:56:10 UTC
[1.x][2.x][DISCUSS] definitions.xml processing
In 1.x, and by implication 2.x, the definitions.xml processing is
problematic in a number of ways. We have started to talk about revisiting
the policy model [1] and although we haven't done that yet in 2.x I'm
trying to get my mind around how definitions.xml files are processed by
Tuscany. There seem to be a number of gaps, e.g. TUSCANY-2499 [2].
A) Resolve definitions gloabally given the set of contributions available. I
think the ideal order of processing for a stand-alone node should be.
- read all defintiions.xml files from extensions that the runtime loads
- read all contributions (which in turn will read any definitions.xml files
that appear in contributions)
- resolve all the definitions that have been read (aggregate all the
definitions models together and resolve them)
- resolve all of the contributions
I believe the contribution processing has been split up already in 2.x so
this change should be straightforward there. I have a patch for 1.x. It
relies on exposing interfaces on the contribution service to allow read and
resolve to be called independently. This does solve 2499 so I'll attach the
patch there for people to look at. I haven't commited directly as there
workspace contribution processing is already in 1.x but I'm not sure yet
what the implications of switching across to that would be.
An interesting problem I uncovered is that the JAAS policy itself dependes
on contribution artifacts (java classes) so you have to resolve the
definitions in the context of the contributions that have previously been
read. This feels a little odd to me.
B) Global access to the definitions artifacts
In 1.x the definitions model is owned by the RuntimeBootStrapper and is made
available to the model through the resolver structure. It seems that it is
not easy to use the resolver approach in some places, e,g the JMS binding
where its gets data from the definitions.xml binding structure. We need to
review this and see how access should be provided to the definitions.xml
model.
C) Retrieve domain definitions from the domain
The problem described in A) raises it's head in the domain also. Here though
the solution is not so straighforward as the domain level defintions model
must be subsequently provided to all nodes (assuming that I understand the
specs correctly of course).
While there are some TODO comments in the code suggesting that defintions
dependencies should be expressed through contribution import/export
statements I don't think this is true as the spec considers defintiions.xml
to be a domain level resource while Tuscany just happens to allow you to
include them in a contribution.
We could take the aggreated definitions.xml artifacts and create a special
contribution and provide this to all nodes. Alternatively we could provide a
specific endpoint from which to retrieve the defintiions.xml artifacts. The
first approach would seem to be the simpler of the two.
Regards
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
[2] http://issues.apache.org/jira/browse/TUSCANY-2499
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by ant elder <an...@apache.org>.
On Thu, Jan 15, 2009 at 1:44 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Jan 15, 2009 at 9:08 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>> <snip>
>>
>>
>>> The Tuscany domain is static in that all contributions must be present
>>> before you start nodes. I'd like to see us move toward a more dynamic
>>> solution but we aren't there yet.
>>>
>>
>> More dynamic operation is a common requirement that keeps on coming up,
>> how about we make it a design point that 2.0 will support a more dynamic
>> mode of operation?
>>
>> ...ant
>>
>>
>>
> I think I would go along with that but we should talk about what we mean by
> dynamic, for example here are a couple of things that could be dynamic
>
> - nodes can be started/restarted while the contributions in the domain
> remain static
> - contributions can be added/removed from the running system
>
> Personally I'm interested in the first one to start with which I believe
> can be achieved by sorting out our endpoint/late binding support [1]. This
> addresses some dynamic infrastructure scenarios I'm interested in;
>
> - I want to start a node and have it added to the domain automatically (we
> can exploit the addNode interface I hope and, with endpoint support, allow
> nodes to come up independently)
> - I want to stop and restart a node (this one is probably OK now)
> - I want to relocate a node (relies on endpoint support)
>
> I haven't thought any more about the second one. There are more
> complications here IMO.
>
> Simon
>
> [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04476.html
>
>
>
Great.
Both of those options you mention sound useful to me, I'm more interested in
the second of those right now for one as thats what we need for the Tuscany
integration with Geronimo its also the type of thing has been requested
several times by users. Anyway, i'd be happy to help with both.
...ant
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Raymond Feng <en...@gmail.com>.
The OASIS draft has a proposal for SCA domain level wire to cover the dynamicity update of wires. We could take a similar approach here for the definitions and propose it back to the spec.
[1] http://www.osoa.org/jira/browse/ASSEMBLY-41
[2] http://lists.oasis-open.org/archives/sca-assembly/200808/msg00019.html
Thanks,
Raymond
From: Simon Laws
Sent: Thursday, January 15, 2009 5:44 AM
To: dev@tuscany.apache.org ; antelder@apache.org
Subject: Re: [1.x][2.x][DISCUSS] definitions.xml processing
On Thu, Jan 15, 2009 at 9:08 AM, ant elder <an...@gmail.com> wrote:
On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com> wrote:
<snip>
The Tuscany domain is static in that all contributions must be present before you start nodes. I'd like to see us move toward a more dynamic solution but we aren't there yet.
More dynamic operation is a common requirement that keeps on coming up, how about we make it a design point that 2.0 will support a more dynamic mode of operation?
...ant
I think I would go along with that but we should talk about what we mean by dynamic, for example here are a couple of things that could be dynamic
- nodes can be started/restarted while the contributions in the domain remain static
- contributions can be added/removed from the running system
Personally I'm interested in the first one to start with which I believe can be achieved by sorting out our endpoint/late binding support [1]. This addresses some dynamic infrastructure scenarios I'm interested in;
- I want to start a node and have it added to the domain automatically (we can exploit the addNode interface I hope and, with endpoint support, allow nodes to come up independently)
- I want to stop and restart a node (this one is probably OK now)
- I want to relocate a node (relies on endpoint support)
I haven't thought any more about the second one. There are more complications here IMO.
Simon
[1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04476.html
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jan 15, 2009 at 9:08 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com>wrote:
>
> <snip>
>
>
>> The Tuscany domain is static in that all contributions must be present
>> before you start nodes. I'd like to see us move toward a more dynamic
>> solution but we aren't there yet.
>>
>
> More dynamic operation is a common requirement that keeps on coming up, how
> about we make it a design point that 2.0 will support a more dynamic mode of
> operation?
>
> ...ant
>
>
>
I think I would go along with that but we should talk about what we mean by
dynamic, for example here are a couple of things that could be dynamic
- nodes can be started/restarted while the contributions in the domain
remain static
- contributions can be added/removed from the running system
Personally I'm interested in the first one to start with which I believe can
be achieved by sorting out our endpoint/late binding support [1]. This
addresses some dynamic infrastructure scenarios I'm interested in;
- I want to start a node and have it added to the domain automatically (we
can exploit the addNode interface I hope and, with endpoint support, allow
nodes to come up independently)
- I want to stop and restart a node (this one is probably OK now)
- I want to relocate a node (relies on endpoint support)
I haven't thought any more about the second one. There are more
complications here IMO.
Simon
[1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04476.html
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by ant elder <an...@gmail.com>.
On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com>wrote:
<snip>
> The Tuscany domain is static in that all contributions must be present
> before you start nodes. I'd like to see us move toward a more dynamic
> solution but we aren't there yet.
>
More dynamic operation is a common requirement that keeps on coming up, how
about we make it a design point that 2.0 will support a more dynamic mode of
operation?
...ant
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com>wrote:
> Hi Greg
>
> Comments in line...
>
> Simon
>
> On Fri, Jan 9, 2009 at 10:38 PM, Greg Dritschler <
> greg.dritschler@gmail.com> wrote:
>
>> Simon,
>>
>> Regarding bullet A, this is fine if the set of contributions is static.
>> What happens as contributions are added and removed (particularly
>> contributions that contain definitions)? I think the spec is silent about
>> what should happen.
>>
>
> I think the confusion is because the spec doesn't state that
> definitions.xml will be provided via contributions. I think having
> definitions.xml inside contributions is a Tuscany thing. The spec talks
> about a domain wide file named definitions.xml. Hence it makes no comment on
> what happens as contributions are added and removed.
>
> Given that we allow definitions.xml files inside contribution I was looking
> at what it would take to really consider these definitions artifacts as
> domain wide. The answer is that we have to change our read and resolution
> process a bit but it's not a huge change.
>
> Another approach would be to change the way Tuscany works and read
> definitions.xml files independently of contributions or, for example,
> mandate that a separate system contribution must be provided to add
> defintions.xml to the domain.
>
> As you point out, I haven't addressed what should happen as contributions
> are added and removed in a running syste. In fact we currently don't address
> this generally. The Tuscany domain is static in that all contributions must
> be present before you start nodes. I'd like to see us move toward a more
> dynamic solution but we aren't there yet. Any change in contributions (or
> defintions.xml) within a running system would imply some kind of eventing to
> notify running nodes that their configuration has changed. This is obviously
> a rather complex proposition given where we are now.
>
> Give where we are with 1.x I think the answer is to;
> - fix our read/resolve process so that definitions.xml are considered to
> be domain wide
> - fix our domain manager so that the domain definitions.xml model is
> passed to each node
> Given these two changes we can close off TUSCANY-2499
> - make a statement that once contributions have been added they can't be
> removed without restarting the nodes that refer to them. If you are prepared
> to restart a node then you are presented with the domain configuration as it
> appears at that time taking into account whatever contributions have been
> added or removed.
>
> For 2.x we could either apply the changes to make definitions that appear
> in contributions be processed as domain wide defintions or take a wider view
> and choose a different approach to reading in definitions.xml.
>
>
>>
>> Raymond,
>>
>> Are you suggesting that the user should have to explicitly import
>> definitions from other user (non-system) contributions? As far as I know
>> all definitions that have been contributed to the domain are implicitly
>> visible to all contributions.
>
>
> I agree. I don't think the user should have to import artifacts from
> definitions.xml files. The spec refers to them as domain wide artifacts.
>
>
I attached my 1.x experiment code as a patch to TUSCANY-2499. I'm not going
to commit is as I implies a change to the API and semantics of the
contribution service. I'll carry on with the changes in 2.x as we have more
liberty to make these kinds of changes there. I'd be interested to hear if
this is causing anyone problems in 1.x
Regards
Simon
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by ant elder <an...@gmail.com>.
On Mon, Jan 12, 2009 at 10:15 AM, Simon Laws <si...@googlemail.com>wrote:
> Hi Greg
>
> Comments in line...
>
> Simon
>
> On Fri, Jan 9, 2009 at 10:38 PM, Greg Dritschler <
> greg.dritschler@gmail.com> wrote:
>
>> Simon,
>>
>> Regarding bullet A, this is fine if the set of contributions is static.
>> What happens as contributions are added and removed (particularly
>> contributions that contain definitions)? I think the spec is silent about
>> what should happen.
>>
>
> I think the confusion is because the spec doesn't state that
> definitions.xml will be provided via contributions. I think having
> definitions.xml inside contributions is a Tuscany thing. The spec talks
> about a domain wide file named definitions.xml. Hence it makes no comment on
> what happens as contributions are added and removed.
>
What would we loose by changing this so that we did have just a domain wide
definitions file (or perhaps one for each node) instead of allowing multiple
ones and inside contributions? Wouldn't doing that make all this much
simpler?
...ant
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It seems that OASIS version of the spec provides a direction here. See: http://www.osoa.org/jira/browse/ASSEMBLY-44. The proposal is quoted below:
"All of these artifacts within an SCA Domain are defined in SCA contributions in files called META-INF/definitions.xml (relative to the contribution base URI). Although the definitions are specified within a single SCA contribution, the definitions are visible throughout the domain. Because of this, all of the QNames for these definitions MUST be unique within the domain. "
I personally think it might be better to provide a bit scoping based on the import/export statements. But it would be a question to the spec people.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, January 12, 2009 2:15 AM
To: dev@tuscany.apache.org
Subject: Re: [1.x][2.x][DISCUSS] definitions.xml processing
Hi Greg
Comments in line...
Simon
On Fri, Jan 9, 2009 at 10:38 PM, Greg Dritschler <gr...@gmail.com> wrote:
Simon,
Regarding bullet A, this is fine if the set of contributions is static. What happens as contributions are added and removed (particularly contributions that contain definitions)? I think the spec is silent about what should happen.
I think the confusion is because the spec doesn't state that definitions.xml will be provided via contributions. I think having definitions.xml inside contributions is a Tuscany thing. The spec talks about a domain wide file named definitions.xml. Hence it makes no comment on what happens as contributions are added and removed.
Given that we allow definitions.xml files inside contribution I was looking at what it would take to really consider these definitions artifacts as domain wide. The answer is that we have to change our read and resolution process a bit but it's not a huge change.
Another approach would be to change the way Tuscany works and read definitions.xml files independently of contributions or, for example, mandate that a separate system contribution must be provided to add defintions.xml to the domain.
As you point out, I haven't addressed what should happen as contributions are added and removed in a running syste. In fact we currently don't address this generally. The Tuscany domain is static in that all contributions must be present before you start nodes. I'd like to see us move toward a more dynamic solution but we aren't there yet. Any change in contributions (or defintions.xml) within a running system would imply some kind of eventing to notify running nodes that their configuration has changed. This is obviously a rather complex proposition given where we are now.
Give where we are with 1.x I think the answer is to;
- fix our read/resolve process so that definitions.xml are considered to be domain wide
- fix our domain manager so that the domain definitions.xml model is passed to each node
Given these two changes we can close off TUSCANY-2499
- make a statement that once contributions have been added they can't be removed without restarting the nodes that refer to them. If you are prepared to restart a node then you are presented with the domain configuration as it appears at that time taking into account whatever contributions have been added or removed.
For 2.x we could either apply the changes to make definitions that appear in contributions be processed as domain wide defintions or take a wider view and choose a different approach to reading in definitions.xml.
Raymond,
Are you suggesting that the user should have to explicitly import definitions from other user (non-system) contributions? As far as I know all definitions that have been contributed to the domain are implicitly visible to all contributions.
I agree. I don't think the user should have to import artifacts from definitions.xml files. The spec refers to them as domain wide artifacts.
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Simon Laws <si...@googlemail.com>.
Hi Greg
Comments in line...
Simon
On Fri, Jan 9, 2009 at 10:38 PM, Greg Dritschler
<gr...@gmail.com>wrote:
> Simon,
>
> Regarding bullet A, this is fine if the set of contributions is static.
> What happens as contributions are added and removed (particularly
> contributions that contain definitions)? I think the spec is silent about
> what should happen.
>
I think the confusion is because the spec doesn't state that definitions.xml
will be provided via contributions. I think having definitions.xml inside
contributions is a Tuscany thing. The spec talks about a domain wide file
named definitions.xml. Hence it makes no comment on what happens as
contributions are added and removed.
Given that we allow definitions.xml files inside contribution I was looking
at what it would take to really consider these definitions artifacts as
domain wide. The answer is that we have to change our read and resolution
process a bit but it's not a huge change.
Another approach would be to change the way Tuscany works and read
definitions.xml files independently of contributions or, for example,
mandate that a separate system contribution must be provided to add
defintions.xml to the domain.
As you point out, I haven't addressed what should happen as contributions
are added and removed in a running syste. In fact we currently don't address
this generally. The Tuscany domain is static in that all contributions must
be present before you start nodes. I'd like to see us move toward a more
dynamic solution but we aren't there yet. Any change in contributions (or
defintions.xml) within a running system would imply some kind of eventing to
notify running nodes that their configuration has changed. This is obviously
a rather complex proposition given where we are now.
Give where we are with 1.x I think the answer is to;
- fix our read/resolve process so that definitions.xml are considered to
be domain wide
- fix our domain manager so that the domain definitions.xml model is
passed to each node
Given these two changes we can close off TUSCANY-2499
- make a statement that once contributions have been added they can't be
removed without restarting the nodes that refer to them. If you are prepared
to restart a node then you are presented with the domain configuration as it
appears at that time taking into account whatever contributions have been
added or removed.
For 2.x we could either apply the changes to make definitions that appear in
contributions be processed as domain wide defintions or take a wider view
and choose a different approach to reading in definitions.xml.
>
> Raymond,
>
> Are you suggesting that the user should have to explicitly import
> definitions from other user (non-system) contributions? As far as I know
> all definitions that have been contributed to the domain are implicitly
> visible to all contributions.
I agree. I don't think the user should have to import artifacts from
definitions.xml files. The spec refers to them as domain wide artifacts.
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Greg Dritschler <gr...@gmail.com>.
Simon,
Regarding bullet A, this is fine if the set of contributions is static. What
happens as contributions are added and removed (particularly contributions
that contain definitions)? I think the spec is silent about what should
happen.
Raymond,
Are you suggesting that the user should have to explicitly import
definitions from other user (non-system) contributions? As far as I know
all definitions that have been contributed to the domain are implicitly
visible to all contributions.
On Fri, Jan 9, 2009 at 12:20 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Jan 9, 2009 at 4:46 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> I had an offline chat with Mike Edwards on a related SCA spec question a
>> few weeks ago. He came up an idea to use the "system contribution" to
>> contain the global definitions in the SCA domain. The definitions from SCA
>> specs and Tuscany extensions will be loaded by Tuscany runtime and added to
>> the "system contribution". The "system contribution" has the exports to make
>> them visible to application contributions.
>>
>> I quite like his idea and I think it's worth to explore. It's similar to
>> the OSGi idea to have a system bundle that exports system packages.
>>
>> Let's say we have an SCA composite application which requires 2
>> contributions: C1 and C2. The "system contribution" is C0. Then the
>> composite application will have access to intents and policySets in C1, C2
>> and C0 if necessary imports/exports are declared. By default, we can assume
>> the import to SCA spec and Tuscany extension namespace is allowed.
>>
>> Thanks,
>> Raymond
>>
>> *From:* Simon Laws <si...@googlemail.com>
>> *Sent:* Friday, January 09, 2009 7:56 AM
>> *To:* tuscany-dev <de...@tuscany.apache.org>
>> *Subject:* [1.x][2.x][DISCUSS] definitions.xml processing
>>
>> In 1.x, and by implication 2.x, the definitions.xml processing is
>> problematic in a number of ways. We have started to talk about revisiting
>> the policy model [1] and although we haven't done that yet in 2.x I'm
>> trying to get my mind around how definitions.xml files are processed by
>> Tuscany. There seem to be a number of gaps, e.g. TUSCANY-2499 [2].
>>
>> A) Resolve definitions gloabally given the set of contributions available.
>> I think the ideal order of processing for a stand-alone node should be.
>>
>> - read all defintiions.xml files from extensions that the runtime loads
>> - read all contributions (which in turn will read any definitions.xml
>> files that appear in contributions)
>> - resolve all the definitions that have been read (aggregate all the
>> definitions models together and resolve them)
>> - resolve all of the contributions
>>
>> I believe the contribution processing has been split up already in 2.x so
>> this change should be straightforward there. I have a patch for 1.x. It
>> relies on exposing interfaces on the contribution service to allow read and
>> resolve to be called independently. This does solve 2499 so I'll attach the
>> patch there for people to look at. I haven't commited directly as there
>> workspace contribution processing is already in 1.x but I'm not sure yet
>> what the implications of switching across to that would be.
>>
>> An interesting problem I uncovered is that the JAAS policy itself dependes
>> on contribution artifacts (java classes) so you have to resolve the
>> definitions in the context of the contributions that have previously been
>> read. This feels a little odd to me.
>>
>> B) Global access to the definitions artifacts
>>
>> In 1.x the definitions model is owned by the RuntimeBootStrapper and is
>> made available to the model through the resolver structure. It seems that it
>> is not easy to use the resolver approach in some places, e,g the JMS binding
>> where its gets data from the definitions.xml binding structure. We need to
>> review this and see how access should be provided to the definitions.xml
>> model.
>>
>> C) Retrieve domain definitions from the domain
>>
>> The problem described in A) raises it's head in the domain also. Here
>> though the solution is not so straighforward as the domain level defintions
>> model must be subsequently provided to all nodes (assuming that I understand
>> the specs correctly of course).
>>
>> While there are some TODO comments in the code suggesting that defintions
>> dependencies should be expressed through contribution import/export
>> statements I don't think this is true as the spec considers defintiions.xml
>> to be a domain level resource while Tuscany just happens to allow you to
>> include them in a contribution.
>>
>> We could take the aggreated definitions.xml artifacts and create a special
>> contribution and provide this to all nodes. Alternatively we could provide a
>> specific endpoint from which to retrieve the defintiions.xml artifacts. The
>> first approach would seem to be the simpler of the two.
>>
>> Regards
>>
>> Simon
>>
>> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
>> [2] http://issues.apache.org/jira/browse/TUSCANY-2499
>>
>
> Yep, I'm with your there. Seems like the most straightforward way to
> represent it.
>
> Simon
>
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 9, 2009 at 4:46 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I had an offline chat with Mike Edwards on a related SCA spec question a
> few weeks ago. He came up an idea to use the "system contribution" to
> contain the global definitions in the SCA domain. The definitions from SCA
> specs and Tuscany extensions will be loaded by Tuscany runtime and added to
> the "system contribution". The "system contribution" has the exports to make
> them visible to application contributions.
>
> I quite like his idea and I think it's worth to explore. It's similar to
> the OSGi idea to have a system bundle that exports system packages.
>
> Let's say we have an SCA composite application which requires 2
> contributions: C1 and C2. The "system contribution" is C0. Then the
> composite application will have access to intents and policySets in C1, C2
> and C0 if necessary imports/exports are declared. By default, we can assume
> the import to SCA spec and Tuscany extension namespace is allowed.
>
> Thanks,
> Raymond
>
> *From:* Simon Laws <si...@googlemail.com>
> *Sent:* Friday, January 09, 2009 7:56 AM
> *To:* tuscany-dev <de...@tuscany.apache.org>
> *Subject:* [1.x][2.x][DISCUSS] definitions.xml processing
>
> In 1.x, and by implication 2.x, the definitions.xml processing is
> problematic in a number of ways. We have started to talk about revisiting
> the policy model [1] and although we haven't done that yet in 2.x I'm
> trying to get my mind around how definitions.xml files are processed by
> Tuscany. There seem to be a number of gaps, e.g. TUSCANY-2499 [2].
>
> A) Resolve definitions gloabally given the set of contributions available.
> I think the ideal order of processing for a stand-alone node should be.
>
> - read all defintiions.xml files from extensions that the runtime loads
> - read all contributions (which in turn will read any definitions.xml files
> that appear in contributions)
> - resolve all the definitions that have been read (aggregate all the
> definitions models together and resolve them)
> - resolve all of the contributions
>
> I believe the contribution processing has been split up already in 2.x so
> this change should be straightforward there. I have a patch for 1.x. It
> relies on exposing interfaces on the contribution service to allow read and
> resolve to be called independently. This does solve 2499 so I'll attach the
> patch there for people to look at. I haven't commited directly as there
> workspace contribution processing is already in 1.x but I'm not sure yet
> what the implications of switching across to that would be.
>
> An interesting problem I uncovered is that the JAAS policy itself dependes
> on contribution artifacts (java classes) so you have to resolve the
> definitions in the context of the contributions that have previously been
> read. This feels a little odd to me.
>
> B) Global access to the definitions artifacts
>
> In 1.x the definitions model is owned by the RuntimeBootStrapper and is
> made available to the model through the resolver structure. It seems that it
> is not easy to use the resolver approach in some places, e,g the JMS binding
> where its gets data from the definitions.xml binding structure. We need to
> review this and see how access should be provided to the definitions.xml
> model.
>
> C) Retrieve domain definitions from the domain
>
> The problem described in A) raises it's head in the domain also. Here
> though the solution is not so straighforward as the domain level defintions
> model must be subsequently provided to all nodes (assuming that I understand
> the specs correctly of course).
>
> While there are some TODO comments in the code suggesting that defintions
> dependencies should be expressed through contribution import/export
> statements I don't think this is true as the spec considers defintiions.xml
> to be a domain level resource while Tuscany just happens to allow you to
> include them in a contribution.
>
> We could take the aggreated definitions.xml artifacts and create a special
> contribution and provide this to all nodes. Alternatively we could provide a
> specific endpoint from which to retrieve the defintiions.xml artifacts. The
> first approach would seem to be the simpler of the two.
>
> Regards
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
> [2] http://issues.apache.org/jira/browse/TUSCANY-2499
>
Yep, I'm with your there. Seems like the most straightforward way to
represent it.
Simon
Re: [1.x][2.x][DISCUSS] definitions.xml processing
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I had an offline chat with Mike Edwards on a related SCA spec question a few weeks ago. He came up an idea to use the "system contribution" to contain the global definitions in the SCA domain. The definitions from SCA specs and Tuscany extensions will be loaded by Tuscany runtime and added to the "system contribution". The "system contribution" has the exports to make them visible to application contributions.
I quite like his idea and I think it's worth to explore. It's similar to the OSGi idea to have a system bundle that exports system packages.
Let's say we have an SCA composite application which requires 2 contributions: C1 and C2. The "system contribution" is C0. Then the composite application will have access to intents and policySets in C1, C2 and C0 if necessary imports/exports are declared. By default, we can assume the import to SCA spec and Tuscany extension namespace is allowed.
Thanks,
Raymond
From: Simon Laws
Sent: Friday, January 09, 2009 7:56 AM
To: tuscany-dev
Subject: [1.x][2.x][DISCUSS] definitions.xml processing
In 1.x, and by implication 2.x, the definitions.xml processing is problematic in a number of ways. We have started to talk about revisiting the policy model [1] and although we haven't done that yet in 2.x I'm trying to get my mind around how definitions.xml files are processed by Tuscany. There seem to be a number of gaps, e.g. TUSCANY-2499 [2].
A) Resolve definitions gloabally given the set of contributions available. I think the ideal order of processing for a stand-alone node should be.
- read all defintiions.xml files from extensions that the runtime loads
- read all contributions (which in turn will read any definitions.xml files that appear in contributions)
- resolve all the definitions that have been read (aggregate all the definitions models together and resolve them)
- resolve all of the contributions
I believe the contribution processing has been split up already in 2.x so this change should be straightforward there. I have a patch for 1.x. It relies on exposing interfaces on the contribution service to allow read and resolve to be called independently. This does solve 2499 so I'll attach the patch there for people to look at. I haven't commited directly as there workspace contribution processing is already in 1.x but I'm not sure yet what the implications of switching across to that would be.
An interesting problem I uncovered is that the JAAS policy itself dependes on contribution artifacts (java classes) so you have to resolve the definitions in the context of the contributions that have previously been read. This feels a little odd to me.
B) Global access to the definitions artifacts
In 1.x the definitions model is owned by the RuntimeBootStrapper and is made available to the model through the resolver structure. It seems that it is not easy to use the resolver approach in some places, e,g the JMS binding where its gets data from the definitions.xml binding structure. We need to review this and see how access should be provided to the definitions.xml model.
C) Retrieve domain definitions from the domain
The problem described in A) raises it's head in the domain also. Here though the solution is not so straighforward as the domain level defintions model must be subsequently provided to all nodes (assuming that I understand the specs correctly of course).
While there are some TODO comments in the code suggesting that defintions dependencies should be expressed through contribution import/export statements I don't think this is true as the spec considers defintiions.xml to be a domain level resource while Tuscany just happens to allow you to include them in a contribution.
We could take the aggreated definitions.xml artifacts and create a special contribution and provide this to all nodes. Alternatively we could provide a specific endpoint from which to retrieve the defintiions.xml artifacts. The first approach would seem to be the simpler of the two.
Regards
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
[2] http://issues.apache.org/jira/browse/TUSCANY-2499