Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Venkata Krishnan]

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: Secure-bigbank demo, was Re: svn commit: r641708 - /incubator/tuscany/java/sca/demos/pom.xml

[Venkata Krishnan]

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=641708&view=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=641708&r1=641707&r2=641708&view=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 @@
> >> bigbank-stockquote
> >> mortgage-creditcheck
> >> mortgage-loanapproval
> >> -secure-bigbank
> >> xml-bigbank
> >> 
> >> 
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: SCA 2.0, was Re: Next SCA release

[Venkata Krishnan]

+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

[Venkata Krishnan]

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: 
> > 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:
> > > > >
> > > > > http://tuscany.apache.org/xmlns/sca/1.0"; ...  >
> > > > >
> > > > >  
> > > > >
> > > > >  > > > >
> > > > >
> > > > > providerFactory="org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory"
> > > > >
> > > > > model="org.apache.tuscany.sca.binding.ws.WebServiceBinding" />
> > > > >
> > > > >  
> > > > >
> > > > > 
> > > > >
> > > > >
> > > 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

[Venkata Krishnan]

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: 
> 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:
> > > >
> > > > http://tuscany.apache.org/xmlns/sca/1.0";
> > > > ...  >
> > > >
> > > >  
> > > >
> > > >  > > >
> > > >
> > > > providerFactory="org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory"
> > > >
> > > > model="org.apache.tuscany.sca.binding.ws.WebServiceBinding" />
> > > >
> > > >  
> > > >
> > > > 
> > > >
> > > >
> > 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

[Venkata Krishnan]

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  > > > > 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 definit

Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)

[Venkata Krishnan]

+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 
>* ant elder 
>* Brady Johnson 
>* Frank Budinsky 
>* Ignacio Silva-Lepe 
>* Jean-Sebastien Delfino 
>* kelvin goodson 
>* Luciano Resende 
>* Mark Combellack 
>* Matthieu Riou 
>* Mike Edwards 
>* Paul Fremantle 
>* Pete Robbins 
>* Raymond Feng 
>* Simon Laws 
>* Simon Nash 
>* Venkata Krishnan 
>
> 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

[Venkata Krishnan]

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  > > > 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 e

Re: [DISCUSS] Declaring extensions as being available in the domain

[Venkata Krishnan]

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  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

[Venkata Krishnan]

+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 
>   - ant elder 
>   - Brady Johnson 
>   - Frank Budinsky 
>   - Ignacio Silva-Lepe 
>   - Jean-Sebastien Delfino 
>   - kelvin goodson 
>   - Luciano Resende 
>   - Mark Combellack 
>   - Matthieu Riou 
>   - Mike Edwards 
>   - Paul Fremantle 
>   - Pete Robbins 
>   - Raymond Feng 
>   - Simon Laws 
>   - Simon Nash 
>   - Venkata Krishnan 
>
>  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

[Venkata Krishnan]

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://lresende.blogspot.com/
>

Re: Adding SVN version to Java files

[Venkata Krishnan]

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://lresende.blogspot.com/
>

Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

[Venkata Krishnan]

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: -


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: [vtest] Java API Spec - Section 2 - Policy Annotations

[Venkata Krishnan]

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: [jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents

[Venkata Krishnan]

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
> > >  element in definitions.xml.  For example:
> > >
> > > > > 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.
> > >
> > >   > > 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.
> > >
> > >   > >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:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Let's assume CZ1 contains the component C1 shown earlier and that it
> > > promotes the component reference C1/r1 as r1.  C1/r1 has the intent
> > > "propagatesTransaction".  This intent is considered a requirement of
> the
> > > implementation and it cannot be overridden by the using composite.
> > >  There

Re: [NOTICE] Wang Feng voted as Tuscany committer

[Venkata Krishnan]

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: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Venkata Krishnan]

+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/
>
> 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/
>
> 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://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: SCA 2.0, was Re: Next SCA release

[Venkata Krishnan]

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:
> >
> >  
> >
> >
> > +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://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Project Ideas - Let's get the community involved !!!

[Venkata Krishnan]

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: Question on Composition.

[Venkata Krishnan]

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: policy itest question

