Re: Secure-bigbank demo, was Re: svn commit: r641708 - /incubator/tuscany/java/sca/demos/pom.xml
Hi, All of what is done in secure-bigbank has now been merged into the bigbank. I should have deleted secure-bigbank then. My bad and apologies for that. Thanks - Venkat On Wed, May 28, 2008 at 10:38 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have added this back to build under revision #661019. On Tue, May 27, 2008 at 11:00 AM, Luciano Resende [EMAIL PROTECTED] wrote: I tried to build the secure-bigbank demo and it worked ok for me. Any particular reason why this demo was removed from build ? On Wed, Mar 26, 2008 at 10:54 PM, [EMAIL PROTECTED] wrote: Author: svkrish Date: Wed Mar 26 22:54:44 2008 New Revision: 641708 URL: http://svn.apache.org/viewvc?rev=641708view=rev Log: removing secure-bigbank demo Modified: incubator/tuscany/java/sca/demos/pom.xml Modified: incubator/tuscany/java/sca/demos/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/demos/pom.xml?rev=641708r1=641707r2=641708view=diff == --- incubator/tuscany/java/sca/demos/pom.xml (original) +++ incubator/tuscany/java/sca/demos/pom.xml Wed Mar 26 22:54:44 2008 @@ -43,7 +43,6 @@ modulebigbank-stockquote/module modulemortgage-creditcheck/module modulemortgage-loanapproval/module -modulesecure-bigbank/module modulexml-bigbank/module /modules /profile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
Congratulations Vamsi... Welcome !!! - Venkat On Mon, Jun 2, 2008 at 11:32 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant
Re: SCA 2.0, was Re: Next SCA release
+1 to Simon's view point. I also see this good from one of our earlier objective to keep our trunk stable. I'd prefer that we evolve the (potentially breaking) changes that we want to do in our road to 2.0 initially in a branch. Just a worry - would it be challenging to keep the branch and trunk in sync from a feature enhancements perspective. i.e. if there are some feature enhancements that go into the trunk then we have to ensure that equivalent ones go into the branch smoothly riding over the changes that have happened in there. - Venkat On Wed, May 14, 2008 at 3:31 PM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien Given the amount of activity we have going on in trunk at the moment, I would support 1.x remaining as trunk and cutting a branch to allow for more innovative (read breaking) development in a 2.0 code stream. Simon
Re: [DISCUSS] Declaring extensions as being available in the domain
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@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
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 [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] 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
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 from me. - Venkat On Sat, May 10, 2008 at 12:47 PM, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: [DISCUSS] Declaring extensions as being available in the domain
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 [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:33 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 4:02 PM, ant elder [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 1:19 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] 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
Re: [DISCUSS] Declaring extensions as being available in the domain
Hi, Please find my comments inline. On Thu, May 8, 2008 at 3:13 PM, Simon Laws [EMAIL PROTECTED] 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
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project
+1 for graduation. We've really come a long way since. - Venkat On Mon, Apr 28, 2008 at 11:46 PM, ant elder [EMAIL PROTECTED] wrote: We've done a lot of work since last October. We now have a diverse community of contributors and have demonstrated the ability to attract new committers to create an even more diverse community, we have shown we can do releases based on Apache guidelines, and we have shown we conduct our discussions in public within full view of the community and can resolve disagreements on the lists. I think we're ready, so please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: - Adriano Crestani adrianocrestani at apache dot org - ant elder antelder at apache dot org - Brady Johnson bjohnson at apache dot org - Frank Budinsky frankb at apache dot org - Ignacio Silva-Lepe isilval at apache dot org - Jean-Sebastien Delfino jsdelfino at apache dot org - kelvin goodson kelvingoodson at apache dot org - Luciano Resende lresende at apache dot org - Mark Combellack mcombellack at apache dot org - Matthieu Riou mriou at apache dot org - Mike Edwards edwardsmj at apache dot org - Paul Fremantle pzf at apache dot org - Pete Robbins robbinspg at apache dot org - Raymond Feng rfeng at apache dot org - Simon Laws slaws at apache dot org - Simon Nash nash at apache dot org - Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
Re: [NOTICE] Mario Antollini voted as Tuscany committer
Congratulations Mario and welcome onboard !! :) - Venkat On Fri, Apr 25, 2008 at 9:17 PM, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Mario Antollini to become a Tuscany committer. Please spend sometime to get familiar with Apache developer's pages [1], the Apache Incubator site [2] and to the Incubator Committers Guide [3]. Also, could you please submit an Apache CLA so we can get your userid and access sorted out, you can find out about the Contributor License Agreement at [4]. Congratulations and welcome Mario! [1] http://www.apache.org/dev/ [2] http://incubator.apache.org/ [3] http://incubator.apache.org/guides/committer.html [4] http://www.apache.org/licenses/#clas -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Adding SVN version to Java files
I agree with Luciano's perspective. - Venkat On Wed, Apr 23, 2008 at 9:28 PM, Luciano Resende [EMAIL PROTECTED] wrote: Considering this has been there in several files for a while, and it really does not affect anyone that does not want to use the extra one line of information on the top of the java file. Why not let other that see some benefits on this to use it ? I'm still +1 on this. On Wed, Apr 23, 2008 at 5:52 AM, Simon Nash [EMAIL PROTECTED] wrote: Mark Combellack wrote: -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: 15 April 2008 02:59 To: tuscany-dev@ws.apache.org Subject: Re: Adding SVN version to Java files Mark Combellack wrote: Hi, I've been looking through the Tuscany source code and noticed that some files have a @version containing the SVN revision number in their JavaDoc headers but others do not. As an example, @version might look like: /** * Some JavaDoc for the class * * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov 2007) $ */ I would like to go through the Tuscany source code and add this header where it is missing. This would involve a large number of minor changes to the Tuscany tree so I wanted to run it by everyone to make sure no-one had a problem with me doing this at this time. I'll probably start this next week unless there is an objection. Thanks, Mark I'm replying again to the original message in this thread, as there doesn't seem to be any conclusion yet. Does anybody understand where we are with this? I'm usually adding the SVN rev tag to the files I touch when I see that it's missing. I guess I can continue like that but it doesn't sound ideal, so I'm still +1 on Mark's proposal. Anyway, Mark Thanks for volunteering to do this. I was hoping it'd take less than 3 weeks to reach consensus on changes like that which don't break anything... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This topic appears to have gone quiet. I guess this means that we have a consensus since there appears to be no active debate on this subject. In summary of this thread, we have: +1 from Mark, Vasmi, Luciano and Sebastian. ant prefers not to do this Simon says he would find it useful. I did say this, but there was subsequent discussion in which an alternative aproach was suggested, and I said the following in reply: Thanks. This seems pretty easy to do, and it's 100% reliable. Now I have discovered this, I don't see any great advantage in having the same information within the file itself. So my view is that there is not much value in doing this. Also, my experience today with patch application indicates that there can be a downside. From the above, we have 4 +1s and no -1s - although we have a preference not to do this from ant. So, the consensus is to make this change. We haven't held a formal vote, so I don't think we should be trying to decide this based on a count of +1s and -1s. I'd prefer to turn the question around and ask what is the value in adding this, given that the information is so easily available by other means. Simon I'll hold off making the changes for a few days and then start later this week. Thanks, Mark -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario
Hi, With r650032, I have committed some simple additions to support the model and StaX processor for the bunch of policy assertions specified in section 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. I'd wish to optimize this a bit and cut down on some classes in the future. As a start for this here is a question related to the specs and hope somebody is able to help me with some clarity... - Do we need three assertions viz. permitAll, denyAll, allow. Why not just the one as follows: - allow roles=listOfNCNames permitAll=xs:boolean/ So if permitAll is 'true' then all roles is permitted. If it is false then only those roles in the 'roles' attribute is permitted. If it is false and there aren't any roles specified then it is equivalent to 'denyAll'. Thanks - Venkat On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Ok. Please be aware there is an errata associated with the authorization elements. http://www.osoa.org/jira/browse/POLICY-26 On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: +1. I will start looking into this after I am done with some half-finished things on my plate at the moment. Thanks. - Venkat On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Greg Dritschler wrote: Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg I think that Tuscany should implement the authorization - I guess that's what you meant :) - and security identity policies as described in section 1.7.3.1 of the Policy spec, at least. We could start with just implementing the model and XML reading for the elements described in 1.7.3.1 and let the various component implementation extensions handle them (or not) in their own way, but having the model and XML processors would be a good start IMO. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents
Hi, With specific reference to the inheritance of intents and policysets across the SCDL-XML hierarchy i.e. the one by which child elements inherit that which is specified in the parent element I have a question as follows :- Do we need to bother about the validity of what a child element actually inherits UNLESS its a binding or implementation element ? For example how very important is it to worry about validating for Mutually exclusive intents at a 'reference' element. I am wondering if I could just about aggregate all intents and policysets upto the immediate parent of a binding or implementation element. Then at this point, when the binding or implementation is about to inherit, I would apply validations related to checks for mutually exclusive intents. I am thinking on these lines because it seems to me that the binding and implementation elements are where intents and policyset actually matter. If specified in any other levle its only for convenience so as to cover a whole bunch of child elements. Am I trying to overly simply things here missing some key point ? Thanks - Venkat On Fri, Apr 18, 2008 at 7:08 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Thanks Mike. As you know I relied on these 2 JIRAs to compose a solution. With respect to POLICY-39, I didn't implement some of the features like wildcarding of qualifiers or not requiring reciprocal exclusions in the interest of getting the basics done and into the code base. These features could be added later if someone has an interest in them. On Thu, Apr 17, 2008 at 9:54 AM, Mike Edwards [EMAIL PROTECTED] wrote: Greg Dritschler (JIRA) wrote: Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1
Re: [vtest] Java API Spec - Section 2 - Policy Annotations
Hi Kevin, Yes, we do support this although there isn't extensive testing of this. There is some rudimenatary testing that I have done in itest/policy but the method that I've had to use there for verification is not a happy one i.e. verification through the calling of policy handlers. So, if you could help with some vtest for this, it will certainly be helpful. Thanks - Venkat On Fri, Apr 18, 2008 at 11:24 PM, Kevin Williams [EMAIL PROTECTED] wrote: We are moving through the Java API and Annotations specification pretty well in vTest and I am wondering if we should start on section 2 which covers policy annotations. Are we supporting this section of the specification? -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Wang Feng voted as Tuscany committer
Congratulations Wang Feng! Welcome! :) - Venkat On Wed, Apr 16, 2008 at 2:25 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Wang Feng to become a Tuscany committer. Congratulations and welcome Wang Feng! ...ant
Re: SCA 2.0, was Re: Next SCA release
Hi, +1 for moving the trunk to 2.0 and working on all the changes that we have been wanted to make to the SPIs, distribution packaging, runtimes etc. +1 for having 1.2 as maintenance branch and keeping it stable. Any improvements keeping this as base could continue on the branch and maybe if our 2.0 release if going to take a while, we could make some 1.2.x sort of minor releases. Since the branch has been cleaned up the release work for these should hopefully be less too. +1 for keeping the same space for the docs but create a separate stream of docs for version 2 specific things. This is 'option 2' in the proposal related to documentation. Thanks - Venkat On Sat, Apr 12, 2008 at 5:34 AM, Luciano Resende [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 3:28 AM, ant elder [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash [EMAIL PROTECTED] wrote: snip +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. So based on the comments so far I think we should hold off on moving to 2.0 for now. +1, let's get consensus first. That said I'm extremely wary of the having work going on in investigative branches, given Tuscany's history of branches and forks I really really hope this doesn't happen much and we'd instead all try to work together in the trunk. +1 ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)
+1 from me. Eclipse update is going fine. Samples are ok. Could not spot any problems with licenses. Luciano, thanks a ton for all the hard work. - Venkat On Mon, Apr 14, 2008 at 3:36 PM, Luciano Resende [EMAIL PROTECTED] wrote: Please review and vote on the 1.2 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. The eclipse updatesite for the Tuscany Eclipse plugins is available at: http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/ The release tag is available at : http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/ Looks OK to me, here is my +1. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on Composition.
Hi Sandeep, The java implementation class is something that typically contains business logic. The SCDL file is where you compose applications that 'use' this java implementation. In this way you could have the same java implementation being 're-used' in different application scenarios. Now, given this understanding, its upto business logic developers on what they might want to put into an implementation and this in my opinion is subjective. So you could, for instance, provide an implemenation of ComposerImpl.java that your clients can use in their compositions. Thanks - Venkat On Thu, Apr 10, 2008 at 3:52 PM, Sandeep Raman [EMAIL PROTECTED] wrote: Hi, I have a requirement as given below:Can you please guide me if this can be done or any alternative is available. To do composition , I need to write my SCDL file and the implementation java class(lets say ComposerImpl.java), Now If the composition is to be done by the End user/Client all I should ask him is to write the Xml file . Is there any way to do without the java class being written manually. Either the java class being generated automatically (writing an own code generator is an option but sequence of the calling the components is a challenge here) or to do with some generic java file. Regards, Sandeep Raman. =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Re: Project Ideas - Let's get the community involved !!!
Hi, This is good idea. I''ve tried to make some minor changes to the page. Thanks - Venkat On Thu, Apr 10, 2008 at 6:50 PM, Dan Becker [EMAIL PROTECTED] wrote: Luciano Resende wrote: I have noticed that the approach we used for GSoC, where we described small project ideas, with a proper description and a suggested scenario to guide the development of the idea is generating much more interest from the community. [1] http://incubator.apache.org/tuscany/getting-involved-projects.html I think this is a great idea and would like to add one minor suggestion. The page might benefit from a large title and brief introductory paragraph. That way if you search for or otherwise stumble onto the page, you have a bit of an idea of the nature of the page, why it's there, who should use it. -- Thanks, Dan Becker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCADefinitionsProviderExtensionPoint interface
Hi Adriano, The SCADefinitionsProviderExtensionPoint has been moved out of the 'definitions' module and into the core-spi module. So you should not be seeing org.apache.tuscany.sca.definitions.SCADefinitionsProviderExtensionPoint anywhere. Could you please point me to where you are observing this duplication ? Thanks - Venkat On Wed, Apr 9, 2008 at 11:59 AM, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, Can anybody tell me what is the difference between org.apache.tuscany.sca.definitions.SCADefinitionsProviderExtensionPoint and org.apache.tuscany.sca.provider.SCADefinitionsProviderExtensionPoint interface? Because they do have the same methods signature. Thanks in advance for the replies Adriano Crestani
Re: policy itest question
Hi Greg, Please find my comments / answers inline. Thanks - Venkat From: Greg Dritschler [EMAIL PROTECTED] Date: Apr 8, 2008 7:05 PM Subject: Re: policy itest question To: tuscany-dev@ws.apache.org D'oh! I didn't think to look at the java classes for annotations. That explains a lot. I agree the itest had some limitations. In particular I think it would catch if the policy handlers were created with the wrong policy sets, but it didn't verify if some expected policy handlers were not created. Over here I assume that the expected PolicyHandlers are called. If there is no PolicyHandler found for a PolicySet, then that would get flagged. My intention was only to verify if the right PolicySets get applied which I could only verify by checking if the PolicyHanlder is called with the right PolicySet. The simpler option would be to get hold of the Composite just after its built and verify the PolicySets that have been attached to the various SCA Artifacts. But all of this is subject to revisit and change as the PolicyHandler is on its way out with the arrival of PolicyProviders. So verifying from handlers is not going to stay for long. Doesn't the test in the assembly module do read/resolve/build testing? How would this be different? I think the assembly module can't test the full inheritance of intents down to implementation or binding given assembly is so early in the build. Would this new test address that? With the assembly module, as you point out rightly, I could just about test for the inheritance excluding the bindings and implementation extensions. If this was also to be done in the assembly module there are issues with pulling in the extensions as dependencies. So, I'd like to cover more comprehensive tests here including binding and implementation extensions. And to do this I intend to do the read, resolve and build explicitly and verify against the built up composite instead of starting the runtime. I'd like to hear if people have objections to this as in all our itests we typically start up the runtime. The reason I'm asking about this is that I'm working on the support for mutually-exclusive intents and I would like to modify an existing test rather than start from scratch. Yes, this makes sense. We should have all sorts of test for policies in this itest module. On Tue, Apr 8, 2008 at 9:20 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, This itest needs to be re-written after the changes to the PolicyHandling story for the java implementation extension. Also I put in this itest to get some cases of policy annotations verified at a rudimentary level - like checking to see if the annotations ever get picked up and applied. IMO, using interceptors for this testing is quite ugly and not going to go very far. I am going to change this to explicitly execute read, resolve and build phases and simply verify against the built up composite. Thanks - Venkat On Mon, Apr 7, 2008 at 4:12 AM, Greg Dritschler [EMAIL PROTECTED] wrote: What is the status of the policy itest? It uses the PolicyHandler interface to do its verification and that doesn't seem to work anymore, at least for Java implementations. (The call to instantiate the JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator is commented out.) Is this itest going to be rewritten? I can't say that I understand how this itest was supposed to have worked. The composite uses only one intent, TestIntent_3, on the implementation of AddServiceComponent. That intent is provided by one policy set TestPolicySet_3_implementation. Yet it looks to me like TestImplPolicyHandler is quite happy if various other policy sets are selected, such TestPolicySet_1_implementation or TestPolicySet_2_implementation. What's the story? Greg Dritschler -- Thanks Regards, Ramkumar Ramalingam
Re: policy itest question
Hi Greg, This itest needs to be re-written after the changes to the PolicyHandling story for the java implementation extension. Also I put in this itest to get some cases of policy annotations verified at a rudimentary level - like checking to see if the annotations ever get picked up and applied. IMO, using interceptors for this testing is quite ugly and not going to go very far. I am going to change this to explicitly execute read, resolve and build phases and simply verify against the built up composite. Thanks - Venkat On Mon, Apr 7, 2008 at 4:12 AM, Greg Dritschler [EMAIL PROTECTED] wrote: What is the status of the policy itest? It uses the PolicyHandler interface to do its verification and that doesn't seem to work anymore, at least for Java implementations. (The call to instantiate the JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator is commented out.) Is this itest going to be rewritten? I can't say that I understand how this itest was supposed to have worked. The composite uses only one intent, TestIntent_3, on the implementation of AddServiceComponent. That intent is provided by one policy set TestPolicySet_3_implementation. Yet it looks to me like TestImplPolicyHandler is quite happy if various other policy sets are selected, such TestPolicySet_1_implementation or TestPolicySet_2_implementation. What's the story? Greg Dritschler
Re: Removing definitions
Hi Ramkumar, Welcome to Tuscany! Yes, this is a good simple start. Please go ahead and create a JIRA for this. Also would like to see you discuss the alternatives you have in mind for this. Thanks - Venkat On Mon, Mar 31, 2008 at 3:58 PM, Ramkumar R [EMAIL PROTECTED] wrote: On 3/27/08, Greg Dritschler [EMAIL PROTECTED] wrote: I'm not sure I'm getting the multi-threading thing, could you say a bit more about it? -- Jean-Sebastien [EMAIL PROTECTED] Thread 1 and thread 2 call ContributionService.contribute. Each contribution contains a defintions.xml file so both threads try to add policy sets etc. Since SCADefinitions uses unsynchronized ArrayLists this is exposed to failure. SCADefinitionsUtil also has some code that isn't thread safe. Greg Hi, I am new to Tuscany Community and trying to catch up. Right now am going through the code to get a feel of it and this threading issue seems to something simple that I can fix to try a hand with Tuscany. Can I create a JIRA for the threading issue alone and attach a patch ? -- Thanks Regards, Ramkumar Ramalingam
Removing SecureBigBank Demo - svn commit: r640886 - /incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.jav
Hi Mark, Now that the security things are integrated into the bigbank demo itself, I wish to remove the secure bigbank demo. I have already done that for our 1.2 release. I wanted to do it for the trunk but find this recent update from you. So am trying to find out if there is anything you are doing with this or would you be ok if I went ahead and removed it. Thanks - Venkat On Tue, Mar 25, 2008 at 9:49 PM, [EMAIL PROTECTED] wrote: Author: mcombellack Date: Tue Mar 25 09:19:48 2008 New Revision: 640886 URL: http://svn.apache.org/viewvc?rev=640886view=rev Log: Removed unused imports Modified: incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.java Modified: incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.java URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.java?rev=640886r1=640885r2=640886view=diff == --- incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.java (original) +++ incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.java Tue Mar 25 09:19:48 2008 @@ -18,11 +18,6 @@ */ package bigbank.security; -import static javax.xml.stream.XMLStreamConstants.END_ELEMENT; -import static javax.xml.stream.XMLStreamConstants.START_ELEMENT; - -import java.util.logging.Level; - import javax.xml.namespace.QName; import javax.xml.stream.XMLStreamException; import javax.xml.stream.XMLStreamReader; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: How to use logger policy?
Hi Wang, Apologies. There is a bug in the the JDKLoggingImplementationPolicyProvider. We must be using component.getPolicySets() and not getApplicablePolicySets(). I am in the course of fixing this along with a few other things in the branch for our 1.2 release after which I will syncing up the trunk for this. So in about an couple of hours you should see all of this working from the trunk as well. There is one thing that I noted though in your definitions.xml. It seems to be providing the 'implementationType' definitions for the sca: implementation.java extension. You should not be doing this as this is something which should be a part of implementation.java extension itself. The trouble that this can cause is with the intents that you might specify as 'mayProvides' and 'alwaysProvides'. When you use the intents defined under these, in your composite, they will never get matched with policysets because, for these it is understood that the extension itself handles what needs to be done. Thanks. - Venkat On Wed, Mar 26, 2008 at 12:15 PM, wang feng [EMAIL PROTECTED] wrote: My definitions.xml file is in the class path of org\apache\tuscany\sca\policy\logging and find the processor has readed the file. The PolicyProvider.createInterceptor will return null,because it can't find any applicable policyset for the component. But I copy the definitions.xml to the same dir of the composite file,it run fine. Is something wrong? Thanks, Wang Feng On 2008-03-26,Raymond Feng [EMAIL PROTECTED] wrote: Hi, Are you packaging definitions.xml in your SCA contribution to try application-level configuration of the intents/policySets? For tuscany extensions, we have switched to SCADefinitionsProvider to contribute definitions.xml model into Tuscany, not the definitions.xmlfile. Can you take the policy-logging module as an example? Thanks, Raymond -- From: wang feng [EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 8:28 PM To: tuscany-dev tuscany-dev@ws.apache.org Subject: How to use logger policy? Hi,all I do a sample to test policy with logger policy,but the logger policy don't work. I debug the code and find the method component.getApplicablePolicySets() in PolicyProvider Impl alway return null. I look for the code and not find where the ApplicablePolicySets value on component or binding or reference was setted. Can anybody help me? Config file like below definitions.xml definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:calc=http://calculator; implementationType type=sca:implementation.java alwaysProvides=tuscany:logging/ intent name=logging constrains=sca:implementation.java descriptionAll messages to and from this implementation must be logged/description /intent policySet name=JDKLoggingPolicy provides=tuscany:logging appliesTo=sca:implementation.java xmlns=http://www.osoa.org/xmlns/sca/1.0; tuscany:jdkLogger name=calculator logLevelALL/logLevel /tuscany:jdkLogger /policySet /definitions calculator.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample=http://sample; name=Calculator xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; component name=CalculatorServiceComponent policyset=tuscany:JDKLoggingPolicy implementation.java class=calculator.CalculatorServiceImpl requires=tuscany:logging/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent / reference name=divideService target=DivideServiceComponent / /component component name=AddServiceComponent implementation.java class=calculator.AddServiceImpl requires=tuscany:logging/ /component component name=SubtractServiceComponent implementation.java class=calculator.SubtractServiceImpl/ /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl/ /component component name=DivideServiceComponent implementation.java class=calculator.DivideServiceImpl/ /component /composite -- wang feng 2008-03-26 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [NOTICE] Giorgio Zoppi voted as Tuscany committer
Congratulations Welcome Giorgio ! :) - Venkat On Wed, Mar 26, 2008 at 2:31 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Giorgio Zoppi to become a Tuscany committer. Could you submit an Apache CLA so i can get your userid and access sorted out, you can find out about the Contributor License Agreement at http://www.apache.org/licenses/#clas Congratulations and welcome Giorgio! ...ant
Re: Error on requires = integrity
Hi, I don't seem to see the definitions.xml attached. If its not too big you could paste it in the mail itself. Thanks - Venkat On Wed, Mar 26, 2008 at 6:34 PM, Sandeep Raman [EMAIL PROTECTED] wrote: Hi, On using requires = integrity on a component service and invoking it i get the following error: Exception in thread main org.apache.axis2.AxisFault: * java.lang.NullPointerException* at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(* Utils.java:486*) at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(* OutInAxisOperation.java:343*) at org.apache.axis2.description.OutInAxisOperationClient.send(* OutInAxisOperation.java:389*) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(* OutInAxisOperation.java:211*) at org.apache.axis2.client.OperationClient.execute(* OperationClient.java:163*) at org.apache.axis2.client.ServiceClient.sendReceive(* ServiceClient.java:528*) at org.apache.axis2.client.ServiceClient.sendReceive(* ServiceClient.java:508*) at TestClient.main(*TestClient.java:33*) Debugging the code doesnt lead to any conclusion for me. Am i missing something. What may be the possible reason. The definitions.xml is attached. Regards Sandeep. =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Discussion] Conversational Polic
Hi, Here is https://issues.apache.org/jira/browse/TUSCANY-2112 where Vamsi is describing the following : - *I have been doing some digging into the conversational semantics. One of the things I have noticed is that when the service is marked with conversational intent, the reference created for the callback does not inherit that intent. Should it be that the callback is marked conversational separate from the service? Also, is it up to the service to mark operations on the callback with an EndsConveration intent? * I guess the reference that gets created for the callback doesn't seem to copy this over, which is something that I will dig up and fix. But I'd like to get a bit of clarity on the inheritance of the intent here. A service could be having 'authentication' as a required intent. Now if that gets to be inherited by the 'callback' element it seem a bit odd to me. The callback should only have intents that the 'calledBack' service has, isn't it. Am I missing something from the inheritance rules here ? Thanks - Venkat
Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?
be a joint effort of a policy interceptor and the binding/implementation provider. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, November 28, 2007 9:05 AM Subject: Policy Handlers ? Hi, Sebastien and Raymond, thanks for your responses on the other thread... I will follow up the issues there one by one. Here I want to discuss about PolicyHandlers. Every policyset encapsulate policies that could follow a standard model such as ws-policy or could follow a custom model as in the case of our axis2-config-param policy and jdkLogging policy. Each implementation and binding type could have its own way of interpretting these policy models and affecting them accordingly in the binding or implementation. For example the axis2 binding simply injects the ws-policy into the axis configuration. Some other binding that works with ws-policy might handle this differently. This sort of 'policy handling' is what I had initially thought of as something that can be dealt by PolicyHandler classes. Now I find that how these classes look and what they do inside it entirely upto the binding and implementation types including when they are called i.e. during start or stop of the binding/implementatoin or during invocation of service methods etc. Given that the PolicyHandler is getting to be something internal to the binding or implementation do we ever have to define an SPI for it ? I am basically questioning the current implementation of defining PolicyHandler classes in a services sort of file in META-INF directory, loading and instantiating them, invoking them and so on. Is there a view-point I am missing here? Thanks -Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?
Hi Raymond, Thanks. Please see my questions / comments inline. - Venkat On Tue, Mar 25, 2008 at 9:01 PM, Raymond Feng [EMAIL PROTECTED] wrote: Please see my comments below. Thanks, Raymond -- From: Venkata Krishnan [EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 4:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Adding SPIs to handle policies, was: Re: Policy Handlers ? Hi Raymond, - How do applications add policy handlers ? For example if an application is wanting to provide some other flavour of logging or authentication how does it get a hook to do this ? Can you explain why we need application-level policy handlers? What is the scope/visibility of these handlers? Are they global to the hosting SCA node? IMO, we need to contribute policy handlers via tuscany extension modules instead of applications. I am imagining a scenario where an application would like to use its own flavour of logging or authentication mechanism. Is this a valid scenario and if so how can the application do this. Yes this handler is scoped to the node on which this application is running. - Also, looking at fixing https://issues.apache.org/jira/browse/TUSCANY-2125I am trying to keep the PolicyProvider mechanism as well as the JavaPolicyRuntimeWireProcessor thing co-existing so that we our bigbank demo going because that demo implements its own PolicyHandler for authorization function. One way of doing this could be if in the JavaPolicyRuntimeWireProcessor I am able to run thro all the interceptors in the invocation chain and see if it has a PolicyInteceptor that handles a particular policySet. If there is one, then I can skip adding the interceptor for this policyset. But I can't figure out a way to do this, since the PolicyInterceptor does not have a marker interface or a accessor method to get the PolicySet name that it handles. Is there a way out for this ? I don't think we should keep two machineries. Why should the java implementation runtime be responsible for the policy handling? What if there is no java component? Agreed about have a single mechanism for this. I was just about trying this out for this release alone since in the bigbank I have tried to use some custom authorization and so need to have a PolicyHandler for this. I'd certainly like to move to one consistent mechanism in the trunk. Can you help migrate the rest of the policy handlers into the Policy Provider SPI? If we see deficiencies, we can enhance the SPI. Thanks - Venkat On Sat, Mar 8, 2008 at 1:36 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I checked in changes that integrate the core with these new SPIs and converted logging and transaction policies under r634776. Can some of you look into the policy security too? Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Thursday, March 06, 2008 10:51 PM To: tuscany-dev@ws.apache.org Subject: Adding SPIs to handle policies, was: Re: Policy Handlers ? Hi, I'm adding the following SPIs to provide pluggable implementations to various policies in Tuscany. See [1]. 1) Define a PolicyProviderFactory that can be contributed to the ProviderFactoryExtensionPoint by policy extensions. This is similar to our BindingProviderFactory and ImplementationProviderFactory. 2) Define a PolicyProvider that can be created by PolicyProviderFactory for the following policy attach points: (component, reference, binding) for reference policies (component, service, binding) for service polices (component, implementation) for implementations Please note that we leave the PolicyProviderFactory to decide if it will create a PolicyProvider based on the resolved policy sets. For some policies, even if there is no intent declared, some default behaviors are desired. 3) Define a PolicyImplementor interface that can be optionally implemented by Binding/Implementaiton Provider to indicate if the binding/implementation extension will handle the policies by themselves. 4) The runtime will iterate through all the policies in the resolved policySets, if a policy is NOT implemented by binding/implementation provider (not on the PolicyImplementor.getImplementedPolices() list), then call PolicyProvider.createInterceptor() to add an interceptor. I also have the logging policy and transaction policy converted into these new SPIs locally. I'll check them in if we agree the SPIs are the right way to go. Thanks, Raymond [1] http://svn.apache.org/viewvc?rev=634558view=rev -- From: Raymond Feng [EMAIL PROTECTED] Sent: Thursday, November 29, 2007 9:01 AM To: tuscany-dev@ws.apache.org Subject: Re: Policy Handlers
Re: [SCA 1.2] Build issues in tools/maven/maven-definitions
Hi, Raymond is right. We don't need this transformer anymore. Am going to remove this from the trunk and branch. Thanks - Venkat On Sat, Mar 22, 2008 at 12:45 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I see the problem is fixed. Thanks. ++Vamsi On Sat, Mar 22, 2008 at 11:31 AM, Luciano Resende [EMAIL PROTECTED] wrote: Fixed as suggested by Raymond in both trunk and 1.2 branch. On Fri, Mar 21, 2008 at 10:24 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: The problem is noticed on trunk too. Can it be resolved in the same manner? ++Vamsi On Sat, Mar 22, 2008 at 10:47 AM, Luciano Resende [EMAIL PROTECTED] wrote: I have fixed the issue in the 1.2 Brach under revision # 639950. On Fri, Mar 21, 2008 at 10:12 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I hit that error two days ago. See http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29260.html ++Vamsi On Sat, Mar 22, 2008 at 8:37 AM, Luciano Resende [EMAIL PROTECTED] wrote: I seeing the following in both branch and trunk. Is anybody else seeing the same issue ? [INFO] Scanning for projects... [INFO] [INFO] Building Apache Tuscany SCA Definitions Shade Transformer for Distribution Bundle [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] [plugin:descriptor] [INFO] Using 2 extractors. [INFO] Applying extractor for language: java [INFO] Extractor for language: java found 0 mojo descriptors. [INFO] Applying extractor for language: bsh [INFO] Extractor for language: bsh found 0 mojo descriptors. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error extracting plugin descriptor: 'No mojo descriptors found in plugin.' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Fri Mar 21 20:06:00 PDT 2008 [INFO] Final Memory: 9M/65M [INFO] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping up with the dev list and the flood of JIRA messages
Hi, Yes its a bit distracting but then I find it ok since I'd like to know as much of the JIRAs as the other discussions. I don't filter them out thro mail filters coz am a bit apprehensive that at times I might entirely ignore what goes in there. The JIRAs are the ones I read out first and clear out of the way. I then run thro the other mails. - Venkat On Thu, Mar 20, 2008 at 3:10 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, Just curious, are people able to keep up with the list discussions in the middle of that flood of JIRA messages? Is everybody routing JIRAs to a separate folder? I'm finding it difficult to see through the traffic without doing that. Thoughts? Can we improve this to make it easier for people to follow? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor
Hi Sebastien, Here is a snippet from https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-transaction/src/main/resources/org/apache/tuscany/sca/policy/transaction/definitions.xml - definitions.xml - definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace= http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany= http://tuscany.apache.org/xmlns/sca/1.0; intent name=managedTransaction constrains=implementation descriptionUsed to indicate the transaction environment desired by a component implementation./description /intent intent name=managedTransaction.global description Used to indicate that a component implementation requires a managed global transaction. /description /intent intent name=managedTransaction.local description Used to indicate that a component implementation requires a managed local transaction. /description /intent .. --- Over here, the intents managedTransaction.global and managedTransaction.local are qualified intents with managedTransaction being the qualifiable intent. Since we have decided that the 'name' attribute of an 'intent' element is going to be NCName we end up forcing the qualifiable intent to also belong to the targetnamespace. If it belonged to namespace other than the target, then we'd have to deal with how we can represent this for example we could resort to ... intent name=tuscany:managedTransaction.global description Used to indicate that a component implementation requires a managed global transaction. /description /intent where we could say that managedTransaction is an intent defined under the namespace that the prefix 'tuscany' points to. But if we did this, the 'name' attribute must be read a QName which ends us in a contradiction. Thanks - Venkat On Thu, Mar 20, 2008 at 2:14 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks. Please find my comments inline. Not much though :) On Tue, Mar 18, 2008 at 3:46 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: 2) Unless I'm missing something, I don't think that you need to set the targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like it's already read as a QName from the XML stream (and this QName does not have to be in the current targetNamespace). First, I think that the Qualifiable intent needs to be in the current namespace since I I am not sure and the specs does not mention either, on how we could represent a qualified intent whose qualifiable intent belongs to a different namespace. So going with the assumption, in this context the qualifiable intent needs to be assigned the targetnamspace. Only then would it be correctly resolved during the resolution phase. Then I don't understand this code: PolicyIntentProcessor:74 qualifiableIntent.setName(getQNameValue(reader, policyIntentName.substring(0, qualifierIndex))); which reads a QName from the XMLStreamReader. Either (a) the qualifiableIntent is always in the target namespace, and then it's name is defined as an NCName and we shouldn't be trying to read it as a QName, or (b) the qualifiable intent name is actually defined as a QName and then it can belong to another namespace. If I understand it correctly, the policy-xsd defines these names as QNames, leading me to believe that (b) is the correct option. Given the context of disussion in this thread (a) seems to be what it should be. When cleaning up I missed out this line and I will fix it rightaway :(. But it ends up working because the name is reset with the targetnamespace later. Why I say (a) is because we'd then have consistency with all intent names being NCNames. Ofcourse, this means that the qualifiable intents should also be from the same namespace. If we allowed intent names to be QNames then (b) would apply and we have the freedom of having qualifiable intents belonging to a different namespace than the targetnamespace. But that will get us back to the bunch of issues that has been discussed in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28653.html. I guess it can't be that qualified intents alone have names that are QNames and the rest will be NCNames. Thanks - Venkat I'm still not sure I understand, I am assuming that when we read XML declarations: - declarations of type xyz name=anNCName get turned into a QName with ns = targetNamespace, localPart = anNCName - declarations of type xyz refToAnotherElement=QName just get the QName as-is, and do not assume that it belongs
definitions.xml and the SCA Domain over a distributed runtime
Hi, I am trying to run the bigbank sample from a distirbution and postulating a multiple contirbutions situation as follow : Let contribution CA and contribution CB each have their definitions.xml that defines some policysets. Now, can the composites defined in CB be able to use the policysets defined in CA ? If so, is there a discipline that needs to be followed in the order of adding these contributions i.e. should CA be added first and then CB ? In a distributed runtime, where CA and CB are added and deployed on two different nodes, would the node that has CB should try to pull down parts (just the defintions.xml) or whole of CA ? Finally, if definitions are going to be applicable to an entire domain, which I believe should be case, then how do we ensure that all definitions.xml contributed are first read and processed before composites are read and processed and how do we make this consolidate / aggregated definitions available to all nodes in the domain ? Thanks - Venkat
Re: [SCA 1.2] Release Branch is now available
Hi, I'd also like to make some very minor fixes related the definitions processing and composite pre-processing. They are very isolated and I will ensure they don't cause any trouble. I should be done with them today. Thanks - Venkat On Wed, Mar 19, 2008 at 4:19 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I consider 1.2 branch open for the next couple days while we still address JIRAs, but I would really like to enforce the don't break the build policy on the branch. OK, I'd like to check in small changes to allow tutorial/ nodes-jee/ catalog-webapp (and webapps packaged the same way) to work as an SCA node (as I was not setting up the node's classloader correctly). I'll be extra careful to not break the build. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: definitions.xml and the SCA Domain over a distributed runtime
Hi Simon, Yes, the defintions contribution by the extensions are available for all composites since they get picked up before the contributions get processed. After that things are governed by the order in which contributions are added. Composites in a contribution can use the policysets and intents that are a part of contributions that have been added ahead of it. The contributions that were loaded ahead cannot use the intents and policysets defined by contributions added later. In this context, I guess what you are observing about the workspace is precisely the way out. Let me take a look at that. Thanks. - Venkat On Wed, Mar 19, 2008 at 5:24 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkat I think that definitions.xml can be provided to Tuscany in two ways. Either in a contribution or in an extension library. I also think that the contents of definitions.xml files provided in either of these ways should be added to the domain wide pool of intents and policy sets and should be applied to composites in the domain as appropriate. Is this correct? I think at the moment the code only treats the definitions.xml added with extensions as being of domain scope. Definitions.xml added within a contribution are only processed in the context of that contribution Is my reading of the code correct? If I'm correct on these two points we need to fix the case where the definitions.xml file comes within a contribution. I think this is independent of whether a node running a composite is remote or not as a node may require multiple contributions in order to support a single composite, as you scenario suggests. I've put some comments in line. Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/workspace-admin/src/main/java/org/apache/tuscany/sca/workspace/admin/impl/DeployableCompositeCollectionImpl.java On Wed, Mar 19, 2008 at 10:11 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am trying to run the bigbank sample from a distirbution and postulating a multiple contirbutions situation as follow : Let contribution CA and contribution CB each have their definitions.xmlthat defines some policysets. Now, can the composites defined in CB be able to use the policysets defined in CA ? I think they should be able to . If so, is there a discipline that needs to be followed in the order of adding these contributions i.e. should CA be added first and then CB ? The code is like this at the moment when it comes to running a composite, i.e. the contributions have to be added in the right order, but it would be good if that were not the case. More importantly the implication is that we need to load ALL of the contributions that are required before any composites are processed. In a distributed runtime, where CA and CB are added and deployed on two different nodes, would the node that has CB should try to pull down parts (just the defintions.xml) or whole of CA ? It might need other things from CA so I would suggest that the whole of CA is given to the node. Finally, if definitions are going to be applicable to an entire domain, which I believe should be case, then how do we ensure that all definitions.xml contributed are first read and processed before composites are read and processed and how do we make this consolidate / aggregated definitions available to all nodes in the domain ? I think we have to look at the ideas in the workspace. Here all of the contributions are expected to be available before any nodes start running composites. I put some code into the workspace code to calculate the URI of all service bindings before any nodes run [1], take a look at the doGet() method. To work this relies on reading all of the contributions required to run the configured domain. This would seem to be a good point at which to pull all definitions.xml files out of all contributions and aggregate the policy sets before individual composites are processed. Thanks - Venkat
SCADefinitionsProvider changes
Hi, Under r638020 I have committed changes to introduce a SCADefinitionsProvider mechanism for Tuscany modules to contribute SCADefinitions. This was earlier being done following the convention of placing the definitions.xml file in the META-INF/services directory. Now this has changed into a programming model where tuscany modules that contribute intents, policysets, binding types, imple types, will implement a SCADefintionsProvider and register it in the meta-inf/services directory. Right now the tuscany modules that contribute to SCADefinitions such as policy-security, policy-logging, policy-transaction implement the providers as a reader of a definitions.xml file. Its not that this is the only option. Modules can choose their own means of providing a SCADefinitions to the runtime. Thanks - Venkat
Re: About StAXArtifactProcessor
Hi Sebastien
Please see my comments inline. Thanks.
- Venkat
On Fri, Mar 14, 2008 at 1:07 AM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
I set up the targetnamespace for the names of
Intents and PolicySets in the SCADefnsProcessor after an Intent or
PolicySet
has been read by a downstream processor.
Given how the policy code is currently organized that seems the simplest
option: SCADefinitionsProcessor is responsible for handling the
targetNamespace, and setting it in the qnames of the policy intents and
policySets that it adds to its lists of policy intents and policySets.
This could be much simplified though, with the following changes:
1) cosmetic but it'll help make that code more readable, change
if (extension != null) {
if ( extension instanceof Intent ) {
((Intent)extension).setName(new QName(targetNamespace,
((Intent)extension).getName().getLocalPart()));
to
if (extension instanceof Intent ) {
Intent intent = (Intent)extension;
intent.setName(new QName(targetNamespace,
intent.getName().getLocalPart()));
as the double 'if' is not necessary, and a local variable will help
avoid repeating the casts.
Yes :) this if looks really crazy now that I am looking back at it. Will
correct it.
2) Unless I'm missing something, I don't think that you need to set the
targetNamespace of QualifiedIntent.qualifiableIntents, as it looks like
it's already read as a QName from the XML stream (and this QName does
not have to be in the current targetNamespace).
First, I think that the Qualifiable intent needs to be in the current
namespace since I I am not sure and the specs does not mention either, on
how we could represent a qualified intent whose qualifiable intent belongs
to a different namespace. So going with the assumption, in this context the
qualifiable intent needs to be assigned the targetnamspace. Only then would
it be correctly resolved during the resolution phase.
3) Finally a bigger change: it seems that you have StAXArtifactProcessor
extensions for Intent, PolicySet etc... but these elements are not
extensions, so you didn't have to go through all that, as they are part
of the SCA core namespace. So, a much simpler approach would be to just
read them in, directly from SCADefinitionsProcessor. This is similar to
CompositeProcessor for example, if we had made a separate processor for
Component, we would have had to pass a lot of context to it.
In short, it looks like you've created a maze of processor extensions
for things that didn't have to be extensions, and are now wondering how
to pass context through this maze :)
The solution is simple, just don't make them extensions :) You can
either move this code to SCADefinitionsProcessor.read() or to private
methods of SCADefinitionsProcessor to which you'll be able to pass
whatever context you need.
Hope this helps.
--
Jean-Sebastien
This is the the first temptation that I went thro i.e. to merge all of this
processing into the SCADefinitionsProcessor similar to the
CompositeProcessor. We did start with all of this in a single module but
somewhere down the line we decided to split them all into different modules
(can't quite remember and pull up that discussion around this). Ok, let me
get them back together for now.
However, I am not sure how far we could go with this. You will agree that
the 'read' and 'resolve' methods of the CompositeProcessor are quite bulky
running to pages and contains quite a bit of state management.
- Venkat
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for binding config in definitions.xml
Yes that makes clear simple sense. Really lost it, I must say. Thanks :)
- Venkat
On Fri, Mar 14, 2008 at 1:19 AM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hmm... seems like I am missing something then... alright let me ask you
this
way...
if SCADefintions is going to contain a list of JMSBinding definitions..
won't in end up something like this...
public interface SCADefinitions {
ListIntent getPolicyIntents();
ListJMSBinding getJmsBindingDefs();
...
}
Now to get the class 'JMSBinding' mustn't the definitions module include
the
binding-jms module as dependency ?
No :) like Service lists Bindings (including JMSBindings) without a
dependency on the JMS binding module.
You just need to define SCADefinitions as follows:
public interface SCADefinitions {
ListIntent getPolicyIntents();
ListBinding getBindings();
}
Does this helps?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
Oops... my mistake... am fixing this rightaway. Apologies. - Venkat On Mon, Mar 12, 0008 at 6:07 PM, Continuum VMBuild Server [EMAIL PROTECTED] wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=64271projectId=277 Build statistics: State: Failed Previous State: Ok Started at: Wed 12 Mar 2008 05:24:07 -0700 Finished at: Wed 12 Mar 2008 05:24:56 -0700 Total time: 49s Build Trigger: Schedule Build Number: 111 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: svkrish @ Wed 12 Mar 2008 05:09:58 -0700 Comment: cleaning up policy computation and fixing holes in policy inheritance in operations Files changed: /incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/BindingPolicyComputer.java ( 636290 ) /incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeWireBuilderImpl.java ( 636290 ) /incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/ImplementationPolicyComputer.java ( 636290 ) /incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/PolicyComputer.java ( 636290 ) /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/BaseAssemblyProcessor.java ( 636290 ) /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/CompositeProcessor.java ( 636290 ) /incubator/tuscany/java/sca/modules/implementation-java-xml/src/test/java/org/apache/tuscany/sca/implementation/java/xml/ReadTestCase.java ( 636290 ) /incubator/tuscany/java/sca/modules/implementation-java-xml/src/test/resources/org/apache/tuscany/sca/implementation/java/xml/definitions.xml ( 636290 ) /incubator/tuscany/java/sca/modules/policy/src/main/java/org/apache/tuscany/sca/policy/util/PolicyValidationUtils.java ( 636290 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1047 Failures: 0 Total time: 943372 Output: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Tuscany SCA Implementation Project [INFO] Apache Tuscany SCA Implementation Modules [INFO] Apache Tuscany SCA Extensibility [INFO] Apache Tuscany SCA Policy Model [INFO] Apache Tuscany SCA Interface Model [INFO] Apache Tuscany SCA Assembly Model [INFO] Apache Tuscany SCA Assembly Model Java DSL [INFO] Apache Tuscany SCA Assembly Model XML Schemas [INFO] Apache Tuscany SCA Definitions [INFO] Apache Tuscany SCA Contribution Model [INFO] Apache Tuscany SCA Policy XML Model [INFO] Apache Tuscany SCA Definitions XML Model [INFO] Apache Tuscany SCA API [INFO] Apache Tuscany SCA Core SPI [INFO] Apache Tuscany SCA Namespace Import/Export Model [INFO] Apache Tuscany SCA Java Import/Export Model [INFO] Apache Tuscany SCA XML Contribution Model [INFO] Apache Tuscany SCA Resource Import/Export Model [INFO] Apache Tuscany SCA Contribution Model Implementation [INFO] Apache Tuscany SCA XML Assembly Model [INFO] Apache Tuscany SCA Java Interface Model [INFO] Apache Tuscany SCA Core Runtime [INFO] Apache Tuscany SCA Domain API [INFO] Apache Tuscany SCA Domain [INFO] Apache Tuscany SCA Node API [INFO] Apache Tuscany SCA Node [INFO] Apache Tuscany SCA Default Binding Model [INFO] Apache Tuscany SCA Default Binding XML Model [INFO] Apache
Re: Splitting up the bigbank demo
.description.OutInAxisOperationClient.executeImpl( OutInAxisOperation.java:211) at org.apache.axis2.client.OperationClient.execute( OperationClient.java:163) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget( Axis2BindingInvoker.java:118) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:89) ... 36 more On Mon, Mar 10, 2008 at 11:18 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Luciano, I have split up the bigbank demo into two. 1) bigbank and 2) bigbank-account. The bigbank is the facade to the users and the bigbank-account is the account management module used by the bigbank. I have also pulling in policies and security - whatever that has been working with the secure-bigbank demo. Now that there are two contributions - bigbank and bigbank-account, am a bit lost getting this going with multiple contributions. I have looked up the itests for imports and exports and followed as much the same for this demo, but things don't seem to work. Could you please take a quick look into this and let me know the thing I am missing in all of this ? I have commented out the bigbank demo from the build though it seems to build successfully locally. I will include it back after I have got it to run as a demo. Thanks - Venkat -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About StAXArtifactProcessor
Hi Luciano, Here is what I am facing... - The targetnamespace attribute is a part of the sca:definitions element and that is read by the SCADefnProcessor. - For subsequent elements such as Intents and Policysets in the definitions.xml, the SCADefnsProcessor delegates to the extension processor which inturn ends up calling the IntentProcessor (to process Intents) or the PolicySetProcessor (to process PolicySets). But it happens that the Intents and PolicySets should inherit the 'targetnmaespace' so that its made to be a part of their name. So it seems like it would have been good for the SCADefnsProcessor to pass this value down. Since this is not possible, I set up the targetnamespace for the names of Intents and PolicySets in the SCADefnsProcessor after an Intent or PolicySet has been read by a downstream processor. I am not so comfortable with this. Does that give you some picture ? Thanks - Venkat On Tue, Mar 11, 2008 at 6:32 AM, Luciano Resende [EMAIL PROTECTED] wrote: Maybe you could describe a little more what is the issue you are having, and we could try helping finding another solution for your issue, particularly related to targetNamespace, as it might be available trough the parser API. Also, I usually try to avoid context objects, as they usually grow out of control very fast causing various side effects. On Mon, Mar 10, 2008 at 10:39 AM, Luciano Resende [EMAIL PROTECTED] wrote: I was going to take a quick look at this, but before I do, let me ask if svn revision #635604 is related to the issue you are asking here. On Mon, Mar 10, 2008 at 2:40 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I recently faced a situation where I wished to passed some context from one StAXArtifact Processor to others down the chain. More specifically, to get the 'targetNamespace' of the definitions.xml file apply to PoliyIntent and PolicySet names, I wished to pass the 'targetNamespace' value from the Definitions Processor (which is where it is read) down to the PolicyIntent and PolicySet processors. I could not figure out a way to do this. Am I missing something here or would it make sense to add an argument named 'context' to the read methods of our StAXProcessor ? I guess there could be other situations when we might need some information from parent element to be passed down. Thoughts ? Thanks - Venkat -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get a list of effective policySets for a given operation?
Hi Raymond, SCA Artifacts that can have operations configured on them implement the 'OperationsConfigurator' interface. This interface has a method that will return a list of 'ConfiguredOperation' and each element in this list represents an operation that has been configured for policies. The 'ConfiguredOperation' extends a PolicySetAttachPoint and hence you should be able to get the list of policysets from this. Yes, we do aggregate the intents and policysets upto the operation level. Let me go and add a test for the scenario you have mentioned here, in the itest-policy. I will post back once that is done Thanks - Venkat On Tue, Mar 11, 2008 at 12:02 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, If I have the (component, service/reference, binding, operation) model instances handy, how can I get a list of effective policySets for the operation? Are we consolidating the declarations at different levels to the binding? We can use the following example (I intentionally omit the @requires). component name=MyComponent policySets=ns1:PS1 service name=MyService policySets=ns1:PS2 operation name=op1 policySets=ns1:PS3 binding.xyz policySets=ns1:PS4 ns2:PS5 operation name=op1 policySets=ns1:PS6 /binding.xyz /service /component Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get a list of effective policySets for a given operation?
Hi Raymond, I found a few holes that had crept into this part with the recent 'applicablePolicySets' related work. Am fixing them and should be done anytime. Will not hold you back from your work for long. Thanks - Venkat On Tue, Mar 11, 2008 at 12:47 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Raymond, SCA Artifacts that can have operations configured on them implement the 'OperationsConfigurator' interface. This interface has a method that will return a list of 'ConfiguredOperation' and each element in this list represents an operation that has been configured for policies. The 'ConfiguredOperation' extends a PolicySetAttachPoint and hence you should be able to get the list of policysets from this. Yes, we do aggregate the intents and policysets upto the operation level. Let me go and add a test for the scenario you have mentioned here, in the itest-policy. I will post back once that is done Thanks - Venkat On Tue, Mar 11, 2008 at 12:02 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, If I have the (component, service/reference, binding, operation) model instances handy, how can I get a list of effective policySets for the operation? Are we consolidating the declarations at different levels to the binding? We can use the following example (I intentionally omit the @requires). component name=MyComponent policySets=ns1:PS1 service name=MyService policySets=ns1:PS2 operation name=op1 policySets=ns1:PS3 binding.xyz policySets=ns1:PS4 ns2:PS5 operation name=op1 policySets=ns1:PS6 /binding.xyz /service /component Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get a list of effective policySets for a given operation?
Hi Raymond, Yes, we create 'configuredOperations' only for those that have been explicitly configured for with some policysetting. I was expecting that the binding/implementation extension or the WireProcessor or whatever mechanism that is which links up policy handlers, will effect all policysets on the binding instance for all operations in addition to whatever is specified for specific operations. I did toy a bit with the idea of creating ConfiguredOperations for all operations in a contract, but wondered if it was going to get too heavy. To get a list of effective policysets, the getPolicySets() alone should be used and not the getApplicablePolicySets(). Thanks - Venkat On Tue, Mar 11, 2008 at 9:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: By debugging, I only see the explicitly configured operations on the OperationsConfigurator.getConfiguredOperations(). Should we populate all operations? Otherwise, we probably need to provide a utility to get effective policySets for a given operation like: PolicyUtil.getEffectivePolicySets(Component, Contract, Binding, Operation); PolicyUtil.getEffectivePolicySets(Component, Implementation, Operation); Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 8:59 AM To: tuscany-dev@ws.apache.org Subject: Re: How can I get a list of effective policySets for a given operation? What about an operation that is not explicitly customized by the operation element? For example, if I have this: component ... policySets=ns1:PS1 service ... policySets=ns1:PS2 binding.xyz ... policuSets=ns1:PS3/ /service /component Can I do the the following? OperationsConfigurator ops = (OperationsConfigurator) binding; ListConfiguredOperation cops= ops.getConfiguredOperations); If op1 is an operation on the service interface, is op1 on the cops list? If yes, do I get ns1:PS1, ns2:PS2 and ns1:PS3 for op1? Should I use PolicyAttachPoint.getPolicySets() or getApplicablePolicySets() to get the list of effective policy sets? Thanks, Raymond -- From: Venkata Krishnan [EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 12:17 AM To: tuscany-dev@ws.apache.org Subject: Re: How can I get a list of effective policySets for a given operation? Hi Raymond, SCA Artifacts that can have operations configured on them implement the 'OperationsConfigurator' interface. This interface has a method that will return a list of 'ConfiguredOperation' and each element in this list represents an operation that has been configured for policies. The 'ConfiguredOperation' extends a PolicySetAttachPoint and hence you should be able to get the list of policysets from this. Yes, we do aggregate the intents and policysets upto the operation level. Let me go and add a test for the scenario you have mentioned here, in the itest-policy. I will post back once that is done Thanks - Venkat On Tue, Mar 11, 2008 at 12:02 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, If I have the (component, service/reference, binding, operation) model instances handy, how can I get a list of effective policySets for the operation? Are we consolidating the declarations at different levels to the binding? We can use the following example (I intentionally omit the @requires). component name=MyComponent policySets=ns1:PS1 service name=MyService policySets=ns1:PS2 operation name=op1 policySets=ns1:PS3 binding.xyz policySets=ns1:PS4 ns2:PS5 operation name=op1 policySets=ns1:PS6 /binding.xyz /service /component Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for binding config in definitions.xml
Hmm... seems like I am missing something then... alright let me ask you this
way...
if SCADefintions is going to contain a list of JMSBinding definitions..
won't in end up something like this...
public interface SCADefinitions {
ListIntent getPolicyIntents();
ListJMSBinding getJmsBindingDefs();
...
}
Now to get the class 'JMSBinding' mustn't the definitions module include the
binding-jms module as dependency ?
- Venkat
On Tue, Mar 11, 2008 at 9:23 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hi Sebastien,
If the SCADefinitions model must hold jms binding definitions, I guess
it
must add the jms binding as a dependency.
Good news, it doesn't need to :)
This is similar to the assembly model holding JMS binding definitions
for example, without having a dependency on the JMS binding.
Or am I missing something?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I get a list of effective policySets for a given operation?
Hi Raymond, I have cleaned up and fixed somethings for operations in r636059. There is one more thing related to validation that needs to be fixed and I shall do it tomorrow. Its basically about operations defined on services need to be inherited by the service bindings. But then it could happen that some operations have intents or policysets that don't apply to a binding. I indend to the following : - - validate the intents specified on the service operation against the binding that is inheriting it. Omit intents that do not apply to the binding. If it happens that no intents specified on the service operation applies then this operation will not be inherited. A similar thing will be done for policysets as well. Right now, all operations on the services are copied over to the bindings. Where the binding itself has specified an operation, on the intents and policysets from the service operation is added. Thanks - Venkat On Tue, Mar 11, 2008 at 10:16 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Raymond, Yes, we create 'configuredOperations' only for those that have been explicitly configured for with some policysetting. I was expecting that the binding/implementation extension or the WireProcessor or whatever mechanism that is which links up policy handlers, will effect all policysets on the binding instance for all operations in addition to whatever is specified for specific operations. I did toy a bit with the idea of creating ConfiguredOperations for all operations in a contract, but wondered if it was going to get too heavy. To get a list of effective policysets, the getPolicySets() alone should be used and not the getApplicablePolicySets(). Thanks - Venkat On Tue, Mar 11, 2008 at 9:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: By debugging, I only see the explicitly configured operations on the OperationsConfigurator.getConfiguredOperations(). Should we populate all operations? Otherwise, we probably need to provide a utility to get effective policySets for a given operation like: PolicyUtil.getEffectivePolicySets(Component, Contract, Binding, Operation); PolicyUtil.getEffectivePolicySets(Component, Implementation, Operation); Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 8:59 AM To: tuscany-dev@ws.apache.org Subject: Re: How can I get a list of effective policySets for a given operation? What about an operation that is not explicitly customized by the operation element? For example, if I have this: component ... policySets=ns1:PS1 service ... policySets=ns1:PS2 binding.xyz ... policuSets=ns1:PS3/ /service /component Can I do the the following? OperationsConfigurator ops = (OperationsConfigurator) binding; ListConfiguredOperation cops= ops.getConfiguredOperations); If op1 is an operation on the service interface, is op1 on the cops list? If yes, do I get ns1:PS1, ns2:PS2 and ns1:PS3 for op1? Should I use PolicyAttachPoint.getPolicySets() or getApplicablePolicySets() to get the list of effective policy sets? Thanks, Raymond -- From: Venkata Krishnan [EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 12:17 AM To: tuscany-dev@ws.apache.org Subject: Re: How can I get a list of effective policySets for a given operation? Hi Raymond, SCA Artifacts that can have operations configured on them implement the 'OperationsConfigurator' interface. This interface has a method that will return a list of 'ConfiguredOperation' and each element in this list represents an operation that has been configured for policies. The 'ConfiguredOperation' extends a PolicySetAttachPoint and hence you should be able to get the list of policysets from this. Yes, we do aggregate the intents and policysets upto the operation level. Let me go and add a test for the scenario you have mentioned here, in the itest-policy. I will post back once that is done Thanks - Venkat On Tue, Mar 11, 2008 at 12:02 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, If I have the (component, service/reference, binding, operation) model instances handy, how can I get a list of effective policySets for the operation? Are we consolidating the declarations at different levels to the binding? We can use the following example (I intentionally omit the @requires). component name=MyComponent policySets=ns1:PS1 service name=MyService policySets=ns1:PS2 operation name=op1 policySets=ns1:PS3 binding.xyz policySets=ns1:PS4 ns2:PS5 operation name=op1 policySets=ns1:PS6 /binding.xyz /service /component Thanks, Raymond
About StAXArtifactProcessor
Hi, I recently faced a situation where I wished to passed some context from one StAXArtifact Processor to others down the chain. More specifically, to get the 'targetNamespace' of the definitions.xml file apply to PoliyIntent and PolicySet names, I wished to pass the 'targetNamespace' value from the Definitions Processor (which is where it is read) down to the PolicyIntent and PolicySet processors. I could not figure out a way to do this. Am I missing something here or would it make sense to add an argument named 'context' to the read methods of our StAXProcessor ? I guess there could be other situations when we might need some information from parent element to be passed down. Thoughts ? Thanks - Venkat
Splitting up the bigbank demo
Hi Luciano, I have split up the bigbank demo into two. 1) bigbank and 2) bigbank-account. The bigbank is the facade to the users and the bigbank-account is the account management module used by the bigbank. I have also pulling in policies and security - whatever that has been working with the secure-bigbank demo. Now that there are two contributions - bigbank and bigbank-account, am a bit lost getting this going with multiple contributions. I have looked up the itests for imports and exports and followed as much the same for this demo, but things don't seem to work. Could you please take a quick look into this and let me know the thing I am missing in all of this ? I have commented out the bigbank demo from the build though it seems to build successfully locally. I will include it back after I have got it to run as a demo. Thanks - Venkat
Re: Support for binding config in definitions.xml
Hi Sebastien, If the SCADefinitions model must hold jms binding definitions, I guess it must add the jms binding as a dependency. On the other hand the jms binding already brings in the 'definitions' module as a downsteam dependency. I guess that some cleaning up of the Contribution might ease a bit of things. I am wondering if the 'contribution' module should be devoid of any dependency on definitions, policy and assembly. I am going to give this a stab now. Thanks. - Venkat On Tue, Mar 11, 2008 at 5:47 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Ant, I suppose this is going to simply use the StAX processor that we currently have for jms binding. That being the case I see there is going to be circular dependency issues I may be able to help with the circular dependencies issues, could you help me understand what circular dependencies you are seeing? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
Ok, I am going to fix this as follows : - - am keeping the name in the PolicyIntent and PolicySet model as QName and assign for the namespaceURI, the targetNamespace specified for the defintions.xml in question - elsewhere in the definitions.xml where the intents defined here are referenced, such as in Profile Intents or PolicySets, the intent names will be used in qualified form with an appropriate prefix that points to the targetnamespace. - Venkat On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler [EMAIL PROTECTED] wrote: See below. On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thinking a bit futher about this, I am wondering what would we expect for 'requires' attribute of a ProfileIntent. Do we assume that the intents required by the Profile Intent should also belong to the same namespace as the Profile Intent ? I guess not. Right. @requires takes a list of QNames so it can be composed of intents in various namespaces. I can see someone wanting to create a profile intent in their own namespace that uses intents in other standard namespaces. How about the case of the 'provides' attribute for PolicySets ? Do we say these must be QNames strictly even if the PolicySet was just about providing for intents in the same namespace ? @provides is also a list of QNames so the usual rules for the prefix should be followed. If there is no prefix, then xmlns is used by default (not targetNamespace). If you want @provides to refer to an intent that's defined in the same definitions.xml, you need to define a namespace prefix for it (with the same value as targetNamespace) and use the prefix appropriately. Am just about trying to understand if the targetnamespace is to be applied only to Intent and PolicySet names and not to where they might be referrred within the same definitions.xml file. - Venkat On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents
Re: Support for binding config in definitions.xml
Hi Ant, I suppose this is going to simply use the StAX processor that we currently have for jms binding. That being the case I see there is going to be circular dependency issues If this is sorted out, I guess then the definitions processor will just about be able to read this instance of binding.jms and add it to the model resolver. Then the binding instance that is referring to this in the composite should resolve this with the model resolver. Thanks - Venkat On Sat, Mar 8, 2008 at 4:32 PM, ant elder [EMAIL PROTECTED] wrote: I'd like to add support for the request/response Connection attributes of the JMS binding (see lines 119 and 123 of the JMS binding spec) and wondered if the existing code in the policy framework would be able to support this today or if I'd need to extend it with some new SPI or something? These attributes enable defining jms binding configurations in a definitions.xml file and referring to those from the binding in a composite, eg: composite service binding.jms requestConnection=StockQuoteService / /service . . . /composite and definitions binding.jms name=StockQuoteService initialContextFactory= org.apache.activemq.jndi.ActiveMQInitialContextFactory jndiURL=tcp://localhost:61616 destination name=StockQuoteServiceQueue create=never/ connectionFactory name=StockQuoteServiceQCF create=never/ /binding.jms /definitions Does anyone who know the policy code have any comments, suggestions or hints? ...ant
Re: [Spec Related] 'provides' attribute in PolicySet
I have fixed this under r634975. Thanks - Venkat On Sat, Mar 8, 2008 at 3:33 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok, I am going to fix this as follows : - - am keeping the name in the PolicyIntent and PolicySet model as QName and assign for the namespaceURI, the targetNamespace specified for the defintions.xml in question - elsewhere in the definitions.xml where the intents defined here are referenced, such as in Profile Intents or PolicySets, the intent names will be used in qualified form with an appropriate prefix that points to the targetnamespace. - Venkat On Sat, Mar 8, 2008 at 3:40 AM, Greg Dritschler [EMAIL PROTECTED] wrote: See below. On Fri, Mar 7, 2008 at 12:11 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Thinking a bit futher about this, I am wondering what would we expect for 'requires' attribute of a ProfileIntent. Do we assume that the intents required by the Profile Intent should also belong to the same namespace as the Profile Intent ? I guess not. Right. @requires takes a list of QNames so it can be composed of intents in various namespaces. I can see someone wanting to create a profile intent in their own namespace that uses intents in other standard namespaces. How about the case of the 'provides' attribute for PolicySets ? Do we say these must be QNames strictly even if the PolicySet was just about providing for intents in the same namespace ? @provides is also a list of QNames so the usual rules for the prefix should be followed. If there is no prefix, then xmlns is used by default (not targetNamespace). If you want @provides to refer to an intent that's defined in the same definitions.xml, you need to define a namespace prefix for it (with the same value as targetNamespace) and use the prefix appropriately. Am just about trying to understand if the targetnamespace is to be applied only to Intent and PolicySet names and not to where they might be referrred within the same definitions.xml file. - Venkat On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata
Re: [Spec Related] 'provides' attribute in PolicySet
Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and policyset defined in a specific definitions.xml is the value of the 'targetNamespace' attribute of the 'definitions' element. Is this right? Typically, all declarations of name elements for elements which live in a particular namespace are defined in the XSDs as NCNames (see Composite, for example). It is usual for the targetNamespace to declare the namespace into which the elements are being declared. So, in this case for the intents policySets, you're right, we'd expect the targetNamespace to be used. Anything else would look distinctly odd. - Can a qualified intent have its qualifiable parent intent belonging to a different targetnamespace. If so how would this be evident from the name of the qualified intent? For example if there is an intent a:intentOne and then there is a qualified intent over this like intentOne.intentTwo - how is to be inferred that intentOne belongs to a different namespace Hmm, we had never intended this. I'd expect the qualified intent and its qualifiers to be in the same namespace. It's not outlawed for them to be in different namespaces, but I've no idea how you would express the definition to indicate this. Thanks - Venkat Hope this helps, Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
Thinking a bit futher about this, I am wondering what would we expect for 'requires' attribute of a ProfileIntent. Do we assume that the intents required by the Profile Intent should also belong to the same namespace as the Profile Intent ? I guess not. How about the case of the 'provides' attribute for PolicySets ? Do we say these must be QNames strictly even if the PolicySet was just about providing for intents in the same namespace ? Am just about trying to understand if the targetnamespace is to be applied only to Intent and PolicySet names and not to where they might be referrred within the same definitions.xml file. - Venkat On Fri, Mar 7, 2008 at 10:09 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Ok. I seemed to have lost the plot down the line. Now that I have re-read Mike's explanation in this thread, it does seem like you have a point. - Venkat On Fri, Mar 7, 2008 at 9:49 PM, Greg Dritschler [EMAIL PROTECTED] wrote: No. The type of @name is either NCName or QName. It cannot be both. If it is an NCName, then it cannot have a namespace prefix; the namespace is always the targetNamespace. If it is a QName, then it can have a namespace prefix; if it does not have a prefix then it uses the default namespace from xmlns. The spec says @name is a QName, but I thought from the above discussion that we had concluded this is not correct and that it should be an NCName. On Fri, Mar 7, 2008 at 1:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and policyset defined in a specific definitions.xml is the value of the 'targetNamespace' attribute of the 'definitions' element. Is this right? Typically, all declarations of name elements for elements which live in a particular namespace are defined in the XSDs as NCNames (see Composite, for example). It is usual for the targetNamespace to declare the namespace into which the elements are being declared. So, in this case for the intents policySets, you're right, we'd expect the targetNamespace to be used. Anything else would look distinctly odd. - Can a qualified intent have its qualifiable parent intent belonging to a different targetnamespace. If so how would this be evident from the name of the qualified intent? For example if there is an intent a:intentOne and then there is a qualified intent over this like intentOne.intentTwo - how is to be inferred that intentOne belongs to a different namespace Hmm, we had never intended this. I'd expect the qualified intent and its qualifiers to be in the same namespace. It's not outlawed for them to be in different namespaces, but I've no idea how you would express the definition to indicate this. Thanks - Venkat Hope this helps, Yours, Mike
Re: [DISCUSS] Validate applicable policySets for a given policy set attachpoint
Hi Raymond, I did start with the write option but ended up with trouble trying to access the write methods from the Builders where the PolicySets get matched. I brought this up for discussion in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html where Sebastien suggested that we move this to a 'preprocessing' phase and that how I do understand your concerns about the dependence this brings into ContributionServiceImpl which is something I anyways planned to clean up by moving all of it to CompositeProcessor. Thanks - Venkat On Thu, Mar 6, 2008 at 6:11 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I'm looking into the policy framework code. I found it very strange that we have some code in the ContributionServiceImpl to modify the composite file and attach tuscany attributes to the XML document to keep the applicable policy sets for a given PolicySetAttachPoint. The later is calculated by applying the PolicySet.getAppliesTo() XPath. The following shows the altered XML: component name=MyComponent tuscany:applicablePolicySets=... tuscany:policySets=... ... /component IMO, the ContributionService should be independent of any artifact types. Why do we need to transform the SCA composite file for the policy validation purpose in the contribution service? I understand it's a bit difficult to apply XPath for StAX streams. Can we do the following instead? 1) Use the StAXArtifactProcessor.write() method to produce a DOM representation of the PolicySetAttachPoint so that we can apply the XPath given by PolicySet.getAppliesTo(). 2) Remove the getApplicablePolicySets() in the PolicySetAttachPoint model. The validation should be handled when we configure/build the composite. There is no need to pre-calculate the applicable policy sets. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Validate applicable policySets for a given policy set attachpoint
Hi, Right but this brings in a circular dependency isn't it ? Thanks. - Venkat On Thu, Mar 6, 2008 at 10:27 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, It should be fairly simple to make StAXArtifactProcessorExtensionPoint available to CompositeBuilderImpl. With that, we can find the corresponding StAXArtifactProcessor for a given PolicySetAttachPoint. For example, if you try to match a component service with an XPath, you can do: StAXArtifactProcessor p = staxArtifactProcessorExtensionPoint.getProcessor(ComponentService.class); p.write(componentReference, staxWriter); Then you can build a DOM from the staxWriter to apply XPath. Am I missing something? Thanks, Raymond -- From: Venkata Krishnan [EMAIL PROTECTED] Sent: Thursday, March 06, 2008 2:52 AM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Validate applicable policySets for a given policy set attachpoint Hi Raymond, I did start with the write option but ended up with trouble trying to access the write methods from the Builders where the PolicySets get matched. I brought this up for discussion in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html where Sebastien suggested that we move this to a 'preprocessing' phase and that how I do understand your concerns about the dependence this brings into ContributionServiceImpl which is something I anyways planned to clean up by moving all of it to CompositeProcessor. Thanks - Venkat On Thu, Mar 6, 2008 at 6:11 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I'm looking into the policy framework code. I found it very strange that we have some code in the ContributionServiceImpl to modify the composite file and attach tuscany attributes to the XML document to keep the applicable policy sets for a given PolicySetAttachPoint. The later is calculated by applying the PolicySet.getAppliesTo() XPath. The following shows the altered XML: component name=MyComponent tuscany:applicablePolicySets=... tuscany:policySets=... ... /component IMO, the ContributionService should be independent of any artifact types. Why do we need to transform the SCA composite file for the policy validation purpose in the contribution service? I understand it's a bit difficult to apply XPath for StAX streams. Can we do the following instead? 1) Use the StAXArtifactProcessor.write() method to produce a DOM representation of the PolicySetAttachPoint so that we can apply the XPath given by PolicySet.getAppliesTo(). 2) Remove the getApplicablePolicySets() in the PolicySetAttachPoint model. The validation should be handled when we configure/build the composite. There is no need to pre-calculate the applicable policy sets. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
Hi Greg, Yes, it seems that when the PolicySet name is a NCName it does not assume the targetNamespace as its namespace. I shall fix this rightaway. But then, I suppose its ok for a PolicySet name to be a QName when it is desired to have the PolicySet take a namespace other than the targetNamespace. i.e. all policysets in a definitions.xml need not belong to the same namespace. Do you share this thought ? Thanks - Venkat If a PolicySet name does not have a prefix it assumes the targetNamespace. If a On Thu, Mar 6, 2008 at 10:50 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Venkat, I was trying some stuff with policy sets and noticed the QName resolution wasn't working as I expected. Specifically the targetNameSpace attribute of the definitions.xml document doesn't appear to be used to form the QName of the policy sets within. I recalled we had discussed this in this old thread. PolicySetProcessor does this: policySet.setName(getQName(reader, NAME)); So it is trying to treat the @name attribute as a QName. I thought we had concluded it is an NCName. For comparison CompositeProcessor does this: composite.setName(new QName(getString(reader, TARGET_NAMESPACE), getString(reader, NAME))); This is what I thought would happen based on this discussion. On Mon, Aug 20, 2007 at 7:36 AM, Mike Edwards [EMAIL PROTECTED] wrote: Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and policyset defined in a specific definitions.xml is the value of the 'targetNamespace' attribute of the 'definitions' element. Is this right? Typically, all declarations of name elements for elements which live in a particular namespace are defined in the XSDs as NCNames (see Composite, for example). It is usual for the targetNamespace to declare the namespace into which the elements are being declared. So, in this case for the intents policySets, you're right, we'd expect the targetNamespace to be used. Anything else would look distinctly odd. - Can a qualified intent have its qualifiable parent intent belonging to a different targetnamespace. If so how would this be evident from the name of the qualified intent? For example if there is an intent a:intentOne and then there is a qualified intent over this like intentOne.intentTwo - how is to be inferred that intentOne belongs to a different namespace Hmm, we had never intended this. I'd expect the qualified intent and its qualifiers to be in the same namespace. It's not outlawed for them to be in different namespaces, but I've no idea how you would express the definition to indicate this. Thanks - Venkat Hope this helps, Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, To update, I have split the bigbank into bigbank and bigbank-account to show the distribution of policies across contributions. I just about have trouble with the things that need to be imported / exported across these two. I'd prob. need Luciano's help to get over this. The other thing I have started to do is the 'alwaysApplicablePolicySets' that was suggested. There weren't to many things to do for this and I am right now trying to find a way to test this in the itest-policy. - Venkat On Thu, Feb 21, 2008 at 11:35 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, Thanks for looking it up and providing opinions. All of them sound good to me and I will get onto them after am done with some things am fixing with policy annotations and an iTest for policy. Just the one thing about the PasswordCallBackHandler. It only meant to domonstrate that its a gateway to your user registries. Agreed that this might be taken very literally by some users. So, do you suggest that I interface with some user registry in the CallBackHandlers ? If so can a simple Hashmap based user registry do or would you like some LDAP based user registry integration here? Thanks. - Venkat On Wed, Feb 20, 2008 at 6:38 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, I have made the changes to the secure-bigbank demo. Let me know if there is something that looks odd and not practical in a real world scenario. Thanks. I'm starting to like it :) I have a few more suggestions: - Merge it into the main bigbank scenario. - Place definitions.xml files in different contributions to show that policies can be configured externally. - Remove the CallbackHandlers as hardcoding a password in a piece of code in the contribution is not what I'd call practical :) Another suggestion to make policies easier to use: Support external attachment of a PolicySet to a composite element independent of the presence of intents. Here are some use cases: - configure confidentiality at deployment time, without having to go back and change the application composite to add intents or policySets. - configure the number of HTTP connections on a reference [1], over time when traffic increases, again with no change to the composite. External policy attachment is starting to be discussed in the OASIS policy spec workgroup [2], but I was thinking that we could start simple with just an additional attribute on PolicySet for now, like this: policySet alwaysAppliesTo=xpath ... !-- typical policySet configuration here -- /policySet The policySet would be applied to the composite elements matching the xpath in alwaysAppliesTo, independent of the presence or not of any intents. Thoughts? [1] http://marc.info/?l=tuscany-userm=120051348720777 [2] http://www.osoa.org/jira/browse/POLICY-15 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to define a customizable value for an intent or policy?
Hi, I am just about going to check in what Sebastien is suggesting here. So you could define a PolicySet as follows : - sca:policySet name=tuscany:Axis2ConnectionsConfPolicySet provides= appliesTo=sca:binding.ws tuscany:alwaysAppliesTo=sca:[EMAIL PROTECTED]'SomeName'] ConnectionsConf NoOfConnections 100 /NoOfConnections TimeOut30/TimeOut /ConnectionsConf /sca:policySet Where the only thing you might have to define is that structure ConnetionsConf and the xml processing for it. Then you need to write your handler for this policyset and register it in the binding module's META-INF/services. Thats it. - Venkat On Tue, Mar 4, 2008 at 10:30 PM, ant elder [EMAIL PROTECTED] wrote: On Tue, Mar 4, 2008 at 4:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: For a few things i've wondered about using intents to configure the behaviour of an extension but cant see how to code it without hard coding values. Using TUSCANY-1997 as an example is there some way of saying something like binding.ws requires=lotsOfConnections / and have that map to a user configurable value like 10? I can see how to use an intent named lotsOfConnections in a definitions.xml file but is there a way to map a value like 10 to that without just hard coding the mapping in the ws binding code? Yes, the policy framework allows you to define in definitions.xml a policySet matching an intent, place in the policySet the desired configuration in a form understood by the binding code, then that configuration will be presented to your binding. For a scenario like configure lots of connections on a reference with binding.ws, there is a better way than using an intent (i.e. I don't think that defining an intent for something like lotsOfConnections is the proper usage of policies): - you can just define the policySet, without an intent - add the policySet explicitly to your composition - or, better, attach it to your composition externally as discussed on tuscany-dev [1], the OASIS SCA Policy group [2] and in JIRA TUSCANY-1997 [2]. [1] http://marc.info/?l=tuscany-devm=120346977514972 [2] http://www.osoa.org/jira/browse/POLICY-15 [3] http://issues.apache.org/jira/browse/TUSCANY-1997?focusedCommentId=12570553#action_12570553 -- Jean-Sebastien Could you show some XML snippets for how that would look? ...ant
Support for external configuration of PolicySets
Hi, Based on the suggestions made by Sebastien in http://marc.info/?l=tuscany-devm=120346977514972 I have checked in some changes under r633563 that brings in support for configuring policysets on sca artifacts externally i.e. without have to modify the composites. In the itest/policy I have tested for this. That itest looks a bit complicated because I am verifying for policy settings based on whether the corresponding handlers are called. I wish I could register for various lifecycle events with the SCA Domain in which case I'd register a listener for the post build phase and simply verify the composite if its properly configured with the right policysets. Thanks - Venkat
Re: Asia Open Source Symposium Code Fest is looking for help, was Fwd: Low hanging bugs for students
My 2c. More than bugs it would be interesting for the students if we could suggest some minor enhancements to our tools or extensions. - Venkat 2008/3/5 haleh mahbod [EMAIL PROTECTED]: It looks like they are looking for short, 1-2 day, projects to expose students to how to provide patches in open source. How about suggesting a few of sample bugs for this exercise? This will expose the students to Tuscany and show them how to run samples. This will also give them a chance to fix smaller scoped problems and gain the experience that is looked for. On 3/3/08, Luciano Resende [EMAIL PROTECTED] wrote: This is a good opportunity for increasing awareness for Apache Tuscany. We could identify some JIRAs and/or very small projects (e.g enhancements to specific extensions) that we could send to J Aaron Farr to be used with the Chinese students. Thoughts ? Any suggestions ? -- Forwarded message -- From: J Aaron Farr [EMAIL PROTECTED] Date: Mon, Mar 3, 2008 at 1:27 AM Subject: Low hanging bugs for students To: Apache Community [EMAIL PROTECTED] This next weekend I'm going to be at the Asia Open Source Symposium Code Fest. What was going to be a hackathon-like event is now a student focused event with something like 50 university students attending for two days to learn something about open source. So now I'm trying to come up with ideas on what to have these students do. My preference is to have the students work on a bunch of patches over two days rather than work on a single application to be released at the end of the event. To me, the patch process is a fairly unique open source skill, so that's what I want to emphasize. I already have some bugs, features and code in mind, most related to the ApacheCon website. But if anyone has some ideas of other low hanging bugs or features that I could task a few students with, please let me know. Think of it as a two-day summer of code. If anyone has any other thoughts or suggestions, please pass them on. Thanks! -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario
+1. I will start looking into this after I am done with some half-finished things on my plate at the moment. Thanks. - Venkat On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Greg Dritschler wrote: Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg I think that Tuscany should implement the authorization - I guess that's what you meant :) - and security identity policies as described in section 1.7.3.1 of the Policy spec, at least. We could start with just implementing the model and XML reading for the elements described in 1.7.3.1 and let the various component implementation extensions handle them (or not) in their own way, but having the model and XML processors would be a good start IMO. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mayProvide Intents in binding.ws
Thanks Sebastien. Its be done already as you might see in https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/META-INF/services/definitions.xml On Wed, Mar 5, 2008 at 11:49 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, I observe are some intents named 'soap', 'soap11', 'soap12'. I'd like to know if these are supposed to be intents classified as 'mayProvide' for binding.ws. Just to refresh, 'mayProvide' intents are those that can be specified for a binding / implementation and that needs no matching policySet. i.e. this is typically a capability that the binding / implementation which could be switched on with just the specification of the intent on the binding / implementation. Given this, I don't see any policySets defined for these intents. So, I'd like to add these intent names to the bindingType definition for binding.ws. Again, just to refresh, the bindingtype information is something that is typically specified in the definitions.xml file and it contains a list of intents that are inherently supported by the binding in question, either as 'mustProvide' or 'mayProvide'. Can folks familiar with binding.ws please say if my understanding is on track ? Thanks. - Venkat Just noticed this pending question now. My understanding is the same as yours, the Web Service binding should declare the soap, soap/1.1 and soap/1.2 intents using the @mayProvide attribute. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java
Hey, that's np. Your response to Sebastien was elaborate enuf :) . Thanks. On Mon, Mar 3, 2008 at 4:30 PM, kelvin goodson [EMAIL PROTECTED] wrote: Sorry Venkat, I didn't explicitly respond to your posting, but I hope the answers I gave to Sebastien's similar line of questioning makes it clear. Please let me know if not. Kelvin. On 28/02/2008, Venkata Krishnan [EMAIL PROTECTED] wrote: This software will implement relevant open standards including, but not limited to, the SCA standard defined by the OASIS OpenCSA member section, and related technologies. When we say including but not limited to I understand that it would very well contain SDO and others implicitly. Or, does this have a different interprettation ? - Venkat On Thu, Feb 28, 2008 at 10:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: Implicit in this rewording is the understanding within the Tuscany community that there would be one Apache home for SDO Java development. When this thread is referenced in proposal for the new project, or discussions around it, it must be clear to the wider Apache community that the Tuscany community accepts that. Without this clear acceptance I fear the new project will face further periods of delay whilst questions are asked about the Tuscany communities intentions with regards to SDO Java development. So the answer to your question is conditional. If the new project is accepted an an incubator - does not require Tuscany to implement SDO anymore --- yes - and still allows Tuscany to implement SDO --- no - and still allows Tuscany to use SDO or any other related technology? --- yes if the project is not accepted as an incubator ... - does not require Tuscany to implement SDO anymore --- yes - and still allows Tuscany to implement SDO --- yes - and still allows Tuscany to use SDO or any other related technology? --- yes I'm trying to understand how to vote, or if I should vote, on your other thread. Maybe I'm missing something. There is an SDO implementation in Tuscany at the moment. SDO is a related technology worked on in OpenCSA too. Why would we want to remove it from the charter? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Community is more important than code
+1 - Venkat On Sun, Mar 2, 2008 at 4:01 PM, ant elder [EMAIL PROTECTED] wrote: After all this time in incubation we've all learnt to understand this but I think it may be useful reaffirm it now with a vote. So please all vote to show you understand and agree with the long standing Apache motto that community is more important than code. +1 from me. ...ant
Re: svn commit: r632646 - in /incubator/tuscany/java/sca/tools/maven/maven-definitions:
Hi Raymond, What I've done here is just about my own shade transformer and I did this just to keep our distribution going. I could not get the 'provider' option suggested by Sebastien done quickly as there needs some trouble with positioning the providers in the right modules and dealing with dependencies. Here is where I mentioned about this http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28469.html. Thanks - Venkat On Tue, Mar 4, 2008 at 2:49 AM, Raymond Feng [EMAIL PROTECTED] wrote: I wonder if it's too heavy to develop a maven plugin to merge the definitions.xml file. BTW, I don't like the all-in-one jar too much as it breaks the modularity and extensibility story. Thanks, Raymond -- From: [EMAIL PROTECTED] Sent: Saturday, March 01, 2008 11:16 AM To: [EMAIL PROTECTED] Subject: svn commit: r632646 - in /incubator/tuscany/java/sca/tools/maven/maven-definitions: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/tuscany/ src/main/java/org/apache/tuscany/sca/ src/main/java/org/... Author: svkrish Date: Sat Mar 1 11:15:54 2008 New Revision: 632646 URL: http://svn.apache.org/viewvc?rev=632646view=rev Log: adding maven shade transformer for aggregating sca definitions files Added: incubator/tuscany/java/sca/tools/maven/maven-definitions/ incubator/tuscany/java/sca/tools/maven/maven-definitions/DISCLAIMER (with props) incubator/tuscany/java/sca/tools/maven/maven-definitions/LICENSE (with props) incubator/tuscany/java/sca/tools/maven/maven-definitions/NOTICE (with props) incubator/tuscany/java/sca/tools/maven/maven-definitions/pom.xml (with props) incubator/tuscany/java/sca/tools/maven/maven-definitions/src/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/maven/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/maven/plugin/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/maven/plugin/shade/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/maven/plugin/shade/transformer/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/main/java/org/apache/tuscany/sca/tools/maven/plugin/shade/transformer/SCADefinitionsAppendingTransformer.java (with props) incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/java/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/maven/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/maven/plugin/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/maven/plugin/shade/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/maven/plugin/shade/transformer/ incubator/tuscany/java/sca/tools/maven/maven-definitions/src/test/resources/org/apache/tuscany/sca/tools/maven/plugin/shade/transformer/SCADefnsAppendingTransformerTest.java (with props) Added: incubator/tuscany/java/sca/tools/maven/maven-definitions/DISCLAIMER URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/maven/maven-definitions/DISCLAIMER?rev=632646view=auto == --- incubator/tuscany/java/sca/tools/maven/maven-definitions/DISCLAIMER (added) +++
Re: [VOTE] (Restarting the vote to ...) Change Tuscany Charter to remove SDO reference
+1 from me - Venkat On Mon, Mar 3, 2008 at 3:09 PM, kelvin goodson [EMAIL PROTECTED] wrote: As requested in [1] I am restarting this vote Please vote to alter the wording of the existing draft Tuscany charter as discussed in http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL PROTECTED] to the following WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Projectt Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the SCA standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: Adriano Crestaniadrianocrestani at apache dot org Andy Grove agrove at apache dot org Andrew Borley ajborley at apache dot org ant elder antelder at apache dot org Brady Johnson bjohnson at apache dot org Frank Budinsky frankb at apache dot org Ignacio Silva-Lepe isilval at apache dot org Jean-Sebastien Delfino jsdelfino at apache dot org kelvin goodson kelvingoodson at apache dot org Luciano Resende lresende at apache dot org Mike Edwards edwardsmj at apache dot org Pete Robbinsrobbinspg at apache dot org Raymond Feng rfeng at apache dot org Simon Laws slaws at apache dot org Simon Nash nash at apache dot org Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. = The wording of the existing draft charter was taken from http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL PROTECTED] Be sure to note when looking at that posting that it consists of a previous version + a modification at the end of the posting. The changes are ... This software will implement relevant open standards including, but not limited to, the SCA and SDO standards defined by the OASIS OpenCSA member section. becomes ... This software will implement relevant open standards including, but not limited to, the SCA standard defined by the OASIS OpenCSA member section, and related technologies. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL PROTECTED]
Trouble with aggregating definitions.xml in distro
Hi, I have accidentally deleted this thread from my mail box. I am not sure how this happened when I save a draft of my reply. So, continuing with that thread... 1) Sebastien suggested that I check out a couple of scenarios merging definitions.xml files using the XMLAppendingTransformer. As suspected by him, the transformer messes up namespaces. 2) Moving to the Provider option, I wanted to write a provider that reads the definitions.xml document and returns the model. With this I had quite a bit of trouble placing this provider - it could best be in the definitions-xml module. But then to instantiate the SCADefnDocProcessor I need the STaxProcessorExtensionPoint. I could have this extracted in the Provider if I passed around the ExtensionPointRegistry to the Provider. But the ExtensionPointRegistry interface is in the core module. So what seemed best as of now is only a SCADefinitionsFileLocationProvider thro which the various modules can return the path to the definitions.xml file within them. Meanwhile, I have written a simple shade transformer that will aggregate the definitions.xml and add a wrapper element tuscany:definitions in our distribution bundle. I have added some code in the SCADefinitionsDocProcessor to deal with this wrapper element. I am in the process of checking this out in a full distro and then will commit. Thanks - Venkat
Re: Trouble with aggregating definitions.xml in distro
Hi, I verified the distro and it seems like the transformer is working. So I have checked in the transformer under sca\tools\maven\maven-definitions and have also checked in the changes that I have done to distribution\bundle\pom.xml Thanks - Venkat On Sun, Mar 2, 2008 at 12:22 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have accidentally deleted this thread from my mail box. I am not sure how this happened when I save a draft of my reply. So, continuing with that thread... 1) Sebastien suggested that I check out a couple of scenarios merging definitions.xml files using the XMLAppendingTransformer. As suspected by him, the transformer messes up namespaces. 2) Moving to the Provider option, I wanted to write a provider that reads the definitions.xml document and returns the model. With this I had quite a bit of trouble placing this provider - it could best be in the definitions-xml module. But then to instantiate the SCADefnDocProcessor I need the STaxProcessorExtensionPoint. I could have this extracted in the Provider if I passed around the ExtensionPointRegistry to the Provider. But the ExtensionPointRegistry interface is in the core module. So what seemed best as of now is only a SCADefinitionsFileLocationProvider thro which the various modules can return the path to the definitions.xml file within them. Meanwhile, I have written a simple shade transformer that will aggregate the definitions.xml and add a wrapper element tuscany:definitions in our distribution bundle. I have added some code in the SCADefinitionsDocProcessor to deal with this wrapper element. I am in the process of checking this out in a full distro and then will commit. Thanks - Venkat
Re: Trouble with aggregating definitions.xml in distro
Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon
Re: Trouble with aggregating definitions.xml in distro
Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. Ant, thanks for point me to this. :) - Venkat On Fri, Feb 29, 2008 at 5:52 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: [VOTE] Pass-by-value related SPI change
My vote is for [2], [1] Thanks - Venkat On Sat, Mar 1, 2008 at 5:14 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add boolean allowsPassByReference() to the Invoker interface directly [2] Add boolean allowsPassByReference() to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, change the Provider.createInvoker() to take InvokerProperties. Add getInvokerProperties() to the Invoker interface. [4] Define an InvokerProperties class to encapsulate known properties including allowsPassByReference, add getInvokerProperties() to the Invoker interface. [5] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, define an InvocationPropertiesFactory interface to create InvokerProperties, add getInvokerProperties() to the Invoker interface. My vote is [1], [2]. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving ServiceDiscovery and related classes to tuscany-util
Alright, I am going to create a new module named tuscany-extensibility. The reason I suggested 'util' was that there are a few more things like the 'getQName' method that is being copied over in several places. I'd like to move these things as well into this module. So lets start with 'extensibility' now. Thanks - Venkat On Fri, Feb 29, 2008 at 9:57 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? Simon Laws wrote: +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. +1 Good idea, I also like tuscany-extensibility better than a general tuscany-util bucket. ant elder wrote: Agree about moving it out of contributions but how about to avoid another new module just to a .utils package in the spi module? I think everything that needs this would already be including the tuscany-core-spi module. Please, let's not make all these modules depend on core-spi with is really a 'runtime' SPI module. This won't help anyway with circular dependencies (just make it worse) as core-spi depends on assembly, policy, contribution etc. We need to move ServiceDiscovery down one layer, not up... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing composite file as a web service
Hi Sandeep, We have some samples to demonstrate this. Have you had a look at http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-ws-webapp ? - Venkat On Thu, Feb 28, 2008 at 12:53 PM, Sandeep Raman [EMAIL PROTECTED] wrote: Hi , When I apply binding to my component , the Tuscany seems to be starting a server on its own on the port i give in the binding uri. how can i make the component service run in axis2 which i have already deployed in tomcat. i.e. how can i tell the composite file to run the service in axis2 deployed in tomcat which is already running on port 8080. can you guide me on this. Regards Sandeep Raman. Simon Laws [EMAIL PROTECTED] wrote on 02/26/2008 07:41:58 PM: On Tue, Feb 26, 2008 at 12:59 PM, Sandeep Raman [EMAIL PROTECTED] wrote: Hi, Can the composite file be exposed as a web service to external world. how can i go about it. can you please guide me. regards Sandeep Raman. =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you Hi Sandeep I'm not clear what you mean by Can the composite file be exposed as a web service.. but you can certainly expose, as web services, component services that a composite file describes. For example, take a look at the helloworld-ws-service sample [1]. In the composite file ( helloworldws.composite) [2] that this sample uses you will see that it defines a single component with a single service exposed as a web service. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld)http://helloworld#wsdl.interface%28HelloWorld%29 / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite Note that the binding.ws... part make the service a web service. So if I run this sample I can reasonably expect to be able to point my browser at http://localhost:8085/HelloWorldService?wsdl To see the WSDL description of the web service that is created and to prove that it is running. For this sample there is also a client SCA application [3] that can be used to make a call to this web service. Hope that helps. Let me know if I'm interpreting the question incorrectly here of if you need more information Regards Simon [1] http://svn.apache. org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service/ [2] http://svn.apache. org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws- service/src/main/resources/META-INF/sca-deployables/helloworldws.composite [3] http://svn.apache. org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/ ForwardSourceID:NT573E =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Re: Trouble with aggregating definitions.xml in distro
Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] altering the Tuscany Charter in relation to SDO Java
This software will implement relevant open standards including, but not limited to, the SCA standard defined by the OASIS OpenCSA member section, and related technologies. When we say including but not limited to I understand that it would very well contain SDO and others implicitly. Or, does this have a different interprettation ? - Venkat On Thu, Feb 28, 2008 at 10:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: Implicit in this rewording is the understanding within the Tuscany community that there would be one Apache home for SDO Java development. When this thread is referenced in proposal for the new project, or discussions around it, it must be clear to the wider Apache community that the Tuscany community accepts that. Without this clear acceptance I fear the new project will face further periods of delay whilst questions are asked about the Tuscany communities intentions with regards to SDO Java development. So the answer to your question is conditional. If the new project is accepted an an incubator - does not require Tuscany to implement SDO anymore --- yes - and still allows Tuscany to implement SDO --- no - and still allows Tuscany to use SDO or any other related technology? --- yes if the project is not accepted as an incubator ... - does not require Tuscany to implement SDO anymore --- yes - and still allows Tuscany to implement SDO --- yes - and still allows Tuscany to use SDO or any other related technology? --- yes I'm trying to understand how to vote, or if I should vote, on your other thread. Maybe I'm missing something. There is an SDO implementation in Tuscany at the moment. SDO is a related technology worked on in OpenCSA too. Why would we want to remove it from the charter? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving ServiceDiscovery and related classes to tuscany-util
Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat
Re: Trouble with aggregating definitions.xml in distro
Hi, This is certainly a good option. We just about have to do two simple things in this transformer. - Create a definitions.xml file with the xml declaration and sca:definitions start element - The for every definitions.xml file read, skip upto the sca: definitions.xml and copy everything else upto the /sca:definitions element - Finally end this aggregated file with /sca:definitions Let me look up the link you provided to see if this is quickly workable. Thanks. - Venkat On Fri, Feb 29, 2008 at 1:09 PM, ant elder [EMAIL PROTECTED] wrote: Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer You can see the src of other Shade plugins and they're not too complicated - https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.java ...ant On Fri, Feb 29, 2008 at 6:35 AM, ant elder [EMAIL PROTECTED] wrote: I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi Ant, Thats going to remain. The providers that I have in mind will just about load the definitions.xml file using the DocProcessor and hand the resulting model out. If we do end up with a need to create the model programmatically then its upto the provider that gets to be written at that time. Thanks - Venkat On Fri, Feb 29, 2008 at 12:05 PM, ant elder [EMAIL PROTECTED] wrote: I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi, First, thanks a ton for all the comments / opinions. I agree, META-INF/services is not the right place for this. I suppose META-INF is ok because the definitions.xml does contain meta-data about binding and implementation types. For example, the definitions.xml in the binding.ws.axis module will define a binding type that will describe the mayProvides and alwaysProvides intents. Or, isn't this metadata at all ? Yes, the point is that definitions.xml can be a part of any contribution and hence can be anywhere. Infact, the samples / demos have the definitions.xml in the resources directory only. The issue is with the definitons.xml in the tuscany modules. They need to be loaded when the runtime is started and hence need to be explicitly searched for and loaded. Whereas in the case of contributions, the definitions.xml get processed like any other artifact in the contribution. So, the bottom line is how do we identify these various definitions.xml in the various tuscany modules ? Thanks - Venkat On Tue, Feb 26, 2008 at 4:55 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: ... For example, could you use something like policy-logging\src\main\resources\org\apache\tuscany\policy\logging\definitions.xml What you're proposing makes sense to me: let's put definitions.xml file in logically named folders. I'm not sure that we even need a naming convention like org/apache/tuscany/module-name. Definitions.xml files live in SCA contributions and the Tuscany contribution code should be able to find them wherever they are in the contribution (like we find WSDLs, XSDs, composite files etc). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi Sebastien,
Thanks for the suggestion. Going by the ProviderExtesionPoint way...
- first I'd prefer load the definitions.xml instead of creating
programmatically so that we don't have to touch the code for every change to
the definitions.
- every module that has its own definitions.xml must define it in a unique
path so that the file does not get lost when we are making the
tuscany-sca-all jar file in the distro.
So, given that every module HAS to define its definitions.xml in a unique
path I am wondering if it would just enuf for each module then to just about
publish the path for this in a file similar to the ones in
META-INF/services. So even when this file is aggregated by the shade plugin
when making the tuscany-sca-all jar, we still have the location paths of all
definitions.xml. Is this a viable alternative ?
Thanks
- Venkat
On Tue, Feb 26, 2008 at 8:48 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hi,
First, thanks a ton for all the comments / opinions.
I agree, META-INF/services is not the right place for this. I suppose
META-INF is ok because the definitions.xml does contain meta-data about
binding and implementation types. For example, the definitions.xml in
the
binding.ws.axis module will define a binding type that will describe the
mayProvides and alwaysProvides intents. Or, isn't this metadata at all
?
Yes, the point is that definitions.xml can be a part of any contribution
and
hence can be anywhere. Infact, the samples / demos have the
definitions.xml in the resources directory only.
The issue is with the definitons.xml in the tuscany modules. They need
to
be loaded when the runtime is started and hence need to be explicitly
searched for and loaded. Whereas in the case of contributions, the
definitions.xml get processed like any other artifact in the
contribution.
So, the bottom line is how do we identify these various definitions.xmlin
the various tuscany modules ?
I think the main issue is that you're trying to use an SCA contribution
based mechanism in non SCA contributions.
I think we should do the following:
- Definitions.xml is metadata, so is .composite, .componentType, etc,
none of them should be under META-INF, we should give a good example in
our own code, i.e. place them out of META-INF.
- Either use proper SCA contributions and the capability of the Tuscany
runtime to load them, and use definitions.xml files in these
contributions.
- Or, if these are not SCA contributions, use the extension point
mechanism we're using everywhere else. For example do something similar
to what we do for XML schemas used for validation, as follows...
a) define a DefinitionProviderExtensionPoint
interface DefinitionProviderExtensionPoint {
void addDefinitionProviderExtensionPoint(DefinitionProvider provider);
void removeDefinitionProviderExtensionPoint(
DefinitionProvider provider);
}
b) define a DefinitionProvider
interface DefinitionProvider {
Definition getDefinition();
}
c) register the DefinitionProviders as we register all extensions.
d) in a DefinitionProvider load definitions.xml from wherever you want
and however, or even better just create that model in code.
class MyDefinitionProvider implements DefinitionProvider {
Definition getDefinition() {
// load or create the Definition model
...
return definition;
}
}
Hope this helps.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi Simon, Thanks for responding. Please see my comments inline. - Venkat On Mon, Feb 25, 2008 at 6:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 1:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat Hi Venkat Can I just clarify that you are saying that you are having problems because of the way that the shader plugin is aggregating the definitions.xml files that now appear in various extension modules, e.g. binding-ws-axis2, poilcy-logging et. and that this is not specifically related to the bingbank demo or to the way that Tuscany subsequently aggregates the contents is finds in definitions.xml files. Yes I am talking about aggregating the definitions.xml files from the various modules. The shade plugin is working alright. This is not specific to the bigbank demo - more a general problem. I think I have been caught on wrong foot trying to use this META-INF/services aggregation for the definitions.xml file as well. :( Does definitions.xml have to appear in META-INF/services. Could we, for example, further qualify the definitions.xml file by putting it in a directory that represents the name of the extension module to which it refers? Or does that make it difficult to pick them up generically? I did think of including the extension module where it is defined, but then we must enlist all extension modules then or in otherwords enlist the locations of these definitions.xml file somewhere. Am not sure if we can search for resources using regular expressions - something like /*/definitions.xml. Thanks. Simon
Trouble with aggregating definitions.xml in distro
Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Hi,
I seem to liking Raymond's suggestion of 'Configurable' interface which will
have methods for setting and getting properties by name. Seems simple and
helps in keeping up binary compatibility. There is something similar we
have done to bring in support for policies where any implementation or
binding that supports policies simply implements the attach point
interfaces. This has let us keep bindings and impls that don't support
policies without any change.
- Venkat
On Feb 19, 2008 5:07 PM, Simon Nash [EMAIL PROTECTED] wrote:
Comments inline.
Simon
Raymond Feng wrote:
+1 on Option 1) which is something I'm scared to propose these days as
we want to keep the SPIs binary compatible :-). I prefer to have an
explict, clean and strongly-typed contract.
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to
the type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty(AllowsPassByReference);
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 3:15 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the
Invoker implementation classes. To support multiple properties, the
invoker can simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
Sorry, but after looking at this again I think that it's getting way
too complicated. Can we please keep this SPI simple?
I agree that the fully dynamic approach with generic multi-typed
returns and casting from Object looks too complicated. However,
I think there are ways to keep the other approach with statically
defined properties simple.
I'd like to propose two options:
1) Add methods to Invoker, mirroring what's described in the spec.
interface Invoker {
boolean allowsPassByReference();
// and another similar method which we'll need to handle
// non-blocking calls
boolean isOneWay();
This is a property of an interface definition, not a property of
the implementation like allowsPassByReference. It's already available
on the Operation interface (though rather confusingly spelt
isNonBlocking). Why would we need this on Invoker as well as
on Operation?
}
2) or if we want to preserve binary compatibility for now, create
interface Invoker2 extends Invoker {
boolean allowsPassByReference();
boolean isOneWay();
}
IMHO it's OK to ask Invoker implementors to add two empty methods when
they port their code to the next release, so I'll prefer option (1) as
it's simpler.
I think it's a problem having to either break compatibility or introduce
a new sub-interface every time we add a new optional property. When
adding a functional method containing executable code, we can't avoid
this, but simple properties can be handled in a different way.
The one-time hit to add new methods everywhere can be managed (though I
was surprised to find as many as 28 classes in Tuscany that implement
Invoker, plus whatever code users have added for extensions). It's the
ongoing need to go through this exercise every time we need a new
optional property that is bothering me.
Here's a proposal for how to do this that's simple, strongly typed,
and doesn't have compatibility issues.
1. Introduce a new interface InvokerProperties with strongly typed
methods for all optional invoker properties (as Raymond proposed
Re: Venkat and Mark added to Tuscany Developer group in Continuum (vmbuild1) eom
Thanks Luciano. I gathered this from the other thread to infra, as well. - Venkat On Feb 18, 2008 6:09 AM, Luciano Resende [EMAIL PROTECTED] wrote: -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, I reviewed these changes a bit in the context of multiple contributions. I guess things should work even then because these steps happen in the course of 'addContribution'. So if a new contribution comes in, the definitions in that would further get aggregated and then the composites coming in would be parsed and processed against the aggregated union of all definitions. Do you see something missing ? Thanks - Venkat On Wed, Feb 13, 2008 at 6:45 PM, Simon Laws [EMAIL PROTECTED] wrote: On Feb 12, 2008 5:18 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, No there isn't a separate phase. Just that in the current read phase I look for *.composite files and set those aside in a list without processing them further. After all artifacts in the contribution have been read I then read the list of composite URIs, read them and modify them with the additional attribute 'applicablePolicySets' and then push it further for the usual processing. I see that this is what you have also summarized on the wiki. I have assumed that in the section titled New Policy Processing Phase should go the description of what we do now with the composite reading and augmenting. I have added that information. Let me know if your thoughts for it were otherwise. I think I might have to change this a bit in the context of multiple contributions. Isn't it ? - Venkat On Feb 12, 2008 2:41 PM, Simon Laws [EMAIL PROTECTED] wrote: snip.. On Feb 12, 2008 8:40 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Because we are now computing the 'applicablePolicySets' for various SCA artifacts and that needs the list of 'all' PolicySets that might be applicable ever. So, in the code today, how do you know you have reached the point that all contributions have been added and you can start associating policy sets with composites? Is the composite processing now in a separate phase independent of the the contribution processing. To try and get this clearer in my mind I've written out a part of the various phases on the wiki [1]. Is there a new phase? Looking at the code I don't see it. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases Hi Venkat Thanks for the updates. The multiple contribution case was the case that I was thinking about :-) So you have these new steps that have to sit between the point where all the definitions.xml files are read from ALL the contributions and the point at which a composite is parsed and turned into an assembly model. SO it sounds like the process would be something like 1. Add contribution 2. Process contribution to extract definitions.xml repeat 1 2 until all contributions are added 3. Find composites in contributions 4. Process appliesTo with reference to each of the composites 5. process the the composites into an assembly model for further domain processing (the domain composite) I'm not necessarily advocating enforcing the approach that all contributions must be added before any further processing commences. You could imagine an approach where the process is just repeated as new contributions are added for example. But you get my point. Simon
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, Yes, this is something that ran thro my mind. I guess A.composite might have to run thro both definitions.xmll(A) and definitions.xml(B) if definitions.xml(B) has brought in some re-definitions of policysets defined in definitions.xml(A). But, is this sort of re-processing / rebuild is a requirment only in this context ? If there are other contexts as well, such as re-wiring and we there is going to be a separate phase for this, then I'd like to do this as well in that phase. Thanks - Venkat On Thu, Feb 14, 2008 at 6:25 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... against the aggregated union of all definitions. Do you see something missing ? The point I'm interested in is what happens to the composites that belong to contributions that have previously been added when you add a new contribution, for example, ContributionA definitions.xml(A) A.composite ContributionB defnitions.xml(B) B.composite When ContributionA is processed A.composite will be processed in the context of any appliesTo statements that appear in deinfitions.xml(A). When ContributionB is added should B.composite be processed in the context of appliesTo statements that appear in both deinfitions.xml(A) and definitions.xml(B)? Should A.composite be re-processed in the context of appliesTo statements that appear in both deinfitions.xml(A) and definitions.xml(B)? Simon
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi Sebastien, Am yet to look into the Bigbank. Will do it soon. But then, I was able to get the helloworld-ws-secure samples to work with only abstract intents like authentication, integrity and not custom ones ;-). The policysets 'appliesTo' was use to target them to specific services / references. - Venkat On Feb 12, 2008 8:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Dealing with the 'appliesTo' attribute in PolicySets has been a subject that I ended up discussing on the thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html. I have gone forward with a suggestion that Sebastien sounded off on that thread and have committed the changes under r620307. First to set the stage --- - The PolicySets could be defined in various definitions.xml which are all read and aggreated for a domain - Each PolicySet defines an 'appliesTo' attribute which is an xpath that specifies the sca artifacts to which this policyset may apply. The problem is about being able to validate the computed or calculated policysets for a binding / implementation using this 'appliesTo' attribute. Here is a summary of what's been done. --- - In the contribution read phase, we postpone the reading of composite files so that all definitions.xml file contents can all be aggregated - After reading all other kinds of artifacts, we finally read the composite files in the contribution. The composite xml is first read as a xml document and for each PolicySet defined for the domain we run the appliesTo xpath against this xml document. For the nodes returned as result of this xpath evaluation, we add an attribute named 'applicablePolicySets' whose value will be the name of the PolicySet in question. So the read composite will now be modified to include this attribute wherever applicable. - The modified composite xml is then passed to the STaX processors for the usual parsing and creation of the the assembly model objects. - Then during the computing / calculation of PolicySets for a PolicySetAttachPoint (i.e. a binding or an implementation) the matching policysets are validated against the list that has been made in the 'applicablePolicySets' attribute of the PolicySetAttachPoint. As a result of this our samples now don't define their own intents to target specific policysets for specific references / services. Instead this targeting is achieved by the proper specification of the 'appliesTo' attribute in the PolicySet. Please let me know your thoughts on this. Thanks - Venkat Looks good to me. I am assuming that 'applicablePolicySets' is a transient and calculated attribute used by Tuscany to flow policySet info with model elements across the composite reading phases, and not exposed to application developers. Were you able to leverage these changes to simplify the bigbank scenario? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
Sure, thanks Sebastien. On Feb 12, 2008 8:34 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Thanks. I will ask Sebastien then :) I'm an administrator on project Tuscany but: - you are not in the Tuscany continuum group - I don't have seem to have authority to perform any user admin tasks Can you ask one of the continuum user administrators, here's the list: http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administratorhttp://vmbuild.apache.org/continuum/security/userlist%21show.action?roleName=User+Administrator -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Yes. Because we are now computing the 'applicablePolicySets' for various SCA artifacts and that needs the list of 'all' PolicySets that might be applicable ever. - Venkat On Feb 12, 2008 2:03 PM, Simon Laws [EMAIL PROTECTED] wrote: On Feb 12, 2008 8:18 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: On Feb 12, 2008 1:09 PM, Simon Laws [EMAIL PROTECTED] wrote: Hi Venkat A question. snip... - In the contribution read phase, we postpone the reading of composite files so that all definitions.xml file contents can all be aggregated Do you mean all the definitions.xml files in the contribution or all the definitions.xml files in the domain? Simon Hi Simon, Ok, I should probably say that all definitions.xml in a runtime and that includes the ones coming from our extensions / runtime and the ones coming in from the contributions. - Venkat So does that mean that all definitions.xml processing has to complete for all contributions before any composites are parsed? Simon
Re: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project
It seems that page is protected from normal users. It appears blank for me. - Venkat On Feb 12, 2008 1:50 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Sure, thanks Sebastien. On Feb 12, 2008 8:34 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Thanks. I will ask Sebastien then :) I'm an administrator on project Tuscany but: - you are not in the Tuscany continuum group - I don't have seem to have authority to perform any user admin tasks Can you ask one of the continuum user administrators, here's the list: http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administratorhttp://vmbuild.apache.org/continuum/security/userlist%21show.action?roleName=User+Administrator -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PolicyHanders
Hi, Thanks for sharing your thoughts further. My comments inline. - Venkat On Feb 12, 2008 9:51 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Comments below. On Feb 11, 2008 7:36 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Greg, Thanks for your observations / suggestions. Please see my comments inline. I apologize for making them lengthy in the hope that it would trigger more discussions. - Venkat On Feb 7, 2008 1:33 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). Just to clarify, I did start with PolicyHanlder types classified against the PolicySet name, but later discovered that this is not scalable. Today, the PolicyHandler types are classified against the PolicyModel that they can understand (i.e. WS-Policy or some customer model) and the Intent that they can deal with (i.e authentication or transaction). I feel we might also have to add one more classifier that denotes the QoS infrastructure that the PolicyHandler is capable of working with. While the policy model and intent can be extracted for a PolicySet to find the appropriate PolicyHandler, I am not sure where we can encapsulate this 'specific infrastructure' information. I wasn't suggesting any changes along these lines. I think using model objects and intents is sufficient. Yes, I understood. :) ..but wanted to see if I could trigger some thoughts / ideas. So, if it does happen that we have mutliple PolicySets on a wire that point to the same PolicyHandler type, yes it makes sense to do what you suggest. Infact, this turns out to be a necessity for example when we want to configure the Axis2 Config Parameters for binding.ws to say enable authentication AND integrity where each of these could have their own PolicySets. 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. +1. At the present moment this is left to how implementation and binding extensions would choose to deal with. I'd prefer that the binding / implementation providers parse the list of required intents and if there are the ones that they 'mayProvide' then suitable PolicySets should be added to the list of PolicySets. Ofcourse the corresponding PolicyHandlers should also be defined and registered. This I feel provide uniformity and extensibility to how policy handling plugs into extensions. Intents in the 'mayProvides' list don't require policy sets. True and will remain so for users. Amongst the choices of various mechanisms that a binding or implementation extension might use to handle mayProvides intents, I am just about suggesting why not use the PolicySet mechanism itself. The fact that the extension uses PolicySets for this is going to be opaque to users. Or am I missing a perspective here ? 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. This sounds like something that is left for bindings / implementations to deal with, in the way they might choose to. As I had mentioned in the previous point a cleaner way would be for binding /implementation providers to verify if a default intent needs to be in force and add the corresponding PolicySet to the list of policysets. For example, if an implementation provider parses the requiredIntents and discovers nothing in there related to transaction intent type, then it could add the default
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi, No there isn't a separate phase. Just that in the current read phase I look for *.composite files and set those aside in a list without processing them further. After all artifacts in the contribution have been read I then read the list of composite URIs, read them and modify them with the additional attribute 'applicablePolicySets' and then push it further for the usual processing. I see that this is what you have also summarized on the wiki. I have assumed that in the section titled New Policy Processing Phase should go the description of what we do now with the composite reading and augmenting. I have added that information. Let me know if your thoughts for it were otherwise. I think I might have to change this a bit in the context of multiple contributions. Isn't it ? - Venkat On Feb 12, 2008 2:41 PM, Simon Laws [EMAIL PROTECTED] wrote: snip.. On Feb 12, 2008 8:40 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Because we are now computing the 'applicablePolicySets' for various SCA artifacts and that needs the list of 'all' PolicySets that might be applicable ever. So, in the code today, how do you know you have reached the point that all contributions have been added and you can start associating policy sets with composites? Is the composite processing now in a separate phase independent of the the contribution processing. To try and get this clearer in my mind I've written out a part of the various phases on the wiki [1]. Is there a new phase? Looking at the code I don't see it. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi Sebastien, I have made the changes to the secure-bigbank demo. Let me know if there is something that looks odd and not practical in a real world scenario. Thanks. - Venkat On Feb 12, 2008 8:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Dealing with the 'appliesTo' attribute in PolicySets has been a subject that I ended up discussing on the thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html. I have gone forward with a suggestion that Sebastien sounded off on that thread and have committed the changes under r620307. First to set the stage --- - The PolicySets could be defined in various definitions.xml which are all read and aggreated for a domain - Each PolicySet defines an 'appliesTo' attribute which is an xpath that specifies the sca artifacts to which this policyset may apply. The problem is about being able to validate the computed or calculated policysets for a binding / implementation using this 'appliesTo' attribute. Here is a summary of what's been done. --- - In the contribution read phase, we postpone the reading of composite files so that all definitions.xml file contents can all be aggregated - After reading all other kinds of artifacts, we finally read the composite files in the contribution. The composite xml is first read as a xml document and for each PolicySet defined for the domain we run the appliesTo xpath against this xml document. For the nodes returned as result of this xpath evaluation, we add an attribute named 'applicablePolicySets' whose value will be the name of the PolicySet in question. So the read composite will now be modified to include this attribute wherever applicable. - The modified composite xml is then passed to the STaX processors for the usual parsing and creation of the the assembly model objects. - Then during the computing / calculation of PolicySets for a PolicySetAttachPoint (i.e. a binding or an implementation) the matching policysets are validated against the list that has been made in the 'applicablePolicySets' attribute of the PolicySetAttachPoint. As a result of this our samples now don't define their own intents to target specific policysets for specific references / services. Instead this targeting is achieved by the proper specification of the 'appliesTo' attribute in the PolicySet. Please let me know your thoughts on this. Thanks - Venkat Looks good to me. I am assuming that 'applicablePolicySets' is a transient and calculated attribute used by Tuscany to flow policySet info with model elements across the composite reading phases, and not exposed to application developers. Were you able to leverage these changes to simplify the bigbank scenario? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Integration Tests
Thanks. Any addition to the tests will be really helpful. To get a jumpstart you could copy over one of the existing tests and modify it deleting / adding classes and resources. - Venkat On Feb 12, 2008 12:01 AM, Kevin Williams [EMAIL PROTECTED] wrote: I noticed there are no spring-related tests in the sca/itest folder and I would like to volunteer to add a few. Does this sound like a good idea? I would probably need some help setting up the basic structure before adding content. Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PolicyHanders
Hi Greg, Thanks for your observations / suggestions. Please see my comments inline. I apologize for making them lengthy in the hope that it would trigger more discussions. - Venkat On Feb 7, 2008 1:33 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). Just to clarify, I did start with PolicyHanlder types classified against the PolicySet name, but later discovered that this is not scalable. Today, the PolicyHandler types are classified against the PolicyModel that they can understand (i.e. WS-Policy or some customer model) and the Intent that they can deal with (i.e authentication or transaction). I feel we might also have to add one more classifier that denotes the QoS infrastructure that the PolicyHandler is capable of working with. While the policy model and intent can be extracted for a PolicySet to find the appropriate PolicyHandler, I am not sure where we can encapsulate this 'specific infrastructure' information. So, if it does happen that we have mutliple PolicySets on a wire that point to the same PolicyHandler type, yes it makes sense to do what you suggest. Infact, this turns out to be a necessity for example when we want to configure the Axis2 Config Parameters for binding.ws to say enable authentication AND integrity where each of these could have their own PolicySets. 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. +1. At the present moment this is left to how implementation and binding extensions would choose to deal with. I'd prefer that the binding / implementation providers parse the list of required intents and if there are the ones that they 'mayProvide' then suitable PolicySets should be added to the list of PolicySets. Ofcourse the corresponding PolicyHandlers should also be defined and registered. This I feel provide uniformity and extensibility to how policy handling plugs into extensions. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. This sounds like something that is left for bindings / implementations to deal with, in the way they might choose to. As I had mentioned in the previous point a cleaner way would be for binding /implementation providers to verify if a default intent needs to be in force and add the corresponding PolicySet to the list of policysets. For example, if an implementation provider parses the requiredIntents and discovers nothing in there related to transaction intent type, then it could add the default transaction PolicySet to the list of policysets. Makes sense or am I missing your point? 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way up the model (component, etc) if it needs to? I suppose what is 'provided' to the handler depends on the implementation or binding extension and from where it decides to call the handlers. If the handlers are called from the interceptors they can provide any state that is available to them. Or if there is context information that is not going to change across service calls then such information could be initialized into PolicyHandlers as part of the 'setup' call. 5. It might be nice for the PolicyHandlingInterceptor constructor to make an initialization call to the handler so it can do some setup. For the JavaImplementation extension this is done in the JavaPolicyHandlingRuntimeWireProcessor that creates these PolicyHandlers and injects them into the interceptor. The 'setup' call is there as part of the
Re: NoSuchMethodError: javax/wsdl/Operation
Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant
Re: XPath related question
Hi Doug and Raymond, Thank you very much. I just figured these out. I am now using the prefixes in all the xpaths I am using. For the other question, I suppose specifying the return type as NODESET returns a list of matching nodes. - Venkat On Feb 8, 2008 10:30 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, My experience is that you need to set the NamespaceContext on the XPath so that you can map a prefix to the namespace URI. See: http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPath.html#setNamespaceContext(javax.xml.namespace.NamespaceContext)http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPath.html#setNamespaceContext%28javax.xml.namespace.NamespaceContext%29 . For example, you can associate sca or s (maybe even an empty one) with the SCA namespace. Then you can use the prefix with the XPath expression, such as s:composite or sca:composite. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Friday, February 08, 2008 4:22 AM Subject: XPath related question Hi, I am trying to get some xpaths evaluated against a composite file. I have a couple of questions related to xpath queries. Can somebody familiar please help. Thanks. My composite element in the composite file defines the defaultnamespace - xmlns=http://www.osoa.org/xmlns/sca/1.0;. Given this if I construct a xpath that is like /composite or /composite/component the query does not return any result. On the other hand if I added the following namespace declaration to the composite element xmlns*:sca*=http://www.osoa.org/xmlns/sca/1.0; and then constructed an xpath - /sca:composite or /sca:composite/sca:component, then the query returns the expected results. Any clues to what I am missing out here ? The other question I have is, to an xpath - /sca:composite/sca:component I expect the set of all component nodes to be returned, but instead I seem to be getting just the first one. How do I get the set of all component nodes ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
