Queries related in the Trunk

[Venkata Krishnan]

Hi Jeremy, Jim, Meeraj,

I assume that runtime/standalone/assembly is going to be the way a SCA
Runtime will be started.  Is this right?

Is there any test or sample in the trunk that can be used to understand how
to program a sca client for example things like how to get hold of a
ComponentContext and use methods over it.  Could you please help with some
pointers?

Thanks

- Venkat

Re: Move Tuscany wiki to Apache CWIKI?

[Venkata Krishnan]

Hi Kelvin,

In my perception, we are moving over to the Confluence wiki - CWIKI.  Infact
some of the recent updates such as things we aspire to do for SCA M3, some
documentation on SCA Deployment and FAQs have already found place there.

Thanks

- Venkat

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


As I'm updating a page on our old wiki,  I'm wondering where we are with
this and whether I should be migrating the content?

Kelvin.

On 24/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> FYI, I have added "edit" permissions to all registered users.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, January 24, 2007 4:59 AM
> Subject: Re: Move Tuscany wiki to Apache CWIKI?
>
>
> > On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > 2) I'm not proposing to change the "edit" policy. The
> >> http://cwiki.apache.org/CWIKI/ page also provides some guidances for
> >> cases
> >> that we use it as a sandbox (open to all registered users) or
> >> documentation
> >> site (open to folks with CLA on file).
> >
> >
> > I also think all our content should be open to any registered user. We
> > want
> > everyone to help maintain it and thats going be more likely to happen
if
> > we
> > make it easy for them. Its harder for users to send in patches for the
> > wiki
> > :)  Can we get update emails sent to the dev list so we all can
monitor
> > the
> > changes?
> >
> >   ...ant
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: What to do with the WSDL tools

[Venkata Krishnan]

Hi,

With respect to the Java2WSDL tool I wish to trim quite of bit of it as most
of what we need has now been incorporated into the Axis2 tool over which
ours has just been a wrapper providing only the missing things.  So AFAICT,
the only thing that our Java2WSDL wrapper could add over the current version
of Axis2 Java2WSDL is the support for SDOs.  I hope to get to this as soon
as I am done with somethings that I currently tied up with.

- Venkat

On 2/7/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Sebastien mentioned stabilizing "tools like WSDL2Java and Java2WSDL
etc." recently and Kelvin and I were previously discussing moving
those tools out of SCA and into SDO on the basis that they actually
don't have any dependency on SCA but do on SDO and EMF. Ant has now
moved them to the axis2 extension, which makes sense given the
dependency on axis2-codegen, but they don't have a dependency on the
other modules in there.

If there is interest in stabilizing these, then let's move them out
to a separate module and release them when they are done.  I assume
that will require a release of SDO first.

--
Jeremy


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

[Specs Related] Component Properties

[Venkata Krishnan]

Hi,

I just took a look at the latest assembly model specs and find a couple of
things that I don't understand.  Could somebody help me out with
clarifications.

i) There are two different illustrations for the schema for a property
element...

   *
   default-property-value?
   

   *
   default-property-value?
   

i.e. one uses a 'required' attribute and another the 'noDefault' attribute.
The xml schema definitions in the appendix however define only 'noDefault'
and so I understand that 'required' is a typo that needs to be removed.  Is
this right?

ii) When defining a 'property value' what is the need to specify the type
for the property.  Isn't it something that is already specified in the
property definition.  i.e. in the following what is the need for the 'type'
or 'element' attributes

*
   property-value?
   

Fwd: [Specs Related] Component Properties

[Venkata Krishnan]

Hi,

I just took a look at the latest assembly model specs and find a couple of
things that I don't understand.  Could somebody help me out with
clarifications.

i) There are two different illustrations for the schema for a property
element...

   *
   default-property-value?
   

   *
   default-property-value?
   

i.e. one uses a 'required' attribute and another the 'noDefault' attribute.
The xml schema definitions in the appendix however define only 'noDefault'
and so I understand that 'required' is a typo that needs to be removed.  Is
this right?

ii) When defining a 'property value' what is the need to specify the type
for the property.  Isn't it something that is already specified in the
property definition.  i.e. in the following what is the need for the 'type'
or 'element' attributes

*
   property-value?


Thanks

- Venkat

Re: Content for next milestone

[Venkata Krishnan]

Hi,

Heres my opinion from the perspective of some items that I have owned up to
do quite a while back - support for complex properties and multivalued
properties.  I'd see them as some fundamental things that a user might
expect to see out of our next milestone and am happy that they are a part of
this list that Sebastien has proposed.

Now to complete this, I am in dire need for a stable runtime and client
API.  I need this for two reasons i) to figure out the workings of the
kernel through debugging so that I may implement these features according to
the framework's design (with loaders, builders, etc.) and ii) to test if the
whole thing sews up together and works as expected.  I am just not able to
figure out how to do this from the current trunk andI have already started
to plead for help in this regard from the community

I have no complaints about the work that is going on presently in the kernel
- infact I am excited about the vision with which its being driven.  But
then, I'd be happy if I could do my parts as well alongside.

Here are my thoughts for the path forward...
- I'd like us to plan for the next milestone release ideally by end of March
to feed the curiosity of our users.  Having a long gap will kill their
interest in our technology.
- I'd deem the current kernel work as well as the items listed by Sebastien
as equally important, but we probably need to figure out how we can do both
parallely.  Can we not do an incremental development of both?  For example
we could baseline a stable and functioning version of the kernel and runtime
and then choose those items from Sebastien's list that can be implemented
over this baseline.  Or maybe do the viceversa, choose the items and bring
the kernel up to a level to be able to support its implementation.  Going
forward with both in increments will also help us to merge forward easily, I
would imagine.
- I don't think its would be a good idea for the items in Sebastien's list
to wait until the ongoing work in the kernel and runtime is complete.

I think Jeremy's point that we have to stop and now look what we are doing
as a community is valid. We must have to get things around so that everybody
in the community is able to contribute effectively.

Thanks

- Venkat


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


A March release with basic functional improvements in a consumable package
(kernel, selected extensions, and tools) makes sense to me.

As well as the items suggested by Sebastien, I'm interested in adding
flexible ordering of elements in SCDL files as required by the SCA spec.

Having work on these items proceed in a branch so that it does not
conflict
with the restructuring and distributed deployment work going on in trunk
would allow people to be more productive, with less interference between
the different activities in progress.

   Simon

Jeremy Boynes wrote:
> Guys,
>
> I'm a little confused here - so far we seem to have 3 different  people
> volunteering to manage 3 different releases. We now have a  very very
> long list of "requirements" many of which have not been  discussed on
> the list and most of which do not have names against  them or really
> relate to the coding that is actually going on; they  also don't seem to
> apply to two out of the three releases. Version  numbers are being
> assigned to milestones, we have stabilization  branches and end-to-end
> scenarios, all without meaningful discussion  on this list.
>
> I think we need to stop and figure out what we are doing as a
> community. Here, on this list, with everyone involved.
> --
> Jeremy
>
> On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote:
>
>> Jim Marino wrote:
>>
>>> Sebastien,
>>>
>>> I'm a little surprised that you have not referenced the previous
>>> release discussion thread or any of the work that has been ongoing
>>> in core over the past month and a half:
>>>
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html
>>>
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html
>>>
>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html
>>>
>>> Most of the work in core during this period has been aimed at
>>> getting a release of kernel out that supports features outlined in
>>> the first referenced thread. How does your proposal relate to that
>>> release? I'm happy to have two simultaneous release processes  going
>>> at once and think it could even be beneficial. However, it  would be
>>> helpful if you put your proposal in context so others  such as myself
>>> can understand it a bit better.
>>>
>>> Jim
>>>
>>>
>>> On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote:
>>>
 Now that we have a list of requirements on our Wiki at http://
 cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what
 +folks+are+working+on, and a number of people are signing up for
 some of the corresponding work, I'd like to start a discussion on
 the content of our next milestone. Give

Re: Move Tuscany wiki to Apache CWIKI?

[Venkata Krishnan]

Hi,

I guess the website and the wiki are both needed and am very much in line
with Dan's thoughts on what should go into each of this.

I guess its now a question of whether we want to move our content out of
that old wike over CWIKI.  I'd say we must go with CWIKI which is a lot more
pleasant to look and feel.

Thanks

- Venkat


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


Dan Murphy wrote:
> Similar to Haleh's opinion... a hybrid of web and wiki seems to make
> sense
> -  use the web site for fairly static content but link from the website
> directly to appropriate places in the wiki where the content is likely
to
> change or hasn't fully been decided yet.
>
> For example, we could remove the "how to build, test and deploy Java
SCA"
> off of the web site and instead link from the web page to a wiki page.
> (IMHO) it becomes easier to maintain...  perhaps if/when it settles
> down (or
> @ V1) we could merge it back into the web site. I'd be happy to help
> maintain this because I can edit the wiki - for me to contribute to
> the web
> site takes much more effort... perhaps this isn't so important to
> others who
> are already committers...
>
> Dan
>
> On 07/02/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>>
>> Rick had asked earlier  "Two concerns come to mind if we make THE
>> website:
>> Is it backed up? can we get past revisions if needed ?  Currently our
>> website is
>> in svn which covers that.
>> The other is we have had past complaints that the site was not "fancy"
>> organized
>> etc, are we confident this wiki can handle this?"
>>
>> Is Confluence backed up regularly?
>>
>> Does it make sense to leave the website skeleton as is and move all
>> documents to confluence WIKI? For example  FAQ, design docs, release
>> information and downloads, etc.
>>
>> It took us a while to get the website look and feel to where it is
right
>> now
>> and this is not the part that needs to be changed that often. We should
>> not
>> move it until we have a good replacement.
>>
>>
>> On 2/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi Kelvin,
>> >
>> > In my perception, we are moving over to the Confluence wiki -
>> > CWIKI.  Infact
>> > some of the recent updates such as things we aspire to do for SCA M3,
>> some
>> > documentation on SCA Deployment and FAQs have already found place
>> there.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> > On 2/6/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>> > >
>> > > As I'm updating a page on our old wiki,  I'm wondering where we are
>> with
>> > > this and whether I should be migrating the content?
>> > >
>> > > Kelvin.
>> > >
>> > > On 24/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > FYI, I have added "edit" permissions to all registered users.
>> > > >
>> > > > Thanks,
>> > > > Raymond
>> > > >
>> > > > - Original Message -
>> > > > From: "ant elder" <[EMAIL PROTECTED]>
>> > > > To: 
>> > > > Sent: Wednesday, January 24, 2007 4:59 AM
>> > > > Subject: Re: Move Tuscany wiki to Apache CWIKI?
>> > > >
>> > > >
>> > > > > On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > 
>> > > > >
>> > > > > 2) I'm not proposing to change the "edit" policy. The
>> > > > >> http://cwiki.apache.org/CWIKI/ page also provides some
>> guidances
>> > for
>> > > > >> cases
>> > > > >> that we use it as a sandbox (open to all registered users) or
>> > > > >> documentation
>> > > > >> site (open to folks with CLA on file).
>> > > > >
>> > > > >
>> > > > > I also think all our content should be open to any registered
>> user.
>> > We
>> > > > > want
>> > > > > everyone to help maintain it and thats going be more likely to
>> > happen
>> > > if
>> > > > > we
>> > > > > make it easy for them. Its harder for users to send in
>> patches for
>> > the
>> > > > > wiki
>> > > > > :)  Can we get update emails sent to the dev list so we all can
>> > > monitor
>> > > > > the
>> > > > > changes?
>> > > > >
>> > > > >   ...ant
>> > > > >
>> > > >
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > >
>> > > >
>> > >
>> >
>>
>
Looks like a number of projects have already moved their web sites to
confluence, including Cayenne, Cxf, Qpid, Directory, Mina, Ode,
ServiceMix, Felix, Yoko, Wicket...

The whole list is there:
http://cwiki.apache.org/confluence/dashboard.action

--
Jean-Sebastien


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

Re: DataBindingInterceptor and PassByValueInterceptor question

[Venkata Krishnan]

Hi Jim,

The PassByValueWirePostProcessor sure needs an update in the sense that it
only looks for allowsPassByReference at the interface level.  It needs to do
this at the operation level as well.

My imagination is to have this information as part of 'Operation' which
presently has things like isNonBlocking, isCallBack and so on.  So something
like 'isAllowsPassByReference'.   If this is right, then is this something
that we must do in the ImplementationProcessor i.e. looking for the
allowsPassByReference annotation and setting this to the Operation instance.

Let me know if I can go ahead and do this.  Thanks.

- Venkat


On 2/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Yes, I agree. And that should be part of the efforts to support the
load/resolve/build for SCDL extensibility elements so that they can be
handled in a pluggable way.

Thanks,
Raymond

- Original Message -
From: "Jim Marino" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 07, 2007 10:37 AM
Subject: Re: DataBindingInterceptor and PassByValueInterceptor question


>
> On Feb 7, 2007, at 10:21 AM, Raymond Feng wrote:
>
>> Hi, Jim.
>>
>> Let me explain the DataBindingInterceptor part.
>>
>> In this case, I pass the CompositeComponent as a metadata in the
>> transformation context so that the transformers can access the
>> extensions (SCAObject.getExtensions) of the CompositeComponent. The
>> extensions contain some information (such as the TypeHelper for the
>> composite) built from SCDL extensibility elements such as  .
>> This is a workaround to support the load/build for  SCDL extensibility
>> elements.
>>
>
> Thanks Raymond for the response...
>
> This seems problematic, particularly since we are passing
> CompositeComponent just to use extensibility elements in an
untyped  way.
> Wouldn't it be better to do this through some type of typed  context (
e.g.
> for extensibility elements, which themselves may need  to be untyped)
for
> the post processor? I generally prefer APIs to be  explicit about what
> they are passing around.
>
> Jim
>
> -
> 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: Fwd: [Specs Related] Component Properties

[Venkata Krishnan]

Sebastien, Thanks.

- Venkat

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


Venkat,

Some answers inline.

Venkata Krishnan wrote:
> Hi,
>
> I just took a look at the latest assembly model specs and find a
> couple of
> things that I don't understand.  Could somebody help me out with
> clarifications.
>
> i) There are two different illustrations for the schema for a property
> element...
>
>many="xs:boolean"? required="xs:boolean"?>*
>default-property-value?
>
>
>many="xs:boolean"? noDefault="xs:boolean"?>*
>default-property-value?
>
>
> i.e. one uses a 'required' attribute and another the 'noDefault'
> attribute.
> The xml schema definitions in the appendix however define only
> 'noDefault'
> and so I understand that 'required' is a typo that needs to be
> removed.  Is
> this right?

Yes, "required" is a typo and should be changed to "noDefault"

>
> ii) When defining a 'property value' what is the need to specify the
type
> for the property.  Isn't it something that is already specified in the
> property definition.  i.e. in the following what is the need for the
> 'type'
> or 'element' attributes
>
> many="xs:boolean"? source="xs:string"? file="xs:anyURI"?>*
>property-value?
> 
>
> Thanks
>
> - Venkat
>

I think that there are a few cases where you need both the type and the
value:
- Define the type of a property inside a  and at the same
time configure the default value.
- Define the type of a property inside a  and at the same
time configure it, this will be the default value for the property in
instances of the composite.
- Configure a property on a , and at the same time define its
type, I think this is what you'll do in top-down scenarios, where you'll
define the component "shape" as you declare and configure it, before
defining its implementation.

--
Jean-Sebastien


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

Re: DataBindingInterceptor and PassByValueInterceptor question

[Venkata Krishnan]

Thanks Raymond.  Yes, I am aware of the fact that this should be picked up
from the Implementation and hence was guessing the ImplementationProcessor
to be the place for picking this up.  Anyways, I guess I can figure that out
:)

- Venkat

On 2/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I guess I need to correct my previous response. The @AllowsPassByReference
should be used to annotate the implementation class/method instead of the
interface. Then the flag should goes to the Java implementation. The
following is quoted from the Java C&I spec:

=
The @AllowsPassByReference annotation is used on implementations of
remotable interfaces to indicate that interactions with the service within
the same address space are allowed to use pass by reference data exchange
semantics. The implementation promises that its by-value semantics will be
maintained even if the parameters and return values are actually passed
by-reference.  This means that the service will not modify any operation
input parameter or return value, even after returning from the operation.
Either a whole class implementing a remotable service or the individual
remotable service method implementation can be annotated using the
@AllowsPassByReference annotation.
==

Thanks,
Raymond

- Original Message -
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, February 08, 2007 8:23 AM
Subject: Re: DataBindingInterceptor and PassByValueInterceptor question


> Hi, Venkat.
>
> I think it's reasonable to add an attribute "allowsPassByReference" to
the
> Operation model. We already have "remotable" in the ServiceContract. The
> java introspection can set the attribute.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, February 08, 2007 4:37 AM
> Subject: Re: DataBindingInterceptor and PassByValueInterceptor question
>
>
>> Hi Jim,
>>
>> The PassByValueWirePostProcessor sure needs an update in the sense that
>> it
>> only looks for allowsPassByReference at the interface level.  It needs
to
>> do
>> this at the operation level as well.
>>
>> My imagination is to have this information as part of 'Operation' which
>> presently has things like isNonBlocking, isCallBack and so on.  So
>> something
>> like 'isAllowsPassByReference'.   If this is right, then is this
>> something
>> that we must do in the ImplementationProcessor i.e. looking for the
>> allowsPassByReference annotation and setting this to the Operation
>> instance.
>>
>> Let me know if I can go ahead and do this.  Thanks.
>>
>> - Venkat
>>
>>
>> On 2/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>
>>> Yes, I agree. And that should be part of the efforts to support the
>>> load/resolve/build for SCDL extensibility elements so that they can be
>>> handled in a pluggable way.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> - Original Message -
>>> From: "Jim Marino" <[EMAIL PROTECTED]>
>>> To: 
>>> Sent: Wednesday, February 07, 2007 10:37 AM
>>> Subject: Re: DataBindingInterceptor and PassByValueInterceptor
question
>>>
>>>
>>> >
>>> > On Feb 7, 2007, at 10:21 AM, Raymond Feng wrote:
>>> >
>>> >> Hi, Jim.
>>> >>
>>> >> Let me explain the DataBindingInterceptor part.
>>> >>
>>> >> In this case, I pass the CompositeComponent as a metadata in the
>>> >> transformation context so that the transformers can access the
>>> >> extensions (SCAObject.getExtensions) of the CompositeComponent. The
>>> >> extensions contain some information (such as the TypeHelper for the
>>> >> composite) built from SCDL extensibility elements such as
>>> >> >> >.
>>> >> This is a workaround to support the load/build for  SCDL
>>> >> extensibility
>>> >> elements.
>>> >>
>>> >
>>> > Thanks Raymond for the response...
>>> >
>>> > This seems problematic, particularly since we are passing
>>> > CompositeComponent just to use extensibility elements in an
>>> untyped  way.
>>> > Wouldn't it be better to do this through some type of typed  context
(
>>> e.g.
>>> > for extensibility elements, which themselves may need  to be
untyped)
>>> for
>>> > the post processor? I generally prefer APIs to be  explicit about
what
>>> > they are passing around.
>>> >
>>> > Jim
>>> >
>>> >
-
>>> > 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: propertyTest failures

[Venkata Krishnan]

Hi,

I am fixing this in the SCA-Java-Int branch now and will move over to do the
same in the Trunk as well very soon.

- Venkat

On 2/13/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Feb 12, 2007, at 6:11 PM, Jim Marino wrote:
> Agreed, however, it is not apparent from that test what is really
> going on or what the intent is.

The propertyTest itest? Agreed.
I'm adding a bunch of stuff to that :-)
--
Jeremy


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

Re: svn commit: r506862 - /incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0/src/main/java/org/osoa/sca/annotations/Property.java

[Venkata Krishnan]

Hi Raymond,

Thanks for pointing this out.  Will take care of this.

- Venkat

On 2/13/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

It seems that the property has a different attribute name in the assembly
model than the java C&I spec.

Assembly: noDefault="true"
Java C&I: @Property(required=true)

Thanks,
Raymond

- Original Message -
From: <[EMAIL PROTECTED]>
To: 
Sent: Monday, February 12, 2007 9:20 PM
Subject: svn commit: r506862 -
/incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0
/src/main/java/org/osoa/sca/annotations/Property.java