[Venkata Krishnan]

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: SCADefinitionsProviderExtensionPoint interface

[Venkata Krishnan]

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

[Venkata Krishnan]

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

[Venkata Krishnan]

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
>

[Discussion] Inheritance of PolicyIntents by 'callback' elements

[Venkata Krishnan]

Hi,

The prev. mail seemed to have a chewed up subject.  So resending with a
better subject line.

-- Forwarded message --
From: Venkata Krishnan <[EMAIL PROTECTED]>
Date: Wed, Mar 26, 2008 at 9:50 PM
Subject: [Discussion] Conversational Polic
To: tuscany-dev@ws.apache.org


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

Removing SecureBigBank Demo - svn commit: r640886 - /incubator/tuscany/java/sca/demos/secure-bigbank/secure-bigbank-account/src/main/java/bigbank/security/CheckingsDeptAuthorizationPolicyProcessor.jav

[Venkata Krishnan]

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=640886&view=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=640886&r1=640885&r2=640886&view=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]
>
>

[Discussion] Conversational Polic

[Venkata Krishnan]

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: Error on requires = "integrity"

[Venkata Krishnan]

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]
>

Re: [NOTICE] Giorgio Zoppi voted as Tuscany committer

[Venkata Krishnan]

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: Re: How to use logger policy?

[Venkata Krishnan]

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" 
> >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
> >> 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";>
> >>
> >>  >> alwaysProvides="tuscany:logging"/>
> >>
> >>All messages to and from this implementation must
> be
> >> logged
> >>
> >> >> appliesTo="sca:implementation.java"
> >>xmlns="http://www.osoa.org/xmlns/sca/1.0";>
> >>
> >>ALL
> >>
> >>
> >> 
> >>
> >> calculator.composite
> >> 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";>
> >>
> >> >> policyset="tuscany:JDKLoggingPolicy">
> >>  >> requires="tuscany:logging"/>
> >>
> >> target="SubtractServiceComponent"
> >> />
> >> target="MultiplyServiceComponent"
> >> />
> >> />
> >>
> >>
> >>
> >> >> requires="tuscany:logging"/>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 
> >> --
> >> 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 additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?

[Venkata Krishnan]

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: 
> 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: 
> >> 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.
> >> >

Re: Adding SPIs to handle policies, was: Re: Policy Handlers ?

[Venkata Krishnan]

 >> global
> >> transaction is demarcated before the control hits the component
> >> implementation. The interceptor can be independent of the
> implementation
> >> types.
> >>
> >> In case 3 & 4, an transaction interceptor can be added to the
> invocation
> >> to
> >> suspend the current transaction before delegating to the next invoker
> and
> >> resume the transaction after the control is returned.
> >>
> >> In case 5, the binding.ws provider will have to deal with
> >> WS-AtomicTransaction to make sure the transaction context can be
> >> propagated
> >> over the SOAP protocol.
> >>
> >> In case 6, if there is an incoming transaction from the WS-AT, the
> >> binding.ws provider will need to import the transaction.
> >>
> >> It seems that the logic that enforces the intents could be a joint
> effort
> >> of
> >> a policy interceptor and the binding/implementation provider.
> >>
> >> Thanks,
> >> Raymond
> >>
> >> - Original Message -
> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> >> To: 
> >> 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: [SCA 1.2] Build issues in tools/maven/maven-definitions

[Venkata Krishnan]

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/~lresende
> 
> > <
> > >  > 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/~lresende
> <
> > 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/~lresende<
> http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: Qualifiable Policy intents - QNames or NCNames? was: About StAXArtifactProcessor

[Venkata Krishnan]

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 -

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";>


Used to indicate the transaction environment desired by
a component implementation.




Used to indicate that a component implementation requires a
managed global transaction.





Used to indicate that a component implementation requires a
managed local transaction.



..

---

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 ...



Used to indicate that a component implementation requires a
managed global transaction.



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-d

Re: Keeping up with the dev list and the flood of JIRA messages

[Venkata Krishnan]

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: definitions.xml and the SCA Domain over a distributed runtime

[Venkata Krishnan]

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
> >
>

Re: [SCA 1.2] Release Branch is now available

[Venkata Krishnan]

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]
>
>

