Validating PolicySet attachments in SCA Artifacts.

[Venkata Krishnan]

Hi,

The PolicyFwk specs mentions that when checking out the applicability of a
PolicySet over a binding or implementation, an xpath expression specified in
the 'appliesTo' attribute of the PolicySet Defn, should be run against the
parent element of the binding or implementation.  Since this validation is
done during the build phase, I am a bit lost of how I could get hold of the
scdl fragment of the parent element of the binding or implementation.

One option I have in mind for this, is to split up the 'write' method in the
CompositeProcessor into smaller methods such as writeComponent or
writeComponentService and so on.  Then its a question of invoking one of
these methods from the build phase.   But the problems I see with this are :
-
- making the CompositeProcessor instance available to the
CompositeConfigurationBuilderImpl which could probably be done during
construction of CompositeConfigurationBuilderImpl
- the services or referneces or components that we might have at the build
phase may not quite reflect exactly what was in the scdl as there is quite a
bit of reconciliations and normalizations that they undergo.  But for the
current context, it should not matter much.

Thoughts ?

Thanks

- Venkat

Re: Move up to Axis2 1.3?

[Venkata Krishnan]

+1 to do this now.

- Venkat

On 8/14/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> Axis2 1.3 has just been released so how about moving up to that? There's a
> lot of improvements and bug fixes in it and as its the level we'll likely
> go
> 1.0 with i think it would be good to get it in sooner so we have time to
> find and fixes any problems. There's a few minor changes we need to do in
> Tuscany to move up but I have it almost going, just one failing testcase
> remaining, so what do people think, should we move up now or wait till
> after
> our next release?
>
>...ant
>

Re: Metadata related to extension types

[Venkata Krishnan]

HI Sebastien, thanks... please see my comments inline.

- Venkat

On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Venkata Krishnan wrote:
> > Hi,
> >
> > The Assembly Model specs mentions the 'need' for definitions of metadata
> > related to implementation and binding extensions types as follows:
> >
> >
> > "2665 In addition to the definition for the new implementation instance
> > element, there needs to be an
> > 2666 associated implementationType element which provides metadata about
> the
> > new implementation
> > 2667 type. The pseudo schema for the implementationType element is shown
> in
> > the following snippet:
> > 2668   > 2669
> alwaysProvides="list of
> > intent xs:QName"
> > 2670 mayProvide="list of
> > intent xs:QName"/>"
> >
> > 2749  > 2750 alwaysProvides="list of intent
> > QNames"?
> > 2751 mayProvide = "list of intent
> > QNames"?/>
> >
> > This metadata is supposed to be defined in definitions.xml file as
> defined
> > on page 57, section title "SCA Definitions".
> >
> > Since I am having to address the definitions.xml file as part of the
> policy
> > framework implementation, I have included model and processors for
> > implementationType and bindingType elements within the policy and
> policy-xml
> > modules.  But I guess this has to move out to a place that typically
> deals
> > with 'domain' related things in general.  Could people share some
> thoughts
> > on this please ?
> >
> > Thanks
> >
> > - Venkat
> >
> >
>
> ImplementationType and BindingType are policy definitions, so what
> you've done - having StAX artifact processors for them in module
> policy-xml - makes sense to me. I'm not sure why we'd want to move them
> to a domain module, as that would tie unrelated aspects of an SCA domain
> together (and that wouldn't be good IMO).


I  am really not able to classify these two as just related to policy
implementation alone.  From what I understand these two are mechanisms for
extensions to publish meta-data in general and not specifically metadata
related to their support for policies.  I just about inferred this from what
the Assembly specs says.  While today, we seem to find this a good place to
define policy related metadata, I guess in future this is going to be
accomodating more.  Is this a right train of thoughts ?

With respect to SCA definitions (contained in definitions.xml), we need:
> - a proper Definitions model separate from the policy module (as it can
> be used to define shared binding declarations which have nothing to do
> with policies - as described in the JMS binding spec)
> - a URLArtifactProcessor and StAXArtifactProcessor for definitions.xml
>
> I think we should follow the same pattern as the other models:
> - the Definitions model and its factory in a definition module
> - the URLArtifactProcessor and StAXArtifactProcessor in a definition-xml
> module
>
> The assembly module and the bindings that need to leverage shared
> definitions will need to depend on this new definition module so I'd
> suggest to it very minimal with just the Definitions model, unless you
> want to have to solve circular dependencies issues :)
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Associating BindingType with Binding instances and ImplementationType with implementation instances

[Venkata Krishnan]

Hi,

There is a phase in the policy fwk impl that needs to validate attachment
points for the intents attached (or specified) in them.  A PolicyIntent
definition has a 'constrains' attribute that lists the valid attachment
points (bindings / implementations) for an intent.  This list is a list of
QNames that point to bindingtypes or implementation types such as binding.wsor
implementation.java.

Having said that, presently I am doing this sort of validation during the
build phase.  For example I am looking into each binding instance, getting
the list of intents attached to it and then for each intent I want to look
up the 'constrains' attribute to see if it lists the 'bindingtype' of the
binding instance in question.  But then, where do I get the bindingType
given the binding instance ?

To support this, seems like we could had a QName field to the Binding and
Implementation abstractions to represent the BindingType and
ImplementationType respectively.  As per the extension model section in the
AssemblySpecs it does seem like every implementation and binding extension
does 'need' to define implementation and bindingType elements and I have
already implemented abstractions for these elements in the Policy module.

References : Pg 5 of Policy Fwk specs, Pg 60 and Pg 62 of Assembly Model
specs.

Thoughts ?

Thanks

- Venkat

Re: Metadata related to extension types

[Venkata Krishnan]

Hi Simon,

You mentioned whatever was running in my mind - a module for sca-domain.  I
did look at the host-embeded for a fit but wasn't comfortable.  I'd imagine
the sca-domain to be a module on its own - having its model, processors and
other things and various runtimes should strap up this domain.  Though the
definitions.xml has mostly about policy related things I'd expect it to
accomodate more things that go just beyond policy and pertain braodly to the
domain.  Infact I'd guess somewhere down the line with the distributed
domain scaling up, this file 'could' have a role to play.

Thanks.

- Venkat

On 8/13/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 8/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > The Assembly Model specs mentions the 'need' for definitions of metadata
> > related to implementation and binding extensions types as follows:
> >
> >
> > "2665 In addition to the definition for the new implementation instance
> > element, there needs to be an
> > 2666 associated implementationType element which provides metadata about
> > the
> > new implementation
> > 2667 type. The pseudo schema for the implementationType element is shown
> > in
> > the following snippet:
> > 2668   > 2669
> alwaysProvides="list
> > of
> > intent xs:QName"
> > 2670 mayProvide="list of
> > intent xs:QName"/>"
> >
> > 2749  > 2750 alwaysProvides="list of intent
> > QNames"?
> > 2751 mayProvide = "list of intent
> > QNames"?/>
> >
> > This metadata is supposed to be defined in definitions.xml file as
> defined
> > on page 57, section title "SCA Definitions".
> >
> > Since I am having to address the definitions.xml file as part of the
> > policy
> > framework implementation, I have included model and processors for
> > implementationType and bindingType elements within the policy and
> > policy-xml
> > modules.  But I guess this has to move out to a place that typically
> deals
> > with 'domain' related things in general.  Could people share some
> thoughts
> > on this please ?
> >
> > Thanks
> >
> > - Venkat
> >
> Hi Venkat
>
> These all seem to be policy related apart from  which, if I
> understand it correctly, allows binding definitions to be pre defined for
> a
> domain.
>
> I think we have three places that do domain kinds of things.
>   host-embedded
>   distributed (am just about to check in a new version along with a
> distributed-impl)
>   topology (this might go depending on the answer to the base uri
> question)
>
> None of these look like particularly likely candidates. How about we have
> a
> "domain" module for this domain level information?
>
> Simon
>

Metadata related to extension types

[Venkata Krishnan]

Hi,

The Assembly Model specs mentions the 'need' for definitions of metadata
related to implementation and binding extensions types as follows:


"2665 In addition to the definition for the new implementation instance
element, there needs to be an
2666 associated implementationType element which provides metadata about the
new implementation
2667 type. The pseudo schema for the implementationType element is shown in
the following snippet:
2668  "

2749 

This metadata is supposed to be defined in definitions.xml file as defined
on page 57, section title "SCA Definitions".

Since I am having to address the definitions.xml file as part of the policy
framework implementation, I have included model and processors for
implementationType and bindingType elements within the policy and policy-xml
modules.  But I guess this has to move out to a place that typically deals
with 'domain' related things in general.  Could people share some thoughts
on this please ?

Thanks

- Venkat

Re: Intent and Policy attachments on Operations

[Venkata Krishnan]

Hi Sebastien, thanks for that explanation.  I get your point.  For now
I'd revert back those changes to 'Operation' and will figure out an
alternative.

- Venkat

On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Sebastien, thanks for responding.   I am still not convinced about
> > Intent instances having links to things in the assembly model.  I
> > perceive the Policy module to be independent of any other SCA module
> > (assembly, or interface, ... ).
> >
> >
> I just responded to some of these in a response to Ant's email in the
> same thread. I think I covered your questions there.
>
> All of this can probably be summarized as:
>
> If you're not convinced that Intent should point to interface/operation,
> try to draw a parallel with how service/reference point to interface.
>
> or
>
> An intent configures a particular use of an interface/operation (so
> it should point to that operation...)
>
> > Also when we are resovling or building the composites, it seems a bit
> > odd to me to go after a PolicyRegistry and get the bunch of all
> > Intents defined for a domain and then run thro each to find the
> > operations that use it.  Also I see that there are other decorations
> > as well to the Operation that exists today - one of which is the
> > databinding.  So, why wouldn't intents and policy sets simply add on.
> >
>
> Because Databindings should not be doing this in the first place :)
>
> > However if you say that we share instances of Operations across
> > interface definitions, then we probably need to store this map in the
> > InterfaceDef.. or if the InterfaceDef instances are shared then we
> > have look at the next higher level thing that is not shared to manage
> > this information.
> >
> > Am I missing some point here ?
> >
> > - Venkat
> >
>
> The models are currently using lists and I'd suggest to continue on the
> same path.
>
> If you really wanted to switch the relationship around, I think you'd
> have to come up with a new model object containing pointers to
> interface, operation, and the list of intents that apply to it. Then try
> to give a meaningful name to that object, if you can't find a good name
> for it, maybe that's because it's just too artificial and does not
> represent a real entity in the model but instead a disguised
> relationship? ... which is simply represented at the moment as an Intent
> -> Operation pointer I'll let you think about it :)
>
> > On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >> Venkata Krishnan wrote:
> >>
> >>> Hi,
> >>>
> >>> The Assembly Specs and the PolicyFramework specs allows for intents
> >>> and policysets to be specified on Operations.
> >>>
> >>> To implement this I'd expect that the Operation interface support
> >>> methods to hold a set of required intents and policysets.  This also
> >>> seems in sync with the schema definition for Operation.
> >>>
> >>> However in the existing code this has been modeled as an Intent
> >>> instance having a list of operations over which the intent could
> >>> apply.  Similarly a PolicySet instance has a list of operations to
> >>> which the policyset applies.  Is there any specific reason for
> >>> modeling it this way?
> >>>
> >>> I am in progress with changes that change this to what I have
> >>> mentioned in the second paragraph of this mail.  If I am heading in
> >>> the wrong direction, could somebody shout please.
> >>>
> >>> Thanks
> >>>
> >>> - Venkat
> >>>
> >>>
> >>>
> >> The "Intent -> operations" relationship was modeled like this 
> >> intentionally.
> >>
> >> Here's why:
> >>
> >> If you're talking about o.a.t.interfacedef.Operation, then I don't think
> >> it can hold intents. Operation represents a business method/operation on
> >> a business interface, potentially used in multiple Services or
> >> References... with different sets of intents.
> >>
> >> The  element in SCA assembly XML does not represent the
> >> actual operation on the business interface, it is just the syntax used
> >> to group the intents that apply to a given operation, within the context
> >> of a particular service or reference.
> >>
> >> 

Re: Policy intents and policySets on bindings and implementations

[Venkata Krishnan]

Hi Sebastien,

Yes, this was what I intended to do initially.  But got a bit
concerned about losing the original state of the model after build
time.  I was thinking of a Admin or Mgmt function that might display
the original configurations before thing got built i.e. computed or
aggregated.  For this I thought its best to have information that was
originially loaded preserved.

The 'ComputedIntents' and 'ComputedPolicies' will only emerge during
the build time.  I could not figure out a better place to hold this
information than the model itself.

Well, that's just for explaining the thoughts behind that
implementation.  I am open to cutting this out :).

Independent of this change, could you please help me get some clarity
on how we could retrieve the original configurations.  Thanks.

- Venkat

On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> I noticed that bindings and implementations now have:
> - intents
> - policySets
>
> and
>
> - computedIntents
> - computedPolicySets
>
> How about simplifying this a bit and doing what we've done in
> CompositeBuilder with all other similar cases like bindings, property
> configuration etc.
> - we read intents
> - we compute/combine/override intents declared at different levels
> - eventually the intents field contains the effective (computed) intents
>
> With bindings on references for example we don't have bindings and
> computedBindings...
>
> This will make the model simpler, and will also avoid confusion when
> people use the model, like: hmm I'm looking at Binding, which intent
> field should I use? intents or computedIntents? should I add to both?
> which one should I get the intents from? if I add to one does the other
> reflect my changes? etc. :)
>
> --
> Jean-Sebastien
>
>
> -
> 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: Intent and Policy attachments on Operations

[Venkata Krishnan]

Sebastien, thanks for responding.   I am still not convinced about
Intent instances having links to things in the assembly model.  I
perceive the Policy module to be independent of any other SCA module
(assembly, or interface, ... ).

Also when we are resovling or building the composites, it seems a bit
odd to me to go after a PolicyRegistry and get the bunch of all
Intents defined for a domain and then run thro each to find the
operations that use it.  Also I see that there are other decorations
as well to the Operation that exists today - one of which is the
databinding.  So, why wouldn't intents and policy sets simply add on.

However if you say that we share instances of Operations across
interface definitions, then we probably need to store this map in the
InterfaceDef.. or if the InterfaceDef instances are shared then we
have look at the next higher level thing that is not shared to manage
this information.

Am I missing some point here ?

- Venkat

On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > The Assembly Specs and the PolicyFramework specs allows for intents
> > and policysets to be specified on Operations.
> >
> > To implement this I'd expect that the Operation interface support
> > methods to hold a set of required intents and policysets.  This also
> > seems in sync with the schema definition for Operation.
> >
> > However in the existing code this has been modeled as an Intent
> > instance having a list of operations over which the intent could
> > apply.  Similarly a PolicySet instance has a list of operations to
> > which the policyset applies.  Is there any specific reason for
> > modeling it this way?
> >
> > I am in progress with changes that change this to what I have
> > mentioned in the second paragraph of this mail.  If I am heading in
> > the wrong direction, could somebody shout please.
> >
> > Thanks
> >
> > - Venkat
> >
> >
>
> The "Intent -> operations" relationship was modeled like this intentionally.
>
> Here's why:
>
> If you're talking about o.a.t.interfacedef.Operation, then I don't think
> it can hold intents. Operation represents a business method/operation on
> a business interface, potentially used in multiple Services or
> References... with different sets of intents.
>
> The  element in SCA assembly XML does not represent the
> actual operation on the business interface, it is just the syntax used
> to group the intents that apply to a given operation, within the context
> of a particular service or reference.
>
> So basically we need to represent the association:
> a set of intents -> a set of operations in the context of a particular
> service/reference
>
> There's basically two ways to represent this:
> a) In an intent, list the business operations that the intent applies to
> or
> b) Invent a new object representing an "operation used within the
> context of a reference/service", pointing to the actual operation +
> listing the intents
>
> The assembly model being a logical model it does not have to follow the
> convolutions of the particular XML syntax, and it seems to me that (a)
> is more logical than (b). At least it'll allow us to easily find which
> operations a particular intent (and the corresponding interceptors)
> applies to.
>
> Hope this helps.
>
> --
> Jean-Sebastien
>
>
> -
> 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: New itest folder: guidelines

[Venkata Krishnan]

Hi Venu,

To start with, you could also simply copy over one of the poms in the
existing itests and modify the artifact names, dependencies etc. that
is specific to what you plan to do.

- Venkat

On 8/9/07, venu reddy <[EMAIL PROTECTED]> wrote:
> Folks, I am planing to create my own folder (venu) in java/sca/itests  and
> write few sample tests. Can any  one please post if  you have any guidelines
> on writing pom.xml (\java\sca\itests\venu\pom.xml)  to include my sample
> tests for maven to build and execute.
> Thanks,
> Venu.
>
> -
> A 'wish' changes nothing. A 'decision' changes everything!  Anon
>

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

Intent and Policy attachments on Operations

[Venkata Krishnan]

Hi,

The Assembly Specs and the PolicyFramework specs allows for intents
and policysets to be specified on Operations.

To implement this I'd expect that the Operation interface support
methods to hold a set of required intents and policysets.  This also
seems in sync with the schema definition for Operation.

However in the existing code this has been modeled as an Intent
instance having a list of operations over which the intent could
apply.  Similarly a PolicySet instance has a list of operations to
which the policyset applies.  Is there any specific reason for
modeling it this way?

I am in progress with changes that change this to what I have
mentioned in the second paragraph of this mail.  If I am heading in
the wrong direction, could somebody shout please.

Thanks

- Venkat

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

Re: Release management for next release, was: SCA 0.92 release?

[Venkata Krishnan]

Hi,

Theres been lots of discussion.  So let me summarize my understanding
/ imaginiation : -

- We will cut a branch around Aug 18th for Release 0.95.  As always,
once the branch is cut we need to be watchful on the commits
(including getting the RMs nod to significant ones) to the branch and
also ensure the trunk is always in sync.
- Post 0.95, maybe a couple of weeks after the release, we'd cut
another branch and head with that for 1.0 release.   Being a 1.0
release, we prob. need a branch early as that so that we can whet the
things we are targetting for the release.

Is that all right ?

- Venkat



On 8/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> 
>
> Sure, 1.0 development should happen in trunk, but I was trying to
> > respond to a different point brought up by Raymond.
> >
> > On Aug 18, we are going to cut the August release branch. The point is
> > about allowing small changes, bug fixes and improvements to continue in
> > that branch while we are putting the release distros together, with the
> > following conditions:
> >
> > - No completely new function, only bug fixes and improvements.
> > - No changes to dependencies or structure of the distro (unless required
> > to fix a major bug, and approved by the RM).
> > - Commits go with a full build of the runtime, itests, samples and demos,
> > and verification that the samples still work following the steps documented
> > in their readmes.
>
>
> Sure ok, the branch wont be immediately frozen, but, and its a big but, we
> need to be really careful with that as every time we've allowed development
> to continue in the branch it has ended up delaying a release. No one can on
> each commit do a full review including running all the samples, reading all
> the readme's and vetting all the legal stuff, so things get missed. Its also
> hard to review things thoroughly after you've already done a review a couple
> of times, so things start getting missed. I'd rather delay taking the branch
> than plan on being able to continue development in the branch. There's been
> a lot of change in trunk since 0.91, maybe what we should do is start the
> clean up work, legal review, sorting out the distributions for all the
> module changes etc in trunk towards then end of next week but not take the
> branch till very early the following week with the expectation of getting
> RC1 out really quickly.
>
>...ant
>

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

Re: Policy Attachments Resolution in the Assembly Model

[Venkata Krishnan]

:) thanks.  That makes sense to me.

- Venkat

On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Not sure I understand this.   I guess its to do with the
> > ExtensibleURLArtifactProcessor that strips off the extension and
> > searches for processors only by those extensions.  So even if the
> > URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
> > still have a problem.  I guess we have to designate some files as
> > configuration files that have specific designated processors.  When
> > the contribution service picks up these files it must invoke the
> > corresponding artifact processors and in all other cases - for
> > application artifacts it could go by what its going currently.  Makes
> > sense ?
> >
> > - Venkat
> >
> >
> > On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> >> [snip]
> >> Venkata Krishnan wrote:
> >>
> >>> Hi Sebastien, thanks.  I've figured out all of this already :)  Just
> >>> the one hanging thing - the definitions.xml is an artifact that might
> >>> have to be picked up by the contribution service.  While processors
> >>> for all other documents could be found by their unique extensions such
> >>> as .composte or .constrainingType its a bit of a trouble with
> >>> definitions.xml, the extension .xml being generic.
> >>>
> >>> Could we extend the logic in ExtensibleURLArtifactProcessor.read to
> >>> first look at extensions and if not found try with the name of the
> >>> file ?  So the principle is - search for processors either by
> >>> extensions or by the file name for specific kind of documents.  I sort
> >>> of feel a bit clumsy about this approach - whats an alternative that
> >>> could be cleaner ?
> >>>
> >>> Thanks
> >>>
> >>>
> >>>
> >>>
> >> Here's a simple change to make this cleaner:
> >>
> >> Instead of URLArtifactProcessor.getType() returning
> >> .composite for *.composite files
> >> definition.xml for definition.xml files
> >>
> >> URLArtifactProcessor.getType() could return
> >> *.composite for *.composites files
> >> definitions.xml for definition.xml
> >>
> >> Thoughts?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
>
> I didn't say that this didn't require any changes in any classes. I'm
> just proposing a change to how URLArtifactProcessors indicate what they
> support:
> *.foo for all files with extension .foo
> foo.bar for file foo.bar
>
> Then, yeah sure, some classes will have to change to accomodate this new
> way of declaring URLArtifactProcessors.
>
> --
> Jean-Sebastien
>
>
> -
> 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: Policy Attachments Resolution in the Assembly Model

[Venkata Krishnan]