> Author: svkrish
> Date: Mon Feb 12 21:20:46 2007
> New Revision: 506862
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=506862
> Log:
> Removed 'override' and included 'noDefault' for Property
>
> Modified:
>
> incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0
/src/main/java/org/osoa/sca/annotations/Property.java
>
> Modified:
> incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0
/src/main/java/org/osoa/sca/annotations/Property.java
> URL:
>
http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0/src/main/java/org/osoa/sca/annotations/Property.java?view=diff&rev=506862&r1=506861&r2=506862
>
==
> ---
> incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0
/src/main/java/org/osoa/sca/annotations/Property.java
> (original)
> +++
> incubator/tuscany/branches/sca-java-integration/spec/sca-api-r1.0
/src/main/java/org/osoa/sca/annotations/Property.java
> Mon Feb 12 21:20:46 2007
> @@ -41,9 +41,9 @@
> public String name() default "";
>
> /**
> - * Indicates if a value must be specified.
> + * Indicates if property can have a default value
>  */
> -public String override() default "may";
> +public String noDefault() default "false";
>
> /**
>  * The XML Type in a QName format
>
>
>
> -
> 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]

[Specs Related] Multivalued Properties

[Venkata Krishnan]

Hi,

I have just looked at 'many valued properties' in the recent Assembly Model
specs and have some questions.  Could somebody please help me with
clarifications.

There are two samples on multivalued properties.  One where the property is
of simple type ..

  
   
   EURO
   Yen
   USDollar
   
   
   


and another where the property is of complex type...


 
AValue
InterestingURI
 
 
BValue
BoringURI
 


Now, don't these two representations look different.  In the Simple-type
property every value is enclosed in a  tag and in the complex type
case all values are enclosed withing a single  tag.  I'd prefer
that even for the complex type property every value is enclosed in its own
 tag... i.e.


 
AValue
InterestingURI
 


 
BValue
BoringURI
 


I wish this, so that when we are loading them we may have a uniform way of
interpretting them immaterial of whether the property is of simple type or
complex type.

Am I missing a better rationale out here ?

Thanks

- Venkat

Re: [Specs Related] Multivalued Properties

[Venkata Krishnan]

Hi ,

To support multivalued properties I intend to change the 'defaultValue'
field of Property and 'value' field of PropertyValue from the type
'Document' to the type 'List'.   When a property is qualified as
'many=false' this list must be constrained to contain only one value and
when many='true' the list can contain more than one value.

Among other things that need a change to support multivalued properties I
see that the PropertyObjectFactory is one.  I see that the 'getInstance'
must be changed to support a list of intances instead of just one.

I did look at the ArrayMultiplicityObjectFactory and
ListMultiplicityObjectFactory for some hints, but wonder if that approach is
applicable here too.  Though a property may have multiple values, my
understanding is that each of these values will conform to the same type and
hence might require just one factory instance to create them all.  So my
suggestion is that these factories return a list of instances.  In the
single valued case this list just contains one value while in other cases it
contains multiple instances.

Thoughts / Suggestions ?

Thanks.

- Venkat



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


Hi,

I have just looked at 'many valued properties' in the recent Assembly
Model specs and have some questions.  Could somebody please help me with
clarifications.

There are two samples on multivalued properties.  One where the property
is of simple type ..

   

EURO
Yen
USDollar





and another where the property is of complex type...


  
 AValue
 InterestingURI
  
  
 BValue
 BoringURI
  


Now, don't these two representations look different.  In the Simple-type
property every value is enclosed in a  tag and in the complex type
case all values are enclosed withing a single  tag.  I'd prefer
that even for the complex type property every value is enclosed in its own
 tag... i.e.


  
 AValue
 InterestingURI
  


  
 BValue
 BoringURI
  


I wish this, so that when we are loading them we may have a uniform way of
interpretting them immaterial of whether the property is of simple type or
complex type.

Am I missing a better rationale out here ?

Thanks

- Venkat

Re: [RTC] Release prep: project wide parent pom and buildtools

[Venkata Krishnan]

+1 and thanks Jeremy.

- Venkat

On 2/20/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


In prep for release, I plan to update the project-wide parent pom to
reflect project-wide settings. Attached is the delta I plan to make
compared to M2 but in brief the changes are:

* change the version to 2-incubating
* remove the semi-official repo on the WS zone (if still needed the
axis module can define this)
* add in the official incubator repo for plugins and artifacts
* remove the global SCM definition as each release bundle should
define its own
* added some informational comments

Given the project-wide impact I'd like review before committing,
especially from the SDO and DAS modules.
Naturally, here's my +1

Thanks
--
Jeremy


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

Re: [Specs Related] Multivalued Properties

[Venkata Krishnan]

Hi Jim,

Thanks for responding.

My concern is that there is no need to create a factory for each of the
multiple values since each of those values are of the same type.  Hence a
single factory instance is good enough to create as list of those values
instead of a list of factories creating each value.

Working further, I am faced with having to have two types of factories - one
for creating a single value instance and another for creating a list.  The
reason for this being that the injectors simply pull out the value factory
from a Property value and invoke the getInstance().  So when setting the
value factory to a PropertyValue instance we have to choose between one of
these two based on whether the property supports 'many' values or not.

- Venkat





On 2/21/07, Jim Marino <[EMAIL PROTECTED]> wrote:



On Feb 19, 2007, at 11:33 PM, Venkata Krishnan wrote:

> Hi ,
>
> To support multivalued properties I intend to change the
> 'defaultValue'
> field of Property and 'value' field of PropertyValue from the type
> 'Document' to the type 'List'.   When a property is
> qualified as
> 'many=false' this list must be constrained to contain only one
> value and
> when many='true' the list can contain more than one value.
>
> Among other things that need a change to support multivalued
> properties I
> see that the PropertyObjectFactory is one.  I see that the
> 'getInstance'
> must be changed to support a list of intances instead of just one.
>
> I did look at the ArrayMultiplicityObjectFactory and
> ListMultiplicityObjectFactory for some hints, but wonder if that
> approach is
> applicable here too.  Though a property may have multiple values, my
> understanding is that each of these values will conform to the same
> type and
> hence might require just one factory instance to create them all.
> So my
> suggestion is that these factories return a list of instances.  In the
> single valued case this list just contains one value while in other
> cases it
> contains multiple instances.
>
> Thoughts / Suggestions ?
>
Like you mentioned above, why couldn't this be done similar to
ArrayMultiplicityObjectFactory? I don't think the builder should have
any special knowledge about multivalued properties.

Jim


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

Re: @Property attributes

[Venkata Krishnan]

Hi Jeremy,

I'll take care of this, when I sync up the trunk for complex and multivalued
properties later down this week.

Thanks

- Venkat

On 2/26/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Feb 26, 2007, at 9:12 AM, Raymond Feng wrote:

> The xml type for a property can be from the introspection of the
> java class or @DataType annotation if the java class doesn't
> provide such metadata.
>
> +1 to remove the xmlType attribute from @Property. We need to fix
> the property handling pieces accordingly.

I removed the attribute and updated core to just use the
SimpleTypePropertyMapper.

I'm guessing that this may have an impact on complex property
support. Raymond, Venkat is this something you can look at or should
I dig into it?

--
Jeremy


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

Re: Changing SCDL in samples and integration tests

[Venkata Krishnan]

Hi,

Thanks.  I like this sort of naming and really helps in identifying scdls
better.

- Venkat

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


[snip]
Dan Murphy wrote:
> Hi Sebastien,
>
> On the move SCDL files... where were you planning to move them to
> (META-INF/scdl, or up futher into the main/resources part of the
> source tree
> ?)
> Just asking so I can keep in sync with you and do the same for my
> intended
> databinding tests (incidently I also adoped the
> composite-name.composite for
> default binding and composite-name.composite.ws for the same composite
> with
> a web service binding... does this still make sense, or are you also
> changing the iTest framework so I could no longer use this approach ?)
>
> Cheers,
> Dan
>

src/main/resources/.composite

The runtime should be able to work with any file name, but I recommend
to use a single .composite extension to avoid confusion and allow people
who are using IDEs to associate .composite files with the correct XML
editor and validate them with the SCDL XML schema.

I also recommend to use different composite names for different
composites, to avoid collisions later when you include these composites
in an SCA domain.

Finally, I am not making changes to the iTest framework/plugin. I am not
using it as I've not found it useful for what I had to do.

--
Jean-Sebastien


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

Re: Cleaning up and reorganizing samples

[Venkata Krishnan]

Hi,

Its really good if we can have sampleapps out - to have another bigbank in
it is quite confusing, for me.  With respect to the naming conventions, yes,
it would be good to have them all uniform, and I prefer something as
loanAppConversation_ws as against loanappconversationws which is quite
painful to make out without peering thro - this is just my opinion.  Thanks.

- Venkat

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


I took a look at the samples in the integration branch and would like to
do some cleanup and a little reorganization.

- Move the Web Service samples still under samples to
sca/extensions/axis2/samples.
- Rename samples/bigbank (this is a scaled down version of bigbank) to
simplebigbank.
- Move sampleapps/bigbank to samples and delete sampleapps.
- Cleanup the names of the samples, we have calculator-ws, helloworldws,
loanappconversationWS, echo.binding, maybe we need to make up our minds
and pick a single consistent naming convention :) I'd like to propose
calculatorws, helloworldws, loanappconversationws, echobinding (no dash
no dot, all lowercase), or use dashes in the names if people prefer that.

Thoughts?

--
Jean-Sebastien


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

Re: [SCA Databinding] - Discussion on pass-by-value parameters and return values

[Venkata Krishnan]

Hi,

Yes, we did agree on this.  I don't think this check is in place in the
WirePostProcessor.  Will take a look and fix that.

Also, in general, I think we intended to skip this copying if there has been
a data transformation performed ahead, in the wire.  So, is it safe to
simply check if the source and target have different databindings and if
they do, then simply skip this copying. ?

Thanks

- Venkat


On 3/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I think we have agreed on this optimization strategy in previous
discussions
on this ML. Venkat, do you know if we have implemented it (to skip
pass-by-value copy if the one end of the wire is a service or reference
with
remote binding)?

Thanks,
Raymond

- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, March 06, 2007 8:45 AM
Subject: Re: [SCA Databinding] - Discussion on pass-by-value parameters
and
return values


> Fuhwei Lwo wrote:
>> Based on the SCA spec, there are two semantics for parameters and
return
>> values - pass-by-reference and pass-by-value. In the case of
>> pass-by-value with Web Service binding, after demarshalling, the data
>> object was newly created from the soap message (the original value) so
>> Tuscany should have no need to make another new copy of the data object
>> because this will have huge impact on performance.
>>
>> Just want to make sure I am on the right track. Thanks.
>>
>> Fuhwei Lwo
>>
>>
> Fuhwei,
>
> That makes sense to me. We need to avoid multiple transformations and
> unnecessary copies from XML to the form expected by the target component
> implementation. If the target component implementation expects an SDO
> DataObject, the DataObject should be created directly from the XML
stream
> out of the SOAP body.
>
> --
> 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: [VOTE] Release 1.0-incubating version of sca-api-r1.0

[Venkata Krishnan]

+1

- Venkat

On 3/4/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Please vote to approve the release of the sca-api's for r1.0 of the
specification. This is the API code that we recently reviewed but
please vote again to confirm the release.

[tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/
spec/sca-api-r1.0/1.0-incubating

[src] http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
incubating/sca-api-r1.0-1.0-incubating-src.tgz
   http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
incubating/sca-api-r1.0-1.0-incubating-src.zip
[rat] http://people.apache.org/~jboynes/sca-api-r1.0-1.0-
incubating/sca-api-r1.0-1.0-incubating.rat

[pom] http://people.apache.org/repo/m2-incubating-repository/org/
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.pom
[binary]  http://people.apache.org/repo/m2-incubating-repository/org/
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating.jar
[javadoc] http://people.apache.org/repo/m2-incubating-repository/org/
osoa/sca-api-r1.0/1.0-incubating/sca-api-r1.0-1.0-incubating-javadoc.jar

Thanks
--
Jeremy


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

Re: [SCA Databinding] - Discussion on pass-by-value parameters and return values

[Venkata Krishnan]

Hi,

I intend to fix this by skipping copying if one end of the wire is either an
instance of ServiceBinding or an instance of ReferenceBinding as we had
agreed that where binding exists, the binding implementation will ensure
passbyvalue semantics.

With respect to skipping copy when both ends of a wire are Components and
there is data transformation that is going to happen on the wire I wonder if
it is valid to assume that any transformed data will not contain any
reference to the original data - and is as good as a copy.

Thoughts ?

Thanks.

- Venkat

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


Hi,

Yes, we did agree on this.  I don't think this check is in place in the
WirePostProcessor.  Will take a look and fix that.

Also, in general, I think we intended to skip this copying if there has
been a data transformation performed ahead, in the wire.  So, is it safe to
simply check if the source and target have different databindings and if
they do, then simply skip this copying. ?

Thanks

- Venkat


On 3/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I think we have agreed on this optimization strategy in previous
> discussions
> on this ML. Venkat, do you know if we have implemented it (to skip
> pass-by-value copy if the one end of the wire is a service or reference
> with
> remote binding)?
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> To: < tuscany-dev@ws.apache.org>
> Sent: Tuesday, March 06, 2007 8:45 AM
> Subject: Re: [SCA Databinding] - Discussion on pass-by-value parameters
> and
> return values
>
>
> > Fuhwei Lwo wrote:
> >> Based on the SCA spec, there are two semantics for parameters and
> return
> >> values - pass-by-reference and pass-by-value. In the case of
> >> pass-by-value with Web Service binding, after demarshalling, the data
> >> object was newly created from the soap message (the original value)
> so
> >> Tuscany should have no need to make another new copy of the data
> object
> >> because this will have huge impact on performance.
> >>
> >> Just want to make sure I am on the right track. Thanks.
> >>
> >> Fuhwei Lwo
> >>
> >>
> > Fuhwei,
> >
> > That makes sense to me. We need to avoid multiple transformations and
> > unnecessary copies from XML to the form expected by the target
> component
> > implementation. If the target component implementation expects an SDO
> > DataObject, the DataObject should be created directly from the XML
> stream
> > out of the SOAP body.
> >
> > --
> > 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: [sca-java-integration-branch] Removing sca-api-r0.95 module

[Venkata Krishnan]

+1  Yes, I too felt that's just about lying there.  Thanks for doing this.

- Venkat

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


The sca-api-r0.95 module does not seem to be used anymore. If there is
no objection I'll remove it from the integration branch tomorrow morning.

--
Jean-Sebastien


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

[Specs Related] Queries on References

[Venkata Krishnan]

Hi,

I am trying to bring the SPI model and the Loaders in sync with the current
level of the specs as available on OSOA site.  I am currently looking at
'references' - as and how they are defined in ComponentType,
ComponentDefinition and Composite and have the following questions:  -

With respect to references defined in ComponentDefitions and the 'target'
attribute therein
- the specs says that whatever is mentioned in the target overrides that
which is mentioned in the implementation.  Now, my understanding is that a
target is used to wire a reference to another Component's service.  Given
this, I thought defining a target makes sense only within a composite.  So
what does it mean by an implementation specifying a target for a reference?

- next, the 'target' attribute for a reference in a component definition is
'optional'.  Assuming there are no targets defined in the implementation and
no targets are defined in the component definition that uses this
implementation (as this is only optional), then what happens to these
references.  Is this something that should not be permitted unless
autowire=true for the reference defn.

Could somebody familiar with the specs kindly help me with understand?
Thanks.

- Venkat

Re: [Specs Related] Queries on References

[Venkata Krishnan]

Hi Sebastien,

I agree with your suggestions on two accounts...

- its really good to have the model defined around interfaces as it gives
the flexibility to improve / modify the implementations we choose over a
period of time without the impacting the core which I assume will use only
these interfaces.  If we use factories to instantiate model objects (i.e.
specific implementations of these interfaces) that will keep the core futher
away from impacts of changes to implementation of the SPI model.  We could
probably configure the factory class to be used as part of the scdl - for
example as the property of a Loader(s).  Hope I am making sense?

- Specific to the case of references, I did imagine that we may have to
clearly abstract out references at componentType level, component level and
composite level as there is something specific in 'references' to each level
- for example the 'promote' is something that is specific to the composite
level.

I have started to make some changes in the SPI model of the kernel.  But
then, it is not going to be difficult for me to migrate this to your
proposed design in the 'assembly'.  So I shall continue for now in the
kernel unless you see some issues.

Thanks.

- Venkat

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


[snip]
Jean-Sebastien Delfino wrote:
> comments inline
>
> Venkata Krishnan wrote:
>> Hi,
>>
>> I am trying to bring the SPI model and the Loaders in sync with the
>> current
>> level of the specs as available on OSOA site.  I am currently looking
at
>> 'references' - as and how they are defined in ComponentType,
>> ComponentDefinition and Composite and have the following questions:  -
>>
>> With respect to references defined in ComponentDefitions and the
>> 'target'
>> attribute therein
>> - the specs says that whatever is mentioned in the target overrides
that
>> which is mentioned in the implementation.  Now, my understanding is
>> that a
>> target is used to wire a reference to another Component's service.
>> Given
>> this, I thought defining a target makes sense only within a
>> composite.  So
>> what does it mean by an implementation specifying a target for a
>> reference?
>>
>
> The idea is to allow a component implementation developed with a
> particular composition in mind to specify a target right in the
> implementation. This makes the SCA programming model more compact as
> you may not even have to write SCDL then. SCA for PHP for example
> leverages this capability, here's a sample from
> http://us2.php.net/manual/en/ref.SCA.php:
>/**
> * The currency exchange rate service to use.
> *
> * @reference
> * @binding.php ../ExchangeRate/ExchangeRate.php
> */
>   public $exchange_rate;
> ?>
>
> The componentType/reference/target attribute allows you to express the
> same thing in a .componentType SCDL file.
>
> Then later if you want to reuse your component implementation in other
> compositions you can rewire the reference using a
> component/reference/target attribute in the particular component
> declaration, without changing your implementation.
>
> More generally, I've started to look more closely at the model spi as
> well as I'm trying to see how to reuse it as an individual module, and
> I'm not sure that the current ReferenceDefinition and ReferenceTarget
> classes correctly represent references as defined in the SCA assembly
> spec.
>
> The assembly spec defines the following:
> - abstract reference definitions in constraining types
> - reference definitions in component types
> - component references
> - composite references
>
> I'll try to come up with some ideas for an accurate representation of
> references at these 4 levels.

Venkat,

I've checked in a few interfaces representing the 4 kinds of References
above at

http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly/src/main/java/org/apache/tuscany/assembly/model/
(plus a few base interfaces to represent SCA interfaces, multiplicity,
basically what I found in the SCA assembly spec for references).

I think that we're going to need interfaces for the model SPI to achieve
good modularization of the Kernel, so I thought I'd try to have these
few interfaces actually in sync with the SCA 1.0 assembly spec.

It's probably premature to try to use this assembly module as I just got
it barely building today and it's not used by the rest of the runtime,
but I hope that the few interfaces can help give some ideas or at least
help initiate a discussion on how best to represent SCA assembly
references.

Let me know what you think.

--
Jean-Sebastien


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

Re: Assembly metadata, was: Queries on References

[Venkata Krishnan]

Hi,

I also see that all our loaders use string literals to load attributes from
the SCDL for e.g. the name of a component or property and so on.  I am
wondering if it would be good to define these as constants somewhere - for
example attributes related to Property element could be defined in the
Property class / interface of the SPI model or maybe have just one class
that defines all of these model attribute names as constant strings.

Thanks

- Venkat

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


Raymond Feng wrote:
> Hi,
>
> I added the namespace support for the SAX handler and a minor fix to
> call setXSDType against Property.
>
> Thanks,
> Raymond
>

Thanks, with your change I was able to put QNames in the test .composite
and .constrainingType files and get them loaded correctly. I'll do some
more tests with property elements and types tomorrow.

--
Jean-Sebastien


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

Re: Assembly metadata, was: Queries on References

[Venkata Krishnan]

Hi,

I am continuing to work on the branch to bring the spi model to level with
the current specs.  One of the key things that I observed is the ability to
override various aspects of properties, services and references starting
from the ComponentType for an implementation and moving up to
ComponentDefinition and then to the Composite.

Looking specifically into references, I understand that targets, interfaces
and bindings are among a few other things that can be defined at the
ComponentType, then overriden if need in the ComponentDefintion (that uses
this component type) and then futher overriden when they are promoted to the
Composite.

Looking into the SPI model to do this, I feel its best to have separate
abstractions instead of one ReferenceDefinition i.e. have
ComponentTypeRefDefn, ComponentRefDefn and CompositeRefDefn all of which
extends an AbstractRefDefn that encapsulates the commonality in all of
this.. such as name, multiplicity, targets, bindings and so on. Though there
is vast commonality amongst references at these three levels (componenttype,
component, composite) there is also something that is specific to each.  For
example the 'autorwire' applies only to references in ComponentDefinitions,
the 'promote' applies only to 'CompositeReferences'.  Thoughts ?

Another thing here is about each of these having their own instances of the
configurable aspects even if they are not overriding.  For example even if
the 'bindings' in ComponentTypeReference are not overriden in the
ComponentDefnition that uses this componentType, I still copy over all of
the 'bindings' in the ComponentTypeReference over to the
ComponentDefnReference.  I just felt comfortable doing this so that I may
avoid one level of indirection when the builder is working around with a
ComponentDefn.  An alternative would be that wherever the ComponentDefnRef
has no overrides, it delegates calls to the underlying ComponentType.  For
example if the ComponentDefRef does not override bindings and if a builder
is looking up its binding, then this lookup call will be delegate to the
underlying ComponentType.  Opinions ?

Since these changes affect the core, far and wide I am about taking sometime
to ensure that I don't break consistencies.

Thanks

- Venkat

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


[snip]
Venkata Krishnan wrote:
> Hi,
>
> I also see that all our loaders use string literals to load attributes
> from
> the SCDL for e.g. the name of a component or property and so on.  I am
> wondering if it would be good to define these as constants somewhere -
> for
> example attributes related to Property element could be defined in the
> Property class / interface of the SPI model or maybe have just one class
> that defines all of these model attribute names as constant strings.
>
> Thanks
>

Yes good idea, I'd suggest one class for the core assembly model, one
class for the policy model, and one for the contribution stuff, roughly
mapping each class to an XSD file in the spec XSDs.

--
Jean-Sebastien


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

Re: Working in trunk, was: Componentizing our SCA runtime kernel

[Venkata Krishnan]

Hi,

My view is that, if the design that Sebastien is proposing is a step forward
in our modularization goals then its good to get it into the trunk.  I like
the design and here is my +1 to move this into the trunk.  IMO, moving to
the trunk  does not mean the kernel will have to be immediately integrated
with this.  I suppose we can take this incrementally evaluating and changing
things (wherever required) as we go along. Since this is going to come in as
a new module, it would only help in the incremental phase over.

Thanks

- Venkat

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


I agree putting it the trunk makes sense for all the reasons already
mentioned.

The trunk is where main development should take place unless there are a
good reasons not to. Code going into trunk does not have to be finished
and
perfect but should be worked on in the trunk to incrementally improve. No
one is going to intentionally set out to make things unstable but during
active development there are going to be times when not everything works
perfectly - just look at the state of the trunk right now. When
requirements
come up that need more guaranteed stability then they can use a branch so
active development can continue in the trunk. This is what we've done in
the
past, eg. for all the releases and with the integration branch.

The proposal is to add a new module for this code in java/sca/assembly so
its not going to make anything unstable, and that allows other modules to
easily start using it as the need arises. I can't see any reasons for this
not to go in trunk.

   ...ant

On 3/20/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> I think it's a good idea to move this code out of the integration
> branch.  I prefer to keep the integration branch for its original
> purpose of providing a stable environment for developing and testing
> end to end scennarios.
>
> I agree that it's important not to destabilize trunk by adding this
> code.  This could be achieved by separating it from the rest of trunk
> by putting it in a separate module that is not part of the main
> build profile.
>
> If there is potential to use this code in other parts of the trunk
> code (Sebastien suggested a few possibilities), then this would be a
> good reason to put it in trunk rather than a sandbox.  I'm not clear
> on whether this usage is something that might happen soon or is a little
> further out.  If this expected usage is a near-term thing, then I think
> it makes sense to put the code in trunk.  If there isn't any immediate
> need to use it elsewhere, then it could go into a sandbox for now.
>
>Simon
>
> Jim Marino wrote:
> >
> > On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
> >
> >> Jean-Sebastien Delfino wrote:
> >>
> >>> I'd like to start a discussion on how we could componentize our  SCA
> >>> runtime kernel. I posted two diagrams on our Wiki at http://
> >>> cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
> >>> +runtime to help start the discussion.
> >>>
> >>> One of the ideas is to allow for different integration strategies
> >>> with app servers and other runtime environments. Some integrations
> >>> may reuse the Tuscany kernel as a whole, but others will want to
> >>> reuse only a subset or replace parts with specific implementations.
> >>>
> >>> A few examples come to mind:
> >>> - swap our POJO IOC container with another one already there in  the
> >>> target app server;
> >>> - strip out the local assembly support when building a WSDL remote-
> >>> interface based (an SCA/BPEL container for example);
> >>> - strip out the federated deployment / discovery / distributed
> >>> wiring support when building a simple standalone runtime, or
if  your
> >>> app server already supports that and you'd like to integrate  with
it;
> >>> - replace the SCDL loaders if you're storing the assembly metadata
> >>> in a database instead of SCDL files;
> >>> - use a different handler/interceptor mechanism already in use in
> >>> your app server or a more dynamic invocation mechanism to support
> >>> scripting languages for example.
> >>>
> >>> Another scenario I have in mind is to reuse parts of the Tuscany
> >>> kernel in validation tasks, codegen utilities, deployment and
> >>> management tools. For example I'd like to have an Ant task that
> >>> automates the generation of SDO or JAXB objects for an entire SCA
> >>> contribution. This task will need access to the SCA assembly  model,
> >>> the SCA contribution model, maybe our Interface contract  model as
> >>> well, but I don't want to drag the whole kernel for that.  Similar
> >>> idea for deployment and management tasks.
> >>>
> >>> A refactored/componentized kernel will also make it easier for
> >>> people to contribute to the individual pieces and exchange
> >>> components between our various initiatives.
> >>>
> >>> For example I'd like to pull pieces of the trunk in the  integration
> >>> branch, and it would be much easier if the single  kernel/core