definitions.xml and the SCA Domain over a distributed runtime

[Venkata Krishnan]

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: Release checklist and process

[Venkata Krishnan]

Hi Simon,

Most certainly YES and thanks for putting this together.  Thanks to the
others as well who have contributed to this.  Most times theres so much that
an RM does to plug so many things which we all don't manage to remember at a
later time.  This is going to be certainly useful in that.

Thanks

- Venkat

On Mon, Mar 17, 2008 at 3:16 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> I've put my notes from release 1.1 up at [1]. This a further development
> of
> Ant's original notes and many of the commands here are from Raymond's
> script
> [2]. Thanks guys.
>
> There is a general high level check list and then a detailed step by step
> guide. This is just a brain dump from my R1.1 experience so consider
> yourselves invited to improve. As we are starting release 1.2 now it seems
> like a good opportunity to test them, plug any holes and generally improve
> for the next person.
>
> Is this of any use?
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases
> [2]
> http://svn.apache.org/repos/asf/incubator/tuscany/java/etc/release-sca.sh
>

Re: About StAXArtifactProcessor

[Venkata Krishnan]

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




>
>
> >>
> >> 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.
> >
>
> I'm not saying that you need to do all the processing in a single method
> :), you can split it multiple methods if you like, but these methods can
> be private methods, do not have to belong to the StAXArtifactProcessor
> interface, and can take whatever context you want to pass to them.
>
> We just need to find the right balance between bulky methods and a maze
> of small methods calling each other :)
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: IntentAttachPointType for internally-created SCA bindings

[Venkata Krishnan]

Hi,

One part of this is fixed in the sense that the binding-sca module now
provides a bindnigType that gets into the model resolver.  Now what needs to
be fixed seems to be how or where we call the 'resolve'.

Thanks

- Venkat


On Fri, Mar 14, 2008 at 9:01 PM, Venkata Krishnan <[EMAIL PROTECTED]>
wrote:

> Hi Greg,
>
> I'll take a look at this right away.
>
> Thanks
>
> - Venkat
>
>
> On Fri, Mar 14, 2008 at 8:08 AM, Greg Dritschler <
> [EMAIL PROTECTED]> wrote:
>
> > I have a question about this method in
> > CompositeConfigurationBuilderImpl.
> >
> >private SCABinding createSCABinding() {
> >SCABinding scaBinding = scaBindingFactory.createSCABinding();
> >IntentAttachPointType bindingType =
> > intentAttachPointTypeFactory.createBindingType();
> >bindingType.setName(BINDING_SCA_QNAME);
> >bindingType.setUnresolved(true);
> >((PolicySetAttachPoint)scaBinding).setType(bindingType);
> >return scaBinding;
> >}
> >
> > This is used to create the SCA binding for wires without explicit
> > bindings.
> > My question is, how is the IntentAttachPointType model resolved?  This
> > code
> > is in the build phase, which is past the read and resolve phases.  I
> > can't
> > see how it is resolved.  The consequence of not resolving it is that the
> > bindingType definition for binding.sca (which may define mayProvide or
> > alwaysProvides intents) won't be used.  I tried to add a resolve() call
> > here
> > to try to resolve the model but I couldn't figure out how to get the
> > ModelResolver to use.
> >
> > Greg
> >
>
>

SCADefinitionsProvider changes

[Venkata Krishnan]

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: IntentAttachPointType for internally-created SCA bindings

[Venkata Krishnan]

Hi Greg,

I'll take a look at this right away.

Thanks

- Venkat

On Fri, Mar 14, 2008 at 8:08 AM, Greg Dritschler <[EMAIL PROTECTED]>
wrote:

> I have a question about this method in CompositeConfigurationBuilderImpl.
>
>private SCABinding createSCABinding() {
>SCABinding scaBinding = scaBindingFactory.createSCABinding();
>IntentAttachPointType bindingType =
> intentAttachPointTypeFactory.createBindingType();
>bindingType.setName(BINDING_SCA_QNAME);
>bindingType.setUnresolved(true);
>((PolicySetAttachPoint)scaBinding).setType(bindingType);
>return scaBinding;
>}
>
> This is used to create the SCA binding for wires without explicit
> bindings.
> My question is, how is the IntentAttachPointType model resolved?  This
> code
> is in the build phase, which is past the read and resolve phases.  I can't
> see how it is resolved.  The consequence of not resolving it is that the
> bindingType definition for binding.sca (which may define mayProvide or
> alwaysProvides intents) won't be used.  I tried to add a resolve() call
> here
> to try to resolve the model but I couldn't figure out how to get the
> ModelResolver to use.
>
> Greg
>