Not sure I understand this.   I guess its to do with the
ExtensibleURLArtifactProcessor that strips off the extension and
searches for processors only by those extensions.  So even if the
URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
still have a problem.  I guess we have to designate some files as
configuration files that have specific designated processors.  When
the contribution service picks up these files it must invoke the
corresponding artifact processors and in all other cases - for
application artifacts it could go by what its going currently.  Makes
sense ?

- Venkat


On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> [snip]
> Venkata Krishnan wrote:
> > Hi Sebastien, thanks.  I've figured out all of this already :)  Just
> > the one hanging thing - the definitions.xml is an artifact that might
> > have to be picked up by the contribution service.  While processors
> > for all other documents could be found by their unique extensions such
> > as .composte or .constrainingType its a bit of a trouble with
> > definitions.xml, the extension .xml being generic.
> >
> > Could we extend the logic in ExtensibleURLArtifactProcessor.read to
> > first look at extensions and if not found try with the name of the
> > file ?  So the principle is - search for processors either by
> > extensions or by the file name for specific kind of documents.  I sort
> > of feel a bit clumsy about this approach - whats an alternative that
> > could be cleaner ?
> >
> > Thanks
> >
> >
> >
> Here's a simple change to make this cleaner:
>
> Instead of URLArtifactProcessor.getType() returning
> .composite for *.composite files
> definition.xml for definition.xml files
>
> URLArtifactProcessor.getType() could return
> *.composite for *.composites files
> definitions.xml for definition.xml
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> -
> 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: Policy Attachments Resolution in the Assembly Model

[Venkata Krishnan]

Yes Luciano, that's what I am suggesting.

- Venkat

On 8/8/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >Could we extend the logic in ExtensibleURLArtifactProcessor.read to
> >first look at extensions and if not found try with the name of the
> >file ?  So the principle is - search for processors either by
> >extensions or by the file name for specific kind of documents.  I sort
> >of feel a bit clumsy about this approach - whats an alternative that
> >could be cleaner ?
>
> Not sure i got this right, but are you asking for the ability to
> register artifactProcessors by fileName as well as extension ?
>
>
> On 8/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > Hi Sebastien, thanks.  I've figured out all of this already :)  Just
> > the one hanging thing - the definitions.xml is an artifact that might
> > have to be picked up by the contribution service.  While processors
> > for all other documents could be found by their unique extensions such
> > as .composte or .constrainingType its a bit of a trouble with
> > definitions.xml, the extension .xml being generic.
> >
> > Could we extend the logic in ExtensibleURLArtifactProcessor.read to
> > first look at extensions and if not found try with the name of the
> > file ?  So the principle is - search for processors either by
> > extensions or by the file name for specific kind of documents.  I sort
> > of feel a bit clumsy about this approach - whats an alternative that
> > could be cleaner ?
> >
> > Thanks
> >
> > - Venkat
> >
> > On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > Venkata Krishnan wrote:
> > > > Hi,
> > > >
> > > > Now that I have the  basic policy model in place I am trying to link
> > > > up this with the assembly model now.
> > > >
> > > > The policy intents and policy sets applicable for a domain are defined
> > > > in the definitions.xml.  There is a SCADefinitions processor that
> > > > deals with reading and resolving the intents and policysets in the
> > > > definitions.xml.  The SCADefinitions processor has a model resolver
> > > > into which the the various policy intents and policy sets that are
> > > > read get added.  All  of this is a part of the policy-xml module.
> > > >
> > > > Now looking into the aspect of dealing with the 'attachments' of
> > > > policy intents and policy sets into various SCA constructs, I see
> > > > there is a need to resolve the intents and policysets with those that
> > > > have been read from the definitions.xml.  This means an artifact
> > > > processor such as the CompositeProcessor needs to be passed a resolver
> > > > that has the various policy intents and policy sets in it.
> > > >
> > > > Now the question is, do we assume that we use the same resolver that
> > > > is used to add up the read sca contructs is used to also add the
> > > > policy intents and policysets ?
> > > >
> > > > or...
> > > >
> > > > Going by the discussion in
> > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I
> > > > am given to understand that its best to keep all of the things related
> > > > to policies - the processor, the resolver etc. separate from those
> > > > that we have for the assembly model.  If this is the case then the
> > > > CompositeProcessor, the ConstrainingType Processor etc. all have to be
> > > > set with the instance of a SCADefinitionsResolver that will be used to
> > > > resolve to policy related things.
> > > >
> > > > Could somebody please help me with some perspectives on which one of
> > > > the above two is better to follow?
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > > >
> > >
> > > I think we can follow the same pattern as implementations, bindings, etc:
> > > - In CompositeProcessor.resolve(model, resolver), call
> > > resolver.resolveModel(policyToResolve) to resolve an unresolved policy
> > > model object, then attach the resolved policy to the composite.
> > > - In your policy-xml module, provide a PolicyModelResolver and register
> > > it in the ModelResolverExtensionPoint. PolicyModelResolver will handle
> > > the resolution of Policy model objects (by qname I guess). Lo

Re: Policy Attachments Resolution in the Assembly Model

[Venkata Krishnan]

Hi Sebastien, thanks.  I've figured out all of this already :)  Just
the one hanging thing - the definitions.xml is an artifact that might
have to be picked up by the contribution service.  While processors
for all other documents could be found by their unique extensions such
as .composte or .constrainingType its a bit of a trouble with
definitions.xml, the extension .xml being generic.

Could we extend the logic in ExtensibleURLArtifactProcessor.read to
first look at extensions and if not found try with the name of the
file ?  So the principle is - search for processors either by
extensions or by the file name for specific kind of documents.  I sort
of feel a bit clumsy about this approach - whats an alternative that
could be cleaner ?

Thanks

- Venkat

On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > Now that I have the  basic policy model in place I am trying to link
> > up this with the assembly model now.
> >
> > The policy intents and policy sets applicable for a domain are defined
> > in the definitions.xml.  There is a SCADefinitions processor that
> > deals with reading and resolving the intents and policysets in the
> > definitions.xml.  The SCADefinitions processor has a model resolver
> > into which the the various policy intents and policy sets that are
> > read get added.  All  of this is a part of the policy-xml module.
> >
> > Now looking into the aspect of dealing with the 'attachments' of
> > policy intents and policy sets into various SCA constructs, I see
> > there is a need to resolve the intents and policysets with those that
> > have been read from the definitions.xml.  This means an artifact
> > processor such as the CompositeProcessor needs to be passed a resolver
> > that has the various policy intents and policy sets in it.
> >
> > Now the question is, do we assume that we use the same resolver that
> > is used to add up the read sca contructs is used to also add the
> > policy intents and policysets ?
> >
> > or...
> >
> > Going by the discussion in
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I
> > am given to understand that its best to keep all of the things related
> > to policies - the processor, the resolver etc. separate from those
> > that we have for the assembly model.  If this is the case then the
> > CompositeProcessor, the ConstrainingType Processor etc. all have to be
> > set with the instance of a SCADefinitionsResolver that will be used to
> > resolve to policy related things.
> >
> > Could somebody please help me with some perspectives on which one of
> > the above two is better to follow?
> >
> > Thanks
> >
> > - Venkat
> >
> >
>
> I think we can follow the same pattern as implementations, bindings, etc:
> - In CompositeProcessor.resolve(model, resolver), call
> resolver.resolveModel(policyToResolve) to resolve an unresolved policy
> model object, then attach the resolved policy to the composite.
> - In your policy-xml module, provide a PolicyModelResolver and register
> it in the ModelResolverExtensionPoint. PolicyModelResolver will handle
> the resolution of Policy model objects (by qname I guess). Look for
> CompositeModelResolver for an example of a ModelResolver.
>
> --
> Jean-Sebastien
>
>
> -
> 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: Making the base artifact processor utilities more readily available

[Venkata Krishnan]

Hi Sebastien, thanks.  Here are the processors in the policy-xml
- 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-xml/src/main/java/org/apache/tuscany/sca/policy/xml/PolicySetProcessor.java
- 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-xml/src/main/java/org/apache/tuscany/sca/policy/xml/PolicyIntentProcessor.java

Right now these two have copies of getQName, getName, getQNameValue
copied over.  These seem to be pretty generic and useful util kind of
methods.

Thanks

- Venkat

On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > +1 to move some commonly useful parts to utils area.  I have also
> > ended up copying some bits of code into processors in the policy-xml
> > module.
> >
> > - Venkat
> >
> > On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >> On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>
> >>> "not completely trivial" is definitely a better term :-).
> >>>
> >>> Thanks,
> >>> Raymond
> >>>
> >>> - Original Message -
> >>> From: "ant elder" <[EMAIL PROTECTED]>
> >>> To: 
> >>> Sent: Tuesday, July 03, 2007 10:55 AM
> >>> Subject: Re: Making the base artifact processor utilities more readily
> >>> available
> >>>
> >>>
> >>>
> >>>> How strict would it be on the error-prone bit be in "Only expose the
> >>>> utility/helper classes if they are common and error-prone"? For example,
> >>>> there's an AbstractImplementation class here which I think is useful and
> >>>> i've used multiple times, but its arguable how error-prone the code is.
> >>>>
> >>>>
> >>>>
> >>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/utils/AbstractImplementation.java
> >>>
> >>>> How about "not completely trivial" instead of "error-prone"?
> >>>>
> >>>>   ...ant
> >>>>
> >>>> On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> At this moment, we use the term "SPI" to represent all the interfaces
> >>>>>
> >>> and
> >>>
> >>>>> classes accessible to the extension developers. I think it can be
> >>>>>
> >>> further
> >>>
> >>>>> divided into two categories.
> >>>>>
> >>>>> 1) The contract interfaces/classes
> >>>>> 2) The utility/helper classes
> >>>>>
> >>>>> 1 is mandatory while 2 is optional to extension developers. I'm fine to
> >>>>> expose the helper/utility classes as long as the following criteria are
> >>>>> meet:
> >>>>>
> >>>>> a) Make it obvious (for example, using util. as part of the package
> >>>>>
> >>> name)
> >>>
> >>>>> for extension developers to understand they are optional helper/utility
> >>>>> classes which are not part of the contract
> >>>>> b) Only expose the utility/helper classes if they are common and
> >>>>> error-prone
> >>>>> to implement by individual extensions.
> >>>>>
> >>>>> Thanks,
> >>>>> Raymond
> >>>>>
> >>>>> - Original Message -
> >>>>> From: "Simon Laws" <[EMAIL PROTECTED]>
> >>>>> To: ; <[EMAIL PROTECTED]>
> >>>>> Sent: Tuesday, July 03, 2007 7:12 AM
> >>>>> Subject: Re: Making the base artifact processor utilities more readily
> >>>>> available
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>>>>>>
> >>>>>>>> In writing the Topology mode I had to make a copy of the base
> >>>>>>>>
> >>>>> artifact
> >>>>>
> >>>>>>>> processor as it only has pack

Re: Extending all Bindings from AbstractBinding

[Venkata Krishnan]

HI Sebastien,

The Binding interface contains methods that are setters / getters for
name, uri and then by extending the intent and policy attach points it
inherits getters for the list of intents and policy sets.  To
implement these methods most of the bindings end up have the same
chunk of code that declares these files and then provides the getters
/ setters around them.  This is what has been abstracted into the
AbstractBinding class.

Thanks.

- Venkat


On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Venkata Krishnan wrote:
> > Hi,
> >
> > I just observed that, not all bindings are extending from
> > AbstractBinding though all implement the interface Binding.  The
> > AbstractBinding class provides an implementation for the Binding
> > interface and in my opinion should be used by all bindings to avoid
> > duplication of code that implements the BInding interface.
> >
> > I feel the pinch for this now as I am adding a couple of things for
> > policies and seems a bit odd to go an copy over the same things across
> > a dozen classes.
> >
> > Let me know what people feel about this and I can go and fix all the
> > bindings for this.
> >
> > Thanks.
> >
> > - Venkat
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> This might sound like a naive question, but if all bindings start to
> extend a common AbstractBinding class then why will we need a Binding
> interface at all? :)
>
> Another way to look at this is that maybe the code that you're copying
> shouldn't be part of the binding in the first place. Could you please
> point to the specific code bits causing the issue to help me understand?
> Thanks.
>
> --
> Jean-Sebastien
>
>
> -
> 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: Extending all Bindings from AbstractBinding

[Venkata Krishnan]

Ant, just what I was wanting to mention - you beat me to it.  I really
think additions may not be a disturbance to the SPIs.  This could be a
start to looking at how much of the extension-helper we could start
moving into the SPIs. But am a bit curious about where this sort of
thing will go into the SPI.  Do we intend another package
org.apache.tuscany.sca.assembly in the spi module ?

Thanks

- Venkat


On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote:
> The ExtensionHelper module was originally intended as just an interim thing
> while we were sorting out the SPIs anyway, so if we  go ahead with this its
> fine to move those abstract classes into the SPI module. Just adding
> something new to the SPI module seems fine to me as its not going to break
> anything so I'm still +1 on doing this.
>
>...ant
>
> On 8/8/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 8/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I just observed that, not all bindings are extending from
> > > AbstractBinding though all implement the interface Binding.  The
> > > AbstractBinding class provides an implementation for the Binding
> > > interface and in my opinion should be used by all bindings to avoid
> > > duplication of code that implements the BInding interface.
> > >
> > > I feel the pinch for this now as I am adding a couple of things for
> > > policies and seems a bit odd to go an copy over the same things across
> > > a dozen classes.
> > >
> > > Let me know what people feel about this and I can go and fix all the
> > > bindings for this.
> > >
> > > Thanks.
> > >
> > > - Venkat
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > I like the idea but it gives me a problem with the sca binding. Adding it
> > to
> > SCABinding would imply a cyclic dependency as AbstractBinding is
> > implemented
> > in ExtensionHelper (as putting it in the SPI would imply and SPI change I
> > guess) which in turn depends on quite a lot of other stuff. If we could
> > separate out AbstractBinding somehow it would work for me. Maybe needs  to
> > wait until our SPI sweep. +1 to using it where ever it can safely be used.
> >
> > Simon
> >
>

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

Extending all Bindings from AbstractBinding

[Venkata Krishnan]

Hi,

I just observed that, not all bindings are extending from
AbstractBinding though all implement the interface Binding.  The
AbstractBinding class provides an implementation for the Binding
interface and in my opinion should be used by all bindings to avoid
duplication of code that implements the BInding interface.

I feel the pinch for this now as I am adding a couple of things for
policies and seems a bit odd to go an copy over the same things across
a dozen classes.

Let me know what people feel about this and I can go and fix all the
bindings for this.

Thanks.

- Venkat

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

Re: Release management for next release, was: SCA 0.92 release?

[Venkata Krishnan]

+1 for Ant taking doing the RM since his seasoned hand will help up
get things our quickly given the little time we have.

Ant, if you are OK with this count me in for any help you might require in this.

Thanks.

- Venkat

On 8/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> ant elder wrote:
> > On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >> With the SCA 0.91 release now being voted on how about starting on 0.92?
> >>
> >> I've already been adding some things I'm interested in getting done to the
> >> next release wiki page -
> >> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
> >>  so far thats mainly related to improving web services functionality.
> >>
> >> So anyone else interested in helping with an 0.92 release or have any
> >> function they'd like to suggest or add to the wiki page? How does aiming 
> >> for
> >> getting it done 4 - 6 weeks again sound?
> >>
> >>...ant
> >>
> >>
> >>
> > Bringing this thread up again as time is ticking on if we want to get a
> > release out this month. How would people feel about taking a branch for this
> > release in a bit less than 2 weeks, say aiming for the 14/15th of August?
> > That should just about give enough time for clean up and voting to get a
> > release out by the end of  August.
> >
>
> Ant,
>
> Thanks for reminding us that time is ticking if we want to get another
> release out this month :) I'd like to nominate you as release manager,
> if you're ok with it.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> -
> 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]

Policy Attachments Resolution in the Assembly Model

[Venkata Krishnan]

Hi,

Now that I have the  basic policy model in place I am trying to link
up this with the assembly model now.

The policy intents and policy sets applicable for a domain are defined
in the definitions.xml.  There is a SCADefinitions processor that
deals with reading and resolving the intents and policysets in the
definitions.xml.  The SCADefinitions processor has a model resolver
into which the the various policy intents and policy sets that are
read get added.  All  of this is a part of the policy-xml module.

Now looking into the aspect of dealing with the 'attachments' of
policy intents and policy sets into various SCA constructs, I see
there is a need to resolve the intents and policysets with those that
have been read from the definitions.xml.  This means an artifact
processor such as the CompositeProcessor needs to be passed a resolver
that has the various policy intents and policy sets in it.

Now the question is, do we assume that we use the same resolver that
is used to add up the read sca contructs is used to also add the
policy intents and policysets ?

or...

Going by the discussion in
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I
am given to understand that its best to keep all of the things related
to policies - the processor, the resolver etc. separate from those
that we have for the assembly model.  If this is the case then the
CompositeProcessor, the ConstrainingType Processor etc. all have to be
set with the instance of a SCADefinitionsResolver that will be used to
resolve to policy related things.

Could somebody please help me with some perspectives on which one of
the above two is better to follow?

Thanks

- Venkat

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

Re: Making the base artifact processor utilities more readily available

[Venkata Krishnan]

+1 to move some commonly useful parts to utils area.  I have also
ended up copying some bits of code into processors in the policy-xml
module.

- Venkat

On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > "not completely trivial" is definitely a better term :-).
> >
> > Thanks,
> > Raymond
> >
> > - Original Message -
> > From: "ant elder" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Tuesday, July 03, 2007 10:55 AM
> > Subject: Re: Making the base artifact processor utilities more readily
> > available
> >
> >
> > > How strict would it be on the error-prone bit be in "Only expose the
> > > utility/helper classes if they are common and error-prone"? For example,
> > > there's an AbstractImplementation class here which I think is useful and
> > > i've used multiple times, but its arguable how error-prone the code is.
> > >
> > >
> > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/utils/AbstractImplementation.java
> > >
> > > How about "not completely trivial" instead of "error-prone"?
> > >
> > >   ...ant
> > >
> > > On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Hi,
> > >>
> > >> At this moment, we use the term "SPI" to represent all the interfaces
> > and
> > >> classes accessible to the extension developers. I think it can be
> > further
> > >> divided into two categories.
> > >>
> > >> 1) The contract interfaces/classes
> > >> 2) The utility/helper classes
> > >>
> > >> 1 is mandatory while 2 is optional to extension developers. I'm fine to
> > >> expose the helper/utility classes as long as the following criteria are
> > >> meet:
> > >>
> > >> a) Make it obvious (for example, using util. as part of the package
> > name)
> > >> for extension developers to understand they are optional helper/utility
> > >> classes which are not part of the contract
> > >> b) Only expose the utility/helper classes if they are common and
> > >> error-prone
> > >> to implement by individual extensions.
> > >>
> > >> Thanks,
> > >> Raymond
> > >>
> > >> - Original Message -
> > >> From: "Simon Laws" <[EMAIL PROTECTED]>
> > >> To: ; <[EMAIL PROTECTED]>
> > >> Sent: Tuesday, July 03, 2007 7:12 AM
> > >> Subject: Re: Making the base artifact processor utilities more readily
> > >> available
> > >>
> > >>
> > >> > On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >> On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >> >> >
> > >> >> > In writing the Topology mode I had to make a copy of the base
> > >> artifact
> > >> >> > processor as it only has package visibilityIt has lots of useful
> > >> >> utilities
> > >> >> > alongside the assembly specific bits. How about we separate the
> > >> >> utilities
> > >> >> > from the assemly specific bits and make the utilities more widely
> > >> >> > available.
> > >> >> > For example, we could separate the utilites for reading XML
> > elements
> > >> >> from
> > >> >> > those that read specific assembly elements into a more fundamental
> > >> base
> > >> >> > class.
> > >> >>
> > >> >>
> > >> >> I think this would be good (but its only fare to note that there's
> > at
> > >> >> least
> > >> >> one who's away on holiday right now who may not be so keen). One of
> > >> >> the
> > >> >> issues is should the SPI be just interfaces or can it also have
> > >> abstract
> > >> >> or
> > >> >> utility helper classes as well. Some of those type of classes could
> > >> make
> > >> >> using the existing SPI much easier IMHO and could make things like
> > the
> > >> >> extension helper redundant.
> > >> >>
> > >> >>...ant
> > >> >>
> > >> > To date the SPI (as described in the 0.90 CHANGES document) has been
> > >> > fairly
> > >> > consistent in that it has concentrated on interfaces. It's always
> > easy
> > >> to
> > >> > find the exception that proves the rule as there are classes in there
> > >> but
> > >> > generally it's interfaces.  I think it would be useful to expose
> > those
> > >> > utilities that we don't expect to change much and allow people access
> > >> > to
> > >> > them. I am completely happy to wait on this though. As I say I took a
> > >> copy
> > >> > at the moment in order to avoid any untoward changes. Not ideal but
> > >> there
> > >> > you go. This case is interesting though as the class I want to use is
> > >> part
> > >> > of assembly.xml which we didn't declare as being part of the SPI
> > >> > currently.
> > >> >
> > >> > Simon.
> > >> >
> > >> > Simon
> > >> >
> > >>
> > >>
> > >> -
> > >> 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]
> >
> > I've just got back to this.

Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)

[Venkata Krishnan]

I've verified the signatures for the src and bin distros and they seem
fine.  The License file mentions 'Apache Jackarta'... while I think it
is 'Apache Jakarta'.  Maybe this very minor thing could be fixed for
the next release.

So over all, here is my +1 for this release.

Thanks

- Venkat