Re: [VOTE] Rewrite kernel model to be based on interfaces

[Venkata Krishnan]

Hi Jeremy,

As part of this discussion and vote could we also summarize the technical
reasons for each of us to be going one way or the other.  Since this is a
major decision point it would be good for everybody to know why we as a
community are taking a specific direction and helps us to get back to these
design decisions in the future whenever in doubt.  I am really keen on
understanding each of our technical perspectives in this regard and not
necessary in the context of weighing opinions for this vote.

Here is my attempt at this...

[X] +1 we should do this
[  ] -1 keep things as they are

My Reasons : (from whatever little I have been thro)
- I see that the interfaces will help us align better with the assembly
model stated in the specs.  What is publicly available out of the model is
just about what is published in the interfaces and that is just about what
the core (or extensions) should be using.  Otherwise we might encapsulate
into the model all that our core implementation would ideally need. Also
basing the model on interfaces us flexibility in that while the model's
implementation undergoes change the core that uses it continues unaffected.


Thats one that I see immd. from whatever I am working currently.

Thanks

- Venkat


On 3/20/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:

> The current model is based on simple POJOs. Sebastien has proposed
> rewriting the configuration model to be based on interfaces with
> separate implementation and factory classes. This will have a major
> impact on the kernel code and all extensions. This vote is not
> about what is in the model, it's is about how the model itself is
> implemented.
>
> [ ] +1 we should do this
> [X] -1 keep things as they are

My opinion.
--
Jeremy


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

Re: How is autowired reference resolved in the composite hierarchy?

[Venkata Krishnan]

Hi,

For this to happen, mustn't reference211 first be promoted to its composite
level i.e. as a reference of Composite2.  For a component reference that is
not wired, I did not find the specs (from whatever I read and understood) as
saying it will be automatically promoted to the composite level.  As far as
autowiring goes I thinks it must look up only within the composite in
question.

My opinion is that, when the CompositeComponentType leaves the
CompositeLoader it must have been validated for all the wiring within it.
If there is a component reference that is not wired then it is either
automatically promoted (which is something that I did not find in the specs
as far as I saw) or an error must be thrown.

Thanks

- Venkat



- if there is a reference in a component that is not wired to any target,


On 3/22/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I'm looking into the extension story with the code base in trunk. As we
know, some of the components in the extensions will have dependencies on
components in the system composite, for example, LoaderRegistry.

By debugging the code, I found that the DefaultAutowireResolver first
searches the siblings in the same composite, if no matching service is
found, then it try to look up the primordial components. Is it the correct
behavior?

Let's take the following hierarchy as example:

composite1
component11 (implemented by composite2)
composite2
component21 (reference211)
component22 (service221)
component12 (service121)

Assuming reference211 is autowired. So if service221 matches the service
contract for reference211, then service221 will be picked as the target.
If
not, do we navigate up in the hierarchy to find service121 if its service
contract matches?

Thanks,
Raymond


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

Re: ServerSide Presentation and Demo

[Venkata Krishnan]

Hi Jim,

Thanks for sharing this information - its really useful.

- Venkat

On 3/22/07, Jim Marino <[EMAIL PROTECTED]> wrote:


Hi,

We just finished the ServerSide demo and I figured I send a mail to
the list outlining how it went...

We had the slot following the opening keynote and were up against Rod
(Spring) and Patrick (OpenJPA) as the other  two talks. I was
surprised to find that the ballroom was pretty full. I gave the talk
and the demo showing end-to-end federated deployment and reaction
seemed very positive.  Meeraj gets the "hero" award for staying up to
an obscene hour in the morning to implement a JMS-based discovery
service as we encountered last-minute hiccups with JXTA.

My observations are:

- After speaking with people after the presentation, feedback on the
value of SCA was consistent. Specifically, they thought the
programming model was nice but not a differentiator. What people got
excited about was being able to dynamically provision services to
remote nodes and have a representation of their service network.  In
this respect, I think the demo worked well. Two people said they need
what the demo showed for projects they currently have underway.

- People asked how SCA is different than Spring.  They reacted
positively when I said "federation" and "distributed wiring". Related
to this, people get dependency injection (i.e. it's old-hat) and just
seem to assume that is the way local components obtain references.

- People seemed to react positively when I compared SCA to Microsoft WCF

- People liked the idea of heterogeneous service networks and support
for components written in different languages, particularly C++.

- People didn't ask about web services. People were nodding their
heads (in agreement) when I talked about having the runtime select
alternative bindings such as AMQP and JMS.

- People want modularity and choice. Two areas they wanted choice in
was databinding and persistence. They liked the fact that we are not
locked into one databinding solution and that we have JPA
integration. (as an aside, they also liked that SDO can be used
without SCA). Spring integration was also popular.

- People also liked the idea of a 2MB kernel download. One person
mentioned they only want to download what they intend to use and not
a lot of extra "clutter".

- People wanted to know how SCA is different than an ESB. I basically
described it using the switch vs. router metaphor and how a component
implementation type can be a proxy for an ESB. Related to this and
point-to-point wires, people thought wire optimization by the
Controller was cool.

- People seemed to be more interested in running Tuscany as a
standalone edge server or embedded in an OSGi container. I didn't get
any questions about running Tuscany in a Servlet container or J2EE
application server. This seems to be consistent with there being a
number of talks on server-side OSGi.

My big takeway is that we need to make the demo a reality.

Jim






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

Deep introspection in JavaInterfaceProcessorRegistryImpl

[Venkata Krishnan]

Hi,

When promoting a component reference to the composite level, the specs says
that if an interface is specified in the composite reference it must be a
superset of what is specified for the component reference that is being
promoted.  To do this I reused the CheckCompatibility method in the
'WireServiceExtension'.

But then this checking is done during the phase when a composite is being
loaded and in this phase it seems like the
JavaInterfaceProcessorRegistryImpl does not do a deep introspection of the
JavaInterface of the component's reference (that is being promoted).  As a
result of this there seems to be no comparison possible.  Any ideas on how I
can get over this ?

Thanks

- Venkat

Re: [VOTE] Adopt a near-zero-tolerance "Be Nice" policy

[Venkata Krishnan]

+1.

Thanks

- Venkat

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


I'd like to have a near-zero-tolerance "Be Nice" policy on the Tuscany
mailing lists where we don't allow participants to slam anyone's posts.
When
replying to email we need to do it in a way that maintains the original
authors dignity.

We've some tough things to work out over the next days and we're only
going
to achieve any real consensus if we all feel the environment allows us to
say what we really think.

I'd really like to see everyone vote on this, surely if nothing else this
is
something we can all agree on?

Here's my +1.

   ...ant

Re: Add a simple embedded runtime for Tuscany dummies

[Venkata Krishnan]

Hi,

I whole-heartedly admit to the comfort of being able to run and debug within
IDE.  Its really very useful to get a grasp of how the runtime works.  For
example, if one were to understand the role of loaders, builders, the wire
service and the invocation pattern, running a sample  test or an iTest from
within an IDE and debugging it gives a real fair idea of all of this.

Raymond thanks and I hope to check this out later during the day.

- Venkat

On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I know we have removed SCATestCase from the trunk, but I always find it
very
useful and convenient for me to run test cases or samples from inside the
IDE directly (by right-clicking on the class and select "Run..." or
"Debug"), especially for debugging and testing purposes.

I put together a simple "embedded runtime" based on the idea of
SCATestCase
so that we can bootstrap Tuscany system and the application code from the
same classpath in case that class isolations are not of interest. It's
built
on top of the current kernel in trunk.

You can find the code at

http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/runtime/embedded/
.
There are two things you can try:
*  calculator.CalculatorClient is a sample with main()
*  org.apache.tuscany.api.SCARuntimeTestCase is a JUNIT test case.

I think it can complement the other runtimes we have in trunk such as
standalone and itest. I would like to check it in under java/runtime if
you
agree with me.

Thanks,
Raymond



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

Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together

[Venkata Krishnan]

+1.  Atleast in the spirit of getting this going for now to enable people to
get on with the r Trunk rightaway as one piece than having to first deal
with its composition.  Thanks.

- Venkat

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


Here's the vote on this I said [1] I'd start to get closure on this issue.

The proposal is to have top-level pom for the Java SCA project that
enables
building all the modules together - kernel, services, runtimes, extensions
etc, and for that to work all those modules need to use the same version
name.

Here's my +1.

   ...ant

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16024.html

Re: [VOTE] Adriano Crestani for Tuscany Committer

[Venkata Krishnan]

+1.  It should be really good to have somebody from a university on board.
Thanks.

- Venkat

On 3/28/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I'd like to nominate Adriano Crestani to become a Tuscany committer.

Adriano started by helping on Java DAS, and recently is contributing a new
DAS C++ Implementation, he has also participated in discussions and is
helping expand the Tuscany community around his college campus in Brazil.
He's contributing to Tuscany for several months now, and I think he is
going
to be a great addition not only for the Tuscany DAS community, but for the
Tuscany community in general.

Here is my +1

--
Luciano Resende
http://people.apache.org/~lresende 

Re: Merge improved databinding code into trunk

[Venkata Krishnan]

Hi Raymond,

Once you have done this, I'd like to get started with syncing up the trunk
for complex and many valued properties since this depends on the databinding
framework to trasform property definitions in SCDLs to JavaObejects.

- Venkat

On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I'll go ahead to commit the last piece which integrates the databinding
framework with the latest core if there are no other concerns.

The new picture will be:

kernel/core: will depend on databinding-framework (the dependency would be
removed as the core is further decomposed)
services/databinding/databinding-framework: Databinding SPIs and built-in
transformers for XML
kernel/databinding: Databinding related WirePostProcessors and Inteceptors

Thanks,
Raymond

- Original Message -
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: 
Sent: Friday, March 16, 2007 10:38 PM
Subject: Merge improved databinding code into trunk


> Hi,
>
> As you might have noticed on the ML, I have improved the databinding
code
> in the sca-java-integration branch over time. I would like to merge the
> changes back to the trunk and bring up the databinding support again in
> the trunk.
>
> Here is the summary of the improvements:
>
> 1. Minimize the usage of @DataType by agressively introspecting the java
> classes
>
> 2. Data transformation for business exceptions
>
> 3. Add copy() support for JAXB and AXIOM
>
> 4. More databindings and transformers such as:
>   * JSON databinding
>   * SDO --> AXIOM using OMDataSource
>   * JavaBean --> XMLStreamReader
>
> 5. More unit and integration test cases for better coverage
>
> To avoid the disruption, I'll stage them as follows:
> 1) Add a "databinding-framework" module under
> "java/sca/services/databinding" to hold the updated code in spi and
core.
> 2) Update individual databindings
> 3) Integrate the databinding pieces with the latest core
>
> Thanks,
> Raymond
>


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

Re: [VOTE] Use single version for all Java/SCA modules and enable building all modules together

[Venkata Krishnan]

Hi Jeremy,

Here is a problem that most of us are facing with the Trunk and is hindering
us to effectively contribute to the trunk.  I see there is one solution that
has been proposed to making this simpler with some compromises.  If this is
not agreeable what is the alternative for those of us who are waiting for a
solution to this.  Whats the simple way for any of us - including somebody
getting in afresh - to quickly jump in and start contributing without having
to worry about the build intricacies.  Should we consider Bert's suggestion?

Theres been may a time when you have helped us out of various technical
difficulties.  Here is yet another time I request for help from you for a
way out of this.

Thanks

- Venkat

On 3/29/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:


Dims,

Sorry, I can't speak on behalf of Jim or Jeremy.

As for me, this is only the second time I have voted -1, the other one
being the one on interfaced based models, which has been withdrawn since
then. On this particular vote, I am ok to go with -0, it was a
misunderstaning on my part on how voting worked. I thought, the rule was
there should be more +1s than -1s and at least three +1s.

As Jim mentioned in one of the previous emails, there is a fundamental
difference that has been evolving between two groups of people, in terms of
what technical direction we should take. There have been laudable efforts
from both sides (especially from the likes of Raymond, Sebastien, Simon, Jim
and Jeremy) to reconcile the differences and move on. However, the plain
fact is that those diffeerences have not been resolved yet and I am not sure
whether they would, given they are quite fundamental.

On your point on projects being thrown out of the incubator, I wouldn't
want that to happen to Tuscany. Lot of people have put in a lot of effort on
this. I am willing to keep the discussions going. At the end of the day, if
I personally can't resolve the technical differences, I would maintain my
dignity and step out of the way and let the community carry on. However,
that would be a last resort for me, I would continue to work with the guys
here and try to reconcile the differences.

On your point on the "Be Nice" vote, I have been thinking hard on the
actual motivation of that vote. I don't think anyone has been disrespectful
to anyone on the list so far. We have had our differences, and we have tried
to discuss them as grown up individuals. Hence, I didn't really understand
the purpose of that vote.

Ta
Meeraj



From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
Sent: Thu 3/29/2007 5:09 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable
building all modules together



Meeraj,

well go over the archives and count how many times you, jim and jeremy
have -1'ed something. The correct vote for "I am happy to go with the
majority view, if that is what the community wants." is -0 *NOT* -1.
When you do a -1 you are supposed to work hard to come up with a
refined proposal that takes in your viewpoint or help come up with a
proposal that evertone can rally around. I see no effort in consensus
building in any of the threads i reviewed after a -1. This is an open
source project, you can have the best goddamn architecture in the
whole wide world. If there is no community to back the work. It will
get thrown out of the incubator. Sorry, that's the way Apache works.
Incubator is not only for legal purposes but also to help build
communities. This is not the way an open source project should work.
Forget about incubator projects, we have closed Top level project
(example Avalon) too because everyone was at cross purposes and no one
was cooperating with any one else. Yes, a few of the people who
started the fracas did say exactly what you said.."I disagree
fundamnetally from a technical perspective". See this email and check
if it is the same situation you all are in.

Finally did the three of you VOTE in the "Be Nice" thread? That just
tells me a lot of things.

thanks,
dims

[1]
http://mail-archives.apache.org/mod_mbox/avalon-dev/200211.mbox/[EMAIL 
PROTECTED]

On 3/28/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
> Dims,
>
> I don't think there is a stream of -1s. This is an issue on which,
unfortunately, I disagree fundamnetally from a technical perspective, with
the percieved majority view. It will be hypocritical of me to +1, if I don't
agree with it.
>
> However, I am happy to go with the majority view, if that is what the
community wants.
>
> Ta
> Meeraj
>
> 
>
> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
> Sent: Wed 3/28/2007 11:24 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [VOTE] Use single version for all Java/SCA modules and
enable building all modules together
>
>
>
> Jim, Meeraj,
>
> If the stream of -1's contnue, am afraid there isn't going to be a
> single release at all.
>
> thx,
> dims
>
> On 3/28/07, Jim M

Re: Using StAX-based loaders for SCDL? was: SCDL4J

[Venkata Krishnan]

Hi,


From what is mentioned here, I'd go with the StAX approach.  Also, Woodstox

seems to be an option for now and would be gone when we move to Java6 which
I suppose we will in the near future.  Is that right?

Thanks

- Venkat

On 4/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


+1.

Thanks,
Raymond

- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, March 31, 2007 9:58 PM
Subject: Using StAX-based loaders for SCDL? was: SCDL4J


> [snip]
> Raymond Feng wrote:
>> Hi,
>>
>> FYI: I checked in the first cut of the StAX-based loaders under
>> scdl4j/stax. The logic is very similar to the SAX handlers.
>>
>> Thanks,
>> Raymond
>>
>
> Thanks Raymond, your new StAX loaders look good to me! actually better
> than the SAX handlers that I had checked in yesterday :)
>
> I made a few minor changes to bring them to the same level of
> functionality as the SAX handlers, and then did a quick comparison
> between the two approaches.
>
> Performance:
> Here are some numbers from the SAXPerfTest and StAXPerfTest programs
> that I committed today, which load the same composite file using both
> techniques.
> - SAX handler using the JDK parser (Xerces): 0.395 msec
> - SAX handler using the Woodstox parser: 0.260 msec
> - StAX reader using the Woodstox parser: 0.258 msec
> Memory usage is slightly lower with StAX/Woodstox.
> So StAX/Woodstox wins by a very small margin, the bigger performance
> gain really comes from using Woodstox instead of the version of Xerces
> that comes with the JDK.
>
> Programming model:
> Both approaches are very similar. I think I slightly prefer Raymond's
> StAX-based approach as it allows state to be kept in local variables
> instead of instance variables shared by multiple event handling methods.
> Also, I thought that our core StAX loaders were a little fragmented
> before and that probably caused some of their complexity, but Raymond's
> new loaders now combines the simplicity of having the parsing logic in a
> single class (similar to the SAX handlers that I had contributed) and
> the convenience of the StAX pull parsing model.
>
> The other advantage of the StAX based approach is that it covers reading
> and writing XML documents (although it's easy to write code that
> produces SAX events to generate a document, as I did in CompositeWriter
> for example).
>
> Dependencies:
> The SAX based approach works with just a JRE and nothing else. StAX
> requires Woodstox (or another StAX implementation) or Java 6.
>
> To summarize, the StAX loaders are slightly faster, slightly simpler to
> write, but require Woodstox (about 500Kb). I'd like to remove the SAX
> handlers that I had contributed in favor of Raymond's new StAX loaders,
> but since one of the goals of this SCDL4J package is to make SCA really
> pervasive and allow projects to consume SCA metadata with minimum
> dependencies, I'd like to make sure that the Woodstox dependency is not
> going to be a problem for people. Other similar packages like WSDL4J or
> Woden for example only require the JRE...
>
> So, what do people think about this dependency on a StAX parser like
> Woodstox?
>
> If there's no objections I'll switch to use Raymond's StAX loaders
> around the end of the day on Monday...
>
> --
> 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]

Resumption of Weekly IRC ?

[Venkata Krishnan]

Hi,

I wonder if we should resume our weekly IRCs to bring in the community a bit
closer and make sure everybody is on the same page with the project.  If
once a week is too frequent then how about fortnightly.

Just in case everybody does agree to this, I'd further suggest that, this
time around we put in an agenda ahead of the IRCs - say atleast a day in
advance so that it gets to be a focussed discussion.

Thanks

- Venkat

Re: SCA source tree and build structure

[Venkata Krishnan]

Hi,

First, thanks for doing this.  I follow what you propose here and makes
sense to me.  So +1.

Just the concern about having the existing folders as well - I suppose we
will clean that up at some point of time once we get this going smooth.

- Venkat.

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


Hi all,

We've discussed the need for a working top-down build in a number of
threads now:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15892.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16085.html

We're also starting to discuss the contents of our next release, so it's
probably about time to do something concrete to fix that build :) Here's
a pretty basic proposal for how to fix it.

First simplify our trunk structure:
java/
  pom/parent/pom.xml

  sca/
pom.xml
modules/
  pom.xml
  assembly
  binding-axis2
  contribution
  core
  databinding
  discovery-jms
  federation
  http-jetty
  idl-java
  impl-java
  ...
  The "next release" discussion will help us determine the list of
modules.

samples/
  build.xml <-- I'd like to build the samples with Ant as well as
Maven
  pom.xml
  calculator
  supplychain
  bigbank
  helloworld
  ...
  Here also, the release discussion will help determine the list.

itest
  pom.xml
  bindings
  exceptions
  spec
  ...
  Here I suggest to copy the tests from the integration branch.

Maven technicalities:
- sca/pom.xml's parent will be pom/parent/pom.xml
- Other poms will use the pom from the parent folder as parent pom
- Group ids: org.apache.tuscany.sca, org.apache.tuscany.sca.samples,
org.apache.tuscan.sca.itest
- Version of our modules will be specified once in java/sca/pom.xml,
child poms don't need specify a version as they get it from their parent

Naming conventions:
- Use all lowercases and dashes in folder names (like in the jar names)
- Maven artifact id = tuscany-

Building the tree:
Simple... cd java/sca, then mvn. It should work even if you start with
an empty Maven local repository, and it should always work :) Build
breaks should be avoided or get fixed quickly, it's the least we can do
to be nice to our community of developers and users to avoid breaking
them all the time.

Handling modules not part of the next release:
If people want to work on some new modules that won't be part of the
next release and not included in the top-down build, that's fine, we can
just avoid listing these modules in java/sca/modules/pom.xml. So, they
can be there in the same source tree but they won't break the release
top-down build, and they won't have to be building at all times.

So, to make this proposal concrete, I'm planning to put my build guy hat
on and start putting that build structure together on Tuesday. I won't
break any of the existing modules as the new folder names won't conflict
with the existing folders. Also I'll copy the modules to the new folders
instead of moving them.

I would like to have this structure running for a few days, get people's
input, feedback or help to make it work :) and adjust it step by step to
what people in our community want. If it works well, then great, we'll
have a working build again and a happy community :) If people want to
try something else, we can try it too. Finally, we can revisit the tree
structure, the build etc. after the next release as well.

Thoughts?

--
Jean-Sebastien


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

Re: SCA source tree and build structure

[Venkata Krishnan]

Hi,

Yes, what Luciano is suggesting here makes sense to me as well.

Thanks

- Venkat

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


Sebastien wrote:
> I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
>probably better. I'll start with alpha1 then.

Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1
when
we branch/tag for release, together with the removal of SNAPSHOT ? This
would make trunk always with same version id, right ?

On 4/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Raymond Feng wrote:
> > Forgot to ask one question:
> >
> > We have inconsistent version ids for artifacts in the trunk, do you
> > plan to reconcile them? If so, what should the version id look like? I
> > propose that we use something like 1.0-incubating-alpha1-SNAPSHOT to
> > reflect the fact that we're working toward a 1.0 release.
> >
> > Thanks,
> > Raymond
> >
>
> Yes I plan to reconcile them, like this:
>
> >
> >> - Version of our modules will be specified once in java/sca/pom.xml,
> >> child poms don't need specify a version as they get it from their
> parent
> >>
>
> I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
> probably better. I'll start with alpha1 then.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Luciano Resende
http://people.apache.org/~lresende