Re: Support for binding config in definitions.xml

[Venkata Krishnan]

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 {
> >  List getPolicyIntents();
> >  List 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 {
>  List getPolicyIntents();
>   List getBindings();
> }
>
> Does this helps?
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: About StAXArtifactProcessor

[Venkata Krishnan]

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: Splitting up the bigbank demo

[Venkata Krishnan]

is2.AxisFault: unknown
>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.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: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Venkata Krishnan]

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=64271&projectId=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 Tu

Re: How can I get a list of effective policySets for a given operation?

[Venkata Krishnan]

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: 
> > 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
> > >  element? For example, if I have this:
> > >
> > > 
> > >
> > >
> > >
> > > 
> > >
> > > Can I do the the following?
> > >
> > > OperationsConfigurator ops = (OperationsConfigurator) binding;
> > > List 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: 
> > > 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
> > >>

Re: Support for binding config in definitions.xml

[Venkata Krishnan]

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 {
 List getPolicyIntents();
 List 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?

[Venkata Krishnan]

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: 
> 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
> >  element? For example, if I have this:
> >
> > 
> >
> >
> >
> > 
> >
> > Can I do the the following?
> >
> > OperationsConfigurator ops = (OperationsConfigurator) binding;
> > List 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: 
> > 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).
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>> 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: How can I get a list of effective policySets for a given operation?

[Venkata Krishnan]

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).
> >
> > 
> >
> >
> >
> >
> >
> >
> > 
> >
> > 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?

[Venkata Krishnan]

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).
>
> 
>
>
>
>
>
>
> 
>
> Thanks,
> Raymond
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: About StAXArtifactProcessor

[Venkata Krishnan]

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/~lresende<http://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: Support for binding config in definitions.xml

[Venkata Krishnan]

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]
>
>

Splitting up the bigbank demo

[Venkata Krishnan]

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

About StAXArtifactProcessor

[Venkata Krishnan]

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

Re: [Spec Related] 'provides' attribute in PolicySet

[Venkata Krishnan]

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

Re: Support for binding config in definitions.xml

[Venkata Krishnan]

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:
>
> 
>
>
>
>. . .
> 
>
> and
>
> 
>  initialContextFactory="
> org.apache.activemq.jndi.ActiveMQInitialContextFactory"
>   jndiURL="tcp://localhost:61616">
>  
>  
>   
> 
>
> Does anyone who know the policy code have any comments, suggestions or
> hints?
>
>   ...ant
>

Re: [Spec Related] 'provides' attribute in PolicySet

[Venkata Krishnan]

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 st

Re: [Spec Related] 'provides' attribute in PolicySet

[Venkata Krishnan]

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

Re: [Spec Related] 'provides' attribute in PolicySet

[Venkata Krishnan]

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

[Venkata Krishnan]

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: [DISCUSS] Validate applicable policySets for a given policy set attachpoint

[Venkata Krishnan]

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: 
> 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:
> >>
> >>  >> tuscany:policySets="..." ...>
> >> 
> >>
> >> 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: [DISCUSS] Validate applicable policySets for a given policy set attachpoint

[Venkata Krishnan]

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:
>
>  tuscany:policySets="..." ...>
> 
>
> 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: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

[Venkata Krishnan]

+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

[Venkata Krishnan]

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: Asia Open Source Symposium Code Fest is looking for help, was Fwd: Low hanging bugs for students

[Venkata Krishnan]

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/~lresende
> > http://lresende.blogspot.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Support for external configuration of PolicySets

[Venkata Krishnan]

Hi,

Based on the suggestions made by Sebastien in
http://marc.info/?l=tuscany-dev&m=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: Is it possible to define a customizable value for an intent or policy?

[Venkata Krishnan]