On 7/30/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> Please vote to release the beta1 distribution of Tuscany DAS for Java.
> All the major issues reported in RC1 and RC2 should now be fixed.
>
> The Release Candidate RC3 for Tuscany Java DAS beta1 is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/
>
> Release Notes are available at
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES
>
> The maven repository artifacts are posted in a staging repository and
> is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/
>
> The release audit tool (rat) results are available at
>
> http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log
>
> The tag for the source code is at
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/
>
> Seems 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]
>
>

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

Re: Changes to Policy Module

[Venkata Krishnan]

Hi Raymond,  I looked thro your changes - just the one thing to say -
Thanks for taking a look and making those changes :)

- Venkat

On 8/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi, Venkat.
>
> I fixed a few related issues and checked the changes into SVN under r562968.
>
> * The IntentImpl.hashCode() should be based on the name
> * Move getRequiredIntents() from Intent to ProfileIntent
> * The resolved intent will be kept in the collection before the clear() is
> called
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To: 
> Sent: Sunday, August 05, 2007 12:57 PM
> Subject: Changes to Policy Module
>
>
> > Hi Raymond,
> >
> > I had wrapped up a local increment to the Policy module and tried to
> > check it in.  However, I find that there are modifications that you
> > had checked in.  With those modifications, the work that I did in
> > policy-xml broke :).
> >
> > I'd need some help to merge what I have done with what you have
> > checked in.  Of particular interest to me is the 'hashcode' method in
> > IntentImpl.java.  The trunk has only your checked in versions of the
> > Intent.java and IntentImpl.java.  For your referene, my versions for
> > these classes are here http://people.apache.org/~svkrish/policy.  If
> > you replace these two files in the trunk, you'd find that the test in
> > policy-xml module runs fine.
> >
> > I am open to any modifications that you might suggest so that
> > implementation is clean.  Could you please help in this regard.
> >
> > Thanks
> >
> > - Venkat
> >
> > -
> > 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]

Changes to Policy Module

[Venkata Krishnan]

Hi Raymond,

I had wrapped up a local increment to the Policy module and tried to
check it in.  However, I find that there are modifications that you
had checked in.  With those modifications, the work that I did in
policy-xml broke :).

I'd need some help to merge what I have done with what you have
checked in.  Of particular interest to me is the 'hashcode' method in
IntentImpl.java.  The trunk has only your checked in versions of the
Intent.java and IntentImpl.java.  For your referene, my versions for
these classes are here http://people.apache.org/~svkrish/policy.  If
you replace these two files in the trunk, you'd find that the test in
policy-xml module runs fine.

I am open to any modifications that you might suggest so that
implementation is clean.  Could you please help in this regard.

Thanks

- Venkat

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

Re: SCA 0.92 release?

[Venkata Krishnan]

Hi Ant... thanks for bringing this up again.  Yes, the week ending Aug
17th seems good if we plan to release end of August.

I'd prefer 0.95 for the next release.

- Venkat

On 8/3/07, ant elder <[EMAIL PROTECTED]> wrote:
> On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > With the SCA 0.91 release now being voted on how about starting on 0.92?
> >
> > I've already been adding some things I'm interested in getting done to the
> > next release wiki page -
> > http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
> >  so far thats mainly related to improving web services functionality.
> >
> > So anyone else interested in helping with an 0.92 release or have any
> > function they'd like to suggest or add to the wiki page? How does aiming for
> > getting it done 4 - 6 weeks again sound?
> >
> >...ant
> >
> >
> Bringing this thread up again as time is ticking on if we want to get a
> release out this month. How would people feel about taking a branch for this
> release in a bit less than 2 weeks, say aiming for the 14/15th of August?
> That should just about give enough time for clean up and voting to get a
> release out by the end of  August.
>
> Another thing I wondered about was the name, we've been talking about this
> being 0.92, how about something higher to show we're getting closer, maybe
> 0.95 or 0.98 or even 0.99? (that prompts a what/when is 1.0, I'll start a
> separate thread about that)
>
>...ant
>

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

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

[Venkata Krishnan]

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?

- 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

Thanks

- Venkat


On 7/31/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> AFAIK, policySet can be used directly without going through intents. So a
> policySet is still valid even it doesn't provide any intents.
>
> Please see the SCA Policy Framework Spec V1.0 starting from line 529:
>
> 529 Similarly, one or more policySets can be attached to any SCA element
> used in the definition of
> 530 components and composites. The attachment is specified by using the
> optional @policySets
> 531 attribute. This attribute takes as its value a list of policySet names.
> 532 For example,
> 533
> 534  or .
> 535  536 .
> 537  or 
> ...
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, July 31, 2007 7:24 AM
> Subject: [Spec Related] 'provides' attribute in PolicySet
>
>
> > Hi,
> >
> > In the specs for the PolicyFwk, the xsds mention the 'provides'
> > attribute for a 'policySet' as optional.  If this attribute is not
> > specified how does one figure out which intent a particular policySet
> > actually provides for.   Could somebody help me with clarity on this,
> > please?
> >
> > Thanks
> >
> > - Venkat
> >
> > -
> > 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]

[Spec Related] 'provides' attribute in PolicySet

[Venkata Krishnan]

Hi,

In the specs for the PolicyFwk, the xsds mention the 'provides'
attribute for a 'policySet' as optional.  If this attribute is not
specified how does one figure out which intent a particular policySet
actually provides for.   Could somebody help me with clarity on this,
please?

Thanks

- Venkat

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

Re: Component Property Definition - resolving 'file' attribute

[Venkata Krishnan]

Thanks Sebastien.  Will go ahead and check in the changes now.

- Venkat

On 7/31/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >> Luciano, you are right...  here is the code snippet that I have added
> >> to the CompositeProcessor.resolve()
> >>
> >> for (ComponentProperty componentProperty : component.getProperties()) {
> >> if ( componentProperty.getFile() != null &&
> >> componentProperty.getFile().length() > 0 ) {
> >> DeployedArtifact deployedArtifact =
> >> contributionFactory.createDeployedArtifact();
> >>
> >> deployedArtifact.setURI(componentProperty.getFile());
> >> deployedArtifact =
> >> resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
> >> if ( deployedArtifact.getLocation() != null &&
> >> deployedArtifact.getLocation().length() > 0 ) {
> >>
> >> componentProperty.setFile(deployedArtifact.getLocation());
> >> }
> >> }
> >> }
> >>
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >>
> >>
> >
> > OK, I understand better now :) What you're proposing looks fine to me.
> > CompositeProcessor already depends on ArtifactProcessor, ModelResolver
> > etc. which are all from the contribution module. So passing a pointer
> > to ContributionFactory to it does not alter any layering.
> >
>
> One minor comment, I'd suggest to remove the:
> && componentProperty.getFile().length() > 0, as it'll mask a syntax
> error in the .composite file
> and
> && deployedArtifact.getLocation().length() > 0, as it'll mask a serious
> error in the contribution service
>
> --
> Jean-Sebastien
>
>
> -
> 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: Component Property Definition - resolving 'file' attribute

[Venkata Krishnan]

Luciano, you are right...  here is the code snippet that I have added
to the CompositeProcessor.resolve()

for (ComponentProperty componentProperty : component.getProperties()) {
if ( componentProperty.getFile() != null &&
componentProperty.getFile().length() > 0 ) {
DeployedArtifact deployedArtifact =
contributionFactory.createDeployedArtifact();
deployedArtifact.setURI(componentProperty.getFile());
deployedArtifact =
resolver.resolveModel(DeployedArtifact.class, deployedArtifact);
if ( deployedArtifact.getLocation() != null &&
deployedArtifact.getLocation().length() > 0 ) {

componentProperty.setFile(deployedArtifact.getLocation());
}
}
}


Thanks

- Venkat







On 7/30/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I guess Venkata is trying to create the deployedArtifact to resolve...
>
> >To resolve an artifact, you simple need to create a DeployedArtifact -
> >see ContributionFactory.createDeployedArtifact() -, set it's URI to the
> >URI of the artifact inside the SCA contribution, then call
> >ModelResolver.resolve(theDeployedArtifact).
>
> But I'll wait to see the code.
>
> On 7/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > Venkata Krishnan wrote:
> > > Hi Sebastien / Luciano,
> > >
> > > I have this going in my local.  But I've had to pass the
> > > ContributionFactory down to the CompositeProcessor thus adding one
> > > more argument to the CompositeProcessor contructor.  Is there any
> > > violation of layering in our design with this passing?  Just want to
> > > check this up before I commit the changes.
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > >
> >
> > I'm not quite sure I understand the relationship between
> > ContributionFactory and resolution of a file. Could you post the code
> > somewhere? It'll help me understand. Thanks.
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > 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]
>
>

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

Re: Component Property Definition - resolving 'file' attribute

[Venkata Krishnan]

Hi Sebastien / Luciano,

I have this going in my local.  But I've had to pass the
ContributionFactory down to the CompositeProcessor thus adding one
more argument to the CompositeProcessor contructor.  Is there any
violation of layering in our design with this passing?  Just want to
check this up before I commit the changes.

Thanks

- Venkat


On 6/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Thanks Sebastien.  I'll try to use this now and see how things go.
>
> - Venkat
>
>
> On 6/19/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> > Luciano Resende wrote:
> > > Would we also need to post process the contribution to check for
> > > unresolved references ? I'm guessing that, file references outside
> > > from the contribution scope will always be on the unresolved status
> > > ,and would need further processing.
> > >
> > > On 5/29/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> > >> Venkata Krishnan wrote:
> > >> > Hi,
> > >> >
> > >> > The property value definition for a component can have an attribute
> > >> named
> > >> > 'file' that points to a xml file that might contain the value for a
> > >> > property. The question is - now that the contribution service is in
> > >> shape
> > >> > must it be used to resolve this file as well just like all other
> > >> > artifacts.
> > >> > If so could somebody please provide some pointers on how to do this.
> > >> > Thanks
> > >> >
> > >> > - Venkat
> > >> >
> > >>
> > >> I think it would be a good idea to use it, this would require a simple
> > >> change to our ArtifactResolver implementation to support something like
> > >> a FileReference object, similar to what we've done for classes with
> > >> ClassReference, but we probably also need to confirm what the SCA
> > >> assembly spec actually means by:
> > >> <<<
> > >> 287 - file (optional) – a dereferencable URI to a file containing a
> > >> value for the property
> > >>  >>>
> > >>
> > >> In particular:
> > >> - foo/bar.xml - is foo/bar.xml relative to the current SCA
> contribution?
> > >> or the referencing composite file?
> > >> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
> > >> SCA contribution?
> > >> - http://foo.org/bar - is this allowed?
> > >>
> > >> --
> > >> Jean-Sebastien
> > >>
> > >>
> >
> > In revision r548560 I have added support for resolution of contribution
> > DeployedArtifacts.
> >
> > To resolve an artifact, you simple need to create a DeployedArtifact -
> > see ContributionFactory.createDeployedArtifact() -, set
> it's URI to the
> > URI of the artifact inside the SCA contribution, then call
> > ModelResolver.resolve(theDeployedArtifact). You'll get back the
> > populated/initialized DeployedArtifact, containing its absolute location
> > and the model that was read from it, if any.
> >
> > This can be used to resolve files used to configure properties and
> > implementation files as well.
> >
> > --
> > Jean-Sebastien
> >
> >
> >
> -
> > 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: Binding endpoints (was Fwd: Services and WSDL files

[Venkata Krishnan]

Hi Ant,

Working with the policy framework, the definitions.xml is the file
that lists all the intents and policysets that are applicable for an
SCA Domain.  The Policy Fwk specs talks quite a bit about the contents
of this file - such as things like the BindingType, ImplementationType
etc.

As for having these in the SPI, I have started off  with some
abstractions for these in
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy/src/main/java/org/apache/tuscany/sca/policy
as part of the PolicyFramework things which is still work in progress.
Once I have some thing substantial we could work on moving some things
as SPI.  Having looked at definitions.xml before, it just about rung a
bell in the context of this discussion.  Not sure if the specs folks
are going to like this proposition ;-)

- Venkat

On 7/30/07, ant elder <[EMAIL PROTECTED]> wrote:
> Thats pretty interesting. Though there's so little detail about
> definitions.xml I find it hard to work out what its for, could any spec
> people give a be more detail about this?
>
> One thing it talks about is using bindingType and implementationType
> elements to add new extensions, should we really be using these as part of
> the extension SPI?
>
>...ant
>
> On 7/29/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Is the definitions.xml  (sec 1.8, line 2490 of Assembly spec) a good
> > place to define the domain uri for various schemes for an SCA Domain.
> >
> > - Venkat
> >
> >
> > On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > On 7/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > [snip]
> > > > > ant elder wrote:
> > > > > >> I think that these URIs should be determined as part of the
> > process
> > > > > of
> > > > > >> combining wires and uris specified at different levels in the SCA
> > > > > >> assembly. If the correct URIs are determined once as part of this
> > > > > >> process, a binding provider should be able to just call
> > > > > >> binding.getURI(), without having to calculate it at all, on its
> > own
> > > > > or
> > > > > >> even calling a central URI calculator method.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Agreed. Something like this would be a vast improvement. And its
> > the
> > > > > best
> > > > > > way to make sure it works consistently across all binding
> > extensions.
> > > > > >
> > > > > >
> > > > > [snip]
> > > > >
> > > > > Ok I'll get started on that.
> > > > >
> > > > > >>>> And we need some configuration that describes the base URIs for
> > > > > each
> > > > > >>>> domain.  The base URI information is part of the topology
> > > > > description
> > > > > >>>> but it
> > > > > >>>> doesn't get used yet so we need to get it into the SCADomain.
> > It
> > > > > >>>> should be
> > > > > >>>> configuratin of the  "URI calculator" which could be in the
> > > > > extension
> > > > > >>>> registry so that all bindings can get at it.
> > > > > >>>>
> > > > > >> I'm not quite getting this part... the extension point registry
> > is
> > > > > >> well... a registry for extension points, an extension point
> > contains
> > > > > >> extensions (multiple extensions), I can't quite see how a URI
> > > > > calculator
> > > > > >> utility is an extension point.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > I'm guessing this is just being used as a way to pass base uri
> > > > > infomation
> > > > > > around as to date we don't really have a way to handle system
> > config
> > > > > data.
> > > > > > Whats an alterantive to using this registry?
> > > > > >
> > > > >
> > > > > If we're talking about a domain URI, this is typically model
&

Re: Binding endpoints (was Fwd: Services and WSDL files

[Venkata Krishnan]

Hi,

Is the definitions.xml  (sec 1.8, line 2490 of Assembly spec) a good
place to define the domain uri for various schemes for an SCA Domain.

- Venkat


On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On 7/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > [snip]
> > > ant elder wrote:
> > > >> I think that these URIs should be determined as part of the process
> > > of
> > > >> combining wires and uris specified at different levels in the SCA
> > > >> assembly. If the correct URIs are determined once as part of this
> > > >> process, a binding provider should be able to just call
> > > >> binding.getURI(), without having to calculate it at all, on its own
> > > or
> > > >> even calling a central URI calculator method.
> > > >>
> > > >
> > > >
> > > > Agreed. Something like this would be a vast improvement. And its the
> > > best
> > > > way to make sure it works consistently across all binding extensions.
> > > >
> > > >
> > > [snip]
> > >
> > > Ok I'll get started on that.
> > >
> > >  And we need some configuration that describes the base URIs for
> > > each
> > >  domain.  The base URI information is part of the topology
> > > description
> > >  but it
> > >  doesn't get used yet so we need to get it into the SCADomain. It
> > >  should be
> > >  configuratin of the  "URI calculator" which could be in the
> > > extension
> > >  registry so that all bindings can get at it.
> > > 
> > > >> I'm not quite getting this part... the extension point registry is
> > > >> well... a registry for extension points, an extension point contains
> > > >> extensions (multiple extensions), I can't quite see how a URI
> > > calculator
> > > >> utility is an extension point.
> > > >>
> > > >
> > > >
> > > > I'm guessing this is just being used as a way to pass base uri
> > > infomation
> > > > around as to date we don't really have a way to handle system config
> > > data.
> > > > Whats an alterantive to using this registry?
> > > >
> > >
> > > If we're talking about a domain URI, this is typically model information
> > > that can be hosted in a Top level Composite or Domain Composite or
> > > Domain model object, whatever we want to call it. If I understand the
> > > spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol
> > > used in the domain. The ExtensionPointRegistry is associated with a
> > > Runtime instance, not tied to a Domain. I'll propose a new model object
> > > to host that domain-wide configuration.
> >
> >
> > Sounds good to me.
> >
> > I'm assuming when you say runtime instance here you mean something like,
> > ReallySmallRuntime. Can you say if you have in your mind some specific
> > scenarios that leverage the difference between the domain model and runtime
> > as they exist in the code at the moment, for example, by starting more than
> > one runtime for a domain model.  I'm happy if the answer is "not at the
> > moment" and that it is just good architecture practice to separate these
> > clearly distinct parts of the solution.
> >
> > [snip]
> > > >
> > > >> I guess it should be sufficient to report if we run in Jetty or
> > > Tomcat,
> > > >> right?
> > > >>
> > > >
> > > >
> > > > And there's webapp's or the hotupdate webapp, and doesn't this also
> > > include
> > > > non http things like rmi host (and jms host if we ever get one of
> > > those)?
> > > >
> > > >
> > > Right, we have multiple options for HTTP hosts so it's interesting to
> > > report which one is used.
> > >
> > > It looks like we have only one implementation for RMI or JMS at this
> > > point. So I was not thinking about spending time reporting which one is
> > > used right now... I'll be happy to spend time sorting out which one is
> > > used when we get to a point where we have multiple implementations for
> > > these.
> > >
> > > >>> All those sound good, and just to add one more, i think there's a
> > > bug
> > > >>> (unless its been fixed recently) in the standalone jetty/tomcat
> > > >>> runtimes so
> > > >>> that the port in a endpoint url is used but only for the first
> > > >>> endpoint. So
> > > >>> if you have two binding uri's http://localhost:8080/foo and
> > > >>> http://localhost:8085/bar then both services are exposed on the same
> > > one
> > > >>> port and its just whichever port happened to get processed first.
> > > >>>
> > > >> Yes, I've bumped into this one several times too... so I'd like to
> > > >> volunteer to fix it.
> > > >>
> > > >> It looks like adding prints is under way too.
> > > >>
> > > >> In addition I'd like to do the following. When Tuscany starts, make a
> > > >> Web Page available with its status, http://localhost:9090 for
> > > example,
> > > >> and on that page say Hello Tuscany has started or something like
> > > that,
> > > >> plus:
> > > >> 1. display the top level components started
> > > >> 2. display the services available and their endpoints
> 

Re: Resolving WSDL/XSD import/include for SCA contributions

[Venkata Krishnan]

Hi,

I was recently looking into
http://issues.apache.org/jira/browse/TUSCANY-1343 and I am able to
relate well with all of what is being discussed here.  From whatever I
understand from that JIRA it is desired that the  package-processor
that is processing an SCA contribution be given the responsibility of
locating and loading the xsd or wsdl.  i.e. the WSDLProcessor does not
take on the locating and loading.  Asking for this seems consistent
with our overall artifact reading and resolution design but I couldn't
quite figure out a clean way of achieving this.  What Huang is
suggesting for a way out of this seems like something worth exploring.
 Thoughts ?

Thanks

- Venkat



On 7/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Jean-Sebastien Delfino wrote:
> > Comments and questions inline.
> >
> > Mike Edwards wrote:
> >> Hi,
> >>
> >> A few thoughts
> >>
> >>
> >> 
> >> >> We have two options here:
> >> >>
> >> >> a) Plugin a tuscany-specific resolver for WSDL4J
> >> >> (javax.wsdl.xml.WSDLLocator) and XmlSchema
> >> >> (org.apache.ws.commons.schema.resolver.URIResolver).
> >> >>
> >> >> This option can handle location case 1, 2 and 3. For 2, we
> >> probably need
> >> >> some context from the contribution service.
> >> >>
> >> >> The difficulty is that both resolvers expect to take an
> >> InputSource. For
> >> >> location case 4 (empty or not present), we don't have a corresponding
> >> >> InputSource.
> >> >
> >> > I was going to respond with a long list of pros-cons for both options,
> >> > then deleted all my comments to ask a simple question :). Why can't we
> >> > return an InputSource for the contents of the imported document?
> >> >
> >>
> >> > Well, for the import/include that can be resolved to a document, we
> >> > return the InputSource. I have said that it works for location case
> >> 1, > 2 and 3. But if the import/include only doesn't have the
> >> > schemaLocation attribute, what InputSource should we return?
> >>
> >> Well, it seems valid to me to go use the SCA resolution mechanism -
> >> it is simple enough to say, either use the WSDL or XML approach (and
> >> require a location) but if there is no location, then this isn't
> >> going to work and SCA takes over.  I note that if the location is
> >> left out in the case of the included/imported file being in the same
> >> contribution as the source file, then things are simple and the SCA
> >> rules will find it.
> >>
> >> If it is elsewhere, then SCA at least defines an algorithm to follow
> >> to attempt to find the referenced file.
> >
> > How about this then:
> > - if the location is not specified you get the first WSDL file we find
> > matching the namespace in the current contribution or in a
> > contribution imported by an SCA 
> > - if you're not happy with that (because for example you have multiple
> > WSDLs sharing the same namespace), please specify a correct location
> > in your WSDL
>
> I should have said XSD here instead of WSDL as locations are mandatory
> in WSDL...
>
> >
> > Is this too simplistic? Do you see any realistic scenarios that we
> > wouldn't be able to support with this approach?
> >
> >>
> >>
> >> > A related question, for an artifact processer that loads multiple
> >> > artifacts following the import/include directives, how can we avoid
> >> > the duplicate loading? For example, we have a.wsdl imports b.wsdl,
> >> > both a.wsdl and b.wsdl are in the same contribution and they are
> >> > processed by the WSDL artifact processor. We probably don't want to
> >> > load b.wsdl twice in this case.
> >>
> >> Why actually load anything before it is clearly required?
> >
> > I'm not quite following yet, how does one know that file X.wsdl is
> > clearly required?
> >
> >> But once it is loaded, keep it around. This should be true for all
> >> artifacts.
> >
> > +1 for all artifacts that we handle ourselves, but WSDL4J and the
> > XmlSchema lib do not seem to support this. Has anybody raised this
> > issue to them?
> >
> >
> >>
> >> Yours,  Mike.
> >>
>
>
> --
> Jean-Sebastien
>
>
> -
> 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: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating

[Venkata Krishnan]

Hi,

I'd like the release guide if the steps we follow are a bit different
than what is normally done or if there are some variations to how we
perform some steps.   But if we were just about going to rephrase all
of what has already been said somewhere else I'd prefer just about
having a pointer from Tuscany.  Maybe a good begining to all of this
could be to have our release guide and link to the information that is
available.  Then as we get to review and apply that we could flesh our
guide.

Having said that, I'd like us to have a 'release review checklist'
that enlists the bunch of things that need to be reviewed in a RC
including things like testing out the binary distro before the source
distro. etc.

- Venkat

On 7/24/07, Simon Laws <[EMAIL PROTECTED]> wrote:

snip..

>
> There's already lots of doc about doing releases in the ASF - on the ASF
> main dev pages and within the Incubator site etc.


The problem with there being lots of docs is that there are, ahem, lots of
docs. Where is the definitive set of guides that provide the detail required
to release Tuscany for someone, like me, who hasn't done it before? Possibly
an impossible question to answer as you don't know what I don't know and I
don't know what you do know so our view of what is an acceptable level of
detail probably differs. Here are the top level guides I found.

http://www.apache.org/dev/#rreleases
http://incubator.apache.org/guides/releasemanagement.html

I can't say whether the above links are satisfactory as I haven't been
through the process but I agree that we should propose updates if they are
found to be wanting. For example, a discussion of RAT.

For consistency I would expect to see all the keystrokes recorded that are
required to produce and distribute a release. The fewer the better so, yes,
more automation would be good.  I expect automation does not completely
remove the responsibility to check the release against release criteria,
e,g, legal, but gives a good indication of what is required to make the
release happen. Again anything we can do to automate these checks is good.

I don't expect that release is a process that should involve a lot of
imagination on our part other than in providing more automation of the
required steps. To put it another way is there anything specific we have to
do for Tuscany that would not be included in the general guide? I note that
many projects do have release guides. Why is this the case?

http://httpd.apache.org/dev/release.html
http://cayenne.apache.org/release-guide.html
http://incubator.apache.org/servicemix/release-guide.html
http://activemq.apache.org/release-guide.html

I do note that the Incubator release guide states "Different options or
opinions are encouraged.". If options are offered (and I can't say that
there are without reading the detail) then we need a place to document which
are chosen for Tuscany releases.

Simon



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

Merging changes in Release 0.91 branch with the trunk

[Venkata Krishnan]

HI,

Now that the 0.91 release is out, I am going to merge the changes that
we done to the branch during the release, over to the trunk.  As of
now here are the areas that I am considering for a merge

- distribution (since we've went about quite a few changes to this
during this release... I'll make sure that Luciano's current exclusion
of the source build is kept intact to let the nightly builds continue)
- samples
- demos

Please let me know if any of you would like me to take care of
something specifically.  Thanks

- Venkat

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

[ANNOUNCE] Apache Tuscany SCA Java 0.91 Released

[Venkata Krishnan]

Hello Everybody,

The Apache Tuscany Team are pleased to announce the 0.91-incubating release
of the Java SCA project.

Apache Tuscany provides a runtime based on the Service Component
Architecture. SCA is a set of specifications aimed at simplifying SOA
Application Development which are being standardized at OASIS as part of
Open Composite Services Architecture (Open CSA).

This release builds further over the previous release by providing
more implementation
and binding extensions.  There are also some enhancements to the core
runtime - for
example the support for multiple contributions to an SCA Domain and an
extension-helper
SPI layer.  There are also additions to the samples to demonstrate the
usage of the
new extensions in this release.  Finally there are some demo
applications as well that
have been added to this release.

To download or for more information about the release go to:
http://incubator.apache.org/tuscany/sca-java-releases.html

To find out more about OASIS Open CSA go to: http://www.oasis-opencsa.org.

Apache Tuscany welcomes your help. Any contribution, including code,
testing, improving the documentation, or bug reporting is always
appreciated. For more information on how to get involved in Apache Tuscany
visit the website at: http://incubator.apache.org/tuscany.

Thank you for your interest in Apache Tuscany!
The Apache Tuscany Team.
---

Tuscany is an effort undergoing incubation at the Apache Software Foundation
(ASF), sponsored by the Apache Web services PMC. Incubation is required of
all newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.

---
On behalf of Team Apache Tuscany
- Venkat

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

Re: XSDDocumentProcessor visibility

[Venkata Krishnan]

+1.  since I imagine xsd documents is not something that is only used
with wsdls.

- Venkat

On 7/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

Looks like XSDDocumentProcessor is not being registered with the
proper artifact extension point, and it's being only available
internally to the WSDLDocumentProcessor. Should we register it with
the extension point to make it more widely available ?

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




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

Re: [CONF] Apache Tuscany: SCA Java binding.jsonrpc (page edited)

[Venkata Krishnan]

Every commit is good to know to keep track of whats going on.  But it
would be good if this mail just about provided a link like this
http://cwiki.apache.org/confluence/pages/viewchangessincelastlogin.action?pageId=54462
which is actually the diff between two versions, than churn out all
contents.

- Venkat

On 7/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:

On 7/18/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> It will, just like when we commit code to SVN. I think its necessary if
> we're to provide proper oversight of whats happening on our website,  do
> others agree?
>
>...ant
>
> On 7/18/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > Ant,
> > will this get generated on each save? I typically do many saves when
> > working
> > on a page. I'd like to understand this to avoid flooding the mailing
> list.
> >
> > Haleh
> >
> > On 7/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > >Page Edited : TUSCANY<
> > http://cwiki.apache.org/confluence/display/TUSCANY>: SCA
> > > Java binding.jsonrpc<
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc
> > >
> > >
> > > SCA Java binding.jsonrpc<
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc
> >has
> > been edited by
> > > ant  (Jul 18,
> 2007).
> > >
> > > (View changes)<
> >
> 
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=54462&originalVersion=17&revisedVersion=18
> > >
> > > Content:
> > >  Unable to render {include} Couldn't find a page to include called:
> > Repeating
> > > Menu<
> >
> 
http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=TUSCANY&title=Repeating+Menu&linkCreation=true&fromPageId=54462
> > >
> > > *Documentation*
> > >
> > > User Guide<
> > http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+User+Guide>
> > > Architecture Guide<
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide
> > >
> > > Developer Guide<
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Development+Guide
> > >
> > > Extension Developer Guide<
> >
> 
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Extension+Development+Guide
> > >
> > >  *Resources*
> > >
> > > FAQ<
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Java+-+FAQ>
> > > Source Code <
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca
> > >
> > >   
> > >
> > > Tuscany supports JSON-RPC  as a protcol for use
> > with
> > > SCA services by using the  SCDL extension. This
> enables
> > > remote web browser clients to easily make RPC style calls to
> server-side
> > SCA
> > > components.
> > >
> > > This binding has no attributes or elements so to include it on a SCA
> > > service simply requires the following SCDL:
> > >
> > > 
> > >
> > >  Also see  > http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.ajax
> >which
> > provides some similar function.
> > >
> > > Any JSON-RPC client may be used to access SCA services which use <
> > > binding.jsonrpc>, but to simplify the task for web browsers the
> binding
> > > can generate a script which may be included within an HTML document to
> > set
> > > up proxy objects for each SCA service within the HTML page
> environment.
> > >
> > > This script is used by simply including the following script tag
> within
> > > the HTML page:
> > >
> > > 
> > >
> > >  This initializes the proxys for the SCA services which can then be
> used
> > > make requests to the server-side components. For example, if there was
> a
> > > service named "myService" which had operations "aOnewayRequest" and
> > > "anRpcRequest" the scripts in the HTML page could now invoke these
> > > opperations with the following:
> > >
> > > myService.aOnewayRequest(args);
> > >
> > >  or
> > >
> > > myService.anRpcRequest(args, responseFunction);
> > >
> > >  In that example 'responseFunction' is the name of a function which is
> > > called to process the response and which gets called asynchronously on
> > > another thread when the response is avaialble. RPC requests are done
> > this
> > > way instead of the simpler "answer = myService.anRpcRequest(args)" to
> > > avoid hanging the browser while the (potentialy slow) request is being
> > > processed. An example of the responseFunction for the previous example
> > is:
> > >
> > > function responseFunction(answer){
> > >   // do something with answer
> > > }
> > >
> > >  Using SCA JSON-RPC services with Dojo
> > >
> > > Apache Tuscany JSON-RPC services provide built-in support for Dojo
> RPC<
> > http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book9>.
> > > The Dojo  toolkit is a popular framework for
> > > writing Ajax/Web 2.0 style browser client applications. Tuscany SCA
> > > services which use  will by default support the
> Simple
> > > Method Description (SMD)  protocol. SMD is
> > > si

Re: Qurey related to wsdl imports

[Venkata Krishnan]

Hi,

I tried this further by adding a little bit of code in the
WSDLDocumentProcessor.read method.  Over there there is a fragment
that scans the schema elements in the read wsdl definition and adds
them to XMLSchemaCollection.  To this loop I added code to peek into
the imported definitions as well and add the schema elements in there
to this XMLSchemaCollection.  Doing this seems to get the imports
going for now.  Not sure if this is the right thing to do.

- Venkat

On 7/19/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi,

I am taking a look at
https://issues.apache.org/jira/browse/TUSCANY-1426 and to get to the
crux of that problem I am first trying to see if wsdl imports work.

Here is what I am attempting.  There is B.wsdl that imports A.wsdl,
where B.wsdl has the bindings and services defined and A.wsdl has the
types, messages and porttypes defined.

But this does not seem to work.  It ends up that while Tuscany WSDL
Interface processor is dealing with B.wsdl it does not seem to find
the elements  (remember they are defined inside inline xsd in A.wsdl).

Has this been tried out before?  Could somebody please point me to
samples or itests that have this working in the trunk?

Related to this, but slightly different question is...
- Do we expect WSDL4J to be resolving the imports and handing us over
an aggregated wsdl definition or are we going to use the model  and
artifact resolution mechanisms within Tuscany to do this ?

Thanks

- Venkat



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

Qurey related to wsdl imports

[Venkata Krishnan]

Hi,

I am taking a look at
https://issues.apache.org/jira/browse/TUSCANY-1426 and to get to the
crux of that problem I am first trying to see if wsdl imports work.

Here is what I am attempting.  There is B.wsdl that imports A.wsdl,
where B.wsdl has the bindings and services defined and A.wsdl has the
types, messages and porttypes defined.

But this does not seem to work.  It ends up that while Tuscany WSDL
Interface processor is dealing with B.wsdl it does not seem to find
the elements  (remember they are defined inside inline xsd in A.wsdl).

Has this been tried out before?  Could somebody please point me to
samples or itests that have this working in the trunk?

Related to this, but slightly different question is...
- Do we expect WSDL4J to be resolving the imports and handing us over
an aggregated wsdl definition or are we going to use the model  and
artifact resolution mechanisms within Tuscany to do this ?

Thanks

- Venkat

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

Re: Website ACL

[Venkata Krishnan]

Thank you, Ant.

On 7/18/07, ant elder <[EMAIL PROTECTED]> wrote:

This is now in place and changes to the Tuscany cwiki now have emails sent
to tuscany-commits

   ...ant

On 7/17/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
>
> Ant,
>
> Please drop an email to apmail AT apache.org.
>
> thanks,
> dims
>
> On 7/16/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 7/15/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > > If we could get cwiki change emails sent to the tuscany-commit mailing
> > list so its easy to give some oversight then I'd be in favour of a very
> low
> > bar of entry.
> >
> > I had a try at doing this by setting up a cwiki user using the
> > [EMAIL PROTECTED] email address and adding that user as a
> > watcher of the cwiki space. This works but all the emails from
> > [EMAIL PROTECTED] to the tuscany-commits list require moderation
> which
> > is a bit of a pain. Does any one know of a way around this? We need some
> way
> > to allow [EMAIL PROTECTED] to post to the tuscany-commits list
> without
> > having to subscribe it to the list so we don't send all the commit
> emails to
> > [EMAIL PROTECTED]
> >
> > (CC'ing you dims as you seem to have lots of mailing lits powers so may
> know
> > some way around this?)
> >
> >...ant
> >
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>



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

Re: [RESULT] was Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC3

[Venkata Krishnan]

Hi

It seems to me that the javadocs for the sca-api and core-spi modules
are not quite the way they should be built since we distribute them
only in the distros now.  With the current build for 0.91-rc3 they
have ended up as maven artifacts with missing legal files.  I am going
to remove them from the maven staging repo for this release.

For future releases, if we wish to have them in the maven repo, we
must fix the build as well to include the relevant legal files.

Thanks

- Venkat

On 7/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Release vote for Tuscany Java SCA 0.91-incubating RC3 has passed with
5 binding +1 and no -1s.

Votes from :
Venkatakrishnan
Anthony Elder
Simon Laws
Raymond Feng
Luciano Resende

Thanks

- Venkat

On 7/12/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi again :),
>
> Please review and vote on the 0.91 release artifacts of Tuscany SCA for
> Java. (RC3).
>
> The artifacts are available for review at:
> http://people.apache.org/~svkrish/tuscany/0.91-rc3/
>
> This includes the binary and source distributions, the RAT reports, and the
> Maven staging repository.
>
> The SVN tag for the release is:
> 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc3-incubating/
>
> - Comments on RC2 related to READMEs of samples have been fixed [1].
> - License file in binary distribution now includes the missing BSD
> license reported during IPMC review [2]
>
> Othere than these two there are no other changes made to this RC over
> the previous one.
>
> [1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19690.html
> [2] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg14615.html
>
> Looks ok to me - so here's my +1.
>
> Thanks
>
> - Venkat
>



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

Re: Fixes for Tuscany SCA Java 0.91 RC4?

[Venkata Krishnan]

Thanks Raymond.

On 7/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi,

I have merged the fix from trunk into 0.91 branch under r557146. We can pull
it into RC4 if we decide the re-spin.

Thanks,
Raymond

- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, July 17, 2007 4:48 PM
Subject: Fixes for Tuscany SCA Java 0.91 RC4?


> It looks like there are still some issues with our 0.91 RC3.
>
> In addition to the issues reported on incubator-general in:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg14743.html
>
> I'd like to see two code issues fixed:
> - Using two bindings that extend PojoBinding in the same composite (e.g.
> JSON and EJB) causes an ClassCastException
> - JSON binding (and other bindings that don't support references) break
> when initializing self references
>
> Both issues are serious, but have been fixed by Raymond in trunk. Details
> and subversion commits can be found at
> http://issues.apache.org/jira/browse/TUSCANY-1435.
>
> Any chance to get this fix merged into 0.91 RC4?
>
> --
> Jean-Sebastien
>
>
> -
> 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: Click to confirm your Google Alert

[Venkata Krishnan]

This is cool and helpful.  Thanks for doing this.  I am happy about this.

- Venkat

On 7/17/07, ant elder <[EMAIL PROTECTED]> wrote:

Fyi, I've taken the liberty of setting up Google blog alerts to send us msgs
when sca or tuscany are found to be mentioned on someones blog, hope no one
minds. Can switch them off if it gets annoying but I've been using this for
a while and find it really useful to see what people are saying.

   ...ant

-- Forwarded message --
From: Google Alerts <[EMAIL PROTECTED]>
Date: Jul 17, 2007 1:19 PM
Subject: Click to confirm your Google Alert
To: [EMAIL PROTECTED]

Google received a request to start sending Alerts for the search
[ SCA SOA ] to [EMAIL PROTECTED]

Verify this Google Alert request:
http://www.google.com/alerts/verify?s=EID92dmrxGyH3Vsj1WImU9Q

Cancel this Google Alert request:
http://www.google.com/alerts/remove?s=EID92dmrxGyH3Vsj1WImU9Q

Thanks,
The Google Alerts Team
http://www.google.com/alerts

-
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: What should be the right Parent pom version ?

[Venkata Krishnan]

+1 for each subproject to have its own.. unless we want to consciously
tie in some commonality through this between the subprojects.

- Venkat

On 7/17/07, ant elder <[EMAIL PROTECTED]> wrote:

On 7/17/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 7/17/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > Doing a quick search on the code, looks like we have a combination of
> > parent pom references in our current trunk code.
> >
> > Searching for: 2-incubating
> > cts\pom.xml(24): 2-incubating
> > sca\pom.xml(25): 2-incubating
> > sca\pom.xml(160): 2-incubating
> > Found 3 occurrence(s) in 2 file(s)
> >
> > Searching for: 2-incubating-SNAPSHOT
> > buildtools\pom.xml(25): 2-incubating-SNAPSHOT
> > buildtools\pom.xml(30): 2-incubating-SNAPSHOT
> > das\pom.xml(25): 2-incubating-SNAPSHOT
> > pom\parent\pom.xml(32): 2-incubating-SNAPSHOT
> > sdo\pom.xml(25): 2-incubating-SNAPSHOT
> > sdo\sdo-api\pom.xml(25): 2-incubating-SNAPSHOT
> > spec\sdo-api\pom.xml(25): 2-incubating-SNAPSHOT
> > Found 7 occurrence(s) in 6 file(s)
> >
> > I guess, we should be using the SNAPSHOT version in trunk, but I want
> > to ask before I make these changes.
> >
> > --
> > 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]
> >
> > Hi Luciano
>
> Shouldn't we be developing against a released/stable version of the parent
> pom unless there are changes that are required? I.e if we develop against
> a
> snapshot , and rely on its features, then we should release the snapshot
> parent pom before we release packages that depend on it.
>
> Simon
>

From past discussion thats been the intention i think - that we'd use the
released non-SNAPSHOT version, but thats going back to the days when there
was separate releases of all the different modules. Probably a bit late for
this now - but do we really even want/need this parent pom? It seems simpler
and more flexible to me if each sub project just has its own.

   ...ant



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

Re: Add isStarted() to o.a.t.sca.assembly.Component?

[Venkata Krishnan]

Seems ok to me since we will only be extending and not disrupting what
exists already.  And extending too seems ok since we are adding in a
substantial feature here - support for management functions.

- Venkat

On 7/17/07, ant elder <[EMAIL PROTECTED]> wrote:

Ok, RuntimeComponent sounds good to me. I guess I wonder if extending the
Lifecycle interface isn't over kill and then this would need to track all
those intermediate states which i wonder if anyone is really interested in?

The main reason I'm asking explicitly is these are interfaces we've said are
in the stable SPI, so whats our policy on adding new methods?

   ...ant

On 7/17/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> RuntimeComponent instead of Component is probably better to hold the
> state.
>
> We might be able to reuse "org.apache.tuscany.sca.scope.Lifecycle.java"
> (move to a different package) and have
> "org.apache.tuscany.sca.runtime.RuntimeComponent.java" extend from it.
> This
> way, the management interface can find the corresponding RuntimeComponent
> and then control the lifecycle of a componenent.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To: "tuscany-dev" 
> Sent: Monday, July 16, 2007 4:00 PM
> Subject: Add isStarted() to o.a.t.sca.assembly.Component?
>
>
> > For TUSCANY-1379 it seems easy enough to start or stop a component but
> > there
> > doesn't seem to be any way to find if the current state of a Component
> is
> > started or stopped. Not sure if thats by design or not, what would
> people
> > think about adding an isStarted method to the Component interface?
> >
> >   ...ant
> >
>
>
> -
> 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 to handle failing itest suites was: Re: Intermittent exception from itest\osgi-implementation suite

[Venkata Krishnan]

+1 Sounds lot of sense to me.  Maybe when commenting out it would be
good to include the number of the JIRA that has been opened for this.

- Venkat

On 7/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

[snip]
Raymond Feng wrote:
> Hi,
>
> I checked the itest/pom.xml and saw quite a few modules are commented
> out. We removed the failing modules from the build "temporarily" but
> it ends that they are excluded from the build "permanently". We're
> cheating ourselves:-(
>
> IMHO, we need to handle these situations more carefully moving
> forward. I suggest that we follow the rules below:
>
> 1) Try to fix the failing test case if the break is caused by your
> changes before the check-in.
> Otherwise,
> 2) Open a JIRA to track the issue if you expect other people to fix
> it. Mark the JIRA as "blocker".
>
+1

I'd add:

3) Mark the JIRA resolved when the problem is fixed :)

--
Jean-Sebastien


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

[RESULT] was Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC3

[Venkata Krishnan]

Release vote for Tuscany Java SCA 0.91-incubating RC3 has passed with
5 binding +1 and no -1s.

Votes from :
Venkatakrishnan
Anthony Elder
Simon Laws
Raymond Feng
Luciano Resende

Thanks

- Venkat

On 7/12/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi again :),

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java. (RC3).

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc3/

This includes the binary and source distributions, the RAT reports, and the
Maven staging repository.

The SVN tag for the release is:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc3-incubating/

- Comments on RC2 related to READMEs of samples have been fixed [1].
- License file in binary distribution now includes the missing BSD
license reported during IPMC review [2]

Othere than these two there are no other changes made to this RC over
the previous one.