Re: Build update, was: SCA source tree and build structure

[Venkata Krishnan]

Yes and I very faintly remember this to be the reason why we moved the specs
out to where it is now. Isn't it ?

- Venkat

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


I was under the impression that the spec-sca-api-r1.0 module would be a
stable one unless the spec changes. Isn't right that, under spec/ we can
have multiple sca releases based on the same spec-sca-api-r1.0, but moving
it to /modules we will be forced to have a spec api release every time we
release sca ?

On 4/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> For SCA, I suggest that we further move it to "modules/spec-sca-api-r1.0
".
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, April 05, 2007 8:36 AM
> Subject: Re: Build update, was: SCA source tree and build structure
>
>
> > Bert Lamb wrote:
> >> Just to note, in order for this build to work from a fresh empty
maven
> >> local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0
/
> >> directory first.
> >>
> >> -Bert
> >>
> >
> > Good point. I had forgotten to commit my change to java/sca/pom.xml to
> > include the spec-api in the top-down build. It's now fixed in revision
> > r525846.
> >
> > Also, I'm not sure it's obvious to everybody that the SCA API is
hiding
> > under java/spec instead of being under the java/sca folder. Similar
> > comment for the SDO API.
> >
> > How about moving java/spec/sca-api-r1.0 to java/sca and
> > java/spec/sdo-api to java/sdo as well?
> >
> > 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]
>
>


--
Luciano Resende
http://people.apache.org/~lresende

Re: Cleaning up module names

[Venkata Krishnan]

+1 for more complete names.

Thanks

- Venkat

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


I would like to adopt more consistent naming conventions to name the
modules under java/sca/modules. Most of our modules use complete names
(binding-*, databinding-*, contribution-*), but a few still use
abbreviations, I'd like to rename them to use clearer, complete names
and have a consistent naming scheme.

idl
idl-java
idl-java-xml
idl-wsdl
idl-wsdl-xml
impl-java
impl-java-xml

will become:
interface
interface-java
interface-java-xml
interface-wsdl
interface-wsdl-xml
implementation-java
implementation-java-xml

If there's no objection I'll make this change sometime tomorrow.

--
Jean-Sebastien


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

Re: Contribution services and SCDL4J

[Venkata Krishnan]

Hi,

I am catching up with all the work that is going on in 'modules' and am
trying my best join the party.  Here are some questions that have come up my
mond... please help me with answers.

- I see that the 'resolve' method in ArtifactProcessor has an argument
'resolver'.   Where is this resolver going to be passed from ?  I see in the
testcases that this resolver is created and then passed, but don't quite get
the bigger picture as to how a chain of resolvers would be instantiated and
passed around.  For example when the CompositeProcessor's resolve method  is
called what is the resolver that would be used.
- To start putting my hands as well into this, I was looking for a humble
start with respect to property loading.  For example if I were to verify
where a component property defined is actually existing in the underlying
componentType where and when would I do this.  I suppose it would be in the
'resolve' phase  right ?  If so which processor should do this?  I was
looking at the CompositeProcessor.resolve for a place to do this but then
ended up with the question in the first bullet.  (hope this is not already
done and I have missed it)
- The 'Reference' interface in assembly has accessor methods for
'autowire'.  I wonder if this should move up to ComponentReference as I did
not see the relvence of 'autowire' in componentType references and composite
references.  Am I missing a point ?

Thanks

- Venkat

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


Luciano Resende wrote:
> I have also made some progress on this: I have simplified the
> packageProcessors interfaces, making it responsible only for providing a
> list of artifacts that need to be processed, and processing now
> should/will
> be driven by the contributionServiceImpl.
>
> I have also started to integrate the artifactProcessors and it's
> phases into
> the contributionServiceImpl, but had a question about whether or not the
> contribution-impl should have dependencies on assembly-impl-xml in
> order to
> be able to perform some unit tests using the artifactProcessors defined
> there. Thoughts ?
>
>

It may be simpler to write a test ArtifactProcessor in
contribution-impl. This way, if I break assembly-xml for example, I
won't break your contribution-impl unit test.

More generally, the contribution framework provides a base platform for
various extensions/plug-ins, assembly, policy, implementation-java etc.
So, it would look odd to have the contribution framework implementation
depend on one of the extensions, even for testing purposes.

If you have your own test ArtifactProcessor in contribution-impl, we
also need to test the integration of assembly-xml and contribution-impl,
but this can be tested in assembly-xml itself..

--
Jean-Sebastien


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

Re: Contribution services and SCDL4J

[Venkata Krishnan]

Hi Sebastien,

First, many thanks for this very explanatory reply.  Please find further
queries below.  Thanks.

- Venkat

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


Some answers inline.

Venkata Krishnan wrote:
> Hi,
>
> I am catching up with all the work that is going on in 'modules' and am
> trying my best join the party.  Here are some questions that have come
> up my
> mond... please help me with answers.
>
> - I see that the 'resolve' method in ArtifactProcessor has an argument
> 'resolver'.   Where is this resolver going to be passed from ?  I see
> in the
> testcases that this resolver is created and then passed, but don't
> quite get
> the bigger picture as to how a chain of resolvers would be
> instantiated and
> passed around.  For example when the CompositeProcessor's resolve
> method  is
> called what is the resolver that would be used.

The resolver is used by an ArtifactProcessor.resolve(model, resolver)
method to resolve references to external models. For example you can use
it to resolve another Composite, or a WSDLInterface referenced by one of
your Services.

An ArtifactResolver takes an unresolved object, for example another
Composite with its unresolved flag set to true, and is responsible for
returning the resolved object: the actual Composite found within the
scope of your current SCA Contribution.

We currently have a single minimalistic implementation of
ArtifactResolver based on just a HashMap. The ContributionService puts
into it all models returned by the ArtifactProcessor.read(...) methods.
So, models are loaded first, then put in the ArtifactResolver's map,
then ArtifactResolver.resolve(an unresolved Composite) finds the
resolved Composite with the same name. At the moment, resolvable models
like CompositeImpl implement the equals() method for this to work with
the simple HashMap ArtifactResolver implementation.



If the resolved model object implements ArtifactResolver itself, then we

delegate further resolution to it. I think that this will be useful to
resolve nested models, for example WSDL portTypes or XML schemas inside
WSDL definitions, but this capability is not used yet. This can probably
be used as well later to replace the custom equals() methods if we prefer.



So can I assimilate what you have mentioned above for the following as well.
i.e. have ComponentImpl implement ArtifactResolver and make it resolve the
implementation, reference, property and service within it.  The
implementation also implements ArtifactProcessor to resolve the underlying
componentType.  Is this thinking right?

So, to summarize, at the moment, there is a single default Resolver,

containing all models loaded from a given SCA contribution. Models are
resolved from this single Resolver's map. I may be wrong, but I don't
think we'll ever need the current ArtifactResolverRegistry or chains of
Resolvers.

> - To start putting my hands as well into this, I was looking for a
humble
> start with respect to property loading.  For example if I were to verify
> where a component property defined is actually existing in the
underlying
> componentType where and when would I do this.  I suppose it would be
> in the
> 'resolve' phase  right ?

The resolve phase is probably a little early for this as you won't be
able to assume that the ComponentTypes defining your Components are
complete, and in particular that their references to XML types are
already resolved. So, my recommendation is to:
- Keep the resolve() method to actual resolution of external models, for
example resolve the references to ComponentTypes.
- Use the wire() method to further "wire" things together, for example
connect a ComponentReference to the Reference that defines its
characteristics in the Component's ComponentType, or merge/normalize
property definitions between the ComponentType, the Component and its
configuration in the enclosing Composite.



I get this and will start working on this.  So am just going to string up
properties, services and references starting from componentTypes at the
bottom upto the composite level.  However, I must say there is quite a bit
that has been covered already by you in this :) and I shall cover up the
left overs.

By the way I'm still not sure about how to call this "wire()" method.

We've tried several names:
- normalize()
- optimize()
- wire()

Maybe configure() is a better name :) I'd be interested in any thoughts
on this.



I'd say  'configure' would be a bit confusing as that is overloaded already
with some connotations.  I understand that we are basically 'linking' up
resolved artifacts and hence could relate to 'wire' better.  Do you want to
use 'link'?  Guess we could leave it as is for now.


If so which processor should do thi

Tuscany weekly IRC Chat on Monday, April 9th, 2007, at 15:30GMT

[Venkata Krishnan]

Hello Everybody,

Some of us developers have decided to resume to the weekly IRC we used
to have in Tuscany -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16295.html

Accordingly this is a reminder that the weekly Tuscany developer chat will be
occurring on Monday, April 9, 2007, at: 15:30 GMT, 16:30 BST, 08:30am PDT,
11:30am EDT, 21:00 Bangalore

The chat takes place on the freenode IRC network, (use server
irc.freenode.net), on channel #tuscany, and is scheduled to last one
hour, though it may run longer.  Please join us!

If you need an IRC client for windows, check out http://www.mirc.com,
and http://www.mirc.com/links.html has some links to clients for other
OS's.

Thanks,
Venkat
PS: Ant, I reused one of your reminder mails. Thanks :)

Re: Contribution services and SCDL4J

[Venkata Krishnan]

Thanks Luciano... I will look that up as well.

- Venkat

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


In case you want to see it all working together, SCARuntimeTestCase in the
host-embedded module is a good place to start, it will drive the
contributionServices wired to all dependencies it  have.


On 4/8/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi Sebastien,
>
> First, many thanks for this very explanatory reply.  Please find further
> queries below.  Thanks.
>
> - Venkat
>
> On 4/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > Some answers inline.
> >
> > Venkata Krishnan wrote:
> > > Hi,
> > >
> > > I am catching up with all the work that is going on in 'modules' and
> am
> > > trying my best join the party.  Here are some questions that have
come
> > > up my
> > > mond... please help me with answers.
> > >
> > > - I see that the 'resolve' method in ArtifactProcessor has an
argument
> > > 'resolver'.   Where is this resolver going to be passed from ?  I
see
> > > in the
> > > testcases that this resolver is created and then passed, but don't
> > > quite get
> > > the bigger picture as to how a chain of resolvers would be
> > > instantiated and
> > > passed around.  For example when the CompositeProcessor's resolve
> > > method  is
> > > called what is the resolver that would be used.
> >
> > The resolver is used by an ArtifactProcessor.resolve(model, resolver)
> > method to resolve references to external models. For example you can
use
> > it to resolve another Composite, or a WSDLInterface referenced by one
of
> > your Services.
> >
> > An ArtifactResolver takes an unresolved object, for example another
> > Composite with its unresolved flag set to true, and is responsible for
> > returning the resolved object: the actual Composite found within the
> > scope of your current SCA Contribution.
> >
> > We currently have a single minimalistic implementation of
> > ArtifactResolver based on just a HashMap. The ContributionService puts
> > into it all models returned by the ArtifactProcessor.read(...)
methods.
> > So, models are loaded first, then put in the ArtifactResolver's map,
> > then ArtifactResolver.resolve(an unresolved Composite) finds the
> > resolved Composite with the same name. At the moment, resolvable
models
> > like CompositeImpl implement the equals() method for this to work with
> > the simple HashMap ArtifactResolver implementation.
>
>
> If the resolved model object implements ArtifactResolver itself, then we
> > delegate further resolution to it. I think that this will be useful to
> > resolve nested models, for example WSDL portTypes or XML schemas
inside
> > WSDL definitions, but this capability is not used yet. This can
probably
> > be used as well later to replace the custom equals() methods if we
> prefer.
>
>
> So can I assimilate what you have mentioned above for the following as
> well.
> i.e. have ComponentImpl implement ArtifactResolver and make it resolve
the
> implementation, reference, property and service within it.  The
> implementation also implements ArtifactProcessor to resolve the
underlying
> componentType.  Is this thinking right?
>
> So, to summarize, at the moment, there is a single default Resolver,
> > containing all models loaded from a given SCA contribution. Models are
> > resolved from this single Resolver's map. I may be wrong, but I don't
> > think we'll ever need the current ArtifactResolverRegistry or chains
of
> > Resolvers.
> >
> > > - To start putting my hands as well into this, I was looking for a
> > humble
> > > start with respect to property loading.  For example if I were to
> verify
> > > where a component property defined is actually existing in the
> > underlying
> > > componentType where and when would I do this.  I suppose it would be
> > > in the
> > > 'resolve' phase  right ?
> >
> > The resolve phase is probably a little early for this as you won't be
> > able to assume that the ComponentTypes defining your Components are
> > complete, and in particular that their references to XML types are
> > already resolved. So, my recommendation is to:
> > - Keep the resolve() method to actual resolution of external models,
for
> > example resolve the references to ComponentTypes.
> > - Use the wire() method to further "wire" things together, for example
> > connect a Compon

Assembly Question - Property interface hierarchy

[Venkata Krishnan]

Hi,

In the Assembly module can I change the Property interface hierarchy as
follows:

- Have ComponentProperty extend from AbstractProperty instead of Property.
- Move the 'defaultValue' accessors into 'Property' from AsbtractProperty
- Introduce accessors for 'value' in ComponentProperty.

Right now the value for a ComponentProperty gets read into the
'defaultValue' field and I just want this to move into 'value' field.

Opinions on this change proposal?  Thanks.

- Venkat

Re: Assembly Question - Property interface hierarchy

[Venkata Krishnan]

Ok... this makes sense to me... I'll go ahead and make this change.  Thanks
:)

- Venkat

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


Venkata Krishnan wrote:
> Hi,
>
> In the Assembly module can I change the Property interface hierarchy as
> follows:
>
> - Have ComponentProperty extend from AbstractProperty instead of
> Property.
> - Move the 'defaultValue' accessors into 'Property' from
AsbtractProperty
> - Introduce accessors for 'value' in ComponentProperty.
>
> Right now the value for a ComponentProperty gets read into the
> 'defaultValue' field and I just want this to move into 'value' field.
>
> Opinions on this change proposal?  Thanks.
>
> - Venkat
>

From the SCA assembly spec, it looks like constrainingType/property can
specify a value as well, so AbstractProperty needs a way to specify a
value. How about just renaming the defaultValue field to value? If we
did that then the structure would be similar to References and Services.
A Reference can have some characteristics (like targets or bindings)
configured in a ComponentType, then reconfigured on a
ComponentReference. Similar for Property, the Property could have its
value configured in a ComponentType, then reconfigured on a
ComponentProperty.

--
Jean-Sebastien


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

Re: Wiring of Services and References ?

[Venkata Krishnan]

Hi,

If the calulator sample is working then I suppose the wiring is in place
isn't it ?   Let me go and try this one.

- Venkat

On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 4/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I'm trying to run the echo-binding testcases after updating the binding
> implementation, but I'm getting the exception below.
> Are we actually wiring services and references  ?
>
> java.lang.IllegalStateException: java.lang.NullPointerExceptionat
> org.apache.tuscany.api.SCARuntime.start(SCARuntime.java:170)at
> org.apache.tuscany.binding.echo.EchoBindingTestCase.setUp(
> EchoBindingTestCase.java:35)at junit.framework.TestCase.runBare(
> TestCase.java:132)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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
> JUnit4TestReference.java:38)at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(
TestExecution.java
> :38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> RemoteTestRunner.java:460)at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
> RemoteTestRunner.java:673)at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
> RemoteTestRunner.java:386)at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
> RemoteTestRunner.java:196)Caused by: java.lang.NullPointerException
at
> org.apache.tuscany.core.implementation.PojoAtomicComponent.start(
> PojoAtomicComponent.java:217)at
> org.apache.tuscany.host.embedded.SimpleRuntimeImpl.start(
> SimpleRuntimeImpl.java:158)at
> org.apache.tuscany.host.embedded.DefaultSCARuntime.startup(
> DefaultSCARuntime.java:50)at org.apache.tuscany.api.SCARuntime.start
(
> SCARuntime.java:168)... 15 more
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
Luciano

Did you get past this. I'm getting an NPE in composite-impl where the
system
is trying to create wires (just posted on it). Be interested to know if
you
solved your problem?

Regards

Simon

Java-Impl-Runtime and DataBinding

[Venkata Krishnan]

Hi,

I have got basic properties to work with the java-implementation-runtime.
Here are some observations that I'd like to validate...

- assuming that we load the assembly models from xml the core will always
hand out to the 'implementation runtimes'' such as 'java-implementation' a
Document object for the value of a property.  The implementation runtimes
are responsible for invoking the databinding framework to convert the
property value from document to whatever form... for example Document to
JavaBean.  Is this right?

If this is right, then I guess the databinding framework need to be plugged
into the java-impl-runtime?  How is this to be ideally done in the current
architecture?  I suppose, dragging it in as a dependency and using it as yet
another dependent class library is not the way.. so could somebody please
help me with some pointers to do this.


Thanks

- Venkat

Re: Wiring of Services and References ?

[Venkata Krishnan]

Hi Simon,

Thanks for considering on expanding the 'problem model'.  Infact I was
wondering if every SCA Object such as a Composite, Component, Reference,
 has a bunch of 'error contexts' encapsulated within it.  So if
something is wrong with a Reference defn, you simply add the problematic
'reference defn. instance' (as it is being done now) and also the Error
Context say something as 'MULTIPLICY_TO_TARGET_MISMATCH'.  The for each of
these 'Error Contexts' the SCA Object also encapsulates what information
would be relevant to output as Error Information.  So if you'd as for an
error message to the Reference Object given the context
'MULTIPLICY_TO_TARGET_MISMATCH' it would provide you the multiplicity and
target settings.

So we simply stack the problematic SCA Objects and simply ask for Error
Information at the end.

Not sure it this would complicate things... it was just a thought... maybe
there are better options.

- Venkat



On 4/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 4/12/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
> > [snip]
> > Simon Laws wrote:
> >>
> >> Composite configuration problem:
> >> [EMAIL PROTECTED]
> >>
> >> I've not looked into this one specifically but it doesn't stop the
test
> >> passing. I do get more of these problem reports in the composite-impl
> >> test
> >> that I'm playing with and it is a real problem in that case. Still
> >> looking
> >> at whats going on.
> >>
> >> Regards
> >>
> >> Simon
> >>
> > Simon,
> >
> > This output is produced by temporary test code that I added to
> > CompositeUtil to help track problems in most of .composite files,
> > which are not all following the SCA assembly XML spec 1.0. In
> particular:
> > - declare a targetNamespace
> > - use qnames to name referenced composites
> > - name included composites in the content of the  element
> > instead of a "name" attribute
> > - use "target" attributes on references instead of naming the target
> > in the element content
> > - use "promote" attributes on composite services and references
> >
> > So before testing, you need to make sure that the .composite files are
> > correct. These print statements should help you detect that there are
> > problems (even if they just dump the model objects at the moment).
> > Then to debug you can set a breakpoint on the line that does the
> > print, and figure what 's wrong in the test case from there.
> >
> Simon,
>
> I just committed a change to print more debug info when encountering a
> composite configuration problem. Hope this helps.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Great, thanks Sebastien.Thanks for doing that. I gave the new code a
spin
and the extra info is interesting. Looking at the CompositeUtil code is
looks like it is always comparing the component definition from the SCDL
with the implementation. Do you have any objection if I go in and add some
more info to the  problem model to record and report the exact nature of
the
problem found?

Simon

Simon

Re: How to tell if a component reference is promoted by a comosite reference?

[Venkata Krishnan]

Hi,

What I menetion here is only from the perspective of the 'future' plan for
this.


From what I understand of the assembly model, I am not so comfortable about

adding 'promotedAs'.  There are probably two options that I can think of
which is 1) add the Composite Reference name to the 'tagets' list of the
component reference or 2) maintain a map in CompositeUtil with
ComponentReference->PromotedReference relationship just to be used in the
'wire' method.

Thanks

- Venkat

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


Simon Laws wrote:
> On 4/13/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> With the current assembly model, how can we tell if a component
>> reference
>> is
>> promoted by a comosite reference? I can get all the promoted references
>> from
>> CompositeReference but not the other way.
>>
>> Thanks,
>> Raymond
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>> If the model is a true reflection of what appears in the SCDL then I
> assume you would have to loop over all the references in the composite
> that
> contains the component in question and test if the componet reference is
> being promoted. I know that isn't telling you anything you don't already
> know but it's just and excuse to add a related question to this thread
>
> Is the philosophy with the assembly model to have it represent precisely
> what appears in the SCDL or is there room to include value add, for
> example,
> links from components references to the composite references that
promote
> them?
>
> Simon
>

We currently have: CompositeReference.promotedReferences --> 0..n
ComponentReference.

We could have the relationship in the other direction:
ComponentReference.promotedAs --> 0..n CompositeReference.

In the future, I would prefer to have only one of the two above
relationships (to avoid confusion with which one needs to be populated
when you read or construct model instances), but maybe we can add the
second relationship for now and populate it in CompositeUtil.wire().

Would that help?

--
Jean-Sebastien


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

Support for Component Properties

[Venkata Krishnan]

Hi,

I have updated the Trunk for some minor changes to bring in support for
properties.  I 'property' iTest is also back fully functional.  With this
check it should be possible to have components configured with simple and
complex properties either single valued or many valued.  The 'source' and
'file' options are also working from what I tested with the iTest.  An
assumption about simple type many values is that if there are many values of
a simple type then they are all provided with spaces separating each value.
For Strings, each string needs to be enclosed within a double quote.
Examples of a many valued  'float' type property and 'string' type property
are...


   12.34 56.78 90.12 34.56


   "Apache" "Tuscany" "Java" "SCA"


The current support for properties does not work for Components whose
implementation is a Composite.  There are some issues that I see with doing
this which I'll start in a new thread.

At the present moment I have included the 'databinding' module as a
dependency into the implementation-java-runtime.  I have created the
DBRegistry, the Transformation Registry and have explicitly registered the
DOM2JavaBeansTransformer.  I have left out the other transformers as I guess
this is going to change with these registries being accessible from the
extentions point registry.  When I figure that out, it would probably bring
in the whole suite of transformers.

With this implementation I also have a few observations over which I request
comments: -
- With respect to the attribute 'many' it is 'false' by default and is also
optional.  Meaning if a property definition does not mentioned this
attribute then it is taken as 'false'.  Given this, if a componentType has a
property that has many='true' then the component that uses this
componentType MUST state many='true' if it also wished to have the property
as many valued.  If the component does not mention this attribute, then the
'many' attribute assumes its default value which is 'false' and prevents the
use of many values in the property definition.  This could quite be a
surprise if the 'many' attribute is left out of the Component with the
assumption that it will inherit whatever is defined in the underlying
componentType.  So in a nutshell, if many values are going to be used then
the Property Defn. in the Component MUST specify many='true' - is this ok ?

- PropertyValues can also be loaded from a file by mentioning the location
of the file in the 'file' attribute.  What is the classloader to be used
when loading this file?  Must the ContributionService be used?  At the
present moment I am using TCCL.