Hi,

I am just about going to check in what Sebastien is suggesting here.  So you
could define a PolicySet as follows : -


 
 100 
30
 
 


Where the only thing you might have to define is that structure
 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  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-dev&m=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
>

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

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>
> >
> > 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-user&m=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: svn commit: r632646 - in /incubator/tuscany/java/sca/tools/maven/maven-definitions:

[Venkata Krishnan]

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=632646&view=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=632646&view=auto
> >
> ==

Re: [VOTE] (Restarting the vote to ...) Change Tuscany Charter to remove SDO reference

[Venkata Krishnan]

+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 Crestani
> Andy Grove   
> Andrew Borley   
> ant elder   
> Brady Johnson  
> Frank Budinsky 
> Ignacio Silva-Lepe  
> Jean-Sebastien Delfino   
> kelvin goodson   
> Luciano Resende   
> Mike Edwards   
> Pete Robbins
> Raymond Feng  
> Simon Laws  
> Simon Nash  
> Venkata Krishnan  
>
> 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]
>

Re: [VOTE] Community is more important than code

[Venkata Krishnan]

+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: [DISCUSS] altering the Tuscany "Charter" in relation to SDO Java

[Venkata Krishnan]

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: Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

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  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
>

Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

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  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: Moving ServiceDiscovery and related classes to tuscany-util

[Venkata Krishnan]

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: [VOTE] Pass-by-value related SPI change

[Venkata Krishnan]

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: Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

Hi Sebastien,

Yes, I will try the scenarios you have mentioned and see if things work fine
with the transformer.

Please see my comments inline for the discussion specific to this thread.

Thanks

- Venkat

On Fri, Feb 29, 2008 at 10:16 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Jean-Sebastien Delfino wrote:
> > Raymond Feng wrote:
> >> My understanding is that there are two different issues here:
> >>
> >> 1) Where definitions.xml should be packaged in a SCA contribution?
> >> 2) How do we merge multiple definitions.xml when we build the
> >> all-in-one binary distro?
> >>
> >> So I assume Sebastien's proposal is for 1) and the maven/shade
> >> discussion is for 2).
> >>
> >> Am I right? If yes, we should have two separate threads as it becomes
> >> confusing.
> >
> > My proposal handled 1 (not forcing definitions.xml to be in a fixed
> > location in the JAR) and 2 (as it didn't require any XML merging).
> >
> > My latest comments below in this email apply to 2 (I'm basically saying
> > "if you really want to do this XML merging, then make sure it works").
> >
> > I'm branching a new thread for 1 :)
> >
>
> Here's your new thread, starting with two statements:
>
> I think that contributors should be able to place their definitions.xml
> files wherever they want in an SCA contribution JAR.


I suppose that's the way it is right now.  The definitions.xml is processed
as any other artifact in a contribution and can be anywhere.

Its only for the definitions.xml file we are packaging in the tuscany
modules - as part of the runtime do we have the issue of placing them in a
well know place.  This is because these definitions.xml  1) don't get to be
treated as a contribution artifact 2) they need to be read before
contribution artifacts are read and resolved.  So to load them during the
runtime startup we are using the ServiceDiscovery to locate all
definitions.xml across Tuscany modules and the ServiceDiscovery needs to be
give a specific location.


>
> I also think that we'll have to support external policy attachments at
> some point (see the Open CSA POLICY-15 JIRA already discussed on
> tuscany-dev on other threads), and these policy attachments won't be in
> a fixed place in the contributions either.
>

I guess these attachments would get to be treated the same way as
definitions.xml in the sense, as any other artifact.


>
> --
> Jean-Sebastien
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

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  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:
> > > >
> > > > 
> > > >META-INF/services/definitions.xml
> > > > 
> > > >
> > >
> > > 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: Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

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  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:
> >
> > 
> >META-INF/services/definitions.xml
> > 
> >
>
> 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

[Venkata Krishnan]

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
 start element
- The for every definitions.xml file read, skip upto the  and copy everything else upto the 
element
- Finally end this aggregated file with 

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:
>
> 
>META-INF/services/definitions.xml
> 
>
> 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
> > > >
> > > > 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";>
> > > >
> > > >   
> > > >
> > > > 
> > > >
> > > > 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