[1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19690.html
[2] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg14615.html

Looks ok to me - so here's my +1.

Thanks

- Venkat



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

Re: svn commit: r556249 - /incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java

[Venkata Krishnan]

Hi,

Yes it seem ok to have both of these defined as there is order of
precedence that has been llaid out.  I am sort of able to fit this
with the general scheme of overriding that has been specified for
various artifacts.

- Venkat

On 7/14/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi, Ant.

It was me who commented out the code when I debugged a test case and ran
into this exception. The WS binding spec says the following:

"The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the
wsa:EndpointReference,
76 2. The explicitly stated URI in the "uri" attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification"

Why is it an error if both uri and WSDL endpoint are present? The spec seems
to say we should use the WSDL endpoint over the binding uri in this case and
they are not exclusive. Maybe I miss some points. Please clarify.

Thanks,
Raymond

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 14, 2007 2:19 AM
Subject: svn commit: r556249 -
/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java


> Author: antelder
> Date: Sat Jul 14 02:18:59 2007
> New Revision: 556249
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=556249
> Log:
> Remove unused import,
> add back in throwing exception when using wsdl port endpoint but a uri is
> specified on the scdl binding
> (not sure why that got commented out, all the tests pass with it in and it
> makes it much easier to debug so adding it back and see if anyone
> complains)
>
> Modified:
>
> 
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
>
> Modified:
> 
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
> URL:
> 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java?view=diff&rev=556249&r1=556248&r2=556249
> ==
> ---
> 
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
> (original)
> +++
> 
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
> Sat Jul 14 02:18:59 2007
> @@ -65,7 +65,6 @@
> private ConfigurationContext configContext;
> private MessageFactory messageFactory;
> private Axis2ServiceBindingProvider callbackProvider;
> -private InterfaceContract bindingInterfaceContract;
>
> // TODO: what to do about the base URI?
> private static final String BASE_URI = "http://localhost:8080/";;
> @@ -193,9 +192,9 @@
> wsdlURI = getEndpoint(wsBinding.getPort());
> }
> if (wsdlURI != null && wsdlURI.isAbsolute()) {
> -//if (wsBinding.getURI() != null &&
> (wsBinding.getServiceName() != null && wsBinding.getBindingName() ==
> null)) {
> -//throw new IllegalArgumentException("binding URI cannot
> be used with absolute WSDL endpoint URI");
> -//}
> +if (wsBinding.getURI() != null && (wsBinding.getServiceName()
> != null && wsBinding.getBindingName() == null)) {
> +throw new IllegalArgumentException("binding URI cannot be
> used with absolute WSDL endpoint URI");
> +}
> return URI.create(wsdlURI.toString());
> }
>
>
>
>
> -
> 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: lost wiki login credentials

[Venkata Krishnan]

Hi Kelvin,

I will send your credentials to your mail id.

- Venkat

On 7/13/07, kelvin goodson <[EMAIL PROTECTED]> wrote:

One of the few things I have truly lost in my recent hard drive crash was my
login details for the tuscany wiki.  They seem to have been saved in my
firefox browser and no-where else :-(How do I retrieve this?  Can
someone help please?

Regards, Kelvin.

P.S.
In the meantime I'll record the update I wanted to make to the SDO FAQ
section here so that I can do it later.

re the FAQ for Installing JavaJet function in eclipse,  to do this via Help
=> Software Updates => "Find and Install"
if you select Java Emmitter Templates (JET) SDKIt may complain that you
don't have the codegen plugin.  To get this you must also tick EMF Extender
SDK.



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

Re: Getting developer jira access to Amita Vadhavkar

[Venkata Krishnan]

+1 from me too.

- Venkat

On 7/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

Amita Vadhavkar  has been helping DAS for couple months and recently
also started to help on SDO and had contributed many patches. I'd like
to give her developer access to JIRA so she can manage JIRAs with more
flexibility, etc.

Thoughts ?

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




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

[VOTE] Release Tuscany Java SCA 0.91-incubating RC3

[Venkata Krishnan]

Hi again :),

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java. (RC3).

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc3/

This includes the binary and source distributions, the RAT reports, and the
Maven staging repository.

The SVN tag for the release is:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc3-incubating/

- Comments on RC2 related to READMEs of samples have been fixed [1].
- License file in binary distribution now includes the missing BSD
license reported during IPMC review [2]

Othere than these two there are no other changes made to this RC over
the previous one.

[1] - http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19690.html
[2] - http://www.mail-archive.com/[EMAIL PROTECTED]/msg14615.html

Looks ok to me - so here's my +1.

Thanks

- Venkat

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

Re: subscribe

[Venkata Krishnan]

Hi Dennis,

Thanks for you interest in Tuscany and eager to see you on our
Mailinglists.  Here is information on how you can subscribe to the
tuscany dev list.

http://incubator.apache.org/tuscany/mailing-lists.html.

Thanks

- Venkat

On 7/10/07, O'Flynn, Dennis <[EMAIL PROTECTED]> wrote:

please subscribe my email address [EMAIL PROTECTED] with the
Tuscany development mailing list.


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it.

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it.



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

Re: [RESULT] was Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC2

[Venkata Krishnan]

Hi,

This RC has got a -1 (non-veto) when seeking IPMC approval due to
failure to include one  of the licenses in the binary distro.

So I am going to now spin another RC :).  Along with the license fix,
I plan to fix some of the comments related to the samples README text
alone.

I will be getting this RC3 out for vote today.

Thanks

- Venkat

On 7/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Release vote for Tuscany Java SCA 0.91-incubating RC2 has passed with
5 binding +1, 1 non-binding +1 and no -1s.

Votes from :
Venkatakrishnan
Simon Laws
Anthony Elder
Luciano Resende
Raymond Feng
Simon Nash (non-binding)


Thanks.

- Venkat

On 7/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Please review and vote on the 0.91 release artifacts of Tuscany SCA for
> Java.
>
> The artifacts are available for review at:
> http://people.apache.org/~svkrish/tuscany/0.91-rc2/
>
> This includes the binary and source distributions, the RAT reports, and the
> Maven staging repository.
>
> The SVN tag for the release is:
> 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubating/
>
> All comments raised for RC1 -
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
> have been fixed.
>
> Looks ok to me - so here's my +1.
>
> Thanks
>
> - Venkat
>



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

Re: [VOTE] Release Tuscany Java DAS beta1 (RC2)

[Venkata Krishnan]

Hi,

Here are my observations on this RC.

1) The source builds successfully from a clean maven repo
- Notice, Disclaimer and License files missing from source 'rdb' module.
2) Trying the samples
a) I see that the source has two additional directories 'testing' and
'dbconfig' which are not there in binary distro. Maybe we must make it
clear that this applies only if one is using the source distro.
b) RDB DAS Sample (companyweb)
- should we change that title to RDB DAS CompanyWeb Sample.
- Readme
- the section "Running from Tomcat configured by the 
build" has
information that cannot be related to with the binary distro.  There
is a mention of 'testing' module within samples and also the paths
seem to be related to the svn structure.
(java/das/samples/testing/tomcat/readme.htm)
- the section "Deploying the CompanyWeb WAR into a 
Tomcat you
configure yourself" talks about a 'sample distribution' - and I don't
think we have one. Do we ?
- furtheron there is mention about copying 
derby.jar but
I see it in the war as well.
- and then in "Install the canned Derby database to 
Tomcat", i
really cannot figure out where datatest directory is.
- I really think this readme needs a overhaul or I am 
grossly
missing something.
c) RDB DAS Customer Sample runs clean as mentioned in the readme
- Section "Running from Tomcat configured by the build" may 
need to
mention that it applies only to src distro
- there is a mention of 'sample distribution' which we don't 
have
- about copying derby.jar to tomcat lib I guess its common/lib 
for
tomcat 5.x and just 'lib' for tomcat 6.x
- I was able to deploy to the war to tomcat, I copied over the
derby-10.1.2.1.jar that I found in the war to the lib directory and
was able to run the sample successfully.  I tried the adhoc queries
and they seemed to work fine for me.

3) License and Notice : I find licenses are in place.  In the notice
there is mention of using software developed by OSOA.  Did not quite
find anything from osoa.

So, overall its about the READMEs for the samples that need some
fixing.  Even there the customer and ajax samples can be worked out
with the current READMEs - with the Ajax sample really give a feel
that DAS works.  So I really cannot see a blocker with this.

Here is my +1.

Thanks.

- Venkat

On 7/10/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

Please vote to release the beta1 distribution of Tuscany DAS for Java.
All the major issues reported in RC1 should now be fixed.

The Release Candidate RC2 for Tuscany Java DAS beta1 is available at

  http://people.apache.org/~lresende/tuscany/das-beta1-rc2/

Release Notes are available at
  
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/distribution/binary/RELEASE_NOTES

The maven repository artifacts are posted in a staging repository and
is available at

  http://people.apache.org/~lresende/tuscany/das-beta1-rc2/maven/

The release audit tool (rat) results are available at

  http://people.apache.org/~lresende/tuscany/das-beta1-rc2/das-beta1-rc2-rat.log

The tag for the source code is at

  
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc2/

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




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

[RESULT] was Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC2

[Venkata Krishnan]

Release vote for Tuscany Java SCA 0.91-incubating RC2 has passed with
5 binding +1, 1 non-binding +1 and no -1s.

Votes from :
Venkatakrishnan
Simon Laws
Anthony Elder
Luciano Resende
Raymond Feng
Simon Nash (non-binding)


Thanks.

- Venkat

On 7/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

Hi,

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java.

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc2/

This includes the binary and source distributions, the RAT reports, and the
Maven staging repository.

The SVN tag for the release is:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubating/

All comments raised for RC1 -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
have been fixed.

Looks ok to me - so here's my +1.

Thanks

- Venkat



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

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating RC2

[Venkata Krishnan]

: 0, Skipped: 0
27. The README for demos/alert-aggregator has a few typos:
   line 20: change "you" to "your"
   line 30: change "you" to "your"
   line 34: change "retrived" to "retrieve"
   line 71: change "you" to "your"
28. The README for demos/bigbank-account has a few typos:
   line 17: change "Ant" to "ant"
   line 25: change "Ant" to "ant"
   line 40: change "you" to "your"
   line 34: change "retrived" to "retrieve"
   line 71: change "you" to "your"

Most of these are minor nits, but I think point 2 is a bit more serious.
In future I don't think we should include samples in a release if they
don't have a README or a JUnit test case or an ant script.

If a respin is required for any other reason then I would suggest either
improving or removing the feed-aggregator sample.  However, I don't
think this is serious enough to delay the release, so here's my
+1 (non-binding).

   Simon

Simon Laws wrote:

> On 7/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi,
>>
>> Please review and vote on the 0.91 release artifacts of Tuscany SCA for
>> Java.
>>
>> The artifacts are available for review at:
>> http://people.apache.org/~svkrish/tuscany/0.91-rc2/
>>
>> This includes the binary and source distributions, the RAT reports, and
>> the
>> Maven staging repository.
>>
>> The SVN tag for the release is:
>>
>> 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubating/
>>
>>
>> All comments raised for RC1 -
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
>> have been fixed.
>>
>> Looks ok to me - so here's my +1.
>>
>> Thanks
>>
>> - Venkat
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> Hi Venkat
>
>
> A few more things I noticed this time round
>
> - No diagram for sample/chat-webapp
> - No README or diagrams for sample/feed-aggregator
> - I can't test demos/bigbank-account until the jars are distributed to the
> maven repos (we need to get the ant script sorted out for this)
>
> I'll raise a JIRA for these items.
>
> - I tried to verify the signature on the binary distro but it didn't work
> for me
>
> C:\simon\tuscany\sca-r0.91-rc2>gpg --verify
> apache-tuscany-sca-0.91-incubating.zip.asc
>
> C:\simon\tuscany\sca-r0.91-rc2>gpg: can't open signed data `--verify'
> gpg: can't hash datafile: file open error
>
> I'm a novice at gpg though and this looks like there is something wrong
> with
> the way I'm trying to use it rather than the signature itself so if someone
> else can check this that would be good.
>
> Assuming the signatures are ok none of these are blockers for me so +1 and
> thanks for pulling it all together.
>
> Regards
>
> Simon
>



-
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: Make sca-api.jar an OSGi bundle

[Venkata Krishnan]

Thanks for that explanation Mike.  Not knowing much of OSGi, I was
trying to be a bit conservative.  Now convinced, here is my +1 for
this inclusion.

- Venkat

On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote:

Venkat,

I'm in favour of adding OSGi metadata to relevant jars to enable them to
act as OSGi bundles.  I think that OSGi is in a different space than
"other runtimes" and that supporting it is a good idea.

Other comments inline...

Yours,  Mike

Venkata Krishnan wrote:
> Hi,
>
> This seems ok since you say it does not have side effects for other
> consumers.  However, I wonder if we can keep doing this for accomodating
> other runtimes as well - am not sure what the others might want or if
> they'd
> need something not as simple as this - just postulating here ;-).

OSGi is less "another runtime" and more "a whole class of runtimes", so
in that sense it is special.  OSGi is a framework for organizing
runtimes into logical chunks.  Many runtimes use OSGi - the most famous
being Eclipse.  I think that we should make it easy for Tuscany SCA (and
SDO for that matter) to fit into a runtime that is using OSGi.  To do
that ideally requires us to add some OSGi metadata to relevant jar files.

> Or,
> seeing it from the other side I wonder if it would be ok to consider
> specific inclusions in OSGi bundles to facilitate their handling in a SCA
> runtime.

This is looking at it the other way around.  I believe that this is the
work that Rajini and others are already doing in building an
 for Tuscany, to allow stuff built using OSGi
to work cleanly within Tuscany.

>
> So, from what I am able to comprehend, I'd prefer to avoid this tie in.
> Maybe we should also hear what others have to say.

It is no tie-in.  Adding OSGi metadata does not make any of our JARs
unusable by anyone else and it does not force the use of OSGi - and the
handling of the OSGi metadata in the build process can be pretty simple,
I believe.

There is a whole separate question about whether we should consider
building the whole Tuscany SCA runtime using OSGi.  There are merits to
that, but also potential downsides - however, we can have a completely
separate debate about that some other time, since it has nothing to do
with Rajini's current proposal.

>
> Thanks
>
> - Venkat
>
> On 7/6/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> Could we convert sca-api.jar to an OSGi bundle so that bundles used by
>> the
>> OSGi implementation type can import SCA annotations and interfaces? This
>> may
>> be already being addressed in the other OSGi related work, but the change
>> is
>> simple and will enable the support for SCA annotations in OSGi bundles to
>> progress.
>>
>> Converting sca-api.jar to an OSGi bundle would just need the addition
>> of a
>> few entries in the manifest file for the jar, and will not affect any
>> other
>> modules using the jar file as a regular jar.
>>
>> Thank you...
>>
>> Regards,
>>
>> Rajini
>>
>

-
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: Java SCA 0.91 Release related

[Venkata Krishnan]

Hi, I don't see this.  Maybe you did a copy paste and copied the 'and'
as well.

- Venkat

On 7/6/07, haleh mahbod <[EMAIL PROTECTED]> wrote:

URL has an extra text on it -> 'and'. Here is the correct one.
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubating<http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand>


On 7/5/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I was intending to send Java SCA RC2 for a vote but it happens that
> minotaur
> is down and I cannot stage RC2.  So, meanwhile it would be great if people
> can take a look at the tag -
>
> 
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand
> try to give me some inputs on how it looks for a release.
>
> Thanks.
>



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

[VOTE] Release Tuscany Java SCA 0.91-incubating RC2

[Venkata Krishnan]

Hi,

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java.

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc2/

This includes the binary and source distributions, the RAT reports, and the
Maven staging repository.

The SVN tag for the release is:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubating/

All comments raised for RC1 -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19416.html -
have been fixed.

Looks ok to me - so here's my +1.

Thanks

- Venkat

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

Re: Make sca-api.jar an OSGi bundle

[Venkata Krishnan]

Hi,

This seems ok since you say it does not have side effects for other
consumers.  However, I wonder if we can keep doing this for accomodating
other runtimes as well - am not sure what the others might want or if they'd
need something not as simple as this - just postulating here ;-).  Or,
seeing it from the other side I wonder if it would be ok to consider
specific inclusions in OSGi bundles to facilitate their handling in a SCA
runtime.

So, from what I am able to comprehend, I'd prefer to avoid this tie in.
Maybe we should also hear what others have to say.

Thanks

- Venkat

On 7/6/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:


Hello,

Could we convert sca-api.jar to an OSGi bundle so that bundles used by the
OSGi implementation type can import SCA annotations and interfaces? This
may
be already being addressed in the other OSGi related work, but the change
is
simple and will enable the support for SCA annotations in OSGi bundles to
progress.

Converting sca-api.jar to an OSGi bundle would just need the addition of a
few entries in the manifest file for the jar, and will not affect any
other
modules using the jar file as a regular jar.

Thank you...

Regards,

Rajini

Java SCA 0.91 Release related

[Venkata Krishnan]

Hi,

I was intending to send Java SCA RC2 for a vote but it happens that minotaur
is down and I cannot stage RC2.  So, meanwhile it would be great if people
can take a look at the tag -
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand
try to give me some inputs on how it looks for a release.

Thanks.

Re: Extending the runtime and domain models

[Venkata Krishnan]

I don't see any reason why you should not open them up a bit instead of
duplicating code.  Especially now that we associate various objects by
interface types, opening them will help in reusing them by substituting
different implementations for such associations.

- Venkat

On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:


The runtime classes (ReallySmallRuntime and ReallySmallRuntimeBuilder) and
the EmbeddedSCADomain implementation are pretty well locked down in terms
of
overriding their members and functions. I had to make copies of most of
this
function to create the distributed runtime and domain. Can we loosen this
up
a bit so that these classes can be extended?

Simon

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Hi,

Yes I too see it.  Just trying to figure out the reason.  For now it seems
like a 'self reference' was not created and added to this component.  Need
to figure out why.

- Venkat