- When a property has 'source' and 'file' defined, the specs says that
'source' takes precedence over file.  Now what if 'source' is provided and
also a value is provided.  Which takes precedence?  Right now the 'source'
is taking precedence.

Thanks for reading upto this point :)

- Venkat

Re: Build failures- Explanation and Proposed Solution

[Venkata Krishnan]

Luciano, thanks for doing this.  +1 from me for '*-incubating-*'.

- Venkat

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


Luciano Resende wrote:
> Hi All
>
>After couple complains about build failures, and couple hours
> investigating the multiple complains on the dev-list [1][2], looks
> like all the issues are being caused due to our artifacts having two
> set of artifact versions : 2-incubating-SNAPSHOT
> and 2-incubator-SNAPSHOT.After I changed everything
> locally to use the same version as the one defined in the
> java/pom/parent 2-incubating-SNAPSHOT, the whole
> build started to work and the issues reported are gone.
>
>So, in order to avoid future complains, I'd like to propose changes
> to remaining artifacts that are using
> 2-incubator-SNAPSHOT version. Note that I have
> already started changing the DAS artifact versions as described in
> [3]. And I have attached a file containing the remaining places that
> need changes.
>
>If people are OK with proposed changes, particularly the SDO team,
> I'd like to go ahead and commit my local changes asap.
>
> [1]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16509.html
> [2]
> http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00822.html
> 
> [3]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg16625.html
>
> --
> Luciano Resende
> http://people.apache.org/~lresende 
> 
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

+1 from me. I think that the recommendation for artifacts from
incubating projects is *-incubating-* (although I can't find the
discussion thread right now I remember I had seen a discussion on this a
while ago). The SCA artifacts are already *-incubating-*, looks like
you're fixing the DAS artifacts, we need the folks working on SDO to say
if they're OK with this change.

--
Jean-Sebastien


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

Re: SDO project build failure

[Venkata Krishnan]

I too faced this problem yesterday with maven-dependency-plugin and things
went thro after I deleted this from my local maven repos.

- Venkat

On 4/18/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Not sure,  it worked for me before and after the removel,  so i guess
perhaps your local maven repo somehow had become corrupted.

Kelvin.


On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> Thanks Kelvin. I removed it and that fixed it for me. It must have been
> corrupted
>
> Frank.
>
> "kelvin goodson" <[EMAIL PROTECTED]> wrote on 04/17/2007 02:29:24
> PM:
>
> > It builds cleanly for me, even after removing
> > ~\.m2\repository\org\apache\maven\plugins\maven-dependency-plugin,  so
> was
> > this an intermittent thing?
> >
> > regards, Kelvin.
> >
> >
> >
> >
> > On 17/04/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I just did an svn update of the SDO project, and now it fails to
> build.
> > > Any ideas?
> > >
> > > Thanks,
> > > Frank.
> > >
> > > [INFO] Scanning for projects...
> > > [INFO] Reactor build order:
> > > [INFO]   Tuscany SDO Implementation Project
> > > [INFO]   Tuscany SDO Implementation
> > > [INFO]   Tuscany SDO Tools
> > > [INFO]   Tuscany SDO Maven Plugin
> > > [INFO]
> > >
>
-
> > > ---
> > > [INFO] Building Tuscany SDO Implementation Project
> > > [INFO]task-segment: [install]
> > > [INFO]
> > >
>
-
> > > ---
> > > [INFO] Skipping missing optional mojo:
> > > org.apache.maven.plugins:maven-site-plugi
> > > n:attach-descriptor
> > > [INFO]
> > >
> 
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >
> 
> > > [INFO] The plugin ' org.apache.maven.plugins:maven-dependency-plugin
'
> does
> > > not ex
> > > ist or no valid version could be found
> > > [INFO]
> > >
> 
> > > [INFO] For more information, run Maven with the -e switch
> > > [INFO]
> > >
> 
> > > [INFO] Total time: 1 second
> > > [INFO] Finished at: Tue Apr 17 11:39:05 EDT 2007
> > > [INFO] Final Memory: 2M/5M
> > > [INFO]
> > >
> 
> > >
> > >
> > >
> > >
-
> > > 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]
>
>

Default Component created for the deployed composite

[Venkata Krishnan]

Hi,

I have been figuring out a way of implementing the overriding of
properties.  Right now in the 'wire' phase for each component definition if
we find there are properties defined in the underlying componentType
(implementatoin) and are not defined in the component definition, then we
define them in the component definition.  This makes makes it convenient in
the build phases where we get all properties at the comp. defn. level itself
and need not dig into the componentType and do all sorts of comparisons.

Now, I see that in DeployerImpl.deploy we create a 'Default Component Defn.
that uses the deployed composite for implementation'.  This component defn.
does not copy over the deployed composite's properties.  This creates
problems in the CompositeBuilder which really is not supposed to know if the
composite being built is the default one or not.  I am going to add a
'createDefaultComponentDef' or something of that sort of method where I'll
create this component and initialize it with copy overs from the deployed
composite.  Please let me know, if somebody things this is not right thing
to do.


Thanks

- Venkat

Re: Improve/simplify the runtime further

[Venkata Krishnan]

Hi,

Having implemented properties support for the java-impl-runtime I was
wanting to get this going with the script-impl-runtime as well.  So in doing
that I think I will also be able to help with the things item 3.  Ant, I'd
be happy to work with you on that.

- Venkat

On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:


On 4/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm thinking of improving and simplifying the runtime further in the
> following directions:
>
> 1. Have the Tuscany runtime to maintain the SCA domain composite and
> refactor the DeployerImpl into the Domain service.
>
> 2. Simplify the relationship between runtime metadata
> (o.a.t.spi.Component/Service/Reference) for the invocations and model
> (o.a.t.assembly.*).
>
> 3. Improve the Wire/InvocationChain to support dynamic style invocation
> (in
> cases that we don't know or don't care about the interface/operation
until
> runtime) in addtion to the operation-based invocation chain.
>
> 4. Implement the CallableReference/ServiceReference/CallbackReference.
>
> The list is not meant to be complete. Please feel free to add your
ideas.


All those sound good to me, I'm particularly interested in 3 for the
script
implementation so I'd like to help with that one to make sure it does what
I
need. Will have to wait a day or two while I get the script implementation
more fully functional.

   ...ant

Re: Represent the recursive composition in runtime

[Venkata Krishnan]

Hi Raymond,

Thanks for bringing this up.  I did get a feel of this during a recent
addition that I did for supporting configuration of properties for
components implemented by a composite.  I was probably at loss to lay out an
illustration as well as you have done :).

1) I guess the 'includes' thing is presently there in CompositeUtil of the
assemly module and gets invoked as part of the 'wire' phase.

2) As far as cloning goes, its seems to be a good solution but I really
wonder if this would give a consistent view of the model.  I persceive a
'componentType' to be singular in a SCA Domain once loaded by the
Contribution and Composite being a 'componentType' makes be feel it should
also be left singular.  If the configuration of the implementation instances
with properties and reference settings happen only during build time for
other implementations that we have done up to now.. like the java-impl,
maybe this is the pattern we must follow for composite implementations too.
I feel this common treatment will help us in framing our SPIs.
consistently.  This is just about what occurs to me immd. and maybe there
are some perspectives I am missing out - please let me know of them.

Thanks

- Venkat


On 4/21/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

In the current code base, we use builder framework to create peer objects
for runtime corresponding to the model and use the runtime metadata to
drive
the component interactions. This approach adds more complexity and
redundance. I think now it should be possible to take advantage of the
fully-resolved/configured model directly.

To acheive this, we need to normalize the model to represent the recursive
composition in runtime. There are some cases:

1) For , we need to merge all
components/services/references/properties from the included composite to
the
enclosing composite.

2) Two components use the same non-composite implementation, for example,
two components are implemented by the same java class. In this case, we
should have two component model instances and one implementation model to
avoid duplicate introspection.


3) Two components are implemented by the same composite

This is a more interesting case. Please see the diagram @

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy
.

Path a: Composite1.ComponentB is implemented by Composite3
Path b: Composite2.ComponentD is implemented by Composite3

The service/reference can be promoted to different things:

a: the final target for the ComponentF.Reference1 is Composite1.ComponentA
b: the final target for the ComponentF.Reference1 is Composite1.Reference1
(pointing to an external service)

The property can be set to different value following different composition
path:

a: Composite3.ComponentE.Property1 is overrided by
Composite1.ComponentB.Property1 (say value="ABC")
b: Composite3.ComponentE.Property1 is overrided by
Composite2.ComponentD.Property1 (say value="XYZ")

To represent the fully-configured components, we need to clone the model
for
Composite3 for Path a and b so that it can be used to hold different
resolved values. With the flatten structure, we should be able to fully
configure the components at model level.

Am I on the right track? Feedbacks are welcome.

Once we agree on this, I'll continue to bring up the discussions on
additional runtime behaviors beyond the model that needs to be provided by
the component implementation or binding extensions to work with the core
invocation framework.

Thanks,
Raymond


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

Re: SPI reorg (was: Re: [Discussion] Tuscany kernel modulization

[Venkata Krishnan]

Hi,

I have shared a recent experience in this regard with comments inline.

Thanks

- Venkat

On 4/20/07, ant elder < [EMAIL PROTECTED]> wrote:


On 3/29/07, ant elder < [EMAIL PROTECTED]> wrote:
>
>
> On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> 
>
> One reason the SPI module is so large is that it does define many the
> > interfaces for the components in you diagram. I think there is room
> > for a reorganization there to clarify the usage of those interfaces.
> > I would propose we start with that ...
>
>
> There have been several emails now which I think show some agreement
that
> we can do some SPI refactoring. Here's something that could be a start
of
> this work:
>
> One area is the extension SPI, on our architecture diagram [1] thats the

> "Extensions" box at the top right. In the past we've had a lot of
problems
> with extensions continually getting broken as the SPIs keep changing.
This
> has made maintaining extensions to be in a working state a big job and
it
> has led to some donated extension just being abandoned.
>
> One of the reasons for this is that the SPIs more reflect the
requirements
> of the Tuscany runtime than the requirements of the extension being
> contributed. For example, a container extension needs to enable
creating,
> initializing, invoking and destroying a component, along with exposing
the
> components services, references and properties. Those things have
remained
> pretty constant even though the SCA specs and Tuscany runtime and SPI
have
> undergone significant changes.
>
> I think we should be able to create SPIs for these type of functions
which
> clearly represent the requirements of a particular extension type, and
that
> doing this would go along way to making things more stable. All this
code is
> there in the current SPI so its mainly just a mater of refactoring parts
> out into separate bits with clearly defined function and adding adapter
code
> so the runtime can use them.
>
> You can even envisage that if this is successful it could define a
runtime
> extension SPI for all the extensible areas of SCA assembly which could
> eventually be standardized to provide portable SCA extensions in a way
> similar to JBI.
>
> What do people think, is this worth looking at? If so I'd like to make
an
> attempt at doing it for bindings and components using the Axis2 binding
and
> script container as guinea pigs. This should be pretty transparent to
the
> rest of the kernel as other than the adapter code it could all be
separate
> modules.
>

I mentioned on the release discussion thread  that I'd bring this thread
up
again.

The new trunk code has made things better in the SPI area but I think
there's still a lot that could be improved (IMHO). The sort of thing i was
thinking about was coming up with runtime support and an spi package for
each extension time that made it clear what all the methods needed to be
implemented for  at least minimum functionality.

For example, for an implementation extension minimum functionality would
support services, references and properties (at least simple type
properties
anyway), correctly merging introspected and sidefile defined component
type
info, component instance life cycle and scope, and the correct invocation
semantics for things like pass-by-value support. And do all that in a way
where the majority of code is done generically in the runtime instead of
the
extension either not supporting some of those things or just copying
chunks
of code from other extensions to get the support.



I entirely agree with this.  I remember that one of the 'ceremonious' things
we used to do in the old code base to implement an extension was to copy
over quite a bit of code from a existing one.  I guess we must avoid that
this time around.  I'd really like to have the .componentType info gathering
done in the core.  The only thing that might get specific to implementation
extensions in this is the URI for the .componentType file.  i.e. for
java-implementations this is derived from the 'class' field of implementaion
.java and for script-impl this is derived from the 'scriptname'.  I guess,
getting this URI can be done by adding one more SPI method
'getComponentTypeURI' like the way we have 'getArtifactType' for each
implementation.

The other case that I feel could be a part of the core itself is the
PropertyValue ObjectFactory and the Databinding support that it uses.  This
can again be a part of the core and there could just about an SPI method
such as 'setProperty(name, value)' that could be implemented by
implementation extensions.  If there are some specific transformers that the
implementation needs then those alone can be contributed by the
implementation.

Do others agree this is something we should try to do for the next release?

If so I thought about starting with a new modules for implementation-spi,
binding-spi etc to avoid changing the existing runtime code for now. And
I'd
like to start on the implementation-spi one wit

Re: [VOTE] Andy Grove for Tuscany Committer

[Venkata Krishnan]

+1 from me.

- Venkat

On 4/23/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


Andy has taken part in SDO Java and C++ discussions since November of
2006,
in particular in the area of the Community Test Suite (CTS).  As some of
you
may not follow this closely, I've distilled quite a bit of detail from the
lists to show Andy's participation.  He ...


   - been active in creating and resolving numerous JIRAs
   - did some of the work of the initial drop of tests to the SDO Java
   CTS from Rogue Wave and in the CTS infrastructure design, including
ensuring
   vendor independence.
   - has discovered and offered solutions to a number of anomalies
   between the CTS and the specification
   - developed and contributed tests for testing XML schema choice
   function.
   - provided good insights to the required and permitted behaviours of
   implementations when dealing with elements which are nillable
   - has taken part in discussions for an M1 release of the CTS
   - Initiated discussions on DataHelper formats wrt dates and durations
   - developed new test cases for spec section 9.10 -- XML without Schema
   to SDO Type and Property
   - solicited input from the Tuscany community with respect to the
   equivalence or otherwise of null URIs versus empty strings,  in order
to
   feed back to the spec group
   - took a significant part in discussions of how to ensure the CTS is
   test harness agnostic, and provided patches to update tests to assist
in
   this goal
   - contributed a set of tests for XSD complex types
   - provided support to the community with problems running the CTS and
   with insights into new Junit features

Aside from Tuscany, Andy has been active in the SDO Java and C++
specification efforts, and I think he will be a great asset to the
project.

Regards, Kelvin.

Re: Nominate Ant as the release manager was: Re: [DISCUSS] Next version - What should be in it

[Venkata Krishnan]

+1.  I completely share Simon's observations

- Venkat

On 4/24/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


+1. I would like to nominate Ant too.

Thanks,
Raymond

- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 24, 2007 4:32 AM
Subject: Re: [DISCUSS] Next version - What should be in it


> How about Ant as release manager for this release?  He has been very
> diligent in reviewing previous Tuscany releases with many helpful
> comments.  He has a good understanding of the Apache requirements
> and process for publishing a release, and I think he is very well
> qualified to take this on.
>
>   Simon
>
> Raymond Feng wrote:
>
>> Hi,
>>
>> After evaluating the features I would like to contribute to this
release
>> in the short timeframe, I don't think I would have enough time to
handle
>> the release as I'm new to this process. I would appreciate if somebody
>> else with more experience volunteers to be the release manager. This
way,
>> I can learn more and get ready for the next time.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message - From: "Luciano Resende"
>> <[EMAIL PROTECTED]>
>> To: 
>> Sent: Friday, April 20, 2007 10:25 AM
>> Subject: Re: [DISCUSS] Next version - What should be in it
>>
>>
>>> +1 on focusing on the stability and consumability for the core
>>> functions,
>>> other then helping on simplifying the runtime further and work on a
>>> Domain
>>> concept, I also want to contribute around having a better integration
>>> with
>>> App Servers, basically start by bringing back WAR plugin and TC
>>> integration.
>>>
>>> +1 on Raymond as Release Manager
>>>
>>> On 4/20/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>

 Hi,

 Considering that we want to achieve this in about 3 weeks, I agree
that
 we
 focus on the stability and consumability for the core functions.

 Other additional features are welcome. We can decide if they will be
 part
 of
 the release based on the readiness.

 Are any of you going to volunteer to be the release manager? If not,
I
 can
 give a try.

 Thanks,
 Raymond

 - Original Message -
 From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
 To: 
 Sent: Wednesday, April 18, 2007 6:07 PM
 Subject: Re: [DISCUSS] Next version - What should be in it


 > Davanum Srinivas wrote:
 >> Folks,
 >>
 >> Let's keep the ball rolling...Can someone please come up with a
 master
 >> list of "extensions, bindings, services, samples" which can then
 >> help
 >> decide what's going to get into the next release. Please start a
 >> wiki
 >> page to document the master list. Once we are done documenting the
 >> list. We can figure out which ones are MUST, which ones are nice
to
 >> have, which ones are out of scope. Then we can work backwards to
 >> figure out How tightly or loosely coupled each piece is/should be
 >> and
 >> how we could decouple them if necessary using
 >> interfaces/spi/whatever...
 >>
 >> Quote from Bert Lamb:
 >> "I think there should be a voted upon core set of extensions,
 >> bindings, services, samples, whatever that should be part of a
 >> monolithic build."
 >>
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html
 >>
 >> Quote from Ant Elder:
 >> The specifics of what extensions are included in this release is
 >> left
 out
 >> of
 >> this vote and can be decided in the release plan discussion. All
 >> this
 >> vote
 >> is saying is that all the modules that are to be included in this
 next
 >> release will have the same version and that a top level pom.xmlwill
 >> exist
 >> to enable building all those modules at once.
 >>
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html
 >>
 >> Thanks,
 >> dims
 >>
 >>
 >
 > Hi all,
 >
 > I think we have made good progress since we initially started this
 > discussion. We have a simpler structure in trunk with a working >
 top-down
 > build. Samples and integration tests from the integration branch
have
 been
 > integrated back in trunk and most are now working.
 >
 > We have a more modular runtime with a simpler extension mechanism.
 > For
 > example we have separate modules for the various models, the core
 runtime
 > and the Java component support. SPIs between the models and the
 rest of
 > the runtime have been refactored and should become more stable. We
 need
 to
 > do more work to further simplify the core runtime SPIs and improve
 > the
 > core runtime but I think this is going in the right direction.
 >
 > I'm also happy to see better support for the SCA 1.0 spec, with
 support
 > for most of the SCA 1.0 assembly XML, and some of the SCA 1.0 APIs.
 > It
 

RMI Binding reactivated on the trunk

[Venkata Krishnan]

Hi,

I have got the RMI Binding going on the trunk now.  This is implemented with
two modules Java RMI Binding and Java RMI Host Extension Point.  For now I
have combined the processor, model and runtime parts of the RMI Binding into
a single module but under distinct packages.  As we whet our SPIs, I shall
split them into separate modules.

Thanks

- Venkat

Re: RMI Binding reactivated on the trunk

[Venkata Krishnan]

Hi Sebastien,  thanks for taking a look.  The testcase in there... maybe its
actually a itest, show how it works, but then it combines the rmi reference
and service into one test.  So I agree that we must have a sample and will
work on that.

- Venkat

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


Venkata Krishnan wrote:
> Hi,
>
> I have got the RMI Binding going on the trunk now.  This is
> implemented with
> two modules Java RMI Binding and Java RMI Host Extension Point.  For
> now I
> have combined the processor, model and runtime parts of the RMI
> Binding into
> a single module but under distinct packages.  As we whet our SPIs, I
> shall
> split them into separate modules.
>
> Thanks
>
> - Venkat
>

Great, Thanks! I took a look and built it, it looks good.

I just reformatted the pom.xml a little as it contained tabs and added
an svn:ignore properties setting. I think it would be nice to have a
simple sample showing how to use the binding under java/sca/samples.

--
Jean-Sebastien


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

Re: RMI Binding reactivated on the trunk

[Venkata Krishnan]

Hi, I have added a couple of samples now - one to demonstrate RMI Binding as
reference binding and another to demonstrate RMI Binding as service
binding.  I have also added a readme.html to these samples.  Thanks.

- Venkat

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


Hi Sebastien,  thanks for taking a look.  The testcase in there... maybe
its actually a itest, show how it works, but then it combines the rmi
reference and service into one test.  So I agree that we must have a sample
and will work on that.

- Venkat

On 4/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Venkata Krishnan wrote:
> > Hi,
> >
> > I have got the RMI Binding going on the trunk now.  This is
> > implemented with
> > two modules Java RMI Binding and Java RMI Host Extension Point.  For
> > now I
> > have combined the processor, model and runtime parts of the RMI
> > Binding into
> > a single module but under distinct packages.  As we whet our SPIs, I
> > shall
> > split them into separate modules.
> >
> > Thanks
> >
> > - Venkat
> >
>
> Great, Thanks! I took a look and built it, it looks good.
>
> I just reformatted the pom.xml a little as it contained tabs and added
> an svn:ignore properties setting. I think it would be nice to have a
> simple sample showing how to use the binding under java/sca/samples.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Tuscany Java sca package names

[Venkata Krishnan]

Hi,

I'd prefer 'org.apache.tuscany.sca' for the sake of consistency if not for
anything else.  I don't mind pushing this change to the post-release time.

Thanks

- Venkat

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


The DAS and SDO sub projects use Java package names
org.apache.tuscany.dasand
org.apache.tuscany.sdo but the SCA sub project uses org.apache.tuscany. As
the next release is attempting to stabilize all the externals I wondered
if
we should change this now to be be org.apache.tuscany.sca, does anyone
have
feelings either way?

   ...ant

Re: Tuscany Java sca package names

[Venkata Krishnan]

HI,

As we had discussed in the IRC, I plan to change the package names in
core-spi module to include 'sca'.  I plan to do this on Tuesday, 24.00 Hrs -
Pacific Time (US & Canada) unless I hear of objections to it.  Please plan
your commits accordingly.  Thanks.

- Venkat

On 5/1/07, Simon Nash <[EMAIL PROTECTED]> wrote:


I can see that the renamed APIs would be more consistent across
Tuscany, which is an advantage.  It is a matter of balancing this
against the work and disruption involved in making the change.
I don't feel strongly either way, but on balance I think it would
make sense to do this renaming either now or after the next release.

   Simon

Raymond Feng wrote:

> Hi,
>
> I think a massive of package renaming is disturbing at this point. Since
> SDO and DAS already have the unique prefixes and there won't be any
> conflicts, I would suggest that we keep the short package name
> org.apache.tuscany for SCA.
>
> Thanks,
> Raymond
>
> - Original Message - From: "ant elder" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 30, 2007 12:59 AM
> Subject: Tuscany Java sca package names
>
>
>> The DAS and SDO sub projects use Java package names
>> org.apache.tuscany.dasand
>> org.apache.tuscany.sdo but the SCA sub project uses
>> org.apache.tuscany. As
>> the next release is attempting to stabilize all the externals I
>> wondered if
>> we should change this now to be be org.apache.tuscany.sca, does anyone
>> have
>> feelings either way?
>>
>>   ...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]

