Hi Raymond, Please see my comments inline.
Also, now that you are with this, may I request your views on the problem that I am facing with attaching intents and policysets on implementation model instances. Presently, atleast for the JavaImplementation model instances we reuse instances across components. i.e. assuming we have CompA and CompB using the same java implementation, then the implementation model instance that we create is just one. This is a bit of a problem when CompA and CompB have different intents specified and the underlying implementations must inherit that. Please see http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg24574.html Thanks - Venkat On 10/20/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > I checked in some code as the seed to jump start the transaction policy > support in Tuscany. Please see more details at > http://svn.apache.org/viewvc?rev=586640&view=rev. > > By looking into the code we have today, I have a few questions. > > 1) > > org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.loadDomainDefinitions > (SCADefinitionsDocumentProcessor) > assuming we have only one "definitions.xml"? Yes. From what I have understood from the Assembly specs this definitions.xml is going to be one per SCA Domain. 2) Should the binding/implementation type contribute policy interceptors > instead of wrapping the invoker? I'd been a bit on cross-roads with this, especially when I recently did up the support for policies in implementation types where I did end up wrapping the invoker. I am also tilting heavily towards interceptors and will lookup that. 3) META-INF/services/org.apache.tuscany.sca.policy.PolicySetHandlers > The syntax <qname>=<class> is not consistent with the other extension > points. I propose that we use: <class>;qname=<qname>, for example, > org.apache.tuscany.sca.policy.transaction.TransactionPolicyHandler;qname={ > http://tuscany.apache.org/xmlns/sca/1.0}TransactionPolicy I just wanted to keep it like a simple properties file and did not foresee more than this one setting. I am ok to move up to this format as we go along. I'll post more questions as we evolve. > > Thanks, > Raymond > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