On 7/4/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Is anyone seeing the following error trying to build 0.91 branch ?

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.547
sec <<< FAILURE!
testTransform(dbecho.EchoDataBindingTestCase)  Time elapsed: 2.5 sec  <<<
ERROR!
org.osoa.sca.ServiceRuntimeException: Service not found: ComponentA
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getService(
DefaultSCADomain.java:278)
at dbecho.EchoDataBindingTestCase.testTransform(
EchoDataBindingTestCase.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(
OldTestClassRunner.java:35)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(
JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(
SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(
SurefireBooter.java:818)


On 7/3/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am working on fixing the points raised by Ant and Simon.  While I am
> looking at the others I need help in filling up the following: -
>
> - the missing readmes in the demos
> - the missing readmes and ant scipts in the samples
>
> Does anybody have the time to help in this ?  Please let me know.
>
> Thanks
>
> - Venkat
>
> On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Thanks Simon.  Let me go fix these things.  Will call out for help
when
> > needed.  :)
> >  - Venkat
> >
> >
> > On 7/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > >
> > > On 6/29/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > >
> > > > On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Please review and vote on the 0.91 release artifacts of Tuscany
SCA
> > > for
> > > > > Java.
> > > > >
> > > > > The artifacts are available for review at:
> > > > > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> > > <http://people.apache.org/%7Esvkrish/tuscany/0.91-rc1/>
> > > > >
> > > > > The SVN tag for the release is:
> > > > >
> > > > >
> > > >
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
> > >
> > > > >
> > > > > Seems ok to me, so here is my +1.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > - Venkat
> > > > >
> > > >
> > > > +1
> > > >
> > > > This looks pretty good to me. There's a few things that could be
> > > improved
> > > > -
> > > > missing readme's for demos and some samples, some missing license
> > > headers
> > > > have crept in, the rmi calculator client fails for me - none of
those
> > > are
> > > > blocking problems though. The biggest is for 0.90 we were asked to
> > 

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Hi,

I am working on fixing the points raised by Ant and Simon.  While I am
looking at the others I need help in filling up the following: -

- the missing readmes in the demos
- the missing readmes and ant scipts in the samples

Does anybody have the time to help in this ?  Please let me know.

Thanks

- Venkat

On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Thanks Simon.  Let me go fix these things.  Will call out for help when
needed.  :)
 - Venkat


On 7/2/07, Simon Laws < [EMAIL PROTECTED]> wrote:
>
> On 6/29/07, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > Please review and vote on the 0.91 release artifacts of Tuscany SCA
> for
> > > Java.
> > >
> > > The artifacts are available for review at:
> > > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> <http://people.apache.org/%7Esvkrish/tuscany/0.91-rc1/>
> > >
> > > The SVN tag for the release is:
> > >
> > >
> > 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
>
> > >
> > > Seems ok to me, so here is my +1.
> > >
> > > Thanks.
> > >
> > > - Venkat
> > >
> >
> > +1
> >
> > This looks pretty good to me. There's a few things that could be
> improved
> > -
> > missing readme's for demos and some samples, some missing license
> headers
> > have crept in, the rmi calculator client fails for me - none of those
> are
> > blocking problems though. The biggest is for 0.90 we were asked to
> list
> > all
> > the jars under the Apache license just to make the licensing clear but
> > thats
> > missing, again not a blocker but it would be good to show we listen.
> I'll
> > try to fix most of these in the brn in case we do cut another rc, but
> > unless
> > many more problems are discovered this rc gets my vote.
> >
> >...ant
>
>
>
> Apologies for being so late to review the RC. Was away last week.
> Anyhow...
>
> I got a clean build of the source distro.
> I went through the samples in the bind distro. The issues I found are
> attached below. Ant, I'm assuming you have fixed many of these. If you
> let
> me know which ones are outstanding I'll go and provide fixes.
>
> None of these in their own right are blockers but together I think they
> mark
> a backward step in terms of quality from 0.90.  I would like to see
> another
> RC but as I'm so late in doing this have to vote - 0.5.
>
>
> Get rid of svg files from the distribution
>
> Samples/README - overview samples list doesn't match current samples
> list
>
> calculator-rmi-reference
> --
>
> Doesn't run for me from the command line.
>
> C:\simon\tuscany\r0.91-rc1\apache-
> tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
> ncubating\samples\calculator-rmi-reference>ant run
> Buildfile: build.xml
>
> run:
>  [java] Composite assembly problem: No targets for reference:
> addService
>  [java] Composite assembly problem: No targets for reference:
> divideService
>  [java] Composite assembly problem: No targets for reference:
> multiplyServic
> e
>  [java] Composite assembly problem: No targets for reference:
> subtractServic
> e
>  [java] Exception in thread "main" java.lang.NullPointerException
>  [java] at calculator.CalculatorServiceImpl.add(
> CalculatorServiceImpl.ja
> va:54)
>  [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>  [java] at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAcces
> sorImpl.java:64)
>  [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMet
> hodAccessorImpl.java:43)
>  [java] at java.lang.reflect.Method.invoke(Method.java :615)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.JavaTar
> getInvoker.invokeTarget(JavaTargetInvoker.java:112)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.JavaTar
> getInvoker.invoke(JavaTargetInvoker.java:134)
>  [java] at
> org.apache.tuscany.sca.implementation.java.invocation.TargetI
> nvokerInvoker.invoke(TargetInvokerInvoker.java:46)
>  [java] at
> org.apache.tuscany.sca.core.invocation.AbstractInvocationHand
> ler.invoke(AbstractInvocationHandler.java:84)
>  [java] at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i
> nvoke(JDKInvocationHandler.java:73)
> 

Re: SCA 0.92 release?

[Venkata Krishnan]

Hi,

Some time ago, just after the creation go TUSCANYWIKI, I had suggested that
committers and non-committers both use only TUSCANYWIKI.

Things that need to go the website also should get added in TUSCANYWIKI
first, just that committers will take up the responsibility of copying them
over to TUSCANY.

This way, the wiki that all of us use is just one which is TUSCANYWIKI.  The
other space TUSCANY is to be perceived just as a web content hosting space
and anything that happens there is only a selective copy over from
TUSCANYWIKI.

Thoughts ?

- Venkat


On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:


On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:



Can we move this information across the to the new wiki space (
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so that
> everyone (including non committers) can add to it?


Is it really so bad having only committers able to update the release plan
and having others needing to post to the mailing list? The committers are
the ones responsible for doing the release (others are still very welcome
to
participate and contribute).

   ...ant

Re: The complete patch for TUSCANY-1341 is available

[Venkata Krishnan]

Hi,

I really like the approach mentioned under '3'.  While the SPIs might
undergo changes sometime, this is probably too early, especially now that we
have promised for its stability from Release 0.90.  Thats just about my
opinion.  Thanks

- Venkat

On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:


I'd like to get some other views on this before I spend a lot of
time reworking this patch.  Please see my comments inline below.

   Simon

ant elder wrote:

> On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
>>
>> I am reconsidering the changes made in stage 2 of this patch, which
>> added two new methods to the Binding SPI interface.
>>
>> I made these changes for the reasons stated in
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
>> and
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19308.html
>> These methods allow bindings to be marked as either callback or
>> forward bindings.  This allows callback binding semantics to be
>> supported correctly with relatively little change to the core runtime.
>>
>> Unfortunately these is a flip side to these benefits.  Adding these
>> methods changes the current published stable Binding SPI, and
>> (probably worse) introduces "pollution" of the Binding SPI to carry
>> information that is there for the convenience of the core runtime,
>> rather than an intrinsic part of the binding semantics.
>>
>> The alternative is to keep the Binding SPI as it was, and make more
>> extensive changes in the core runtime to use the more correct version
>> of the model as proposed in
>>   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19305.html
>>
>> I will look at the impact to the core runtime of the alternative
>> approach that keeps the Binding SPI unchanged and I will post my
>> findings back to this list.
>>
>> This discussion only affects the Binding SPI changes in stage 2 of
>> the patch.  It does not affect the provider SPI changes in stage 1
>> of the patch.
>>
>> I'd be interested in any comments on the above or on any other aspects
>> of this patch.
>
>
>
> It sounds good the binding SPI can remain unchanged, it also sounded
like
> from the other thread that it should be possible to avoid some of the
other
> SPI changes in "stage 1" as well which would be good.
>
I'm getting on quite well with reworking the code that currently depends
on the changes to the binding SPI.  There's one slightly ugly area, but I
think I'll be able to get around it without too much hackery.

The provider SPI changes can't be avoided, though they can be deferred.
In the short term this may seem attractive because it gets something
working with less new code.  However, the total amount of work will be
greater since my patch already contains all the necessary collateral
changes for code that's impacted by the provider SPI changes.  I would
have to do significant rework on the patch to remove these for now, then
repeat much of this work to recreate a smilar set of collateral changes
when we finally adopt these new SPIs.

> How about trying to get as much as this going with as few changes to the
> existing SPI as possible for now even if doing that requires some less
then
> perfect code in the runtime impl and axis2 binding, and then once we
have
> call backs and async working well with axis2 and ws-addressing and
ideally
> at least another extension or two then look at what the best way to
change
> the SPIs might be?
>
I think there's pretty much a straight trade-off between how many of
these SPI changes are deferred and the amount of temporary workaround
code that would be needed in the core to compensate for this.

Let's take the provider SPI changes one by one, in approximate order of
increasing difficulty for working around not having them.

1. Not including the change to remove the redundant isCallback parameter
from ReferenceBindingProvider.createInvoker() doesn't cause any
significant problems in the core.  The core can always pass the
meaningless extra parameter, and the providers can always ignore it.
This does incur the collateral rework costs that I mentioned above
for when we get around to cleaning this one up.

2. Not including the supportsAsyncOneWayInvocation() methods on
ReferenceBindingProvider and ServiceBindingProvider presents a bit
more of a challenge.  One possibility is to create a new marker
interface that can be implemented by providers that support
asynchronous one-way invocation.  The core could test for this marker
interface and omit the thread switch if the provider implements it.
I'm not really convinced that this is cleaner (it's probably a bit
more tricky to explain than just having methods for this as we do
everywhere else in the SPI), but it would get around the need for a
breaking SPI change now.  What do people think about this approach?

3. Not including the createCallbackInvoker() method on
ServiceBindingProvider.
seems at first sight to make it im

Re: [VOTE] Release Tuscany Java DAS beta1

[Venkata Krishnan]

Hi, I tried out the source and binary distributions and here are some
observations: -

Source Distro

- In the license file there is a mention of Tuscany SDO and Eclipse license,
but am not able to figure out a distribution of these packages.  If we are
not distributing them why do we include them in the licenses?
- The Notice file contains a mention of packages used from osoa.org but did
not quite find a distribution for it and don't know if something from osoa
is at all used.
- In the file BUILDING the following could be changed for clairty : -

" Change to the top level directory to Apache Tuscany source distribution"
to
"Go over to the directory where you have extracted the DAS Source
Distribution and execute the following:
- cd tuscany-das-1.0-incubating-beta1
- mvn

- I cleaned up das and sdo from my local repo and was able to build the
source successfully.

Binary Distribution
--
- There are some dependent jars that are spread into the sample
directories.  Just wonder if we can bring them all under the lib and make
the samples use them from lib as we are doing in SCA
- sample-ajax-das has a war file that has jstl.jar packaged in it.  I don't
find any mention of jstl.jar in the license file.

- Samples (from Binary Distribution)
   - CompanyWeb Sample :
   - In the readme for section titled "Running from Tomcat configured
by the build" we should probably make it clear that this is an option to be
tried only with the source disb.  And then there is a mention of
"java/das/samples/testing/tomcat build" which needs to be made relative to
the source disb. extraction.
   -  The section "Deploying the CompanyWeb WAR into a Tomcat you
configure yourself" needs to be updated a bit.  For example it mentions
about downloading derby. jar whereas its already a part of the war
   - Customer Sample - the readme does not have enuf info on how to go
about running it.

I will give the samples another shot tomorrow to get them to work.

Thanks

- Venkat



On 7/1/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Please vote to release the beta1 distribution of Tuscany DAS for Java.

The Release Candidate RC1 for Tuscany Java DAS beta1 is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/

Release Notes are available at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/distribution/binary/RELEASE_NOTES

The maven repository artifacts are posted in a staging repository and
is available at

   http://people.apache.org/~lresende/tuscany/das-beta1-rc1/maven/

The release audit tool (rat) results are available at


http://people.apache.org/~lresende/tuscany/das-beta1-rc1/das-beta1-rc1-rat.log

The tag for the source code is at


https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc1/

Seems 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 0.92 release?

[Venkata Krishnan]

Hi,

I am looking at the Policy Framework and shall update the wiki on the
specifics soon.  Once this is done to some level, I'd also like to help a
bit with the ws-* things (may be WS-Security to start with) that Ant has
listed on the wiki page.

- Venkat

On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:


With the SCA 0.91 release now being voted on how about starting on 0.92?

I've already been adding some things I'm interested in getting done to the
next release wiki page -

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-
so far thats mainly related to improving web services functionality.

So anyone else interested in helping with an 0.92 release or have any
function they'd like to suggest or add to the wiki page? How does aiming
for
getting it done 4 - 6 weeks again sound?

   ...ant

Re: [VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Thanks Simon.  Let me go fix these things.  Will call out for help when
needed.  :)
- Venkat


On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 6/29/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Please review and vote on the 0.91 release artifacts of Tuscany SCA
for
> > Java.
> >
> > The artifacts are available for review at:
> > http://people.apache.org/~svkrish/tuscany/0.91-rc1/
> >
> > The SVN tag for the release is:
> >
> >
>
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/
> >
> > Seems ok to me, so here is my +1.
> >
> > Thanks.
> >
> > - Venkat
> >
>
> +1
>
> This looks pretty good to me. There's a few things that could be
improved
> -
> missing readme's for demos and some samples, some missing license
headers
> have crept in, the rmi calculator client fails for me - none of those
are
> blocking problems though. The biggest is for 0.90 we were asked to list
> all
> the jars under the Apache license just to make the licensing clear but
> thats
> missing, again not a blocker but it would be good to show we listen.
I'll
> try to fix most of these in the brn in case we do cut another rc, but
> unless
> many more problems are discovered this rc gets my vote.
>
>...ant



Apologies for being so late to review the RC. Was away last week.
Anyhow...

I got a clean build of the source distro.
I went through the samples in the bind distro. The issues I found are
attached below. Ant, I'm assuming you have fixed many of these. If you let
me know which ones are outstanding I'll go and provide fixes.

None of these in their own right are blockers but together I think they
mark
a backward step in terms of quality from 0.90.  I would like to see
another
RC but as I'm so late in doing this have to vote -0.5.


Get rid of svg files from the distribution

Samples/README - overview samples list doesn't match current samples list

calculator-rmi-reference
--

Doesn't run for me from the command line.

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\calculator-rmi-reference>ant run
Buildfile: build.xml

run:
 [java] Composite assembly problem: No targets for reference:
addService
 [java] Composite assembly problem: No targets for reference:
divideService
 [java] Composite assembly problem: No targets for reference:
multiplyServic
e
 [java] Composite assembly problem: No targets for reference:
subtractServic
e
 [java] Exception in thread "main" java.lang.NullPointerException
 [java] at calculator.CalculatorServiceImpl.add(
CalculatorServiceImpl.ja
va:54)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAcces
sorImpl.java:64)
 [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMet
hodAccessorImpl.java:43)
 [java] at java.lang.reflect.Method.invoke(Method.java:615)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invokeTarget(JavaTargetInvoker.java:112)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.JavaTar
getInvoker.invoke(JavaTargetInvoker.java:134)
 [java] at
org.apache.tuscany.sca.implementation.java.invocation.TargetI
nvokerInvoker.invoke(TargetInvokerInvoker.java:46)
 [java] at
org.apache.tuscany.sca.core.invocation.AbstractInvocationHand
ler.invoke(AbstractInvocationHandler.java:84)
 [java] at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.i
nvoke(JDKInvocationHandler.java:73)
 [java] at $Proxy1.add(Unknown Source)
 [java] at calculator.CalculatorClient.main(CalculatorClient.java
:35)
 [java] Java Result: 1

Calculator-webapp
--

The ant file produces a war called sample-calculator-web.war rather than
sample-calculator-webapp.war

chat-webapp
--

has no README, diagram or ant build file. Here's the URL you need to use

http://localhost:8080/sample-chat-webapp/

databining-echo
---

C:\simon\tuscany\r0.91-rc1\apache-
tuscany-sca-0.91-incubating\tuscany-sca-0.91-i
ncubating\samples\databinding-echo>ant run
Buildfile: build.xml

run:
 [java] Exception in thread "main"
org.osoa.sca.ServiceRuntimeException:
jav
a.lang.IllegalStateException: java.lang.ClassNotFoundException:
echo.module.Echo
ModuleActivator
 [java] at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
nce(SCADomain.java:263)
 [java] at
org.apache.tuscany.sca.host.embedded.SCADom

[VOTE] Release Tuscany Java SCA 0.91-incubating

[Venkata Krishnan]

Hi,

Please review and vote on the 0.91 release artifacts of Tuscany SCA for
Java.

The artifacts are available for review at:
http://people.apache.org/~svkrish/tuscany/0.91-rc1/

The SVN tag for the release is:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/

Seems ok to me, so here is my +1.

Thanks.

- Venkat

Re: Code check-in freeze on Rel 0.91 branch (https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.91)

[Venkata Krishnan]

Folks, I am not able to pull this off today due to some real bizzare
experiences with 'searching and replacing the SNAPSHOT' and then with the
SVN commits as well.  I'd definitely get this out tomorrow.  My apologies
for this delay.

Thanks

- Venkat

On 6/27/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hello Everybody,

In the next few hours I am going to start with cutting of the first RC for
SCA Release 0.91.  Hence I request you to kindly hold back any check-ins
to the branch -
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.91- 
until I get back about the RC on the ML.  Thanks.

- Venkat

Re: Added a Spring based sample, was: 0.91 release?

[Venkata Krishnan]

Hi Sebastien, thanks for doing this.  I am going to be away for the rest of
the week after today.  So I wish to try an RC before I leave to get some
feedback from the community.   I am leaving out this sample for the first RC
but would most certainly include in the next RC (which I hope will be the
last ;-)).

Thanks

- Venkat

On 6/26/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> [snip]
>> Venkata Krishnan wrote:
>>> Hi
>>>
>>> So here is a list of things that will be included for the 0.91release.
>>>
>>> - binding-ajax (has sample to demonstrate this)
>>> - extension-helper (the scripting extensions demonstrate this)
>>> - binding-ejb
>>> - binding-feed (the bigbank demo uses this)
>>> - implementation-resource   (the bigbank demo uses this)
>>> - implementation-spring  (no sample, no demos, but interesting to
>>> have and
>>> hope Sebastien is able to contribute a sample for this).
>>>
>>> As far as demos and samples are concerned I intend to include only
>>> the ones
>>> that have READMEs.  So if you folks can help me fix READMEs for the
>>> ones
>>> that need to be included and that don't have this, that will be very
>>> helpful.
>>>
>>> Finally, may I request that any improvements or changes which any of
>>> you
>>> wish to be a included in the release be done on the branch and then
>>> also
>>> merged with the trunk immediately.  I hope we don't have large ones
>>> ;-).
>>>
>>> Thanks.
>>>
>>
>> I have added a sample showing how to use the implementation-resource
>> extension under [1]. I can add merge it into the 0.91 branch in a day
>> or two after people get a chance to review it if you think it's
>> useful to have in the release. It doesn't have a README yet, I'll try
>> to add one tomorrow.
>>
>> I'm still working on a Spring sample as well, it will be a variation
>> of the simple-bigbank sample.
>>
>> [1]
>>
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/
>>
>>
>
> I have added a Spring sample under [2]. This is a variation of the
> simple-bigbank sample that uses a nested Spring assembly using
>  instead of a nested SCA assembly using
> .
>
> Here are the relevant XML snippets.
>
> The original SCA simple-bigbank:
>
> BigBank.composite
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace="http://bigbank";
> xmlns:a="http://account";
> xmlns:s="http://stockquote";
> name="BigBank">
>
>
>
> target="StockQuoteServiceComponent"/>
>
>
>
>
>
>
> 
>
>
> Account.composite
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace="http://account";
> name="Account">
>   promote="AccountServiceComponent"/>
>
>
>
> target="AccountDataServiceComponent"/>
>USD
>
>
>
> class="bigbank.accountdata.AccountDataServiceImpl"/>
>
>promote="AccountServiceComponent/stockQuoteService"/>
>
> 
>
>
> The SCA + Spring based spring-bigbank:
>
> BigBank.composite
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace="http://bigbank";
> xmlns:s="http://stockquote";
> name="BigBank">
>
>
>
> target="StockQuoteServiceComponent"/>
>
>
>
>
>
>
> 
>
>
> Account-spring-context.xml
>
> http://www.springframework.org/schema/beans";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns:sca="http://www.springframework.org/schema/sca";
>   xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd";>
>
> class="bigbank.account.AccountServiceImpl">
>
>
>
>
>
> class="bigbank.accountdata.AccountDataServiceImpl">
>
>
> 
>
>
>
> [2]
>
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/spring-bigbank/
>
>

I improved the sample a bit to show how to declare proper SCA services
and references in a Spring assembly, using the Spring SCA extension
elements.

Account-spring-context.xml now looks like this:

http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xmlns:sca="http://www.springframework.org/schema/sca";
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
   http://www.springframework.org/schema/sca
http://www.springframework.org/schema/sca/spring-sca.xsd";>
















--
Jean-Sebastien


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

Code check-in freeze on Rel 0.91 branch (https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.91)

[Venkata Krishnan]

Hello Everybody,

In the next few hours I am going to start with cutting of the first RC for
SCA Release 0.91.  Hence I request you to kindly hold back any check-ins to
the branch -
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-0.91 -
until I get back about the RC on the ML.  Thanks.

- Venkat

Re: [VOTE] Fuhwei Lwo for Tuscany Committer

[Venkata Krishnan]

Yes, I am aware of Fuhwei Lwo's contribution to some extent and he'd get my
whole-hearted nod.

Here is my +1.

- Venkat

On 6/26/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


I'd like to propose Fuhwei Lwo as a Tuscany Committer.

According to my gmail archive he has, since mid of 2006, posted 114 times
to
tusany-dev, 79 of those times resulting from interactions with JIRA issue
management.

He has raised 34 JIRAs (see [1])

The gmail search  -- "from:fuhwei [jira] Attachment:" shows
that
Fuhwei has attached around 27 patches to JIRAs.

The JIRAs he raises, the comments he makes and the solutions he provides
demonstrate in depth knowledge of SDO and clearly he will be a strong
asset
for the community.

Please vote to give Fuhwei this well deserved status

Regards, Kelvin.

[1]

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&reporterSelect=specificuser&reporter=fuhwei&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC

SCA Release 0.91 Distros

[Venkata Krishnan]

Hi,

Here is where distros that are intended for SCA Release 0.91 have been put
up for a quick review.

http://people.apache.org/~svkrish/Rel_0.91/

I request a review of these distros from you folks.  I plan to cut an RC
this Wednesday or Thursday based on the review comments.  These distros
aren't yet complete and ready.   Things that need to be work on further are
:
- Updated Release Notes
- Verifying inclusion of Disclaimer, Notices, License files

With respect to licenses, given that the following modules have been added,
what are there additional license notifications that need to be included.
- binding-ejb
- binding-ajax
- binding-feed
- implementation-spring
- implementation-resource

Anything else that has been left out of the distros ?

Thanks.

- Venkat

Re: Trunk Broken

[Venkata Krishnan]

Hi.. I have reverted back on the breaking changes and have the trunk
building now.  Thanks to Sebastien :) for pointing out the information
related to svn merges on anther thread on this ML - that was helpful.

Thanks

- Venkat

On 6/25/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,  I might have just about broken the trunk accidently commiting some
half baked changes to the policy module alongside with some fixes for
license headers.  I am right now fixing it.  I regret and apologize for
this inconvenience.

Thanks

- Venkat

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I have cleaned up the branch and the corresponding parts in the trunk to fix
for missing header files.  Here is an updated RAT report.

http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt

Thanks

- Venkat

On 6/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Simon Nash wrote:
> Comments inline.
>
> Simon
>
> ant elder wrote:
>
>> On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> 
>>
>> as long as something works, I'm not sure why we would exclude it from a
>>
>>> Tuscany release.
>>
>>
>>
>> I think we need a bit more clarity about what it means to include
>> something
>> in the release. Is it just having the code included in the src
>> distro, or
>> included in the src distro as part of the build, or also included in
the
>> binary distro, or included in both distro's along with itests, samples,
>> readme's or web site doc, and mention of the new thing in the release
>> notes?
>>
> My take is that included in the release means included in both distros
> along with itests, samples, readmes or web site doc, and mention of the
> new thing in the release notes.
>

+1 from me.

I'm expecting the itest suite to grow over time as not all extensions
are covered yet.

I just added a sample for the implementation-resource extension, and am
still working on a sample for the implementation-spring extension.

>>
>>> From the 0.90 release things were pulled out for not being quite
>>> there, a
>>
>> lot of the time spent before the final release artifacts got done was
>> because people reviewing the distro's wanted all things up to a certain
>> standard. Getting all this done can take a lot of work. Last minute
>> changes
>> often cause unexpected blocking problems in the distributions
>> resulting in
>> respins and more delay.
>>
>> If we just include everything "that works" is someone reviewing a
>> release RC
>> going to complain that some new sample is missing a readme, that a demo
>> should have an Ant build script, or that some new extension doesn't
even
>> have a sample? If things must be of a certain standard then I don't
>> think
>> its reasonable to expect the release manager to do all the work to get
>> things there.
>>
> I agree that these things are needed and that the burden of doing them
> should not fall on the RM.
>