Running RAT on Tuscany Distribution

[Venkata Krishnan]

Hi,

I built the sca\distribution and extracted the contents of
tuscany-sca-1.0-incubating-SNAPSHOT.zip  (binary disb) and
tuscany-sca-1.0-incubating-SNAPSHOT-src.zip (src disb) found in the target
directory.

I then ran the RAT tool on the base directory of these extractions.  RAT
seemed have trouble with the following files...

- samples\das-service\webclient\dastest\db.lck
- modules\http-tomcat\work\null\localhost\_\SESSIONS.ser

Skipping these two, the RAT report for the rest can be found in the
following links.

RAT on Binary Disb : http://people.apache.org/~svkrish/RAT_M3/RAT_BIN.txt
RAT on Src Disb : http://people.apache.org/~svkrish/RAT_M3/RAT_SRC.txt

I shall be taking a closer look at those reports and shall fix as much as I
can.

Comments ?

Thanks

- Venkat

Re: RMI Binding reactivated on the trunk

[Venkata Krishnan]

Oops. sorry.. I did not add them to the samples pom when I committed them.
Yes they are working and I will add them right away.  Thanks

- Venkat

On 5/3/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Hi Venkat, are the RMI samples working now (calculator-rmi-reference and
calculator-rmi-service)?
Just checking as they were not added into the samples pom, so they could
be
built during regular builds.

On 4/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi, I have added a couple of samples now - one to demonstrate RMI
Binding
> as
> reference binding and another to demonstrate RMI Binding as service
> binding.  I have also added a readme.html to these samples.  Thanks.
>
> - Venkat
>
> On 4/27/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi Sebastien,  thanks for taking a look.  The testcase in there...
maybe
> > its actually a itest, show how it works, but then it combines the rmi
> > reference and service into one test.  So I agree that we must have a
> sample
> > and will work on that.
> >
> > - Venkat
> >
> > On 4/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > Venkata Krishnan wrote:
> > > > Hi,
> > > >
> > > > I have got the RMI Binding going on the trunk now.  This is
> > > > implemented with
> > > > two modules Java RMI Binding and Java RMI Host Extension
Point.  For
> > > > now I
> > > > have combined the processor, model and runtime parts of the RMI
> > > > Binding into
> > > > a single module but under distinct packages.  As we whet our SPIs,
I
> > > > shall
> > > > split them into separate modules.
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > >
> > > Great, Thanks! I took a look and built it, it looks good.
> > >
> > > I just reformatted the pom.xml a little as it contained tabs and
added
> > > an svn:ignore properties setting. I think it would be nice to have a
> > > simple sample showing how to use the binding under java/sca/samples.
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>



--
Luciano Resende
http://people.apache.org/~lresende

JRubyScriptEngine in Tuscany ScriptImpl

[Venkata Krishnan]

Hi Ant,

I guess the JRubyScriptEngine in the BSF distribution has some problem
dealing with 'global variables' since the other three engines - JavaScript,
Groovy and Jython work clean.

I pulled down the source for JRubyScriptEngine from
https://scripting.dev.java.net/source/browse/*checkout*/scripting/engines/jruby/src/com/sun/script/jruby/JRubyScriptEngine.java?rev=1.7and
hacked a bit with it to get this going.

So here is what I suggest we can do : -
- make a copy of the JRubyScriptEngine code locally within the script-impl
module with the hacks to get it going for us.
- in the ScriptComponent.createInstance method, if the script extn. is 'rb'
we will instantiate this local copy of the JRubyScriptEngine otherwise
delegate it to the ScriptManager to get the engine for the extn. as it is
being done presently.  I also explored a bit about registering this local
copy of the engine with the ScriptManager but there are somethings that make
it a little complicated.  So decided to go with this simpler option which is
anyways a temporary fix till we find a solution.

Please let me know your thoughts about this.  I hope there is not going to
be any licensing issues with this copying over of the engine code.

Thanks

- Venkat

Re: Next release name? (was: Re: [DISCUSS] Next version - What should be in it)

[Venkata Krishnan]

+1 for 0.90

- Venkat

On 5/2/07, ant elder <[EMAIL PROTECTED]> wrote:


It would be good to choose a name soon so we can start completing all the
readme's and release notes etc, there doesn't seem much consensus on beta1
so how about 0.90? That sounds closer to 1.0 than M3 or alpha and still
gives space for more releases before the final 1.0.

   ...ant

On 5/1/07, Bert Lamb <[EMAIL PROTECTED]> wrote:
>
> I realize I'm a bit late to this conversation, I'm just now getting
> mostly unpacked from a move to Somerville, MA.  I agree with Simon in
> that we should be careful what we call "beta".  I know that we all
> would like to get to beta quality code and features as soon as we can,
> but I don't think we are there yet nor will we be there by JavaOne.
> What we currently have in the trunk I think is a much more manageable
> code base but it actually has fewer features, if I'm not mistaken,
> than M2 had.  So, my vote, if I had a binding one, would be for 3,
> with a name of M3 or maybe alpha.
>
> -Bert
>
> On 4/25/07, ant elder <[EMAIL PROTECTED]> wrote:
> > On 4/24/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > So I think it comes down to whether it is more important to put
> > > something out by JavaOne (in which case I'd be hesitant to call it
> > > "beta") or whether it is more important to attain a true "beta"
level
> > > of quality even if that takes a little bit longer.
> >
> >
> > I guess a lot comes down to everyones slightly different perceptions
as
> to
> > what the name "beta" implies, what do others think about this? Should
> we:
> >
> > 1) continue aiming for a beta1 release around JavaOne timeframe
> > 2) continue with a beta1 release but take a bit more time
> > 3) aim for a release around JavaOne timeframe but change to a
non-"beta"
> > release name, alpha-x or maybe a numeric like 0.90?
> >
> > I probably favor (2) as looking at things people have said they'd like
> to
> > get done it seems unlikely to me we'll be ready by JavaOne anyway.
> >
> >...ant
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [Proposal] Clean up the code base

[Venkata Krishnan]

+1 for cleaning rightaway and temporarily commenting out modules that
break.  Thanks

- Venkat

On 5/4/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

As you might have known from the mailing list that we have made good
processes in refining the extension interfaces and simplifying the
runtime.
Now we have the CRUD component type, Java component type, echo-binding and
echo-databinding working with the new runtime. I assume it's ready for
other
extensions to be ported over.

To not break the build, we have created classes/interfaces in different
packages for the new things. As a result, the code base is a bit messy and
you might be confused by the two code paths. To speed up the transition
and
avoid further confusions, I propose that we start to remove the old code.
It
may break the some of the modules for one or two days. We can temporarily
remove such modules from the main build and add them back when they are
fixed.

Please let me know if you have any concerns.

Thanks,
Raymond



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

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi.. .what  about the workitem related to renaming the core-spi to include
'sca' for packages.  Is it a good time to do this ?  Thanks

- Venkat

On 5/4/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 5/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > There's been a lot of progress, things are starting to look good and
> most
> > things on the wiki page (
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> )
> >
> > look like they're nearing completion. So I think what we should do is
> > aim at
> > creating an SVN branch for the release around Tuesday next week, start
> > being
> > more controlled about what changes go into the branch and start
> > publishing
> > candidate distributions from that, then when we think it looks ok vote
> on
> > the final release candidate from that, hopefully by the end of next
> week.
> > Does this sound ok to everyone? It does mean most changes anyone wants
> in
> > should be tried to be committed by Tuesday.
> >
> > The latest distribution downloads to try out are available at:
> > http://people.apache.org/~antelder/tuscany/latest/
> >
> > There's now a Java-SCA-0.90 version in Jira so any bugs found or
things
> > people want to get done should be added there:
> >
>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312478
> >
> >
> >   ...ant
> >
>
> +1 from me. Like you said a lot of what we had on the Wiki are near
> completion. One of the most important items I think is to complete the
> clean up of the code base and simplify further some of our interfaces
> for extensions, but Tuesday looks reasonable to me.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Sounds like a good timescale to me. Gives time to finish the sample
builds
and readmes.

Simon

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi, please find my comments inline.

Thanks

- Venkat

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


Raymond Feng wrote:
> Hi,
>
> I tried a bit to rename some of the packages (not adding sca yet) but
> I just realized that it became a bit out of control with the flood of
> check-ins.
>
> Maybe the best way is that we agree on the naming convention for the
> core-spi and core and then have one person to do all the refactoring
> in one shot once we see a functionally stable code base.
>
> Thanks,
> Raymond
>
> - Original Message - From: "Venkata Krishnan"
> <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, May 04, 2007 10:48 PM
> Subject: Re: Status of Java SCA 0.90 release
>
>
>> Hi.. .what  about the workitem related to renaming the core-spi to
>> include
>> 'sca' for packages.  Is it a good time to do this ?  Thanks
>>
>> - Venkat
>>
>> On 5/4/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>>>
>>> On 5/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>> >
>>> > ant elder wrote:
>>> > > There's been a lot of progress, things are starting to look good
>>> and
>>> > most
>>> > > things on the wiki page (
>>> > >
>>> >
>>>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>>>
>>> > )
>>> > >
>>> > > look like they're nearing completion. So I think what we should
>>> do is
>>> > > aim at
>>> > > creating an SVN branch for the release around Tuesday next week,
>>> > > start
>>> > > being
>>> > > more controlled about what changes go into the branch and start
>>> > > publishing
>>> > > candidate distributions from that, then when we think it looks
>>> ok > > vote
>>> > on
>>> > > the final release candidate from that, hopefully by the end of
next
>>> > week.
>>> > > Does this sound ok to everyone? It does mean most changes anyone
>>> > > wants
>>> > in
>>> > > should be tried to be committed by Tuesday.
>>> > >
>>> > > The latest distribution downloads to try out are available at:
>>> > > http://people.apache.org/~antelder/tuscany/latest/
>>> > >
>>> > > There's now a Java-SCA-0.90 version in Jira so any bugs found or
>>> things
>>> > > people want to get done should be added there:
>>> > >
>>> >
>>>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312478
>>>
>>> > >
>>> > >
>>> > >   ...ant
>>> > >
>>> >
>>> > +1 from me. Like you said a lot of what we had on the Wiki are near
>>> > completion. One of the most important items I think is to complete
>>> the
>>> > clean up of the code base and simplify further some of our
interfaces
>>> > for extensions, but Tuesday looks reasonable to me.
>>> >
>>> > --
>>> > Jean-Sebastien
>>> >
>>> >
>>> >
-
>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>> >
>>> > Sounds like a good timescale to me. Gives time to finish the sample
>>> builds
>>> and readmes.
>>>
>>> Simon
>>>
>>

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 

Re: Axis2 binding status

[Venkata Krishnan]

I just tried and modules and samples build clean.  As Ant mentions there are
failures in itests.  Maybe you should do a clean build.

- Venkat

On 5/9/07, ant elder <[EMAIL PROTECTED]> wrote:


It builds ok for me, all the modules and samples build ok, there are a few
itest failures still. Those errors looks like it may be picking up some
old
version of one of the other modules.

   ...ant

On 5/9/07, Bert Lamb <[EMAIL PROTECTED]> wrote:
>
> Should I be able to build what is in the trunk for this binding right
> now?  I'm currently getting a compilation failure:
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ServiceBindingProvider.java:[66,74]
> type org.apache.tuscany.provider.ServiceBindingProvider does not take
> parameters
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[36,74]
> type org.apache.tuscany.provider.BindingProviderFactory does not take
> parameters
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[44,35]
> type org.apache.tuscany.provider.ReferenceBindingProvider does not
> take parameters
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[48,33]
> type org.apache.tuscany.provider.ServiceBindingProvider does not take
> parameters
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ReferenceBindingProvider.java:[50,78]
> type org.apache.tuscany.provider.ReferenceBindingProvider does not
> take parameters
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[39,35]
> cannot find symbol
> symbol  : class ProviderFactoryExtensionPoint
> location: package org.apache.tuscany.provider
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,8]
> cannot find symbol
> symbol  : class ProviderFactoryExtensionPoint
> location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator
>
>
>
D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\ap
> ache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,85] cannot find
> symbol
> symbol  : class ProviderFactoryExtensionPoint
> location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator
>
> -Bert
>
> On 5/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> > On 5/9/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm debugging the Axis2 binding to get the samples running so that
> > > we can put this back into the build.  I'm making good progress
> > > (just tracked down and fixed one bug) and I'll continue to work on
> > > this today.
> > >
> > >Simon
> >
> >
> > I've just committed some changes so a lot more of the tests are
passing
> now,
> > could you checkout the latest SVN code?
> >
> >...ant
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi Bert,

I had volunteered to do this, but then I am happy to let you take over.
Just in case you need a helping hand anytime around please let me know.
Thanks for volunteering.

- Venkat

On 5/8/07, Bert Lamb <[EMAIL PROTECTED]> wrote:


On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> - I'm not sure about the JSONRPC binding, wouldn't it be nice to have it
> too?

I'd be more than happy to work on the port of the JSONRPC binding, I
was waiting for the axis2 binding to get updated since that was the
binding I used as a template for the last time I ported the JSONRPC
binding.

The only problem is that I will be on vacation next week, so unless I
get a good axis2 binding to work from soon, I'm not sure I'll be able
to get the JSONRPC binding up and running by the end of this week.

-Bert

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

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

+1 for controlled commits.  If people will ensure no commits on Thursday
after about 24.00Hrs Pacific Time (US and Canada), I can go ahead and change
the core-spi packages to include 'sca'.  Ant, please let me know if there
are other things that I can help with.  I am also going to start looking at
getting the spec-api itest to work.

Thanks

- Venkat

On 5/9/07, ant elder <[EMAIL PROTECTED]> wrote:


On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Raymond Feng wrote:
> > Hi,
> >
> > I tried a bit to rename some of the packages (not adding sca yet) but
> > I just realized that it became a bit out of control with the flood of
> > check-ins.
> >
> > Maybe the best way is that we agree on the naming convention for the
> > core-spi and core and then have one person to do all the refactoring
> > in one shot once we see a functionally stable code base.
> >
> > Thanks,
> > Raymond
> >
> > - Original Message - From: "Venkata Krishnan"
> > <[EMAIL PROTECTED]>
> > To: 
> > Sent: Friday, May 04, 2007 10:48 PM
> > Subject: Re: Status of Java SCA 0.90 release
> >
> >
> >> Hi.. .what  about the workitem related to renaming the core-spi to
> >> include
> >> 'sca' for packages.  Is it a good time to do this ?  Thanks
> >>
> >> - Venkat
> >>
> >> On 5/4/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >>>
> >>> On 5/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >>> >
> >>> > ant elder wrote:
> >>> > > There's been a lot of progress, things are starting to look good
> >>> and
> >>> > most
> >>> > > things on the wiki page (
> >>> > >
> >>> >
> >>>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> >>>
> >>> > )
> >>> > >
> >>> > > look like they're nearing completion. So I think what we should
> >>> do is
> >>> > > aim at
> >>> > > creating an SVN branch for the release around Tuesday next week,
> >>> > > start
> >>> > > being
> >>> > > more controlled about what changes go into the branch and start
> >>> > > publishing
> >>> > > candidate distributions from that, then when we think it looks
> >>> ok > > vote
> >>> > on
> >>> > > the final release candidate from that, hopefully by the end of
> next
> >>> > week.
> >>> > > Does this sound ok to everyone? It does mean most changes anyone
> >>> > > wants
> >>> > in
> >>> > > should be tried to be committed by Tuesday.
> >>> > >
> >>> > > The latest distribution downloads to try out are available at:
> >>> > > http://people.apache.org/~antelder/tuscany/latest/
> >>> > >
> >>> > > There's now a Java-SCA-0.90 version in Jira so any bugs found or
> >>> things
> >>> > > people want to get done should be added there:
> >>> > >
> >>> >
> >>>
>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312478
> >>>
> >>> > >
> >>> > >
> >>> > >   ...ant
> >>> > >
> >>> >
> >>> > +1 from me. Like you said a lot of what we had on the Wiki are
near
> >>> > completion. One of the most important items I think is to complete
> >>> the
> >>> > clean up of the code base and simplify further some of our
> interfaces
> >>> > for extensions, but Tuesday looks reasonable to me.
> >>> >
> >>> > --
> >>> > Jean-Sebastien
> >>> >
> >>> >
> >>> >
> -
> >>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> > For additional commands, e-mail: [EMAIL PROTECTED]
> >>> >
> >>> > Sounds like a good timescale to me. Gives time to finish the
sample
> >>> builds
> >>> and readmes.
> >>>
> >>> Simon
> >>>
> >>
>
> There has been many commi

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Ok. I am starting with the renaming of the packages for the core-spi
module.  Thanks

- Venkat

On 5/11/07, ant elder <[EMAIL PROTECTED]> wrote:


+1 to starting with the package renames on Friday.

   ...ant

On 5/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> +1 for controlled commits.  If people will ensure no commits on Thursday
> after about 24.00Hrs Pacific Time (US and Canada), I can go ahead and
> change
> the core-spi packages to include 'sca'.  Ant, please let me know if
there
> are other things that I can help with.  I am also going to start looking
> at
> getting the spec-api itest to work.
>
> Thanks
>
> - Venkat
>
> On 5/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > >
> > > Raymond Feng wrote:
> > > > Hi,
> > > >
> > > > I tried a bit to rename some of the packages (not adding sca yet)
> but
> > > > I just realized that it became a bit out of control with the flood
> of
> > > > check-ins.
> > > >
> > > > Maybe the best way is that we agree on the naming convention for
the
> > > > core-spi and core and then have one person to do all the
refactoring
> > > > in one shot once we see a functionally stable code base.
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > - Original Message - From: "Venkata Krishnan"
> > > > <[EMAIL PROTECTED]>
> > > > To: 
> > > > Sent: Friday, May 04, 2007 10:48 PM
> > > > Subject: Re: Status of Java SCA 0.90 release
> > > >
> > > >
> > > >> Hi.. .what  about the workitem related to renaming the core-spi
to
> > > >> include
> > > >> 'sca' for packages.  Is it a good time to do this ?  Thanks
> > > >>
> > > >> - Venkat
> > > >>
> > > >> On 5/4/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >>>
> > > >>> On 5/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > >>> >
> > > >>> > ant elder wrote:
> > > >>> > > There's been a lot of progress, things are starting to look
> good
> > > >>> and
> > > >>> > most
> > > >>> > > things on the wiki page (
> > > >>> > >
> > > >>> >
> > > >>>
> > >
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> > > >>>
> > > >>> > )
> > > >>> > >
> > > >>> > > look like they're nearing completion. So I think what we
> should
> > > >>> do is
> > > >>> > > aim at
> > > >>> > > creating an SVN branch for the release around Tuesday next
> week,
> > > >>> > > start
> > > >>> > > being
> > > >>> > > more controlled about what changes go into the branch and
> start
> > > >>> > > publishing
> > > >>> > > candidate distributions from that, then when we think it
looks
> > > >>> ok > > vote
> > > >>> > on
> > > >>> > > the final release candidate from that, hopefully by the end
of
> > > next
> > > >>> > week.
> > > >>> > > Does this sound ok to everyone? It does mean most changes
> anyone
> > > >>> > > wants
> > > >>> > in
> > > >>> > > should be tried to be committed by Tuesday.
> > > >>> > >
> > > >>> > > The latest distribution downloads to try out are available
at:
> > > >>> > > http://people.apache.org/~antelder/tuscany/latest/
> > > >>> > >
> > > >>> > > There's now a Java-SCA-0.90 version in Jira so any bugs
found
> or
> > > >>> things
> > > >>> > > people want to get done should be added there:
> > > >>> > >
> > > >>> >
> > > >>>
> > >
> >
>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312478
> > > >>>
&g

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi.. I have made some progress with the renaming.  Since there are changes
across modules, I request that there are no commits till I get back on the
ML and state that is ok to commit.

Thanks

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Ok. I am starting with the renaming of the packages for the core-spi
module.  Thanks

- Venkat

On 5/11/07, ant elder < [EMAIL PROTECTED]> wrote:
>
> +1 to starting with the package renames on Friday.
>
>    ...ant
>
> On 5/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > +1 for controlled commits.  If people will ensure no commits on
> Thursday
> > after about 24.00Hrs Pacific Time (US and Canada), I can go ahead and
> > change
> > the core-spi packages to include 'sca'.  Ant, please let me know if
> there
> > are other things that I can help with.  I am also going to start
> looking
> > at
> > getting the spec-api itest to work.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 5/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Raymond Feng wrote:
> > > > > Hi,
> > > > >
> > > > > I tried a bit to rename some of the packages (not adding sca
> yet)
> > but
> > > > > I just realized that it became a bit out of control with the
> flood
> > of
> > > > > check-ins.
> > > > >
> > > > > Maybe the best way is that we agree on the naming convention for
> the
> > > > > core-spi and core and then have one person to do all the
> refactoring
> > > > > in one shot once we see a functionally stable code base.
> > > > >
> > > > > Thanks,
> > > > > Raymond
> > > > >
> > > > > - Original Message - From: "Venkata Krishnan"
> > > > > < [EMAIL PROTECTED]>
> > > > > To: 
> > > > > Sent: Friday, May 04, 2007 10:48 PM
> > > > > Subject: Re: Status of Java SCA 0.90 release
> > > > >
> > > > >
> > > > >> Hi.. .what  about the workitem related to renaming the core-spi
> to
> > > > >> include
> > > > >> 'sca' for packages.  Is it a good time to do this ?  Thanks
> > > > >>
> > > > >> - Venkat
> > > > >>
> > > > >> On 5/4/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > >>>
> > > > >>> On 5/4/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> wrote:
> > > > >>> >
> > > > >>> > ant elder wrote:
> > > > >>> > > There's been a lot of progress, things are starting to
> look
> > good
> > > > >>> and
> > > > >>> > most
> > > > >>> > > things on the wiki page (
> > > > >>> > >
> > > > >>> >
> > > > >>>
> > > >
> > >
> > 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
>
> > > > >>>
> > > > >>> > )
> > > > >>> > >
> > > > >>> > > look like they're nearing completion. So I think what we
> > should
> > > > >>> do is
> > > > >>> > > aim at
> > > > >>> > > creating an SVN branch for the release around Tuesday next
> > week,
> > > > >>> > > start
> > > > >>> > > being
> > > > >>> > > more controlled about what changes go into the branch and
> > start
> > > > >>> > > publishing
> > > > >>> > > candidate distributions from that, then when we think it
> looks
> > > > >>> ok > > vote
> > > > >>> > on
> > > > >>> > > the final release candidate from that, hopefully by the
> end of
> > > > next
> > > > >>> > week.
> > > > >>> > > Does this sound ok to everyone? It does mean most changes
> > anyone
> > > > >>> > > wants
> > > > >>> > in
> > > > >>> > > should be tried to be committed by Tuesday.
> &

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi, thank you all for being really patient.  This iteration of refactoring
is now over and committed.  But looks like I am going to come back with
similar requests if people are ok to name the other modules as well

