On Fri, Jan 9, 2009 at 4:46 PM, Raymond Feng <enjoyj...@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 <simonsl...@googlemail.com> > *Sent:* Friday, January 09, 2009 7:56 AM > *To:* tuscany-dev <dev@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