[Venkata Krishnan]

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
> > >
> > > 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";>
> > >
> > >   
> > >
> > > 
> > >
> > > 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]
> > >
> > >
> >
>

Moving ServiceDiscovery and related classes to tuscany-util

[Venkata Krishnan]

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: [DISCUSS] altering the Tuscany "Charter" in relation to SDO Java

[Venkata Krishnan]

"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: Trouble with aggregating definitions.xml in distro

[Venkata Krishnan]

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
>
> 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";>
>
>   
>
> 
>
> 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: Exposing composite file as a web service

[Venkata Krishnan]

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.
> >
> > http://www.osoa.org/xmlns/sca/1.0";
> >targetNamespace="http://helloworld";
> >xmlns:hw="http://helloworld";
> > name="helloworldws">
> >
> > 
> > 
> >
> > > interface="http://helloworld#wsdl.interface(HelloWorld)"
> />
> >http://localhost:8085/HelloWorldService"/>
> >
> > 
> >
> > 
> >
> >
> > Note that the  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

[Venkata Krishnan]

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

[Venkata Krishnan]

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/. 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

[Venkata Krishnan]

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  elements but no root.  Also there seems to be
> > multiple 'xml' declarations - .
> > 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

[Venkata Krishnan]

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  elements but no root.  Also there seems to be
multiple 'xml' declarations - .   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: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

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>
>
> 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-user&m=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: 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

[Venkata Krishnan]

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: 
> > 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: 
> >>> 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 {
> >...
> > 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

Re: Venkat and Mark added to Tuscany Developer group in Continuum (vmbuild1)

[Venkata Krishnan]

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://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

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

[Venkata Krishnan]

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: Legacy JMS System suppport

[Venkata Krishnan]

Hi Ant,

How about bringing in some policy handling into our JMS binding ?  We could
pick some non-functional characteristic that is typical with use of
messaging.  I am not sure what that could be - is it message encryption ?

If you can help a bit with the things to be done from the JMS side, I will
take care of all that might need to come from the PolciyFwk side. ?

Thoughts ?

Thanks

- Venkat



On Feb 12, 2008 11:34 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:

> Great, thanks Ant - I shall take a look and see :)
>
> On Feb 12, 2008 6:02 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On Feb 12, 2008 4:33 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> >
> > > Hi All,
> > >
> > > I'm trying to ascertain whether it is possible to specify a policySet
> > > applied to a service which would allow us to replace or augment the
> > > data binding?
> > >
> > > The rationale behind this is that we're trying to use a legacy JMS
> > > system as a binding.jms reference, but the TextMessage payload is
> > > marked up in XML and we don't have the ability to change the
> > > interface/implementation of this system to be able to strip off/pad
> > > the xml as appropriate.
> > >
> > > Is this possible?  Or is there another option that would allow me to
> do
> > > this?
> > >
> > > Cheers,
> > >
> > > Dave.
> > >
> >
> > There's no official way to do what you want, all the JMS binding spec
> says
> > about this is:
> >
> > "231 To support any other type of JMS message, the SCA runtime should
> > provide the means for supplying and identifying alternative data binding
> > behaviors."
> >
> > In early drafts of the spec there was a description of a Message
> processing
> > component that provided this but it got removed. We still have some of
> the
> > code for supporting those early drafts still left in the jms binding
> though
> > and i've just committed a change to make it available again from a
> composite
> > so you could try that to see if it does what you need and help us come
> up
> > with a good way to do this. This current code adds a "messageProcessor"
> > attribute to the JMS binding scdl, that class must implement the
> > MessageProcessor interface which gives access to the JMS message to
> fiddle
> > with the payloads during the invocation. There's a testcase
> demonstrating
> > this at:
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/simple/mpclient.composite
> >
> > This is all completely open to change to architect a better, more
> complete
> > solution, so if you could try this out and provide feed back that would
> be
> > great as this seems like this will be quite a common thing to want to
> do.
> >
> >...ant
> >
>
>
>
> --
> Dave Sowerby MEng MBCS
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: PolicyHanders

[Venkata Krishnan]

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 

Re: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

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: Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

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
>