Thanks

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi.. I have made some progress with the renaming.  Since there are changes
across modules, I request that there are no commits till I get back on the
ML and state that is ok to commit.

Thanks

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Ok. I am starting with the renaming of the packages for the core-spi
> module.  Thanks
>
> - Venkat
>
> On 5/11/07, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > +1 to starting with the package renames on Friday.
> >
> >...ant
> >
> > On 5/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > >
> > > +1 for controlled commits.  If people will ensure no commits on
> > Thursday
> > > after about 24.00Hrs Pacific Time (US and Canada), I can go ahead
> > and
> > > change
> > > the core-spi packages to include 'sca'.  Ant, please let me know if
> > there
> > > are other things that I can help with.  I am also going to start
> > looking
> > > at
> > > getting the spec-api itest to work.
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > > On 5/9/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > >
> > > > On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Raymond Feng wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I tried a bit to rename some of the packages (not adding sca
> > yet)
> > > but
> > > > > > I just realized that it became a bit out of control with the
> > flood
> > > of
> > > > > > check-ins.
> > > > > >
> > > > > > Maybe the best way is that we agree on the naming convention
> > for the
> > > > > > core-spi and core and then have one person to do all the
> > refactoring
> > > > > > in one shot once we see a functionally stable code base.
> > > > > >
> > > > > > Thanks,
> > > > > > Raymond
> > > > > >
> > > > > > - Original Message - From: "Venkata Krishnan"
> > > > > > < [EMAIL PROTECTED]>
> > > > > > To: < tuscany-dev@ws.apache.org>
> > > > > > Sent: Friday, May 04, 2007 10:48 PM
> > > > > > Subject: Re: Status of Java SCA 0.90 release
> > > > > >
> > > > > >
> > > > > >> Hi.. .what  about the workitem related to renaming the
> > core-spi to
> > > > > >> include
> > > > > >> 'sca' for packages.  Is it a good time to do this ?  Thanks
> > > > > >>
> > > > > >> - Venkat
> > > > > >>
> > > > > >> On 5/4/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > > >>>
> > > > > >>> On 5/4/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > wrote:
> > > > > >>> >
> > > > > >>> > ant elder wrote:
> > > > > >>> > > There's been a lot of progress, things are starting to
> > look
> > > good
> > > > > >>> and
> > > > > >>> > most
> > > > > >>> > > things on the wiki page (
> > > > > >>> > >
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > > 
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents
> >
> > > > > >>>
> > > > > >>> > )
> > > > > >>> > >
> > > > > >>> > > look like they're nearing completion. So I think what we
> > > should
> > > > > >>> do is
> > > > > >>> > > aim at
> > > > > >>> > > creating an SVN branch for the release around Tuesday
> > next
> > > week,
> > > > > >>> > > start
> > > > > >>> > > being
> > > > > >>> > > more contr

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi,

I am just about to start the next iteration of renaming.  So here is another
request to refrain from commits till I come back on the ML.  Thanks again
for co-operating :)

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi, thank you all for being really patient.  This iteration of
refactoring  is now over and committed.  But looks like I am going to come
back with similar requests if people are ok to name the other modules as
well

Thanks

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi.. I have made some progress with the renaming.  Since there are
> changes across modules, I request that there are no commits till I get back
> on the ML and state that is ok to commit.
>
> Thanks
>
> - Venkat
>
> On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED] > wrote:
> >
> > Ok. I am starting with the renaming of the packages for the core-spi
> > module.  Thanks
> >
> > - Venkat
> >
> > On 5/11/07, ant elder < [EMAIL PROTECTED]> wrote:
> > >
> > > +1 to starting with the package renames on Friday.
> > >
> > >...ant
> > >
> > > On 5/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > +1 for controlled commits.  If people will ensure no commits on
> > > Thursday
> > > > after about 24.00Hrs Pacific Time (US and Canada), I can go ahead
> > > and
> > > > change
> > > > the core-spi packages to include 'sca'.  Ant, please let me know
> > > if there
> > > > are other things that I can help with.  I am also going to start
> > > looking
> > > > at
> > > > getting the spec-api itest to work.
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > > > On 5/9/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Raymond Feng wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I tried a bit to rename some of the packages (not adding sca
> > > yet)
> > > > but
> > > > > > > I just realized that it became a bit out of control with the
> > > flood
> > > > of
> > > > > > > check-ins.
> > > > > > >
> > > > > > > Maybe the best way is that we agree on the naming convention
> > > for the
> > > > > > > core-spi and core and then have one person to do all the
> > > refactoring
> > > > > > > in one shot once we see a functionally stable code base.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Raymond
> > > > > > >
> > > > > > > - Original Message - From: "Venkata Krishnan"
> > > > > > > < [EMAIL PROTECTED]>
> > > > > > > To: < tuscany-dev@ws.apache.org>
> > > > > > > Sent: Friday, May 04, 2007 10:48 PM
> > > > > > > Subject: Re: Status of Java SCA 0.90 release
> > > > > > >
> > > > > > >
> > > > > > >> Hi.. .what  about the workitem related to renaming the
> > > core-spi to
> > > > > > >> include
> > > > > > >> 'sca' for packages.  Is it a good time to do this ?  Thanks
> > > > > > >>
> > > > > > >> - Venkat
> > > > > > >>
> > > > > > >> On 5/4/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > > > >>>
> > > > > > >>> On 5/4/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > > wrote:
> > > > > > >>> >
> > > > > > >>> > ant elder wrote:
> > > > > > >>> > > There's been a lot of progress, things are starting to
> > > look
> > > > good
> > > > > > >>> and
> > > > > > >>> > most
> > > > > > >>> > > things on the wiki page (
> > > > > > >>> > >
> > > > > > >>> >
> > > > > > >>>
> > > > > >
> > > > >
> > > > 
http://cwiki.apache.org/con

Re: Status of Java SCA 0.90 release

[Venkata Krishnan]

Hi all, thanks for putting up.  I am done with the renaming of the core
module.  Now you are free to commit as you will.

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

I am just about to start the next iteration of renaming.  So here is
another request to refrain from commits till I come back on the ML.  Thanks
again for co-operating :)

- Venkat

On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi, thank you all for being really patient.  This iteration of
> refactoring  is now over and committed.  But looks like I am going to come
> back with similar requests if people are ok to name the other modules as
> well
>
> Thanks
>
> - Venkat
>
> On 5/11/07, Venkata Krishnan < [EMAIL PROTECTED]> wrote:
> >
> > Hi.. I have made some progress with the renaming.  Since there are
> > changes across modules, I request that there are no commits till I get back
> > on the ML and state that is ok to commit.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 5/11/07, Venkata Krishnan <[EMAIL PROTECTED] > wrote:
> > >
> > > Ok. I am starting with the renaming of the packages for the core-spi
> > > module.  Thanks
> > >
> > > - Venkat
> > >
> > > On 5/11/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > >
> > > > +1 to starting with the package renames on Friday.
> > > >
> > > >...ant
> > > >
> > > > On 5/10/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > +1 for controlled commits.  If people will ensure no commits on
> > > > Thursday
> > > > > after about 24.00Hrs Pacific Time (US and Canada), I can go
> > > > ahead and
> > > > > change
> > > > > the core-spi packages to include 'sca'.  Ant, please let me know
> > > > if there
> > > > > are other things that I can help with.  I am also going to start
> > > > looking
> > > > > at
> > > > > getting the spec-api itest to work.
> > > > >
> > > > > Thanks
> > > > >
> > > > > - Venkat
> > > > >
> > > > > On 5/9/07, ant elder < [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > On 5/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > >
> > > > > > > Raymond Feng wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I tried a bit to rename some of the packages (not adding
> > > > sca yet)
> > > > > but
> > > > > > > > I just realized that it became a bit out of control with
> > > > the flood
> > > > > of
> > > > > > > > check-ins.
> > > > > > > >
> > > > > > > > Maybe the best way is that we agree on the naming
> > > > convention for the
> > > > > > > > core-spi and core and then have one person to do all the
> > > > refactoring
> > > > > > > > in one shot once we see a functionally stable code base.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Raymond
> > > > > > > >
> > > > > > > > - Original Message - From: "Venkata Krishnan"
> > > > > > > > < [EMAIL PROTECTED]>
> > > > > > > > To: < tuscany-dev@ws.apache.org>
> > > > > > > > Sent: Friday, May 04, 2007 10:48 PM
> > > > > > > > Subject: Re: Status of Java SCA 0.90 release
> > > > > > > >
> > > > > > > >
> > > > > > > >> Hi.. .what  about the workitem related to renaming the
> > > > core-spi to
> > > > > > > >> include
> > > > > > > >> 'sca' for packages.  Is it a good time to do this
> > > > ?  Thanks
> > > > > > > >>
> > > > > > > >> - Venkat
> > > > > > > >>
> > > > > > > >> On 5/4/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > > > > >>>
> > > > > > > >>> On 5/4/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]>
> > > > wrote:

Re: JavaOne Demo

[Venkata Krishnan]

Hi Sebastien, first thanks for doing all of this.  +1 for sca/demos/bigbank

- Venkat

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


Hi all,

I would like to commit the three modules that I have put together for
demos of Tuscany/SCA at JavaOne.

The demo is a variation of the BigBank scenario that we've been using in
Tuscany and some of the SCA documents to illustrate the SCA programming
model.

This is a sample banking application that takes your customer id and
first gets information on your checking, savings, and stock account,
gets stock prices from a stockquote service, converts it to a configured
currency using a bunch of calculator components and returns the total
balance of all your accounts.

The application is implemented as a set of SCA composites and components
wired together and running on different JVMs:

- A StockQuote Java component (returning random stock prices) providing
a StockQuote service with a Web Service binding.

- A Calculator composite containing a fancy Calculator assembled with 4
components written in different scripting languages (Ruby, Groovy,
Python and Javascript) implementing the 4 basic operations of a
calculator, providin a Calculator service with an RMI binding.

- An AccountData composite containing an AccountData Java component
returning account information, used as a nested composite with an SCA
default binding in the BigBank composite.

- A BigBank composite, containing an Account Java component wired to the
above components, implementing the logic to retrieve account data, the
stock quote info, perform a currency conversion and sum the balances of
your three accounts. The Account service is provided with both a Web
Service binding and a JSON-RPC binding.

- A simple J2SE client program for the Account service as well as a Web
2.0 client user interface using DOJO and JSON-RPC to call the Account
JSON_RPC service directly from your Web browser.

The demo can run from a command line with the J2SE client, or you can
deploy it to Tomcat and then run it from your Web browser.

I posted a diagram showing the SCA assembly for the demo on our Wiki
there: http://cwiki.apache.org/confluence/display/TUSCANY/JavaOne+Demo

This demo shows many aspects of SCA:
- Recursive SCA assembly using the SCA specification 1.0 syntax.
- Assembly of Java components and components written in 4 other languages.
- SCA Java annotations.
- Web Service, RMI and JSON-RPC bindings (plus the SCA default binding
used inside the composites).
- SCA components running on different servers in an SCA domain.
- An SCA client programming model to invoke services in the SCA domain.

Where do people think it should go? samples? demo? demo-javaone?

--
Jean-Sebastien


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

Re: Removing WorkContext

[Venkata Krishnan]

+1 from me as it seems to be much cleaner to me.

Thanks

- Venkat

On 5/12/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

The WorkContext was defined to carry some context such as the conversation
id, http session id and callback path over the thread local. And the
usages
are so messy in the code and nobody can really understand how it should be
used.

As part of the final push for clean SPIs, I propose that we remove the
WorkContext and work out a better context propagation story.

There are three cases that involves context propagations:

1) For Invokers on the invocation chain, the context should be exposed by
the Message SPI. We need to add things such as ConverstationID, To and
From
to the Message.

2) For an inbound service, the service binding provider (will be
responsible
for retrieving the context data from the protocol/transport layer and
makes
them available in the Message when it dispatches to the promoted
component.

3) Component implementation invokers should be responsible for passing the
context from the incoming Message to the implementation logic and the
proxy
or invoker for the references. The propagation should be local to the
component implementation types and we could provide some utilities such as
a
ThreadLocal if it helps.

4) For an outbound reference, the reference binding provider should take
the
context from the Message and marshal them into the protocol/transport
layer.

I did the first cut to remove the WorkContext and use ThreadLocal to pass
the context (used by callback at this moment) and the build is successful
with all modules, samples and itests.

Thoughts?

If there are no objections, I will check them in ASAP and use it as a base
for improvement.

Thanks,
Raymond


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

Re: Running RAT on Tuscany Distribution

[Venkata Krishnan]

Hi,

I updated from the repo this morning and built the distribution.  Then I
extracted the tuscany-sca-1.0-incubating-SNAPSHOT.zip and
tuscany-sca-1.0-incubating-SNAPSHOT-src.zip and run the Release Audit Tool
on the base directory of these extractions.  Here are the results of that
run : -

Binary Disb : http://people.apache.org/~svkrish/RAT_0.90/Bin_RAT.txt
Source Disb : http://people.apache.org/~svkrish/RAT_0.90/Src_RAT.txt

Some Observations :
--
1) The following files failed the tool from running.  They seem to be binary
files related to some lock information and serialized sessions:

Binary Disb:
tuscany-sca-1.0-incubating-SNAPSHOT\samples\helloworld-ws-reference\work\null\localhost\_\SESSIONS.ser
tuscany-sca-1.0-incubating-SNAPSHOT\samples\helloworld-ws-service\work\null\localhost\_\SESSIONS.ser
tuscany-sca-1.0-incubating-SNAPSHOT\samples\das-service-web\dastest\db.lck

Source Disb:
tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\das-service\src\test\resources\dastest\db.lck
tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\das-service-web\dastest\db.lck
tuscany-sca-1.0-incubating-SNAPSHOT-src\modules\http-tomcat\work\null\localhost\_\SESSIONS.ser
tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\helloworld-ws-reference\work\null\localhost\_\SESSIONS.ser
tuscany-sca-1.0-incubating-SNAPSHOT-src\samples\helloworld-ws-service\work\null\localhost\_\SESSIONS.ser

2) If you go to end of the .txt files you will get to see the locations that
RAT suspects for aberrations.

I have fixed all that I thought needs to be fixed and what you'll find are
the ones that I am not able to decide about fixing.  I'd be happy to take
suggestions on the right path of action and fix them as well.

Thanks

- Venkat



On 5/2/07, ant elder <[EMAIL PROTECTED]> wrote:


On 5/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I built the sca\distribution and extracted the contents of
> tuscany-sca-1.0-incubating-SNAPSHOT.zip  (binary disb) and
> tuscany-sca-1.0-incubating-SNAPSHOT-src.zip (src disb) found in the
target
> directory.
>
> I then ran the RAT tool on the base directory of these extractions.  RAT
> seemed have trouble with the following files...
>
> - samples\das-service\webclient\dastest\db.lck
> - modules\http-tomcat\work\null\localhost\_\SESSIONS.ser
>
> Skipping these two, the RAT report for the rest can be found in the
> following links.
>
> RAT on Binary Disb :
http://people.apache.org/~svkrish/RAT_M3/RAT_BIN.txt
> RAT on Src Disb :
http://people.apache.org/~svkrish/RAT_M3/RAT_SRC.txt
>
> I shall be taking a closer look at those reports and shall fix as much
as
> I
> can.
>
> Comments ?


Thats great thanks, it would be really helpful to get all the missing
licenses fixed. There's quite a few so just say if you need a hand.

   ...ant

Re: A convention for deployable composites, was: Web Application integration story

[Venkata Krishnan]

+1.  This really puts some certainity into what actually gets deployed.

- Venkat

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


ant elder wrote:
> Ok, i re-read this last email again [1] and i guess i missed the
> "...if we
> could make it work consistently, with JARs as well as WARs" bit
> before. I'm
> not sure I agree with that, why should WARs be hamstrung with a less
user
> friendly way of working just because jars can't work as easily? If we
can
> have this really simple approach working in WARs why not support it,
> its not
> like jars and wars are interchangeable?
>
>   ...ant
>
> [1]
>
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/[EMAIL 
PROTECTED]
>
>

A few more thoughts. I have 2 problems with this approach... but I think
your requirement is very valid and I have a proposal at the end of this
email :)

1. This approach doesn't work the same way in a JAR, a folder, a WAR, an
expanded Web app folder. I'm looking for consistency in the programming
model and any conventions we implement. We could probably get this
working with a JAR if SCADomain.newInstance() could take as a parameter
a class belonging to the SCA contribution which we could use to
determine its location, but that would be one more option and too many
options are just going to complicate the application developer's life IMO.

2. I find this approach a little too error prone and it may actually
complicate my life as an app developer in some cases. Here are a few fun
scenarios to illustrate that...

- I could start developing a contribution and place my deployable
composites at the root of the contribution, without an
sca-contribution.xml. Then at some point, let's imagine that I need an
sca-contribution.xml to import a WSDL or XSD for example, all of a
sudden I'm going to have to list all my composites in
sca-contribution.xml to get them deployed now (as the automatic
deployment behavior won't be available to me anymore). So something that
initially seemed simple, add an  of a namespace to a
contribution, will actually require more significant development work.
I'll have to open all composites, find their names and namespaces and
spend some time in my sca-contribution.xml to declare them.

- Another scenario, removing an sca-contribution.xml (because I don't
need any XML imports or exports anymore at some point for example) may
inadvertently expose all the .composites file at the root of my
contribution as deployables. So I would have to move them out of there.

- Another interesting one I think. SCA contributions can be used to
package implementation artifacts, .java, .scripts, and .composites for
example. Most of these contributions will not contribute any
deployables, and will not contain an sca-contribution.xml. Then I would
have to be really careful to not place any of these deployables at the
root of these contributions, to prevent them to be automatically added
to the SCA domain as deployables.

All of that doesn't sound too good to me, but I don't like to write XML
files either so, like you, I'd be happy to see a simple approach to just
place deployable .composite files in a well known location instead of
writing a page of angle brackets...

Now here's an idea, which I think could give you what you're looking for:

- Deployable .composite files could be placed in
META-INF/sca-deployables. We will consider all the files in that folder
as deployables.

- This folder could co-exist with a META-INF/sca-contribution.xml, and
it would be an extension of the  list in sca-contribution.xml.

- This would be supported in the same way in all contribution types,
JARs, WARs, folders, web app folders. We would just implement this
behavior once in the ContributionService.

I think this would give you what you're looking for (no XML, a
convention location for deployables). It makes clear that these are
deployables, doesn't generate more work, inconsistencies or surprises
when you add/remove an sca-contribution.xml file. It's also easy to
implement as it's very close to the previous code that we had in
ContributionService which used to add all composites as deployables.

Thoughts?

--
Jean-Sebastien


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

Re: Sample README - sample overview

[Venkata Krishnan]

This is now working in revision 538883.  Thanks.

On 5/17/07, Simon Laws <[EMAIL PROTECTED]> wrote:


OK, done at revision 538871.

On the subject of samples. I'm just adding the mission README and build
for
the jsonrpc sample. Does this work for you now?

Simon

Re: Tuscany Logo..

[Venkata Krishnan]

Hi, like the others I like Logo 1 but find the picture on the left to be out
of place - does not gel well with the rest of the image.  Also if 'Apache'
in 'Apache Tuscany' could be right aligned it would look a little better I
thought.

- Venkat

On 5/18/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


posted a new  logo. You'll find Logo1, Logo2, Logo 3

http://cwiki.apache.org/confluence/display/TUSCANY/TuscanyLogos

On 5/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> Haleh,
>
> As others have said, the right hand side is superb - keep it.
>
> The cypress image is a good idea, but the particular one that you have
> doesn't look effective when it is Icon sized - it's too detailed and
> fussy.  Better to have a simpler image with fewer, bolder trees.  I'll
> have a hunt to see if I can find one.
>
> Whoever put that image up of Van Gogh's painting will get us into
> copyright trouble - I suggest removing it ASAP !!
>
> The other image characteristic of Tuscany are bell towers, like the ones
> in Siena and Florence
>
>
> Yours, Mike.
>
> haleh mahbod wrote:
> > Here is another try. I moved the logos to this link:
> >
> > http://cwiki.apache.org/confluence/display/TUSCANY/TuscanyLogos
> >
> >
> > On 5/17/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> snip
> >>
> >> >
> >> >  If yes, I'll go ahead and add it to the website ( I'll need help
for
> >> > doing this correctly please ).
> >> >
> >>
> >>
> >> If you want to put a logo up on the site in place of the confluence
> logo
> >> (the man type thing with a C wrapped round him) then there is an
option
> >> under space admin to set the space logo.
> >>
> >> Simon
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

[Venkata Krishnan]

Hi,

I've give the distros a shot on windows xp.

- The src disb. builds clean
- The tried all the samples from the binary dist just following the
READMEs.  Like the others I do find the README for the rmi samples out of
sync and also the  crud-client app does not run.  But all the other samples
run cleanly.

With the rmi samples I am quite surprised because during the code chill time
period I think I fixed the samples to run as per the README.  The RMI Server
sample used a RMI Client ( an not a SCA Reference) and similarly the RMI
Reference sample used a RMI Server (not a SCA Service) and each was pretty
compact in itself.  I am not sure about where it changed after that.

Anyways, looking at it overall I'd like to give a '+1' based on the
following: -
- Though I agree that this is not the most perfect of packages I still feel
none of the glitches are paralysing.  For example, even if the rmi samples
did not work as per the README they contain all that is required to run them
and then there are a whole bunch of other samples that work cleanly
demonstrating SCA and the extensions we offer to date.
- Its been a while since we released and this one has fundamental changes to
how things were a few months ago.  Getting this release out asap is good for
us and to users so that there is enough time for trying out and giving
feedback that can be picked up for our next release which I guess is going
to be in another few weeks from now.
- Finally this is just about 0.90 and I am ok to have the sort of issues
that have been identified with it.  I am happy to know what we need to watch
for in our next release.

Thanks

- Venkat



On 5/21/07, ant elder <[EMAIL PROTECTED]> wrote:


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

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

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

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

Thanks in advance,

   ...ant

Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi,

I have started to look at getting our wiki to look a bit like a website and
am working a bit with Confluence to figure out how this can be achieved.

I looked up a couple of sites for ideas and quite liked the Geronimo site
exported from the wiki - http://cwiki.apache.org/GMOxSITE.  I am going to
see if we can borrow the templates from Geronimo, folks to start with.  Also
if we have to update the template for the Tuscany Space on the Apache
Confluence Server, we need administration access on that server.  Does
anybody have this on Tuscany Team?