+1 that's what I had in mind as well when I said "works", as samples and
a readme are the basic requirements for a user to be able to get an
extension to work.

>> How about:
>> - by default everything is kept in the src distro unless there's some
>> reason
>> not to
> >
> I'm not sure about this. What is the value of including modules in the
> source distro but exluding them from the build? The latest levels of
> this code (presumably better) are available in trunk. Since these things
> weren't built or tested as part of the release, the snapshot state they
> were in on release date has no particular significance.
>
> I also recall a discussion some time ago (not specific to Tuscany but on
> [EMAIL PROTECTED] IIRC) in which it was said that the source distro
> is what really defines the content of the release, and the binaries are
> included for convenience. For all of these reasons, it seems better for
> the source and binary distros to have matching contents unless there's
> some reason not to.
>

Matching source and bin distros make more sense to me as well.

>> - only the things mentioned on the release wiki page get included in
the
>> build, binary distribution, and mentioned in the release notes
> >
> This seems OK for new function. I'm not sure what process we use for
> JIRA fixes. They don't seem to be listed on this page. I would expect
> that marking the "Fix version field" accordingly is all that is needed.

Not sure that it's realistic.

>
>> - after the brn is cut we need to ask on the ML before adding new
>> things to
>> the wiki release page
> Agreed.

+1

>
>> - adding something to the wiki release page implies some commitment
>> to help
>> get it to the required standard in line with the release schedule.
> >
> Agreed.

+1

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


--
Jean-Sebastien


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

Trunk Broken

[Venkata Krishnan]

Hi,  I might have just about broken the trunk accidently commiting some half
baked changes to the policy module alongside with some fixes for license
headers.  I am right now fixing it.  I regret and apologize for  this
inconvenience.

Thanks

- Venkat

Re: 0.91 release?

[Venkata Krishnan]

Hi

So here is a list of things that will be included for the 0.91 release.

- binding-ajax (has sample to demonstrate this)
- extension-helper (the scripting extensions demonstrate this)
- binding-ejb
- binding-feed (the bigbank demo uses this)
- implementation-resource   (the bigbank demo uses this)
- implementation-spring  (no sample, no demos, but interesting to have and
hope Sebastien is able to contribute a sample for this).

As far as demos and samples are concerned I intend to include only the ones
that have READMEs.  So if you folks can help me fix READMEs for the ones
that need to be included and that don't have this, that will be very
helpful.

Finally, may I request that any improvements or changes which any of you
wish to be a included in the release be done on the branch and then also
merged with the trunk immediately.  I hope we don't have large ones ;-).

Thanks.

- Venkat




On 6/22/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Venkata Krishnan wrote:
> Yes... I guess it should be possible to have them.  I'd say, at the
least
> that we have a readme that describes the demo layout, what its intent
> is and
> how you get to run it.  I guess this is something we have already done
> for
> the samples.
>
> - Venkat
>
> On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> [snip]
>> Simon Laws wrote:
>> > Are we releasing the demos this time? Were you sans aggregator
because
>> > there
>> > is a problem with it? I can go fix it if so. I know I should go try
it
>> > but I
>> > haven't checked the branch out yet;-)
>> >
>> > Simon
>> >
>>
>> Would it be possible to have the demos in the release? What do we need
>> to do to make it happen?
>>
>> Thanks.
>>
>> --
>> Jean-Sebastien
>>
>>

I'll contribute the README for the Bigbank demo. Hope to have it by
tomorrow.

The Bigbank demo uses the implementation-resource extension, which makes
it much easier to package and run as it doesn't need to be packaged in a
WAR anymore, so if bigbank-demo is included and implementation-resource
needs to be as well.

--
Jean-Sebastien


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

Re: Component Property Definition - resolving 'file' attribute

[Venkata Krishnan]

Thanks Sebastien.  I'll try to use this now and see how things go.

- Venkat

On 6/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Luciano Resende wrote:
> Would we also need to post process the contribution to check for
> unresolved references ? I'm guessing that, file references outside
> from the contribution scope will always be on the unresolved status
> ,and would need further processing.
>
> On 5/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> Venkata Krishnan wrote:
>> > Hi,
>> >
>> > The property value definition for a component can have an attribute
>> named
>> > 'file' that points to a xml file that might contain the value for a
>> > property. The question is - now that the contribution service is in
>> shape
>> > must it be used to resolve this file as well just like all other
>> > artifacts.
>> > If so could somebody please provide some pointers on how to do this.
>> > Thanks
>> >
>> > - Venkat
>> >
>>
>> I think it would be a good idea to use it, this would require a simple
>> change to our ArtifactResolver implementation to support something like
>> a FileReference object, similar to what we've done for classes with
>> ClassReference, but we probably also need to confirm what the SCA
>> assembly spec actually means by:
>> <<<
>> 287 - file (optional) – a dereferencable URI to a file containing a
>> value for the property
>>  >>>
>>
>> In particular:
>> - foo/bar.xml - is foo/bar.xml relative to the current SCA
contribution?
>> or the referencing composite file?
>> - /foo/bar.xml - is /foo/bar relative to my hard drive? or the current
>> SCA contribution?
>> - http://foo.org/bar - is this allowed?
>>
>> --
>> Jean-Sebastien
>>
>>

In revision r548560 I have added support for resolution of contribution
DeployedArtifacts.

To resolve an artifact, you simple need to create a DeployedArtifact -
see ContributionFactory.createDeployedArtifact() -, set it's URI to the
URI of the artifact inside the SCA contribution, then call
ModelResolver.resolve(theDeployedArtifact). You'll get back the
populated/initialized DeployedArtifact, containing its absolute location
and the model that was read from it, if any.

This can be used to resolve files used to configure properties and
implementation files as well.

--
Jean-Sebastien


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

Re: Tuscany/ODE resources questions

[Venkata Krishnan]

Is this something that we should consider permitting thro external config
files ?  And how would it work - the contribution service picks the resource
up and makes it available to the module activators  ?

Thanks

- Venkat


On 6/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I'm still reviewing the patch provided by Matthieu [1], but I think he
is taking the similar approach we have for the embedded hosts.

I think that, one difference, is that we don't necessary expose or let
the user tweak server configuration when we start an embedded jetty or
tomcat, do we ?

[1] http://issues.apache.org/jira/browse/TUSCANY-1365

On 6/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I assume there is going to be just about 'one' ODE instance which might
be
> running several processes that are implementations of different
components
> in a deployment.  Is the ODE server something that we should implement
on
> lines with the 'hosts' that we have have ?   Thoughts ?
>
> - Venkat
>
> On 6/21/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> >
> > Hi guys,
> >
> > I'm starting on the lifecycle part of the Tuscany/ODE integration to
get
> > an
> > engine started with all its necessary resources (transaction,
persistence,
> > ...). I can go with in-memory mode and light configuration for now but
> > we'll
> > want a fully working server sooner or later. So I have a few
questions:
> >
> > 1. How can I get server-wide configuration properties to configure the
> > behavior of the engine? Things like the size of our thread pool, if we
> > should use an embedded database or try to lookup a datasource, some
memory
> > optimization modes we can run in, ... These would be for the whole ODE
> > server and not on a per-process basis.
> >
> > 2. How can I get the a transaction manager? I haven't been able to
find an
> > extension point for it. If there are none available, I can still
create my
> > own but it'd be probably be better to reuse the Tuscany one if it's
there.
> >
> > 3. In embedded persistence mode, ODE uses a Derby database. Which
means
> > files located somewhere. Is there a way to lookup a given directory
under
> > which the database could be made available? For example when we deploy
ODE
> > in a webapp for example, the database is prepackage in the webapp and
we
> > find it under the context root (or alternatively a path can be
configured,
> > see 1)
> >
> > I think that's all for now but I'll certainly find more in the coming
days
> > :)
> >
> > Thanks!
> > Matthieu
> >
>


--
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: Lazy loading of Tuscany extensions, was: Status of Java SCA 0.90 release

[Venkata Krishnan]

I am yet to try this out but then from what I read, this sounds good and
useful as it would determine how fast we can bring up the runtime.

Thanks for doing this :)

- Venkat

On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:
>
> There has been many commits and good progress the last few days, so I
> spent a little bit of time checking the status of the trunk.
>
> Here's a summary of what I found:
> - The code cleanup is almost complete, I think there's a little bit
> work left to refactor one last .spi. package, remove a few dead
> classes, also it looks like Raymond has started to clean up the Scope
> registry and WorkContext I'm not sure if it's finished or not.
> - The Java, Script and RMI extensions are now stable, as well as the
> sample implementation, binding, and data binding extensions.
> - It looks like we have a reasonable Web app story with a servlet
> context listener, but it may require a little bit of cleanup to avoid
> confusion with sca-contribution.xml. I'm also not sure if it allows to
> expose Web Services from a Web app, or if we even want to do that now.
>
> Main todo's that I could think of:
> - Port the Web Service binding extension to the latest code, as it's
> really important to have, and is also used by many integration tests.
> - Run RAT and check licenses and notices.
> - Check why the itest/spec-api test cases are failing.
> - Create a JAR containing the source of our runtime, to help debugging
> in an IDE.
> - Are the samples build.xml finished?
> - I have ported the Spring extension to the latest code but need to do
> a little bit of cleanup tomorrow before committing it.
> - I'm not sure about the JSONRPC binding, wouldn't it be nice to have
> it too?
> - Lazy loading of our modules to avoid loading too many dependencies
> when using tuscany-sca-all.jar.
> - Rename the packages to *.sca.* but I would suggest to delay this to
> a later point some time next week after our first RC.
>
> And there's probably a few more :)
>

0.91 is around the corner and I finally found some time to tackle the
"Lazy loading of modules" issue mentioned in this thread.

The 0.90 release code was pretty aggressive with loading all Tuscany
extension modules on the classpath. This can be optimized now.

With the changes I have committed today (r549339) an extension does not
have to register a ModuleActivator anymore (it can still do it but does
not have to). Instead you can declare your Tuscany extension's
ArtifactProcessors and ProviderFactories individually, still using the
same META-INF/services mechanism, but allowing you to specify additional
metadata when you declare them, like the QName of the XML element and
the name of the model class you're handling.

If you do that, then you'll give the Tuscany runtime enough information
to allow it to load your classes dynamically, when your particular
implementation or binding extension is hit in an SCA assembly. If your
extension is not used in your application, it will not be loaded at all.

I have committed new extension samples that show how to use this
improved declaration mechanism:
samples/implementation-crud2-extension
samples/binding-echo2-extension
samples/implementation-pojo2-extension

File

META_INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor
registers an artifact processor
syntax:
;type=#,model=

File

META_INF/services/services/org.apache.tuscany.sca.provider.ImplementationProviderFactory
registers an implementation provider factory
syntax:
;model=

File

META_INF/services/services/org.apache.tuscany.sca.provider.BindingProviderFactory
registers a binding provider factory
syntax:
;model=

If people find this new capability useful I can help merge the code into
the 0.91 branch. The changes are mainly new Lazy*Something classes and a
little more code in the host-embedded runtime bootstrapping.

--
Jean-Sebastien


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

Re: Tuscany/ODE resources questions

[Venkata Krishnan]

Hi,

I assume there is going to be just about 'one' ODE instance which might be
running several processes that are implementations of different components
in a deployment.  Is the ODE server something that we should implement on
lines with the 'hosts' that we have have ?   Thoughts ?

- Venkat

On 6/21/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:


Hi guys,

I'm starting on the lifecycle part of the Tuscany/ODE integration to get
an
engine started with all its necessary resources (transaction, persistence,
...). I can go with in-memory mode and light configuration for now but
we'll
want a fully working server sooner or later. So I have a few questions:

1. How can I get server-wide configuration properties to configure the
behavior of the engine? Things like the size of our thread pool, if we
should use an embedded database or try to lookup a datasource, some memory
optimization modes we can run in, ... These would be for the whole ODE
server and not on a per-process basis.

2. How can I get the a transaction manager? I haven't been able to find an
extension point for it. If there are none available, I can still create my
own but it'd be probably be better to reuse the Tuscany one if it's there.

3. In embedded persistence mode, ODE uses a Derby database. Which means
files located somewhere. Is there a way to lookup a given directory under
which the database could be made available? For example when we deploy ODE
in a webapp for example, the database is prepackage in the webapp and we
find it under the context root (or alternatively a path can be configured,
see 1)

I think that's all for now but I'll certainly find more in the coming days
:)

Thanks!
Matthieu

Re: SCA Toys?

[Venkata Krishnan]

This would be good to get users one step forward with respect to using SCA.
A good tool to have would be one that validates a composite assembly -
against the xsds and then for overall consistency.  I know we do quite a bit
of the latter as part of the artifact processing but wonder if it would go
an extra mile if abstracted as a tool.

I also liked the transformers that we have in the databinding modules
today.  It would be good to have them as individual tools as well.

I'd go for java/tools, atleast to start with.

- Venkat

On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:


I've collected a couple of utilites that have helped me during debugging
some problems (

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/sample-sca-toys/
).
For example this is the code I drop at the end of a test to print out the
model hierarchy that was built:

// inspect the model
Field domainCompositeField = scaDomain.getClass
().getDeclaredField("domainComposite");
domainCompositeField.setAccessible(true);
Composite domainComposite = (Composite)
domainCompositeField.get(scaDomain);

OutputStream os = new ByteArrayOutputStream();
PrintUtil printUtil = new PrintUtil(os);
printUtil.print(domainComposite);
System.out.println("Assembly \n " + os.toString());

I'm sure people have much smarter utils than I that they use to make their
lives easier. If you have tools are you prepared to share them?

How about we create a module:

java/sca/devtools

or even

java/devtools

Simon

Re: 0.91 release?

[Venkata Krishnan]

Hi Simon, the aggregator demo seemed to throw classdefnotfound exception for
javax.servlet. ServletException.

I guess it would be good to release the demos to give people a better feel
of how things work.

- Venkat

On 6/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:


I can speak for the following

binding-jms - Works for sychronous, Java object based messages and
implements a part of the spec but not all of it. So it depends on how
comfortable we are with spec incomplete bindings. I would leave it out for
now

binding-sca - part of the distributed runtime. All checked in now with a
working sample but uses binding-jms (as there is a lack of point to point
protocols that I can leverage without change).  Am just writing mail now
to
describe what I've been up to and now you've taken the branch I'll put it
in
the build.

Are we releasing the demos this time? Were you sans aggregator because
there
is a problem with it? I can go fix it if so. I know I should go try it but
I
haven't checked the branch out yet;-)

Simon

Re: 0.91 release?

[Venkata Krishnan]

Yes... I guess it should be possible to have them.  I'd say, at the least
that we have a readme that describes the demo layout, what its intent is and
how you get to run it.  I guess this is something we have already done for
the samples.

- Venkat

On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


[snip]
Simon Laws wrote:
> Are we releasing the demos this time? Were you sans aggregator because
> there
> is a problem with it? I can go fix it if so. I know I should go try it
> but I
> haven't checked the branch out yet;-)
>
> Simon
>

Would it be possible to have the demos in the release? What do we need
to do to make it happen?

Thanks.

--
Jean-Sebastien


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

Re: Policy Framework Impl. in Tuscany

[Venkata Krishnan]

Hi Sebastien,

First thanks to you and Dave for responding to my queries.

I always had this one point troubling my mind with this.  Its about creating
those various proxy objects and abandoning them once they are resolved to
the original one. Since we do this right across our model I wonder if it
would do hurt to have so many objects dereferenced this way or am I
imagining too much and that this is actually quite affordable.

Thanks

- Venkat

On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


It looks like we're on the same page, I added some clarifications where
you had a question inline.

scabooz wrote:
> Venkat,
> comments embedded...
>
> - Original Message - From: "Jean-Sebastien Delfino"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, June 18, 2007 10:33 AM
> Subject: Re: Policy Framework Impl. in Tuscany
>
>
>> Venkata Krishnan wrote:
>>> Hi,
>>>
>>> I am keen on adding further to the Policy support thats in Tuscany
>>> today. I
>>> recently run thro the Policy Framework specs and was looking into
>>> Tuscany on
>>> how far we had gone on this.  Here's my understanding of all that.  I
>>> request people's perspective on my understanding before I go ahead and
>>> implement things.
>>>
>>> 1.  Policy intents and PolicySets are things that can be defined at
the
>>> domain level.  I propose we have Policy Registry or Repository that
>>> hosts
>>> the set of all intents and policy sets that pertain to a domain.
>>
>> +1 but I think we could start with something simpler than a
>> repository, simply a model for definitions.xml, and a reader for this
>> file.
>>
>
> In addition, you could consider PolicySets packaged with a contribution,
> such that it's not possible (a temporary restriction) to reference a
> policySet from another contribution.  Start simple.
>
>>>
>>> 2. There can be a PolicyRegistryService that can provide interfaces
>>> to add,
>>> retrieve and remove intents and policies to the Policy Registry /
>>> Repository.
>>
>> +1
>>
>>>
>>> 3. The set of intents and policy sets for a domain could be defined
>>> in the
>>> definitions.xml file which could be picked up by the
>>> ContributionsProcessor
>>> (see line 2490 of Assembly Model Spec).  Infact there is more - such
>>> as the
>>> intents that are supported by binding and implementation types in
>>> the domain
>>> and so on.  We could have a processor for the sca definitions that
>>> will read
>>> among other artifacts the policy intents and policy sets and add
>>> them to the
>>> registry.  The model objects to represent policy intents and policy
>>> sets and
>>> the factory to create them are already in place under the policy
>>> module.
>>>
>>
>> Policy administration is independent of SCA contributions. How about
>> a new policy-xml module for the code that will read definitions.xml,
>> independent of the ContributionProcessor?
>>
>
> Right. A long term solution would include a seperation of policy from
> contributions.  The "policy registry" could even be separate from
> the Domain as an entity, but a Domain will have a reference to a
> policy registry.
>
>>> 4. SCA artifacts will have intents and policy sets attached to them.
>>> Presently the artifact processors create the Intents and PolicySet
>>> objects.
>>> I propose that the artifact processor that read these SCA Artifacts
>>> will
>>> just about read the QNames and resolve them in the resolution phase
>>> with the
>>> help of the PolicyRegistryService.  This way we can also check if
>>> the intent
>>> or policy set specified for an artifact is really applicable to the
>>> artifact
>>> or not.
>>>
>>
>> Intents need to be resolved to point to the intents defined in
>> definitions.xml in ArtifactProcessor.resolve(). I'd suggest to adopt
>> to the same approach as for all other objects that need to be resolved:
>> 1. read creates an Intent / PolicySet with unresolved = true
>> 2. resolve replaces it with the resolved Intent / PolicySet
>>
>
> I didn't quite follow this.  Is this different from canonicalizing
> intent and policySet attachments as described in the lengthy algorithm
in
> section 1.4.10 of the spec?

I was describing the general pattern currently used in Tuscany to
represent and resolve relationships between models. Our models need to
be able to 

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I have the branch building modules, itests, samples and demos (sans the
aggregator).  I have rolled back the SDO dependencies to the beta1 release
in the branch.

Now I'd like to figure out the modules that we intend to actually include in
this release.  Here is a list of the modules that were a part of the trunks
build, this morning when I cut the branch and are additions over what we
already had for Rel. 0.90.

- binding-jms
- binding-ajax
- binding-ejb
- binding-feed
- databinding-json
- extension-helper
- implementation-bpel
- implementation-resource
- implementation-spring
- topology
- topology-xml

Out of these I know for sure from the wiki (
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents)
that we are going to include the following.  The extensions that depend on
DAS are not going to be a part of this release and am excluding them though
they have been specifed in the wiki.

- binding-ajax
- extension-helper

What do people think about the others.  IMHO, I guess we could include the
following
- binding-ejb
- binding-feed
- implementation-spring

There are a whole lot of others as well on the trunk which are presently not
a part of the build but interesting though :
- binding-sca
- binding-osgi
- implementation-osgi
- the geronimo integration
- implementation-bpel

I am really not sure where we are with these but just about feel that they
are not ready for the release round the corner as they are not yet a part of
the trunk build as of this morning.  However I'd like to know if there are
other opinions on this.

I hope to finalize on this list today so that I may start working on the
distributions tomorrow.

Also, please feel free to point out anything that I might have missed out on
all of this.

Thanks

- Venkat


On 6/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

I guess the changes after beta1 are to do with some restructuring of
classes across packages.  Also when I rolled back the SDO DB back to beta1,
it seems to build fine with just changes to the package names it was using.
So seems like beta1 seems ok for SDO Databinding.  Let me do the same for
the others and get back.

- Venkat