If I manage to get the templates going then here is what I intend to do ...
- Get the navigation bar of our wiki site
http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a
classic navigation bar with menu items
- Ensure that all pages have the menu bars.  Right now there are pages that
do not have this Navigation bar
- Export the wiki thro the Geronimo template and .css for first iteration
and help to get a different look on http://cwiki.apache.org/TUSCANY/ than
what exists today.  As we move forward we can customize the template and
.css as people might fancy.

I hope to be able to get all this done for people to get a feel of it
tomorrow.

Thanks

- Venkat

Re: Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi Simon,
 I mean the ones on the left.

- Venkat


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


Hi Venkat, sounds great. Can I just ask, when you say...

snip
> - Get the navigation bar of our wiki site
> http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a
> classic navigation bar with menu items
>

Do you mean the one on the left hand side or the tabs at the top or
something else?

Simon

Re: Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi Hernan,

This is really great!.  Its just about the help that I have been looking
for.  Since we have a release round the corner we need to have the website
up quickly as that's our shop window to the world.  So I am going to
certainly take your help for Confluence Admin.

The other link that you have attached is also quite useful and seems like in
the next iteration we will certainly be exploring having multiple spaces.

Where is the template that you have mentioned?  I don't see any attachment
here.  Maybe you must zip and attach otherwise the MLs skip the attachments
from what I know.

I shall update the wiki now so that all pages have menus.  After this I
shall work on the template (maybe you'd send it by then ;-)) and keep things
in shape for you to simply go over and export.

Thank you so much for helping in this.

- Venkat

On 5/24/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:


Hi Venkat,
I'm helping with the documentation and web site for the Geronimo project.
We recently moved the authoring of our web site to Confluence, now it is a
lot easier to maintain.

If you folks don't have a Confluence admin I'll be happy to help updating
the templates.
I just sent you a sample template for the autoexport plugin, you may want
to make some updates to it ;-)

Let me know if you get stuck anywhere with the template. Once you have it
ready for the first test run let me know and I can update it in Confluence
so everybody else can see how the website could look like ;-)

Not sure how is the process to get an admin account in confluence,
probably sending a req to infra@ or opening a JIRA, don't really know.

Keep in mind that if you folks decide to implement this approach you will
need to have more control on the TUSCANY space in Confluence. For the
Geronimo website (GMOxSITE space) we have only project's committers with
edit access. If you guys have only one space then you should start planning
for having one for the web site and at least another for the formal wiki.
Does that make sense!?

Here is a doc I put together for how the Geronimo spaces (documentation
and web site) are organized.


http://cwiki.apache.org/geronimo/geronimo-cwiki-documentation-architecture.html

HTH

Cheers!
Hernan

Venkata Krishnan wrote:
> Hi,
>
> I have started to look at getting our wiki to look a bit like a website
and
> am working a bit with Confluence to figure out how this can be achieved.
>
> I looked up a couple of sites for ideas and quite liked the Geronimo
site
> exported from the wiki - http://cwiki.apache.org/GMOxSITE.  I am going
to
> see if we can borrow the templates from Geronimo, folks to start with.
> Also
> if we have to update the template for the Tuscany Space on the Apache
> Confluence Server, we need administration access on that server.  Does
> anybody have this on Tuscany Team?
>
> If I manage to get the templates going then here is what I intend to do
...
> - Get the navigation bar of our wiki site
> http://cwiki.apache.org/confluence/display/TUSCANY/Home to look like a
> classic navigation bar with menu items
> - Ensure that all pages have the menu bars.  Right now there are pages
that
> do not have this Navigation bar
> - Export the wiki thro the Geronimo template and .css for first
iteration
> and help to get a different look on http://cwiki.apache.org/TUSCANY/than
> what exists today.  As we move forward we can customize the template and
> .css as people might fancy.
>
> I hope to be able to get all this done for people to get a feel of it
> tomorrow.
>
> Thanks
>
> - Venkat
>

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

Re: [Fwd: Re: Website / Wiki was:Tuscany Logo..]

[Venkata Krishnan]

Thanks Hernan.  I have uploaded the images and the .css to my
apache.people.org account and have updated the template and .css files to
reflect the URL.

I have updated the modified template to the wiki.  Please let me know if
everythings ok.

- Venkat

On 5/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:


Ok, I saw the changes in the color schema you folks are using on the menus
and updated the css.

I would propose to keep track of all these changes here


http://cwiki.apache.org/confluence/display/TUSCANY/Autoexport+plugin+template

let's use some timestamp on the file names for easy tracking.

I'll be updating the template soon

Cheers!
Hernan

Hernan Cunico wrote:
> Great, I just added a child page and included the attachment there, here
> is the link
>
>
http://cwiki.apache.org/confluence/display/TUSCANY/Autoexport+plugin+template
>
>
> Cheers!
> Hernan
>
> haleh mahbod wrote:
>> Hi Hernan,
>> Thank you for your help.
>> You can use this sandbox location for uploading the template files to
the
>> wiki. Eventualy this should be checked in I suppose.
>> http://cwiki.apache.org/confluence/display/TUSCANY/Sandbox+for+website
>>
>> Haleh
>>
>> On 5/24/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>>>
>>> ahhh, fourth attempt now. This time I intentionally removed the
>>> attachment
>>> to see if it makes it through the spam blocker
>>>
>>> Is there a place you the wiki I could upload the zip with the
template?
>>>
>>> Cheers!
>>> Hernan
>>>
>>>  Original Message 
>>> Subject: Re: Website / Wiki was:Tuscany Logo..
>>> Date: Thu, 24 May 2007 09:12:46 -0400
>>> From: Hernan Cunico <[EMAIL PROTECTED]>
>>> To: tuscany-dev@ws.apache.org
>>> References: <
[EMAIL PROTECTED]
>>> ><[EMAIL PROTECTED]> <
>>> [EMAIL PROTECTED]>
>>>
>>> ahhh, all these years and still miss the attachments :-P
>>>
>>> I took the liberty to do some more updates to the template so you can
>>> actually see it working with a "Tuscany theme" ;-)
>>> I'm including some images and the css we use in Geronimo so you can
see
>>> how to do some additional filtering from all the data Confluence
>>> provides.
>>> More specifically, the "Added by...Last edited by ..." are chopped
>>> off on
>>> the template. If you guys are using "News" on Confluence, some of
>>> that info
>>> is chopped off on the .css
>>>
>>> To have a better idea of what I mean compare these two links, the
first
>>> one is just pure, unaltered Confluence content. The second is after
>>> applying
>>> the template and css.
>>>
>>> http://cwiki.apache.org/confluence/display/GMOxSITE
>>>
>>> http://cwiki.apache.org/GMOxSITE
>>>
>>> Keep in mind the user permissions, if this will become your main web
>>> site
>>> then only committers should have edit access.
>>>
>>> HTH
>>>
>>> Cheers!
>>> Hernan
>>>
>>>
>>> Venkata Krishnan wrote:
>>> > Hi Hernan,
>>> >
>>> > This is really great!.  Its just about the help that I have been
>>> looking
>>> > for.  Since we have a release round the corner we need to have the
>>> website
>>> > up quickly as that's our shop window to the world.  So I am going to
>>> > certainly take your help for Confluence Admin.
>>> >
>>> > The other link that you have attached is also quite useful and seems
>>> > like in
>>> > the next iteration we will certainly be exploring having multiple
>>> spaces.
>>> >
>>> > Where is the template that you have mentioned?  I don't see any
>>> attachment
>>> > here.  Maybe you must zip and attach otherwise the MLs skip the
>>> attachments
>>> > from what I know.
>>> >
>>> > I shall update the wiki now so that all pages have menus.  After
>>> this I
>>> > shall work on the template (maybe you'd send it by then ;-)) and
keep
>>> > things
>>> > in shape for you to simply go over and export.
>>> >
>>> > Thank you so much for helping in this.
>>> >
>>> > - Venkat
>>> >
>>> > On 5/24/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> Hi Venkat,
>>> >> I'm helping

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

[Venkata Krishnan]

Hi,

I tried building the source disb and the samples from the binary and all
works well.

+1 for the release.

Thanks

- Venkat


On 5/24/07, ant elder <[EMAIL PROTECTED]> wrote:


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

The artifacts are available for review at:
http://people.apache.org/~antelder/tuscany/0.90-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.90-incubating/

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

Thanks in advance,

   ...ant

Re: [Fwd: Re: Website / Wiki was:Tuscany Logo..]

[Venkata Krishnan]

Hernan, thank you so much.  It all looks really good now.  Lets hear what
othes have to say ;-)

- Venkat

On 5/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:


I just attached the "edit" image to match the color scheme and also ran
the export, take a pick at to how it is starting to look like :D

http://cwiki.apache.org/TUSCANY/

Cheers!
Hernan

Venkata Krishnan wrote:
> Thanks Hernan.  I have uploaded the images and the .css to my
> apache.people.org account and have updated the template and .css files
to
> reflect the URL.
>
> I have updated the modified template to the wiki.  Please let me know if
> everythings ok.
>
> - Venkat
>
> On 5/25/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>>
>> Ok, I saw the changes in the color schema you folks are using on the
>> menus
>> and updated the css.
>>
>> I would propose to keep track of all these changes here
>>
>>
>>
http://cwiki.apache.org/confluence/display/TUSCANY/Autoexport+plugin+template
>>
>>
>> let's use some timestamp on the file names for easy tracking.
>>
>> I'll be updating the template soon
>>
>> Cheers!
>> Hernan
>>
>> Hernan Cunico wrote:
>> > Great, I just added a child page and included the attachment there,
>> here
>> > is the link
>> >
>> >
>>
http://cwiki.apache.org/confluence/display/TUSCANY/Autoexport+plugin+template
>>
>> >
>> >
>> > Cheers!
>> > Hernan
>> >
>> > haleh mahbod wrote:
>> >> Hi Hernan,
>> >> Thank you for your help.
>> >> You can use this sandbox location for uploading the template files
to
>> the
>> >> wiki. Eventualy this should be checked in I suppose.
>> >>
http://cwiki.apache.org/confluence/display/TUSCANY/Sandbox+for+website
>> >>
>> >> Haleh
>> >>
>> >> On 5/24/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> ahhh, fourth attempt now. This time I intentionally removed the
>> >>> attachment
>> >>> to see if it makes it through the spam blocker
>> >>>
>> >>> Is there a place you the wiki I could upload the zip with the
>> template?
>> >>>
>> >>> Cheers!
>> >>> Hernan
>> >>>
>> >>>  Original Message 
>> >>> Subject: Re: Website / Wiki was:Tuscany Logo..
>> >>> Date: Thu, 24 May 2007 09:12:46 -0400
>> >>> From: Hernan Cunico <[EMAIL PROTECTED]>
>> >>> To: tuscany-dev@ws.apache.org
>> >>> References: <
>> [EMAIL PROTECTED]
>> >>> ><[EMAIL PROTECTED]> <
>> >>> [EMAIL PROTECTED]>
>> >>>
>> >>> ahhh, all these years and still miss the attachments :-P
>> >>>
>> >>> I took the liberty to do some more updates to the template so you
can
>> >>> actually see it working with a "Tuscany theme" ;-)
>> >>> I'm including some images and the css we use in Geronimo so you can
>> see
>> >>> how to do some additional filtering from all the data Confluence
>> >>> provides.
>> >>> More specifically, the "Added by...Last edited by ..." are chopped
>> >>> off on
>> >>> the template. If you guys are using "News" on Confluence, some of
>> >>> that info
>> >>> is chopped off on the .css
>> >>>
>> >>> To have a better idea of what I mean compare these two links, the
>> first
>> >>> one is just pure, unaltered Confluence content. The second is after
>> >>> applying
>> >>> the template and css.
>> >>>
>> >>> http://cwiki.apache.org/confluence/display/GMOxSITE
>> >>>
>> >>> http://cwiki.apache.org/GMOxSITE
>> >>>
>> >>> Keep in mind the user permissions, if this will become your main
web
>> >>> site
>> >>> then only committers should have edit access.
>> >>>
>> >>> HTH
>> >>>
>> >>> Cheers!
>> >>> Hernan
>> >>>
>> >>>
>> >>> Venkata Krishnan wrote:
>> >>> > Hi Hernan,
>> >>> >
>> >>> > This is really great!.  Its just about the help that I have been
>> >>> looking
>> >>> > for.  Since

Wiki cleanup : was : Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi,

Since we now export the wiki content for our website, we need to follow some
guidelines from now on when adding content to the wiki.

1) First we need to steam line our menus to follow some scheme.  for example
have one top level menu set that has General, Tuscany SCA , SDO and DAS (as
we have it now).  So all pages that are general will have these options in
the navigation bar on the left.  Once into SCA or SDO or DAS we could have
another set of menu options for each with probably the General always
tagging on so that the user can get back to Home or other generic things.
All pages falling under SCA (say) should have the same set of options unless
we have a sub-item with SCA that gets to have lots of options and hence must
have its own menu - for example Java SCA.  When zeroing on the menu options
we have to make sure we only have general things there.  For example
architecture docs, programming guides, release process docs could all go
under 'Documentation' and the documentation page can provide a link to all
the documents as its first page instead of each of the docs featuring as a
menu item.

2) I have created a separate hierarchy of pages for Menus.  We must not
hardcode or embed menus inside pages.  Its good to create separate Menu
Pages and then include them the various content pages.  And then when
creating a Menu Page ensure it goes into the Menus hierarchy and does not
get mixed with content pages

3) Once having created a Menu Page it would be good to go over and create a
template page using that menu.  For this you need to go to the 'Template'
tab in the 'Browse Space' page and add a template.  In the template can
typically contain the section, column and the include macro for the Menu.
Once a template is created new pages can be created from this template and
these pages will readily have the menus embeded in them with just the page
content to be filled out. This will help in avoind cut/pase of menus in each
page.

4) When composing content from now on we have to use 'Heading Styles' to
demarcate various portions of the content.  We could use h1, h2... h5 to
create a hierarchy in the content.  Other than heading styles we must avoid
other ways of creating sections in the content to show some sort of
hierarchy.  Having the content done this way could lead to a cleaner export
to the website using stylesheets.

5) I have moved a whole bunch of pages to a separate hierarchy called 'To Be
Deleted'.  It would good if people can take a look at them as see if its
fine.  Also if you find anything else that must be deleted simply make the
parent of that page as 'To Be Deleted'.  We will delete all of these pages
in a few weeks.

6) The banner portion looks empty but for the logo in the left end.  It
would be good to have that space filled with something ;-)

So thats as much I can recollect on things that I wanted to share.  If
anybody has more to add to this you are welcome.

Thanks

- Venkat

Re: Wiki cleanup : was : Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi Ant,

Ideally I'd imagine a menu item titled 'Documentation' under 'SCA Java' or
under 'Tuscany SCA'.  Clicking on this will open up a page that lists all
the documentations under SCA Java.  One of the links in that list will
probably be 'Tuscany Architecture and Programming Model'.   Clicking this
will open a page that will have some introductory content and then a list of
links to various aspects of the architecture and prog. model.  One of the
the links would be 'Tuscany Script Implementation Extension'.

So the trail would be Tuscany SCA->SCA Java->Documentation->Tuscany
Archp->Tuscany Extensions->Tuscany Script Implementation Extension.  If you
also think the above organization is reasonable then we probably have to
creating the missing things in that trail.

Assuming we have all that in place then we'd probably have a 'SCA Java Menu
page' and a template page for it.  Right now there is menu page for SCA Java
but we need to whet that a bit.

Having said all that, let me get to what you might want to do for <
implementatoin.script> for now... Right now I have created a template in
http://cwiki.apache.org/confluence/pages/templates/listpagetemplates.action?key=TUSCANYnamed
'Java SCA'.  Just click on the 'create page from template' option and
a page with the Java SCA menu embeded will be created where you can add the
content.

Hope this long winding reply helps :)

- Venkat

On 5/25/07, ant elder <[EMAIL PROTECTED]> wrote:


On 5/25/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Since we now export the wiki content for our website, we need to follow
> some
> guidelines from now on when adding content to the wiki.
>
> 1) First we need to steam line our menus to follow some scheme.  for
> example
> have one top level menu set that has General, Tuscany SCA , SDO and DAS
> (as
> we have it now).  So all pages that are general will have these options
in
> the navigation bar on the left.  Once into SCA or SDO or DAS we could
have
> another set of menu options for each with probably the General always
> tagging on so that the user can get back to Home or other generic
things.
> All pages falling under SCA (say) should have the same set of options
> unless
> we have a sub-item with SCA that gets to have lots of options and hence
> must
> have its own menu - for example Java SCA.  When zeroing on the menu
> options
> we have to make sure we only have general things there.  For example
> architecture docs, programming guides, release process docs could all go
> under 'Documentation' and the documentation page can provide a link to
all
> the documents as its first page instead of each of the docs featuring as
a
> menu item.
>
> 2) I have created a separate hierarchy of pages for Menus.  We must not
> hardcode or embed menus inside pages.  Its good to create separate Menu
> Pages and then include them the various content pages.  And then when
> creating a Menu Page ensure it goes into the Menus hierarchy and does
not
> get mixed with content pages
>
> 3) Once having created a Menu Page it would be good to go over and
create
> a
> template page using that menu.  For this you need to go to the
'Template'
> tab in the 'Browse Space' page and add a template.  In the template can
> typically contain the section, column and the include macro for the
Menu.
> Once a template is created new pages can be created from this template
and
> these pages will readily have the menus embeded in them with just the
page
> content to be filled out. This will help in avoind cut/pase of menus in
> each
> page.
>
> 4) When composing content from now on we have to use 'Heading Styles' to
> demarcate various portions of the content.  We could use h1, h2... h5 to
> create a hierarchy in the content.  Other than heading styles we must
> avoid
> other ways of creating sections in the content to show some sort of
> hierarchy.  Having the content done this way could lead to a cleaner
> export
> to the website using stylesheets.
>
> 5) I have moved a whole bunch of pages to a separate hierarchy called
'To
> Be
> Deleted'.  It would good if people can take a look at them as see if its
> fine.  Also if you find anything else that must be deleted simply make
the
> parent of that page as 'To Be Deleted'.  We will delete all of these
pages
> in a few weeks.
>
> 6) The banner portion looks empty but for the logo in the left end.  It
> would be good to have that space filled with something ;-)
>
> So thats as much I can recollect on things that I wanted to share.  If
> anybody has more to add to this you are welcome.
>
> Thanks
>
> - Venkat
>

Not sure I understand all this so probably the best way is to try to add
something...I want to make a page documenting  so i
guess that goes in "Java SCA" somewhere and is linked to from
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Subproject,
could you give a brief outline of how and where i should do that?

   ...ant

Re: Wiki cleanup : was : Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

HI Haleh,

There isn't a 'Documentation' menu item.   Thats what I am talking about
getting our menus organized.  Now there is a 'Guides' menu set where I think
all the docs are being linked.

- Venkat

On 5/25/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Hi Venkat,
I must be looking at the wrong place. I don't see documentation when I go
to
SCA Java. Instead I see the SDO and DAS links on the SCA java page. Am I
looking at the right place?

[1]:
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Subproject

On 5/25/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> Thanks, thats just what I needed. I've started doing this at
>
> http://cwiki.apache.org/confluence/display/TUSCANY/implementation.script
>
> Not sure about the page name, is there some format it should use that
> includes Java and SCA in the  page name?
>
>...ant
>
> On 5/25/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ant,
> >
> > Ideally I'd imagine a menu item titled 'Documentation' under 'SCA
Java'
> or
> > under 'Tuscany SCA'.  Clicking on this will open up a page that lists
> all
> > the documentations under SCA Java.  One of the links in that list will
> > probably be 'Tuscany Architecture and Programming Model'.   Clicking
> this
> > will open a page that will have some introductory content and then a
> list
> > of
> > links to various aspects of the architecture and prog. model.  One of
> the
> > the links would be 'Tuscany Script Implementation Extension'.
> >
> > So the trail would be Tuscany SCA->SCA Java->Documentation->Tuscany
> > Archp->Tuscany Extensions->Tuscany Script Implementation
Extension.  If
> > you
> > also think the above organization is reasonable then we probably have
to
> > creating the missing things in that trail.
> >
> > Assuming we have all that in place then we'd probably have a 'SCA Java
> > Menu
> > page' and a template page for it.  Right now there is menu page for
SCA
> > Java
> > but we need to whet that a bit.
> >
> > Having said all that, let me get to what you might want to do for <
> > implementatoin.script> for now... Right now I have created a template
in
> >
> >
>
http://cwiki.apache.org/confluence/pages/templates/listpagetemplates.action?key=TUSCANYnamed
> > 'Java SCA'.  Just click on the 'create page from template' option and
> > a page with the Java SCA menu embeded will be created where you can
add
> > the
> > content.
> >
> > Hope this long winding reply helps :)
> >
> > - Venkat
> >
> > On 5/25/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On 5/25/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Since we now export the wiki content for our website, we need to
> > follow
> > > > some
> > > > guidelines from now on when adding content to the wiki.
> > > >
> > > > 1) First we need to steam line our menus to follow some
scheme.  for
> > > > example
> > > > have one top level menu set that has General, Tuscany SCA , SDO
and
> > DAS
> > > > (as
> > > > we have it now).  So all pages that are general will have these
> > options
> > > in
> > > > the navigation bar on the left.  Once into SCA or SDO or DAS we
> could
> > > have
> > > > another set of menu options for each with probably the General
> always
> > > > tagging on so that the user can get back to Home or other generic
> > > things.
> > > > All pages falling under SCA (say) should have the same set of
> options
> > > > unless
> > > > we have a sub-item with SCA that gets to have lots of options and
> > hence
> > > > must
> > > > have its own menu - for example Java SCA.  When zeroing on the
menu
> > > > options
> > > > we have to make sure we only have general things there.  For
example
> > > > architecture docs, programming guides, release process docs could
> all
> > go
> > > > under 'Documentation' and the documentation page can provide a
link
> to
> > > all
> > > > the documents as its first page instead of each of the docs
> featuring
> > as
> > > a
> > > > menu item.
> > > >
> > > > 2) I have created a separate hierarchy of pages for Menus.  We
must
> > no

Re: Wiki cleanup : was : Website / Wiki was:Tuscany Logo..

[Venkata Krishnan]

Hi Hernan, thanks :).  I have refreshed the .css.

- Venkat

On 5/26/07, Hernan Cunico <[EMAIL PROTECTED]> wrote:


I updated the template and css and attached them here.

http://cwiki.apache.org/TUSCANY/autoexport-plugin-template.html

default_2007-05-25.zip
TUSCANY_template_2007_5_25_v2.zip

I already applied the autoexport template but I don't have access for
updating the css.
Venkat, I think that it's your call ;-)

Some of the changes to the style sheet include:
- Applied the same color schema to all title headers (h1..h5) for
consistency
- Corrected the blank spaces between titles
- Corrected the spacing for the content within the menu boxes

It looks a lot better now.

Cheers!
Hernan

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