On 6/20/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 6/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I have cut a branch for the 0.91 release and have changed over the
> > artifact
> > versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and
> > here
> > are some problems that I have observed.
> >
> > - The SDO dependency seems to be on the current
> > 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
> > and sdo-lib that are being used
> > as dependencies in the SDO Databinding.  This does not match with the
> last
> > sdo release of 1.0-incubating-beta1 .  So how are we going to go
> forward
> > with
> > the SDO dependency for this SCA release?  Are we going to roll back
> things
> > to beta1 (which is not something I'd be happy about) or should we
> consider
> > using a snapshot from the trunk (which is also something that we have
> > decided not to do)  or is there another alternative to this?  Could
> people
> > please help in this.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 6/19/07, Simon Nash < [EMAIL PROTECTED] > wrote:
> > >
> > > I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
> > > are confident that the DAS release can be created quickly, I think
> > > it's better to go ahead with SCA 0.91 as planned and defer the DAS
> > > support.
> > >
> > > An alternative packaging approach (which I am starting to think
> would
> > > be even better) is to reverse the dependency and have the DAS
> release
> > > ship the pieces identified by Luciano below.  It should be possible
> > > (even desirable) for Tuscany SCA extensions that support another
> > > technology to ship as part of a release of that technology rather
> than
> > > always making them part of a Tuscany SCA release.
> > >
> > >Simon
> > >
> > > Venkata Krishnan wrote:
> > >
> > > > Hi Luciano,
> > > >
> > > > This is a surprise :)... I was planning on taking the 0.91 brn
> > tomorrow
> > > and
> > > > imediately start getting out RCs to vote on, but I can't do that
> if it
> >
> > > > needs
> > > > to include the DAS beta1 release???.
> > > >
> > > > What do people think?
> > > >
> > > > - Venkat
> > > >
> > > > On 6/18/07, Luciano Resende < [EMAIL PROTECTED] > wr

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I guess the changes after beta1 are to do with some restructuring of classes
across packages.  Also when I rolled back the SDO DB back to beta1, it seems
to build fine with just changes to the package names it was using.  So seems
like beta1 seems ok for SDO Databinding.  Let me do the same for the others
and get back.

- Venkat

On 6/20/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 6/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have cut a branch for the 0.91 release and have changed over the
> artifact
> versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and
> here
> are some problems that I have observed.
>
> - The SDO dependency seems to be on the current
> 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
> and sdo-lib that are being used
> as dependencies in the SDO Databinding.  This does not match with the
last
> sdo release of 1.0-incubating-beta1 .  So how are we going to go forward
> with
> the SDO dependency for this SCA release?  Are we going to roll back
things
> to beta1 (which is not something I'd be happy about) or should we
consider
> using a snapshot from the trunk (which is also something that we have
> decided not to do)  or is there another alternative to this?  Could
people
> please help in this.
>
> Thanks
>
> - Venkat
>
> On 6/19/07, Simon Nash <[EMAIL PROTECTED] > wrote:
> >
> > I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
> > are confident that the DAS release can be created quickly, I think
> > it's better to go ahead with SCA 0.91 as planned and defer the DAS
> > support.
> >
> > An alternative packaging approach (which I am starting to think would
> > be even better) is to reverse the dependency and have the DAS release
> > ship the pieces identified by Luciano below.  It should be possible
> > (even desirable) for Tuscany SCA extensions that support another
> > technology to ship as part of a release of that technology rather than
> > always making them part of a Tuscany SCA release.
> >
> >Simon
> >
> > Venkata Krishnan wrote:
> >
> > > Hi Luciano,
> > >
> > > This is a surprise :)... I was planning on taking the 0.91 brn
> tomorrow
> > and
> > > imediately start getting out RCs to vote on, but I can't do that if
it
>
> > > needs
> > > to include the DAS beta1 release???.
> > >
> > > What do people think?
> > >
> > > - Venkat
> > >
> > > On 6/18/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >> Sorry, I'm having some restricted internet access as I'm traveling
> > >> since last week... that's probably why we haven't created a DAS
> > >> release candidate yet... but the community and I think that we are
> > >> ready to have one.
> > >>
> > >> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
> > >> following items:
> > >>- implementation.das
> > >>- implementation.data
> > >>- some samples (maybe including the samples we didn't ship in
0.9)
> > >>
> > >> On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >> > What will be the relationship between SCA 0.91 and DAS?  I have
> seen
> > >> > some discussions on the list about a DAS release.  Will SCA
0.91have
> > >> > this DAS release as a dependency?
> > >> >
> > >> >Simon
> > >> >
> > >> > Luciano Resende wrote:
> > >> >
> > >> > > I have updated the wiki [1] page with things that I'm working
on,
>
> > and
> > >> > > would like to have in 0.91 .
> > >> > >
> > >> > > As for the implementation.das question regarding it's canned
> derby
> > >> db,
> > >> > > we recently created a db utility to create and populate the
> > database,
> > >> > > and I have plans to integrate with it.
> > >> > >
> > >> > > [1]
> > >> > >
> > >>
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> > >>
> > >> > >
> > >> > >
> > >> > > On 6/16/07, ant elder < [EMAIL PROTECTED]> wrote:
> > >> > >
> > >> > >> Wow 571 license problems! after being clean for 0.90 just a
> month
> > >&

Re: 0.91 release?

[Venkata Krishnan]

Hi,

I have cut a branch for the 0.91 release and have changed over the artifact
versions to 0.91-incubating-SNAPSHOT.  I am now trying to build it and here
are some problems that I have observed.

- The SDO dependency seems to be on the current
1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl
and sdo-lib that are being used
as dependencies in the SDO Databinding.  This does not match with the last
sdo release of 1.0-incubating-beta1.  So how are we going to go forward with
the SDO dependency for this SCA release?  Are we going to roll back things
to beta1 (which is not something I'd be happy about) or should we consider
using a snapshot from the trunk (which is also something that we have
decided not to do)  or is there another alternative to this?  Could people
please help in this.

Thanks

- Venkat

On 6/19/07, Simon Nash <[EMAIL PROTECTED]> wrote:


I would prefer not to delay SCA 0.91 for the DAS support.  Unless we
are confident that the DAS release can be created quickly, I think
it's better to go ahead with SCA 0.91 as planned and defer the DAS
support.

An alternative packaging approach (which I am starting to think would
be even better) is to reverse the dependency and have the DAS release
ship the pieces identified by Luciano below.  It should be possible
(even desirable) for Tuscany SCA extensions that support another
technology to ship as part of a release of that technology rather than
always making them part of a Tuscany SCA release.

   Simon

Venkata Krishnan wrote:

> Hi Luciano,
>
> This is a surprise :)... I was planning on taking the 0.91 brn tomorrow
and
> imediately start getting out RCs to vote on, but I can't do that if it
> needs
> to include the DAS beta1 release???.
>
> What do people think?
>
> - Venkat
>
> On 6/18/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
>>
>> Sorry, I'm having some restricted internet access as I'm traveling
>> since last week... that's probably why we haven't created a DAS
>> release candidate yet... but the community and I think that we are
>> ready to have one.
>>
>> Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
>> following items:
>>- implementation.das
>>- implementation.data
>>- some samples (maybe including the samples we didn't ship in 0.9)
>>
>> On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>> > What will be the relationship between SCA 0.91 and DAS?  I have seen
>> > some discussions on the list about a DAS release.  Will SCA 0.91 have
>> > this DAS release as a dependency?
>> >
>> >Simon
>> >
>> > Luciano Resende wrote:
>> >
>> > > I have updated the wiki [1] page with things that I'm working on,
and
>> > > would like to have in 0.91 .
>> > >
>> > > As for the implementation.das question regarding it's canned derby
>> db,
>> > > we recently created a db utility to create and populate the
database,
>> > > and I have plans to integrate with it.
>> > >
>> > > [1]
>> > >
>>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>>
>> > >
>> > >
>> > > On 6/16/07, ant elder <[EMAIL PROTECTED]> wrote:
>> > >
>> > >> Wow 571 license problems! after being clean for 0.90 just a month
>> ago.
>> > >>
>> > >> One question this brings up is what is actually intended to be
>> > >> included in
>> > >> 0.91? There's been quite a few new extensions and demo's etc added
>> > >> recently
>> > >> but no one has said they want those included in 0.91. Should they
be
>> by
>> > >> default or should we just include things that are mentioned on the
>> > >> release
>> > >> wiki page? If so anyone else care to help clean things up, add
>> missing
>> > >> license headers, check the distribution works and includes
>> > >> dependencies etc?
>> > >> The implementation.das is including an entire database in the
>> src, is
>> > >> there
>> > >> any way that could be generated by the tests?
>> > >>
>> > >>...ant
>> > >>
>> > >> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> > >> >
>> > >> > Thanks Ant.  So could we all please use this wiki page to put
down
>> > >> things
>> > >> > that are going to be increments over 0.90.
>>

Re: 0.91 release?

[Venkata Krishnan]

Hi Luciano,

This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and
imediately start getting out RCs to vote on, but I can't do that if it needs
to include the DAS beta1 release???.

What do people think?

- Venkat

On 6/18/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Sorry, I'm having some restricted internet access as I'm traveling
since last week... that's probably why we haven't created a DAS
release candidate yet... but the community and I think that we are
ready to have one.

Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the
following items:
   - implementation.das
   - implementation.data
   - some samples (maybe including the samples we didn't ship in 0.9)

On 6/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> What will be the relationship between SCA 0.91 and DAS?  I have seen
> some discussions on the list about a DAS release.  Will SCA 0.91 have
> this DAS release as a dependency?
>
>Simon
>
> Luciano Resende wrote:
>
> > I have updated the wiki [1] page with things that I'm working on, and
> > would like to have in 0.91 .
> >
> > As for the implementation.das question regarding it's canned derby db,
> > we recently created a db utility to create and populate the database,
> > and I have plans to integrate with it.
> >
> > [1]
> >
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> >
> >
> > On 6/16/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >> Wow 571 license problems! after being clean for 0.90 just a month
ago.
> >>
> >> One question this brings up is what is actually intended to be
> >> included in
> >> 0.91? There's been quite a few new extensions and demo's etc added
> >> recently
> >> but no one has said they want those included in 0.91. Should they be
by
> >> default or should we just include things that are mentioned on the
> >> release
> >> wiki page? If so anyone else care to help clean things up, add
missing
> >> license headers, check the distribution works and includes
> >> dependencies etc?
> >> The implementation.das is including an entire database in the src, is
> >> there
> >> any way that could be generated by the tests?
> >>
> >>...ant
> >>
> >> On 6/16/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Thanks Ant.  So could we all please use this wiki page to put down
> >> things
> >> > that are going to be increments over 0.90.
> >> >
> >> > Also I run the RAT on the trunk - just java/sca and here is the
> >> report.  I
> >> > intend to go and fix the missing headers just ahead of cutting the
> >> branch.
> >> > Before that if anybody would like to jump in and help with this,
> >> please feel
> >> > free do so.
> >> >
> >> >
> >> http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt<
http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt>
> >>
> >> >
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >> > On 6/14/07, ant elder <[EMAIL PROTECTED]> wrote:
> >> > >
> >> > > Taking a branch around the 20th sounds ok to me.
> >> > >
> >> > > The high level things I'm focusing on for the 0.91 release are:
> >> > >
> >> > > - Simplification of using script components (working without
> >> > > .componentType
> >> > > side files)
> >> > > - First cut of the simpler binding/implementation SPI
> >> > > - clean up of ajax and jsonrpc bindings
> >> > > - The EJB binding
> >> > >
> >> > > I'd also said to someone on the user list I'd get WS services
without
> >> > > wsdl
> >> > > working so will try to do that as well.
> >> > >
> >> > > Most of the code for those is close-ish to being done, though
there's
> >> > > still
> >> > > a whole lot of related sample work to get done.
> >> > >
> >> > > I'd started a wiki page for 0.91 at
> >> > >
> >> > >
> >>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> >>
> >> > >
> >> > >...ant
> >> > >
> >> > > On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]>

Re: Domains, runtimes, components and cardinality

[Venkata Krishnan]

Hi,

I guess it should be a good start to have SCA domains span across runtimes
and leave the runtimes being shared by SCA domains to the next iteration.

As for the second point, is there a possibility of seeing this as
replication of components across two runtimes instead of nodes?  Anyways, to
start with, I'd be happy to leave this out for the next iteration.

Thanks

- Venkat


On 6/18/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Following on from recent discussion on the distributed binding (I've been
putting notes here [1])... In a Tuscany SCA runtime what do we expect the
cardinality between the various parts of it to be?

A domain notionally runs on a runtime. In the case of a stand-alone
Tuscany
SCA runtime this will be a single process (C++ exe, Java VM etc.). In the
case of a distributed Tuscany SCA runtime, the runtime is made up of many
distributed nodes that each run parts of the domain.

1/ Can domains share runtimes/nodes?

I.e can components from more than one domain be running inside a single
Tuscany SCA runtime or is the user expected to start up multiple runtimes
to
run multiple domains.

2/ How many nodes can a single component run on?.

I.e. is the assignment of a component to multiple nodes, for performance,
reliability etc. reasons, explicitly supported as part of the topology
description of a distributed domain. If so then the  SCA binding chooses
which node to use. If not then any distribution of workload is considered
to
be a job for the node implementation.

I'd be interested to hear peoples views on this

My starting point is...

1/ No, we will support multiple domains by starting multiple runtimes. We
could add the extra function to support sharing of runtimes between
domains
in the future if it's found to be required.

2/ We shouldn't restrict whatever structure we use to describe the
component/node association to be 1-1. But we can assume 1 in the first
instance and consider adding more complex node selection features to the
SCA
binding in the future.

Regards

Simon

[1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=59826

Re: Finding the .componentType file

[Venkata Krishnan]

On 6/18/07, ant elder <[EMAIL PROTECTED]> wrote:


On 6/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



The component name may be nothing like the implementation name


How does that fit with the spec saying - ""A component type file has the
same name as the implementation file but has the extension
".componentType""
? I'm looking for a way to make the default case easy, it doesn't have to
deal with every edge case.

The componentType file is really to be thought of as an extension of the
> implementation for those (hopefully few) cases where introspection of
> the implementation cannot provide the required information.


Maybe "implementationType" would have been be a better name :-)

My suggestion is that the SPI should put the burden on the
> implementation module - for example a special method on the
> xxxImplementation class with a name like "locateComponentTypeFile".
> Actual loading of the componenttype file can be generic, but finding the
> file is definitely a job for the implementation-handling code.


The problem with this is some don't want the simple xxxImplementation
class
to even be implementing any interface so ideally as much generic function
would be built in the runtime, and thats what I'm trying to find a way of
doing.

I was wondering if the contribution service could help here. It could
discover all the .componentType files in a contribution making their names
available,  the values of all the attributes of the xxxImplementation
class
are also known so it could compare  all the attribute values against all
the
found .componentType file names ignoring the file extension and when
there's
a match thats the .componentType for the implementation. How does that
sound?



That could be quite a gamble in my opinion.  There is a possibility that
some attribute value of an implementation type instance could end up
matching a componentType that corresponds to some other implementation.

Even if the specs changed to have an attribute called 'implArtifact' or
'implResource'  so that you can pick up the implementation resource
information, it would still not help to deal generically if implementation
types have their own means of loading this and the associated componentType
info.  And then what is implementation types decide to  add their extensions
to a ComponentType. ?


...ant



- Venkat

Re: Finding the .componentType file

[Venkata Krishnan]

Hi,

Yes, I'd feel that it could end up being non-compliant and we might lose a
bit on portability as well.  Since an implementation could be reused across
a bunch of components, having the componentType go after the component may
not work.

I'd say that we leave the componentType resolution to the implementation
types upto to locating and loading the resource as input stream after which
the artifact processing can be done generically.

- Venkat

On 6/17/07, ant elder <[EMAIL PROTECTED]> wrote:


I'm struggling with how to define and locate the .componentType side file
in
the implementation SPI. The assembly spec says:

"A component type file has the same name as the implementation file but
has
the extension ".componentType"...The location of the component type file
depends on the type of the component implementation..." (page 13 line
445).

The problem is "the implementation file" is not specific enough and there
isn't a standard way for the runtime to know which implementation
attribute
is the "implementation file". Eg, for implementation.java its the 'class'
attribute, for implentation.script its the 'script' attribute, for
implementation.das its the 'config' attribute etc.

Any one have any ideas on how to do this? Would it be be terribly
non-compliant if the default used by the runtime was "A component type
file
has the same name as the _component_ with the extension ".componentType"?

   ...ant

Re: 0.91 release?

[Venkata Krishnan]

Thanks Ant.  So could we all please use this wiki page to put down things
that are going to be increments over 0.90.

Also I run the RAT on the trunk - just java/sca and here is the report.  I
intend to go and fix the missing headers just ahead of cutting the branch.
Before that if anybody would like to jump in and help with this, please feel
free do so.

http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt

Thanks

- Venkat

On 6/14/07, ant elder <[EMAIL PROTECTED]> wrote:


Taking a branch around the 20th sounds ok to me.

The high level things I'm focusing on for the 0.91 release are:

- Simplification of using script components (working without
.componentType
side files)
- First cut of the simpler binding/implementation SPI
- clean up of ajax and jsonrpc bindings
- The EJB binding

I'd also said to someone on the user list I'd get WS services without wsdl
working so will try to do that as well.

Most of the code for those is close-ish to being done, though there's
still
a whole lot of related sample work to get done.

I'd started a wiki page for 0.91 at

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents

   ...ant

On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Thanks for the faith and encouragement.  This is going to be my first
> experience and I am sure of getting all the help from you folks to pull
> this
> off successfully.
>
> So, to start with, I propose to cut a branch around June 20th, 2007.  If
> people are ok with this, then all that we'd like to be a part of
0.91should
> get in by then (June 20th, 2007).  Does that work fine with everybody?
>
> Also, I'd also like to list down the significant additions /
enhancements
> over 0.90 for the Release Notes.  You can state the item here on this
> thread
> and I will take care of recording it.
>
> - Venkat
>
> On 6/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > +1 from me too.  I'm sure Venkat will do a fine job.
> >
> >Simon
> >
> > Jean-Sebastien Delfino wrote:
> >
> > > Simon Laws wrote:
> > >
> > >> Yeah, Venkat did loads on the last release. +1 from me for Venkat
as
> > >> 0.91 RM
> > >>
> > >> Simon
> > >>
> > >
> > > +1 from me
> > >
> > >
-
> > > 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 are we going to use the Tuscany Wiki space?

[Venkata Krishnan]

Hi Mike,

I agree we need to put some information on the Home page of the TUSCANYWIKI,
related to how the wiki is to be used - alteast earmark some place in the
page hierarchy under which discussion pages should go and how content for
website should be contributed.

As far as the copying of pages over to TUSCANYWIKI from TUSCANY is
concerned, I thought it would be easy for folks wanting to contribute to
website to be able to position their contributions better with respect to
the site structure.  This would get easier if contributions are coming as
corrections or additions to existing pages.

Am I missing a better way of doing this?

- Venkat

On 6/15/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Folks,

I'm a bit confused (nothing out of the ordinary there then!) about how
we intend to use the new Tuscany Wiki space.

So, the Apache Tuscany space is the material which makes up the external
Tuscany website.  I understand our desire to control the update of
material there - hence there is a restricted list of people who can edit
pages there.

So, I thought, perhaps wrongly, that the Tuscany Wiki space was created
to be a space "open to all" where any kind of material can be placed by
anyone.  This includes different sorts of stuff, I think:

a) Material that is being prepared for the Tuscany website, so that it
can be checked out before it goes live.

b) Discussion and similar material that is useful to help the work
within the Tuscany community, but which may never reach the public
website, such as design ideas related to discussions in the mailing list
(good example is the stuff Simon Laws has created relating to
distributed runtime).

Currently, the material in the Tuscany Wiki space is simply a mirror of
the Apache Tuscany space.  I don't think that this is right.  First,
simply repeating everything that is in the main space is confusing at
best.  Worse, there needs to be some explanation of the use of the space
and some specific navigation available, such as where to create new
material and, for material intended for the main Tuscany website, some
explanation of the process.

I'd like folks views on this.  If you agree with me, then I suggest that
we should:

a) Rewrite the front page of the Tuscany Wiki to explain its purpose
b) Remove the Tuscany Wiki pages that are mere copies of pages on the
main Wiki and adjust the navigation to separate out discussion pages
from pages being prepared for the main site
c) Provide an explanation of how to write pages intended for the main
Tuscany website and the process for getting them there...

Thoughts?


Yours,  Mike.

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

Policy Framework Impl. in Tuscany

[Venkata Krishnan]

Hi,

I am keen on adding further to the Policy support thats in Tuscany today. I
recently run thro the Policy Framework specs and was looking into Tuscany on
how far we had gone on this.  Here's my understanding of all that.  I
request people's perspective on my understanding before I go ahead and
implement things.

1.  Policy intents and PolicySets are things that can be defined at the
domain level.  I propose we have Policy Registry or Repository that hosts
the set of all intents and policy sets that pertain to a domain.

2. There can be a PolicyRegistryService that can provide interfaces to add,
retrieve and remove intents and policies to the Policy Registry /
Repository.

3. The set of intents and policy sets for a domain could be defined in the
definitions.xml file which could be picked up by the ContributionsProcessor
(see line 2490 of Assembly Model Spec).  Infact there is more - such as the
intents that are supported by binding and implementation types in the domain
and so on.  We could have a processor for the sca definitions that will read
among other artifacts the policy intents and policy sets and add them to the
registry.  The model objects to represent policy intents and policy sets and
the factory to create them are already in place under the policy module.

4. SCA artifacts will have intents and policy sets attached to them.
Presently the artifact processors create the Intents and PolicySet objects.
I propose that the artifact processor that read these SCA Artifacts will
just about read the QNames and resolve them in the resolution phase with the
help of the PolicyRegistryService.  This way we can also check if the intent
or policy set specified for an artifact is really applicable to the artifact
or not.

5. Loading of PolicySet could get a bit deeper since there is extensibility
that is allowed on the policy language that could be used.  But I guess
WS-Policy will need to be supported for by Tuscany as that is view to be a
common thing that could be used

So thats a summary the loading part.

In the building phase there are algorithms that the Policy Framework Specs
has specified to validate the wiring between components in the context of
policies (including each end of the wire could inherit from ancestor
artifacts and what is the binding or implementation type being used and what
that supports inherently).

Finally during runtime we have to make sure that the policy statements are
handed out to the appropriate QoS infrastructures i.e Security or
Transaction support modules so that they may be enforced.  I am a bit
unclear on the options related to this at the present moment.

Before I get to a discussion on the wiring and runtime aspects related to
policy I wish to know if my thoughts are in the right direction this far.

Thanks

- Venkat