Re: Fixes for Tuscany SCA Java 0.91 RC4?

[ant elder]

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


...


and other bindings that don't support references) break
when initializing self references



Isn't this a more general problem with the way self references are handle
right now? What was the fix that was done for this, I can't see any commit
comments mentioning it?

  ...ant

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I'd like some info on what I need to edit in the platform.properties.
Particularly:

platform.compiler-definition=g++m32
platform=rhas4u4_gcc346

One good thing about automake is that it detects your
platform/compiler etc automatically.

Cheers,


On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

I put together some documentation for using ant with TuscanySCA Native.

How's this?


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]




Using ant to build TuscanySCA Native



1. Required Software to build TuscanySCA Native with ant:

Ant:
   Ant comes installed with almost all Linux distributions
   version 1.6 or later
   Download: http://ant.apache.org/

antcontrib:
   version 1.0b3 or later
   Download: http://ant-contrib.sourceforge.net/

antcontrib cpptasks.jar
   version 1.0b4 or later
   Download: http://ant-contrib.sourceforge.net/
   Information: http://ant-contrib.sourceforge.net/cc.html


2. Installation Instructions:

Linux
-

Make sure JAVA_HOME is set before starting.

Install ant according to http://ant.apache.org/manual/index.html.

Set the ANT_HOME variable to the directory where you install ant.
export ANT_HOME="/home/you/ant"

Add $ANT_HOME/bin to your path.
export PATH="${PATH}:${ANT_HOME}/bin"

Optional ant tasks, such as antcontrib and cpptasks, should be installed
in $ANT_HOME/lib
So place the antcontrib and cpptasks jars there.

If you dont have write access to $ANT_HOME/lib, do the following:
- create ${user.home}/.ant/lib
- place the jars here

Avoid adding optional ant tasks to your classpath, this is problematic.

Windows
---

Make sure JAVA_HOME is set before starting.

Install ant according to http://ant.apache.org/manual/index.html.

Set the ANT_HOME variable to the directory where you install ant.
set ANT_HOME=c:\ant

Add %ANT_HOME%\bin to your path.
set PATH=%PATH%;%ANT_HOME%\bin

Optional ant tasks, such as antcontrib and cpptasks, should be installed
in %ANT_HOME%\lib
So place the antcontrib and cpptasks jars there.

If you dont have write access to %ANT_HOME%\lib, do the following:
- create ${user.home}\.ant\lib
- place the jars here

Avoid adding optional ant tasks to your classpath, this is problematic.





-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 17, 2007 1:24 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Thanks Brady. I'll take a look at this. We will need doc as to what the
dependencies are (cpptasks etc) and any configuration that is needed.

Cheers,

On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> For anyone interested, I uploaded another patch for this JIRA that
> makes it work better for windows.
>
>tuscanySCAnative_ant_update1.tar.gz
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
> 
>
>
>
> -Original Message-
> From: Brady Johnson [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 16, 2007 10:46 AM
> To: tuscany-dev@ws.apache.org
> Subject: [SCA Native] preliminary ant build
>
> Hello,
>
> This may be the second time you receive this email, the first time I
> sent it with an attachment, which I later realized that this dist list

> may reject. So here it is again, w/o the attachment. I created a JIRA
> and put the attachment there:
>
>https://issues.apache.org/jira/browse/TUSCANY-1438
>
> According to a previous thread titled "[SCA Native] next release
> content
> [was: Tuscany roadmap]" (I didnt want to add another "was" redirection
> ;) ), I have prepared ant build scripts for cpp/sca/runtime/core.
>
> The tar.gz file attached to the jira should just "overlay" onto the
> tuscany SCA cpp source code directory structure. It consists of the
> following files:
>
> /
>  |
>  | build.xml
>  |
>  | antscripts/
>  | |
>  | | compilers.xml
>  | | compile-targets.xml
>  | | platform.properties
>  |
>  | runtime/core/src/build.xml
>
> In order to use it, you will need to modify the platform.properties
> file. This will later be taken care of by either configure, or maybe
> just an install script.
>
> Currently it compiles and links runtime/core/src/tuscany/sca {core,
> extension, model, util} and creates libtuscany_sca.so. The install
> target installs the lib and the headers from those src directories to
> the install directory specified in platform.properties.
>
> Give it a spin and let me know what you think. It shouldnt take much
> to finish it for the rest of tuscany cpp.
>
> If it works out, we can then discuss how to configure
> platform.properties.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
> 
>
> 

[jira] Assigned: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson reassigned TUSCANY-1110:
---

Assignee: Kelvin Goodson

> Improve the performance of TypeHelperImpl.getType(Class)
> 
>
> Key: TUSCANY-1110
> URL: https://issues.apache.org/jira/browse/TUSCANY-1110
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Raymond Feng
>Assignee: Kelvin Goodson
> Fix For: Java-SDO-1.0
>
> Attachments: 1110.patch, 1110.patch2
>
>
> In the SDO databinding for SCA, we need to introspect a java class/interface 
> to figure out the corresponding SDO type. Looking into the code, there is a 
> TODO comment:
> //TODO more efficient implementation ... this is a really bad one!
> Do you plan to provide a more efficient impl :-)?
> Thanks,
> Raymond

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-1110.
-

Resolution: Fixed

2nd patch applied to trunk and branch

> Improve the performance of TypeHelperImpl.getType(Class)
> 
>
> Key: TUSCANY-1110
> URL: https://issues.apache.org/jira/browse/TUSCANY-1110
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-Next
>Reporter: Raymond Feng
>Assignee: Kelvin Goodson
> Fix For: Java-SDO-1.0
>
> Attachments: 1110.patch, 1110.patch2
>
>
> In the SDO databinding for SCA, we need to introspect a java class/interface 
> to figure out the corresponding SDO type. Looking into the code, there is a 
> TODO comment:
> //TODO more efficient implementation ... this is a really bad one!
> Do you plan to provide a more efficient impl :-)?
> Thanks,
> Raymond

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

I'm going to number off the non jira related tasks so that its easy to
reference them

I just did 1 and now plan to do 4,5,7,8,9

1 the pom has a "provided scope" dependency on stax  -- I will fix this as
per my note to tuscany-dev
2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch

the following have been raised by comments on RC1

4 NOTICE files (create separate ones for impl and bin and ensure no
disclaimer contained)
5 need to update release notes with descriptive para and fixed jiras
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
7 should remove EPL license from src distro
8 add stax reference in bin distro license
9 add readme to bin distro samples folder
10 fix up runsamples scripts to be more robust/helpful and ensure that the
runsamples.sh script runs ok in a linux env
11 fix up bad javadoc links in samples index.html
12 exclude samples infrastructure classes from samples javadoc
13 fix link back to tuscany site from overview.html to point to the get
involved page
14 incorporate Haleh's suggested paragraph [1] into overview.html

and some of my own todos that I hope to get to
12 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
13 put an overview doc into the sdo lib project's javadoc
14 add the change summary aspects of the medical scenario sample

Regards, Kelvin

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


This release is running later than I had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out.  Please help with some of these TODOs if you can.  If you plan
to tackle anything please post here so that we don't overlap;  I'll do the
same.

these are the things that I think are "must-fix"

1143 -- the issues re test failures are being resolved   -- david's
working on this
1429 -- i've looked at this and it is fine apart from the casting to
HelperContextImpls -- i put a note on the jira,
1428 -- note appended to jira asking for code to exercise/demonstrate the
fix

other issues raised on the list

the pom has a "provided scope" dependency on stax  -- I will fix this as
per my note to tuscany-dev
use rat results to fix license header issues and post rat results
check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch

the following have been raised by comments on RC1

NOTICE files (create separate ones for impl and bin and ensure no
disclaimer contained)
need to update release notes with descriptive para and fixed jiras
need to remove dependencies on snapshot plugins (rfeng 13/7)
should remove EPL license from src distro
add stax reference in bin distro license
add readme to bin distro samples folder
fix up runsamples scripts to be more robust/helpful and ensure that the
runsamples.sh script runs ok in a linux env
fix up bad javadoc links in samples index.html
exclude samples infrastructure classes from samples javadoc
fix link back to tuscany site from overview.html to point to the get
involved page
incorporate Haleh's suggested paragraph [1] into overview.html

and some of my own todos that I hope to get to
ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
put an overview doc into the sdo lib project's javadoc
add the change summary aspects of the medical scenario sample




[1]
b) You could remove the first sentence since it does not really make
sense.
How about .. Apache Tuscany SDO Samples are provided here to help users
learn SDO.'index by SDO subproject ' lists the different samples available
to you. These samples provide a starting point for learning SDO and can be

extended and enhanced to experiment with other available SDO features.
Please help us enhance these samples by sending your feedback to Tuscany
mailing list or join us and contribute to this project .

[jira] Resolved: (TUSCANY-1342) Component-level not supported

[Venkatakrishnan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Venkatakrishnan resolved TUSCANY-1342.
--

Resolution: Fixed

This seems to have been fixed on the Trunk.  I have added this case to the 
samples to test this out.  Please try - 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-reference/src/main/resources/helloworldwsclient.composite

> Component-level  not supported
> --
>
> Key: TUSCANY-1342
> URL: https://issues.apache.org/jira/browse/TUSCANY-1342
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: Scott Kurz
>
> See thread:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18780.html
> Something like this does not work:
>  
> 
> 
> 
> < binding.ws wsdlElement="..."/>
> 
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Build break in implementation-das?

[Simon Nash]

I did a clean checkout this morning my time and built SCA from an
empty Maven repo.  I got the same build error in implementation-das
that Sebastien was seeing.

I was hoping that starting with an empty maven repo would cause the
correct levels of SDO and DAS to be downloaded but it seems that this
is not the case.

Is it always necessary to build SDO and/or DAS before building SCA?
When will the correct SDO and DAS levels be published as snapshots so
that this is not necessary?

For now I have commented out implementation-das from my build so that
I can make progress.

  Simon

Jean-Sebastien Delfino wrote:


Luciano Resende wrote:


Everything is building ok for me too, is this the only module that is
failing for you ?




It works now, see: 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20174.html


Thanks
--
Jean-Sebastien





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

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

just did 4,5,7,8,9,10(a) -- still not run the linux script
so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly numbered as
12,13,14 -- doh!)

2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
10b ensure that the runsamples.sh script runs ok in a linux env
11 fix up bad javadoc links in samples index.html
12 exclude samples infrastructure classes from samples javadoc
13 fix link back to tuscany site from overview.html to point to the get
involved page
14 incorporate Haleh's suggested paragraph [1] into overview.html
15 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
16 put an overview doc into the sdo lib project's javadoc
17 add the change summary aspects of the medical scenario sample

I'm going to tackle 3 now

Kelvin.

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


I'm going to number off the non jira related tasks so that its easy to
reference them

I just did 1 and now plan to do 4,5,7,8,9

1 the pom has a "provided scope" dependency on stax  -- I will fix this as
per my note to tuscany-dev
2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch

the following have been raised by comments on RC1

4 NOTICE files (create separate ones for impl and bin and ensure no
disclaimer contained)
5 need to update release notes with descriptive para and fixed jiras
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
7 should remove EPL license from src distro
8 add stax reference in bin distro license
9 add readme to bin distro samples folder
10 fix up runsamples scripts to be more robust/helpful and ensure that the
runsamples.sh script runs ok in a linux env
11 fix up bad javadoc links in samples index.html
12 exclude samples infrastructure classes from samples javadoc
13 fix link back to tuscany site from overview.html to point to the get
involved page
14 incorporate Haleh's suggested paragraph [1] into overview.html

and some of my own todos that I hope to get to
12 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
13 put an overview doc into the sdo lib project's javadoc
14 add the change summary aspects of the medical scenario sample

Regards, Kelvin

On 17/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> This release is running later than I had hoped due to extra jiras being
> added to the plan, and a few issues that have come up after recent fixe, so
> we are a bit behind where I'd proposed we should be in terms of getting this
> release out.  Please help with some of these TODOs if you can.  If you plan
> to tackle anything please post here so that we don't overlap;  I'll do the
> same.
>
> these are the things that I think are "must-fix"
>
> 1143 -- the issues re test failures are being resolved   -- david's
> working on this
> 1429 -- i've looked at this and it is fine apart from the casting to
> HelperContextImpls -- i put a note on the jira,
> 1428 -- note appended to jira asking for code to exercise/demonstrate
> the fix
>
> other issues raised on the list
>
> the pom has a "provided scope" dependency on stax  -- I will fix this as
> per my note to tuscany-dev
> use rat results to fix license header issues and post rat results
> check that all recent fixes in the trunk since the branch was made have
> equivalent fixes in the branch
>
> the following have been raised by comments on RC1
>
> NOTICE files (create separate ones for impl and bin and ensure no
> disclaimer contained)
> need to update release notes with descriptive para and fixed jiras
> need to remove dependencies on snapshot plugins (rfeng 13/7)
> should remove EPL license from src distro
> add stax reference in bin distro license
> add readme to bin distro samples folder
> fix up runsamples scripts to be more robust/helpful and ensure that the
> runsamples.sh script runs ok in a linux env
> fix up bad javadoc links in samples index.html
> exclude samples infrastructure classes from samples javadoc
> fix link back to tuscany site from overview.html to point to the get
> involved page
> incorporate Haleh's suggested paragraph [1] into overview.html
>
> and some of my own todos that I hope to get to
> ensure consistency of each sample program's javadoc to point back to
> central instructions for running samples
> put an overview doc into the sdo lib project's javadoc
> add the change summary aspects of the medical scenario sample
>
>
> 
>
> [1]
> b) You could remove the first sentence since it does not really make
> sense.
> How about .. Apache Tuscany SDO Samples are provided here to help users
> learn SDO.'index by SDO subproject ' li

[RDB DAS] Wrong Query Result when SELECT misses PKs

[Amita Vadhavkar]

Sorry for the leng  thy mail

Tried to check the case when the database has parent-child tables and DAS
SELECT Command may/may not
contain the PKs of the tables. And found some quite confusing cases/results,
which are effectively giving
user a wrong impression of the data in tables.

Looks like there are places where we are allowing partial results, wrong
association in parent and child rows.
As RDB DAS logic revolves around PKs, can we state clearly that
"When Query SELECT does not include PK for a table, the data graph will be
empty for that table"
? i.e. in the below analysis, instead of giving wrong/partial result, at
least consistently give no result?
And make necessary code corrections to adhere to this statement?

Or any alternative approaches?

What DAS C++ is doing for this case? Just curious.
-
Say, take below data -
Parent: SINGER(ID, NAME), Child:SONG (ID, TITLE, SINGERID)
Data:
SINGER
ID NAME

1  Jonh
2  Jane

SONG
ID   TITLE   SINGERID
-
10   ABCD  1
20   Lamb   1
30   La ra ra2

There are total 8 cases that I can see. viz.

No relationship in config
--
   parent PK in SEL   child PK in SELResult
--
[1]   present  presentcorrect
[2]   present  missingwrong
[3]   missing  presentwrong
[4]   missing  missing   wrong

Relationship in config
[5]   presentpresent correct
[6]   presentmissing wrong
[7]   missingpresent wrong
[8]   missingmissingwrong
-
When relationship is not defined in DAS Config
DAS Client code:

DAS das = DAS.FACTORY.createDAS(getConfig("cfg.xml"), getConnection());
Command select = das.getCommand("withNoRel-5/6/7/8");
DataObject root = select.executeQuery();
List singers = root.getList("SINGER");
   if(singers != null){
   System.out.println("Singer size:"+singers.size());
   for(int i=0; i

Re: Website ACL

[ant elder]

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

  ...ant

On 7/17/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:


Ant,

Please drop an email to apmail AT apache.org.

thanks,
dims

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


--
Davanum Srinivas :: http://davanum.wordpress.com

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml
to "runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me
like the second defintion of core.dir is being ignored. I'm not an ant
expert ... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one
of the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in
the top level build.xml I added:



and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I'd like some info on what I need to edit in the platform.properties.
Particularly:

platform.compiler-definition=g++m32
platform=rhas4u4_gcc346

One good thing about automake is that it detects your
platform/compiler etc automatically.

Cheers,


On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> I put together some documentation for using ant with TuscanySCA Native.
>
> How's this?
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>
>
> Using ant to build TuscanySCA Native
>
>
>
> 1. Required Software to build TuscanySCA Native with ant:
>
> Ant:
>Ant comes installed with almost all Linux distributions
>version 1.6 or later
>Download: http://ant.apache.org/
>
> antcontrib:
>version 1.0b3 or later
>Download: http://ant-contrib.sourceforge.net/
>
> antcontrib cpptasks.jar
>version 1.0b4 or later
>Download: http://ant-contrib.sourceforge.net/
>Information: http://ant-contrib.sourceforge.net/cc.html
>
>
> 2. Installation Instructions:
>
> Linux
> -
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> export ANT_HOME="/home/you/ant"
>
> Add $ANT_HOME/bin to your path.
> export PATH="${PATH}:${ANT_HOME}/bin"
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in $ANT_HOME/lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to $ANT_HOME/lib, do the following:
> - create ${user.home}/.ant/lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
> Windows
> ---
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> set ANT_HOME=c:\ant
>
> Add %ANT_HOME%\bin to your path.
> set PATH=%PATH%;%ANT_HOME%\bin
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in %ANT_HOME%\lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to %ANT_HOME%\lib, do the following:
> - create ${user.home}\.ant\lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
>
>
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 17, 2007 1:24 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> Thanks Brady. I'll take a look at this. We will need doc as to what the
> dependencies are (cpptasks etc) and any configuration that is needed.
>
> Cheers,
>
> On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > For anyone interested, I uploaded another patch for this JIRA that
> > makes it work better for windows.
> >
> >tuscanySCAnative_ant_update1.tar.gz
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> > 
> >
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 10:46 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: [SCA Native] preliminary ant build
> >
> > Hello,
> >
> > This may be the second time you receive this email, the first time I
> > sent it with an attachment, which I later realized that this dist list
>
> > may reject. So here it is again, w/o the attachment. I created a JIRA
> > and put the attachment there:
> >
> >https://issues.apache.org/jira/browse/TUSCANY-1438
> >
> > According to a previous thread titled "[SCA Native] next release
> > content
> > [was: Tuscany roadmap]" (I didnt want to add another "was" redirection
> > ;) ), I have prepared ant build scripts for cpp/sca/runtime/core.
> >
> > The tar.gz file attached to the jira should just "overlay" onto the
> > tuscany SCA cpp source code directory 

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml
to "runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me
like the second defintion of core.dir is being ignored. I'm not an ant
expert ... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one
of the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in
the top level build.xml I added:





or...
  


and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'd like some info on what I need to edit in the platform.properties.
> Particularly:
>
> platform.compiler-definition=g++m32
> platform=rhas4u4_gcc346
>
> One good thing about automake is that it detects your
> platform/compiler etc automatically.
>
> Cheers,
>
>
> On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > I put together some documentation for using ant with TuscanySCA Native.
> >
> > How's this?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> >
> > Using ant to build TuscanySCA Native
> >
> >
> >
> > 1. Required Software to build TuscanySCA Native with ant:
> >
> > Ant:
> >Ant comes installed with almost all Linux distributions
> >version 1.6 or later
> >Download: http://ant.apache.org/
> >
> > antcontrib:
> >version 1.0b3 or later
> >Download: http://ant-contrib.sourceforge.net/
> >
> > antcontrib cpptasks.jar
> >version 1.0b4 or later
> >Download: http://ant-contrib.sourceforge.net/
> >Information: http://ant-contrib.sourceforge.net/cc.html
> >
> >
> > 2. Installation Instructions:
> >
> > Linux
> > -
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > export ANT_HOME="/home/you/ant"
> >
> > Add $ANT_HOME/bin to your path.
> > export PATH="${PATH}:${ANT_HOME}/bin"
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > in $ANT_HOME/lib
> > So place the antcontrib and cpptasks jars there.
> >
> > If you dont have write access to $ANT_HOME/lib, do the following:
> > - create ${user.home}/.ant/lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is problematic.
> >
> > Windows
> > ---
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > set ANT_HOME=c:\ant
> >
> > Add %ANT_HOME%\bin to your path.
> > set PATH=%PATH%;%ANT_HOME%\bin
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > in %ANT_HOME%\lib
> > So place the antcontrib and cpptasks jars there.
> >
> > If you dont have write access to %ANT_HOME%\lib, do the following:
> > - create ${user.home}\.ant\lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is problematic.
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 17, 2007 1:24 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > Thanks Brady. I'll take a look at this. We will need doc as to what the
> > dependencies are (cpptasks etc) and any configuration that is needed.
> >
> > Cheers,
> >
> > On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > For anyone interested, I uploaded another patch for this JIRA that
> > > makes it work better for windows.
> > >
> > >tuscanySCAnative_ant_update1.tar.gz
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > > 
> > >
> > >
> > >
> > > -Original Message-
> > > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, July 16, 2007 10:46 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: [SCA Native] preliminary ant build
> > >
> > > Hello,
> > >
> > > This may be the second time you receive this email, the first time I
> > > sent it with an attachment, which I later realized that this dist list
> >
> > > may reject. So here it is again, w/o the attachment. I created a JIRA
> > > and put the attachment there:
> > >
> > >https://issues.apache.org/jira/browse/TUSCANY-1438
> >

[jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1431:
-

Attachment: 1431.patch

Please note that in patch file for below there is no new line at end. But when 
patch is applied, a new line get s in after 
org.apache.tuscany.das.xquery.impl.XQuerySaxonFactoryImpl and this causes 
ClassNotFound exception in UT case, if this is corrected manually , all UT 
cases go thru fine.

Index: 
xquery/src/main/resources/META-INF/services/org.apache.tuscany.das.ImplementationFactory
===
--- 
xquery/src/main/resources/META-INF/services/org.apache.tuscany.das.ImplementationFactory
(revision 0)
+++ 
xquery/src/main/resources/META-INF/services/org.apache.tuscany.das.ImplementationFactory
(revision 0)
@@ -0,0 +1 @@
+org.apache.tuscany.das.xquery.impl.XQuerySaxonFactoryImpl
\ No newline at end of file


> DAS with XQuery based data access support
> -
>
> Key: TUSCANY-1431
> URL: https://issues.apache.org/jira/browse/TUSCANY-1431
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java DAS XQuery
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
> Attachments: 1431.patch, 1431.patch, 1431_api.patch, 1431_xquery.patch
>
>
> place for submitting incremental patches for the ground work of XQuery DAS

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [DAS] XQuery-DAS

[Amita Vadhavkar]

Hi ,
I am trying to summarize some updates on progress in XQuery DAS -
extended the Service Provider framework to support invocation of
different XQuery Implementations.

Open Issues:-
I am considering 2 alternative XQuery Implementations

1) DB2 Express
- here my main concern is, is it possible to get any db2 jars under maven
repo?
- based on license, will there be any problems in getting this under maven
repo?
anybody any clue?

2) Saxon
Some plus points here are
- it is following XQJ compliance (not completely)
- there is a claim that Flat File as well as Database back end is supported.

(I have come across problems when checking the database support in saxon-b,
getting exception when I try to pass JDBC Connection in SaxonXQDataSource()
constructor ,  looks like - not yet implemented - in Saxon)

Some open issues are
- 2 Saxon jars are required at minimal to use XQJ compliance - saxon8 and
saxon8-xqj.
(which are part of version 8.9), but the highest version I could see in
maven repos
was 8.7 and so 3 jars (including xqj) are missing too.

- So, either, we need to leave XQJ ((:), and use whatever is available in
8.7 or otherwise
have a way to get the latest saxon version in maven repos. It will be great
if latest 8.9
saxon can appear in maven repo.

Regards,
Amita
On 7/15/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:


Hi,
Yes, Saxon was suggested by Ant also before and it has saxon-b as
freeware.
Anybody please any comment on any licensing restrictions? Also I was just
giving a try to DB2 Express XQuery support. There are a couple of others
listed in June
15 mail, in this same thread. Saxon will be a good choice from XQJ
compliance point too.
(I will be able to upload a patch in 1-2 days time on the top of what
is there in 
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/

with some documentation to continue design discussion)

Regards,
Amita

On 7/13/07, Doug Tidwell < [EMAIL PROTECTED]> wrote:
>
> Gang, how is XPath support implemented today?  I've looked at the code
> briefly in the past, but couldn't make sense of it.  I was hoping that
> XPath support came from the Xalan jar files.  If that were true, it
> would
> be a SMOP to replace the Xalan XPath libraries with the Saxon libraries.
> Saxon supports XSLT 2.0, XPath 2.0 and XQuery.
>
> That's a straightforward approach to leveraging someone else's excellent
> work, although I don't know if Saxon's license would be compatible.
>
> Anyway, if somebody knows how XPath is implemented now, that would be a
> start towards figuring out how to plug in an XQuery engine.
>
> Cheers,
> -Doug

[jira] Resolved: (TUSCANY-1431) DAS with XQuery based data access support

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-1431.
--

   Resolution: Fixed
Fix Version/s: Java-DAS-Next

Latest patch from Amita applied to Amita's sandbox

> DAS with XQuery based data access support
> -
>
> Key: TUSCANY-1431
> URL: https://issues.apache.org/jira/browse/TUSCANY-1431
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java DAS XQuery
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: 1431.patch, 1431.patch, 1431_api.patch, 1431_xquery.patch
>
>
> place for submitting incremental patches for the ground work of XQuery DAS

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

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

[Venkata Krishnan]

Hi

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

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

Thanks

- Venkat

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

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

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

Thanks

- Venkat

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



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

Re: [DAS] XQuery-DAS

[Luciano Resende]

Comments inline

On 7/18/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Hi ,
I am trying to summarize some updates on progress in XQuery DAS -
extended the Service Provider framework to support invocation of
different XQuery Implementations.

Open Issues:-
I am considering 2 alternative XQuery Implementations

1) DB2 Express
- here my main concern is, is it possible to get any db2 jars under maven
repo?
- based on license, will there be any problems in getting this under maven
repo?
anybody any clue?


When connecting to DB2, what are the jars going to be used for ? I'd
imagine this scenario would be simmilar to regular RDB DAS connecting
to MySQL, where we give people the proper instructions to configure
their environment (e.g download JDBC driver) so DAS could work with.



2) Saxon
Some plus points here are
- it is following XQJ compliance (not completely)
- there is a claim that Flat File as well as Database back end is supported.

(I have come across problems when checking the database support in saxon-b,
getting exception when I try to pass JDBC Connection in SaxonXQDataSource()
constructor ,  looks like - not yet implemented - in Saxon)

Some open issues are
- 2 Saxon jars are required at minimal to use XQJ compliance - saxon8 and
saxon8-xqj.
(which are part of version 8.9), but the highest version I could see in
maven repos
was 8.7 and so 3 jars (including xqj) are missing too.
> - So, either, we need to leave XQJ ((:), and use whatever is available in
8.7 or otherwise
have a way to get the latest saxon version in maven repos. It will be great
if latest 8.9
saxon can appear in maven repo.


If we decide to use this libraries,  we could contact the Saxon
community at sourceforge and check if they would upload the required
to maven. I'm not sure if we could directly try to work with maven
team to post these libraries to some maven repo.


Regards,
Amita
On 7/15/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Yes, Saxon was suggested by Ant also before and it has saxon-b as
> freeware.
> Anybody please any comment on any licensing restrictions? Also I was just
> giving a try to DB2 Express XQuery support. There are a couple of others
> listed in June
> 15 mail, in this same thread. Saxon will be a good choice from XQJ
> compliance point too.
> (I will be able to upload a patch in 1-2 days time on the top of what
> is there in 
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/
>
> with some documentation to continue design discussion)
>
> Regards,
> Amita
>
> On 7/13/07, Doug Tidwell < [EMAIL PROTECTED]> wrote:
> >
> > Gang, how is XPath support implemented today?  I've looked at the code
> > briefly in the past, but couldn't make sense of it.  I was hoping that
> > XPath support came from the Xalan jar files.  If that were true, it
> > would
> > be a SMOP to replace the Xalan XPath libraries with the Saxon libraries.
> > Saxon supports XSLT 2.0, XPath 2.0 and XQuery.
> >
> > That's a straightforward approach to leveraging someone else's excellent
> > work, although I don't know if Saxon's license would be compatible.
> >
> > Anyway, if somebody knows how XPath is implemented now, that would be a
> > start towards figuring out how to plug in an XQuery engine.
> >
> > Cheers,
> > -Doug
>
>
>




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Created: (TUSCANY-1450) Javadoc removed from distribution profile to allow build to complete in continuun machine

[Luciano Resende (JIRA)]

Javadoc removed from distribution profile to allow build to complete in 
continuun machine
-

 Key: TUSCANY-1450
 URL: https://issues.apache.org/jira/browse/TUSCANY-1450
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
Affects Versions: Java-SCA-Next
Reporter: Luciano Resende
Priority: Blocker
 Fix For: Java-SCA-Next


When running on the continuum build machine, the -Pdistribution profile (from 
java/sca) is not working, and it cannot find the javadoc dependencies. We 
should investigate the issue and find a proper fix.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [SCA Native] preliminary ant build

[Luciano Resende]

Hey Guys

Does a lot of external dependencies need to be setup in order to
proper run the build ? Once this is complete, we could try to
integrate the ant build with Continuun (looks like it supports ant
builds) and try to get a nightly build published for Native project as
well ?

On 7/18/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I ran into a couple of issues tryingt o run this ant build. Firstly I
> got an error with a path
> x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
> the fact that the property core.dir is set in the top level build.xml
> to "runtime/core/src" and in the runtime/core/src/build.xml the same
> property name is used and set tu "tuscany/sca/core". It looks to me
> like the second defintion of core.dir is being ignored. I'm not an ant
> expert ... do properties get propagated from higher level build files?
> I got around this by changing the name of core.dir to src.dir in one
> of the files.
>
> Rather than specifying the paths to the source code etc in the
> platform.properties I would prefer to set these automatically so in
> the top level build.xml I added:
>
> 
>

or...
   

> and then based other properties from this. It seemed to work!
>
> Do these changes make sense?
>
> Cheers,
>
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I'd like some info on what I need to edit in the platform.properties.
> > Particularly:
> >
> > platform.compiler-definition=g++m32
> > platform=rhas4u4_gcc346
> >
> > One good thing about automake is that it detects your
> > platform/compiler etc automatically.
> >
> > Cheers,
> >
> >
> > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > I put together some documentation for using ant with TuscanySCA Native.
> > >
> > > How's this?
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > Using ant to build TuscanySCA Native
> > >
> > >
> > >
> > > 1. Required Software to build TuscanySCA Native with ant:
> > >
> > > Ant:
> > >Ant comes installed with almost all Linux distributions
> > >version 1.6 or later
> > >Download: http://ant.apache.org/
> > >
> > > antcontrib:
> > >version 1.0b3 or later
> > >Download: http://ant-contrib.sourceforge.net/
> > >
> > > antcontrib cpptasks.jar
> > >version 1.0b4 or later
> > >Download: http://ant-contrib.sourceforge.net/
> > >Information: http://ant-contrib.sourceforge.net/cc.html
> > >
> > >
> > > 2. Installation Instructions:
> > >
> > > Linux
> > > -
> > >
> > > Make sure JAVA_HOME is set before starting.
> > >
> > > Install ant according to http://ant.apache.org/manual/index.html.
> > >
> > > Set the ANT_HOME variable to the directory where you install ant.
> > > export ANT_HOME="/home/you/ant"
> > >
> > > Add $ANT_HOME/bin to your path.
> > > export PATH="${PATH}:${ANT_HOME}/bin"
> > >
> > > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > > in $ANT_HOME/lib
> > > So place the antcontrib and cpptasks jars there.
> > >
> > > If you dont have write access to $ANT_HOME/lib, do the following:
> > > - create ${user.home}/.ant/lib
> > > - place the jars here
> > >
> > > Avoid adding optional ant tasks to your classpath, this is problematic.
> > >
> > > Windows
> > > ---
> > >
> > > Make sure JAVA_HOME is set before starting.
> > >
> > > Install ant according to http://ant.apache.org/manual/index.html.
> > >
> > > Set the ANT_HOME variable to the directory where you install ant.
> > > set ANT_HOME=c:\ant
> > >
> > > Add %ANT_HOME%\bin to your path.
> > > set PATH=%PATH%;%ANT_HOME%\bin
> > >
> > > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > > in %ANT_HOME%\lib
> > > So place the antcontrib and cpptasks jars there.
> > >
> > > If you dont have write access to %ANT_HOME%\lib, do the following:
> > > - create ${user.home}\.ant\lib
> > > - place the jars here
> > >
> > > Avoid adding optional ant tasks to your classpath, this is problematic.
> > >
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, July 17, 2007 1:24 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > Thanks Brady. I'll take a look at this. We will need doc as to what the
> > > dependencies are (cpptasks etc) and any configuration that is needed.
> > >
> > > Cheers,
> > >
> > > On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > For anyone interested, I uploaded another patch for this JIRA that
> > > > makes it work better for windows.
> > > >
> > > >tuscanySCAnative_ant_update1.tar.gz
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA
> > > > Rogue Wave Software - [EMAIL PROTECTED]
> > 

SDO Snapshot, was Re: Build break in implementation-das?

[Luciano Resende]

Kelvin or others working more closely with SDO, could someone please
publish the latest SDO Snapshots ?

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

I did a clean checkout this morning my time and built SCA from an
empty Maven repo.  I got the same build error in implementation-das
that Sebastien was seeing.

I was hoping that starting with an empty maven repo would cause the
correct levels of SDO and DAS to be downloaded but it seems that this
is not the case.

Is it always necessary to build SDO and/or DAS before building SCA?
When will the correct SDO and DAS levels be published as snapshots so
that this is not necessary?

For now I have commented out implementation-das from my build so that
I can make progress.

   Simon

Jean-Sebastien Delfino wrote:

> Luciano Resende wrote:
>
>> Everything is building ok for me too, is this the only module that is
>> failing for you ?
>>
>>
>
> It works now, see:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20174.html
>
> Thanks
> --
> Jean-Sebastien
>



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





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

That sounds like a good idea. I hope to minimize/automate as much of
the configuration as possible but there are a fair number of external
dependencies (libxml, httpd, libcurl, Ruby, Python... etc..)

Cheers,

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

Hey Guys

Does a lot of external dependencies need to be setup in order to
proper run the build ? Once this is complete, we could try to
integrate the ant build with Continuun (looks like it supports ant
builds) and try to get a nightly build published for Native project as
well ?

On 7/18/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I ran into a couple of issues tryingt o run this ant build. Firstly I
> > got an error with a path
> > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
> > the fact that the property core.dir is set in the top level build.xml
> > to "runtime/core/src" and in the runtime/core/src/build.xml the same
> > property name is used and set tu "tuscany/sca/core". It looks to me
> > like the second defintion of core.dir is being ignored. I'm not an ant
> > expert ... do properties get propagated from higher level build files?
> > I got around this by changing the name of core.dir to src.dir in one
> > of the files.
> >
> > Rather than specifying the paths to the source code etc in the
> > platform.properties I would prefer to set these automatically so in
> > the top level build.xml I added:
> >
> > 
> >
>
> or...
>
>
> > and then based other properties from this. It seemed to work!
> >
> > Do these changes make sense?
> >
> > Cheers,
> >
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'd like some info on what I need to edit in the platform.properties.
> > > Particularly:
> > >
> > > platform.compiler-definition=g++m32
> > > platform=rhas4u4_gcc346
> > >
> > > One good thing about automake is that it detects your
> > > platform/compiler etc automatically.
> > >
> > > Cheers,
> > >
> > >
> > > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > I put together some documentation for using ant with TuscanySCA Native.
> > > >
> > > > How's this?
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA
> > > > Rogue Wave Software - [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > Using ant to build TuscanySCA Native
> > > >
> > > >
> > > >
> > > > 1. Required Software to build TuscanySCA Native with ant:
> > > >
> > > > Ant:
> > > >Ant comes installed with almost all Linux distributions
> > > >version 1.6 or later
> > > >Download: http://ant.apache.org/
> > > >
> > > > antcontrib:
> > > >version 1.0b3 or later
> > > >Download: http://ant-contrib.sourceforge.net/
> > > >
> > > > antcontrib cpptasks.jar
> > > >version 1.0b4 or later
> > > >Download: http://ant-contrib.sourceforge.net/
> > > >Information: http://ant-contrib.sourceforge.net/cc.html
> > > >
> > > >
> > > > 2. Installation Instructions:
> > > >
> > > > Linux
> > > > -
> > > >
> > > > Make sure JAVA_HOME is set before starting.
> > > >
> > > > Install ant according to http://ant.apache.org/manual/index.html.
> > > >
> > > > Set the ANT_HOME variable to the directory where you install ant.
> > > > export ANT_HOME="/home/you/ant"
> > > >
> > > > Add $ANT_HOME/bin to your path.
> > > > export PATH="${PATH}:${ANT_HOME}/bin"
> > > >
> > > > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > > > in $ANT_HOME/lib
> > > > So place the antcontrib and cpptasks jars there.
> > > >
> > > > If you dont have write access to $ANT_HOME/lib, do the following:
> > > > - create ${user.home}/.ant/lib
> > > > - place the jars here
> > > >
> > > > Avoid adding optional ant tasks to your classpath, this is problematic.
> > > >
> > > > Windows
> > > > ---
> > > >
> > > > Make sure JAVA_HOME is set before starting.
> > > >
> > > > Install ant according to http://ant.apache.org/manual/index.html.
> > > >
> > > > Set the ANT_HOME variable to the directory where you install ant.
> > > > set ANT_HOME=c:\ant
> > > >
> > > > Add %ANT_HOME%\bin to your path.
> > > > set PATH=%PATH%;%ANT_HOME%\bin
> > > >
> > > > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > > > in %ANT_HOME%\lib
> > > > So place the antcontrib and cpptasks jars there.
> > > >
> > > > If you dont have write access to %ANT_HOME%\lib, do the following:
> > > > - create ${user.home}\.ant\lib
> > > > - place the jars here
> > > >
> > > > Avoid adding optional ant tasks to your classpath, this is problematic.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, July 17, 2007 1:24 AM
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: [SCA Native] preliminary ant build
> > > >
> > > > Thanks Brady. I'll take a look a

Re: SCA nightly builds unavailable?

[Luciano Resende]

Made some progress here, we are passed all issues now, just getting
Out Of Memory while  creating the distribution. I'll have to check
what are the MAVEN_OPTS on the continuum machine.

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

No, I don't think we ever found a solution for this.

On 7/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Luciano Resende wrote:
> > I have fixed some of the regression around missing dependencies with
> > maven-antrun-plugin.
> > But we still have one issue while trying to build the distribution
> > profile, for some reason, looks like it can't find the
> > tuscany-core-spi artifact.
> >
> > [INFO] Failed to resolve artifact.
> >
> > GroupId: org.apache.tuscany.sca
> > ArtifactId: tuscany-core-spi
> > Version: 1.0-incubating-SNAPSHOT
> >
> > Detailed log available here [1]. Any help or hints appreciated.
> >
> > [1]
> > 
http://vmbuild.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=217640&id=381
> >
> >
>
> This is not the first time we see this. Last time it happened didn't a
> cleanup on the build machine fix the problem?
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Resolved: (TUSCANY-1344) Tuscany does not provide a loader for the elements in scdl

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1344.
-

Resolution: Fixed

There is one now, in a new binding-sca module.

> Tuscany does not provide a loader for the  elements in scdl
> --
>
> Key: TUSCANY-1344
> URL: https://issues.apache.org/jira/browse/TUSCANY-1344
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-0.90, Java-SCA-0.91
> Environment: sca-java-0.90
>Reporter: Matthew Sykes
>Priority: Trivial
>
> There doesn't appear to be a StAXArtifactProcessor capable of reading and 
> serializing  elements in the scdl.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: [SCA Native] preliminary ant build

[Brady Johnson]

Pete,

Thanks for trying out the ant build scripts.

Regarding core.dir, you're right, the name will need to change. I can do
that no problem.

As for the "tuscanySCA.root.dir" : Your suggestion will work if you only
execute ant from the root directory, but not if you execute ant from the
runtime/core/src directory. That's why I put it in the
platform.properties, which is accessed by all build.xml's. Its better
ant coding style to have anything that needs to be configured in a
properties file, not in an ant build.xml file.

As for the platform.properties file for windows:
The property platform can/should be removed, its not necessary. If the
property "platform.compiler-definition" is set, then that value will be
used for the compiler selection, else it will get set to msvc for
windows as can be seen on line 18 of compilers.xml.

I think the way this should ship is to have several platform.properties
files for the different platform: 
platform.properties.linux
platform.properties.windows
platform.properties.mac
Which will each have values pre configured for the corresponding
platform. Then with either configure or a shell script, the platform
file wil be copied to platform.properties and the directory properties
will be set accordingly.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 7:08 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml to
"runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me like
the second defintion of core.dir is being ignored. I'm not an ant expert
... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one of
the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in the
top level build.xml I added:



and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'd like some info on what I need to edit in the platform.properties.
> Particularly:
>
> platform.compiler-definition=g++m32
> platform=rhas4u4_gcc346
>
> One good thing about automake is that it detects your 
> platform/compiler etc automatically.
>
> Cheers,
>
>
> On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > I put together some documentation for using ant with TuscanySCA
Native.
> >
> > How's this?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> >
> > Using ant to build TuscanySCA Native
> >
> >
> >
> > 1. Required Software to build TuscanySCA Native with ant:
> >
> > Ant:
> >Ant comes installed with almost all Linux distributions
> >version 1.6 or later
> >Download: http://ant.apache.org/
> >
> > antcontrib:
> >version 1.0b3 or later
> >Download: http://ant-contrib.sourceforge.net/
> >
> > antcontrib cpptasks.jar
> >version 1.0b4 or later
> >Download: http://ant-contrib.sourceforge.net/
> >Information: http://ant-contrib.sourceforge.net/cc.html
> >
> >
> > 2. Installation Instructions:
> >
> > Linux
> > -
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > export ANT_HOME="/home/you/ant"
> >
> > Add $ANT_HOME/bin to your path.
> > export PATH="${PATH}:${ANT_HOME}/bin"
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be 
> > installed in $ANT_HOME/lib So place the antcontrib and cpptasks jars

> > there.
> >
> > If you dont have write access to $ANT_HOME/lib, do the following:
> > - create ${user.home}/.ant/lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is
problematic.
> >
> > Windows
> > ---
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > set ANT_HOME=c:\ant
> >
> > Add %ANT_HOME%\bin to your path.
> > set PATH=%PATH%;%ANT_HOME%\bin
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be 
> > installed in %ANT_HOME%\lib So place the antcontrib and cpptasks 
> > jars there.
> >
> > If you dont have write access to %ANT_HOME%\lib, do the following:
> > - create ${user

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

Thanks for trying out the ant build scripts.

Regarding core.dir, you're right, the name will need to change. I can do
that no problem.

As for the "tuscanySCA.root.dir" : Your suggestion will work if you only
execute ant from the root directory, but not if you execute ant from the
runtime/core/src directory. That's why I put it in the
platform.properties, which is accessed by all build.xml's. Its better
ant coding style to have anything that needs to be configured in a
properties file, not in an ant build.xml file.



Yes... I realized that would limit you to running ant from the top
level. So, as most of the info in platform.properties can be deduced
would a better solution be to have a top level (or in antscripts dir)
platform-properties.xml that
a) imports platform.properties for any overrides
b) sets the properties conditional on the platform.

e.g.
 
   
 
 
   
 
 
   
 


As for the platform.properties file for windows:
The property platform can/should be removed, its not necessary. If the
property "platform.compiler-definition" is set, then that value will be
used for the compiler selection, else it will get set to msvc for
windows as can be seen on line 18 of compilers.xml.

I think the way this should ship is to have several platform.properties
files for the different platform:
   platform.properties.linux
   platform.properties.windows
   platform.properties.mac
Which will each have values pre configured for the corresponding
platform. Then with either configure or a shell script, the platform
file wil be copied to platform.properties and the directory properties
will be set accordingly.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 7:08 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml to
"runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me like
the second defintion of core.dir is being ignored. I'm not an ant expert
... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one of
the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in the
top level build.xml I added:



and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'd like some info on what I need to edit in the platform.properties.
> Particularly:
>
> platform.compiler-definition=g++m32
> platform=rhas4u4_gcc346
>
> One good thing about automake is that it detects your
> platform/compiler etc automatically.
>
> Cheers,
>
>
> On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > I put together some documentation for using ant with TuscanySCA
Native.
> >
> > How's this?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> >
> > Using ant to build TuscanySCA Native
> >
> >
> >
> > 1. Required Software to build TuscanySCA Native with ant:
> >
> > Ant:
> >Ant comes installed with almost all Linux distributions
> >version 1.6 or later
> >Download: http://ant.apache.org/
> >
> > antcontrib:
> >version 1.0b3 or later
> >Download: http://ant-contrib.sourceforge.net/
> >
> > antcontrib cpptasks.jar
> >version 1.0b4 or later
> >Download: http://ant-contrib.sourceforge.net/
> >Information: http://ant-contrib.sourceforge.net/cc.html
> >
> >
> > 2. Installation Instructions:
> >
> > Linux
> > -
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > export ANT_HOME="/home/you/ant"
> >
> > Add $ANT_HOME/bin to your path.
> > export PATH="${PATH}:${ANT_HOME}/bin"
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be
> > installed in $ANT_HOME/lib So place the antcontrib and cpptasks jars

> > there.
> >
> > If you dont have write access to $ANT_HOME/lib, do the following:
> > - create ${user.home}/.ant/lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is
problematic.
> >
> > Windows
> > ---
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.a

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> Thanks for trying out the ant build scripts.
>
> Regarding core.dir, you're right, the name will need to change. I can do
> that no problem.
>
> As for the "tuscanySCA.root.dir" : Your suggestion will work if you only
> execute ant from the root directory, but not if you execute ant from the
> runtime/core/src directory. That's why I put it in the
> platform.properties, which is accessed by all build.xml's. Its better
> ant coding style to have anything that needs to be configured in a
> properties file, not in an ant build.xml file.
>

Yes... I realized that would limit you to running ant from the top
level. So, as most of the info in platform.properties can be deduced
would a better solution be to have a top level (or in antscripts dir)
platform-properties.xml that
 a) imports platform.properties for any overrides
 b) sets the properties conditional on the platform.

e.g.
 
   
 
 
   
 
 
   
 



the build.xml files would all import this top level file:



> As for the platform.properties file for windows:
> The property platform can/should be removed, its not necessary. If the
> property "platform.compiler-definition" is set, then that value will be
> used for the compiler selection, else it will get set to msvc for
> windows as can be seen on line 18 of compilers.xml.
>
> I think the way this should ship is to have several platform.properties
> files for the different platform:
>platform.properties.linux
>platform.properties.windows
>platform.properties.mac
> Which will each have values pre configured for the corresponding
> platform. Then with either configure or a shell script, the platform
> file wil be copied to platform.properties and the directory properties
> will be set accordingly.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 7:08 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> I ran into a couple of issues tryingt o run this ant build. Firstly I
> got an error with a path
> x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
> the fact that the property core.dir is set in the top level build.xml to
> "runtime/core/src" and in the runtime/core/src/build.xml the same
> property name is used and set tu "tuscany/sca/core". It looks to me like
> the second defintion of core.dir is being ignored. I'm not an ant expert
> ... do properties get propagated from higher level build files?
> I got around this by changing the name of core.dir to src.dir in one of
> the files.
>
> Rather than specifying the paths to the source code etc in the
> platform.properties I would prefer to set these automatically so in the
> top level build.xml I added:
>
> 
>
> and then based other properties from this. It seemed to work!
>
> Do these changes make sense?
>
> Cheers,
>
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I'd like some info on what I need to edit in the platform.properties.
> > Particularly:
> >
> > platform.compiler-definition=g++m32
> > platform=rhas4u4_gcc346
> >
> > One good thing about automake is that it detects your
> > platform/compiler etc automatically.
> >
> > Cheers,
> >
> >
> > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > I put together some documentation for using ant with TuscanySCA
> Native.
> > >
> > > How's this?
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > Using ant to build TuscanySCA Native
> > >
> > >
> > >
> > > 1. Required Software to build TuscanySCA Native with ant:
> > >
> > > Ant:
> > >Ant comes installed with almost all Linux distributions
> > >version 1.6 or later
> > >Download: http://ant.apache.org/
> > >
> > > antcontrib:
> > >version 1.0b3 or later
> > >Download: http://ant-contrib.sourceforge.net/
> > >
> > > antcontrib cpptasks.jar
> > >version 1.0b4 or later
> > >Download: http://ant-contrib.sourceforge.net/
> > >Information: http://ant-contrib.sourceforge.net/cc.html
> > >
> > >
> > > 2. Installation Instructions:
> > >
> > > Linux
> > > -
> > >
> > > Make sure JAVA_HOME is set before starting.
> > >
> > > Install ant according to http://ant.apache.org/manual/index.html.
> > >
> > > Set the ANT_HOME variable to the directory where you install ant.
> > > export ANT_HOME="/home/you/ant"
> > >
> > > Add $ANT_HOME/bin to your path.
> > > export PATH="${PATH}:${ANT_HOME}/bin"
> > >
> > > Optional ant tasks, such as antcontrib and cpptasks, should be
> > > installed in $ANT_HOME/lib So place the antcontrib a

ConversationId determination

[Simon Laws]

I've been looking at how to bring conversational semantics back to life [1]
(as has Ant who has been worrying about the same problem). It seems that, in
resurrecting conversational semantics, a good place to start is a bit of a
reorg of itest/conversations to:

- make the test names more consistent
- separate the separate tests out a bit more and represent them explicitly
in the JUnit test
- add stateless conversations to the test

I just checked in a starting point for this [2] but have hit a snag. The
very first test case I made has a client component which calls several
operations on an @Conversational service component and it doesn't work. The
failure occurs because the runtime uses the message context from the client
message in order to obtain the conversation id to pass to the service.
However my client is not itself conversational and hence messages arriving
at it have no conversation id.

The existing/old test marks both client and service as conversational. This
is valid but should not be required according to the way that I interpret
the spec.

Is there anyone who can comment on why it is this way? I think we need to
change it to store the conversationId somewhere else in the reference/proxy
structure for a started conversation.

Simon


[1] http://issues.apache.org/jira/browse/TUSCANY-1377
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/conversations/src/main/java/org/apache/tuscany/sca/itest/conversational/

RE: [SCA Native] preliminary ant build

[Brady Johnson]

Pete,

That's a good idea. Then the only thing that really need to be set in
platform.properties file would be:
tuscanySCA.install.dir
and any possible overides

I'll put that together real quick and upload it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 9:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > Thanks for trying out the ant build scripts.
> >
> > Regarding core.dir, you're right, the name will need to change. I 
> > can do that no problem.
> >
> > As for the "tuscanySCA.root.dir" : Your suggestion will work if you 
> > only execute ant from the root directory, but not if you execute ant

> > from the runtime/core/src directory. That's why I put it in the 
> > platform.properties, which is accessed by all build.xml's. Its 
> > better ant coding style to have anything that needs to be configured

> > in a properties file, not in an ant build.xml file.
> >
>
> Yes... I realized that would limit you to running ant from the top 
> level. So, as most of the info in platform.properties can be deduced 
> would a better solution be to have a top level (or in antscripts dir) 
> platform-properties.xml that
>  a) imports platform.properties for any overrides
>  b) sets the properties conditional on the platform.
>
> e.g.
>  
>
>  
>  
>
>  
>  
>
>  
>

the build.xml files would all import this top level file:


> > As for the platform.properties file for windows:
> > The property platform can/should be removed, its not necessary. If 
> > the property "platform.compiler-definition" is set, then that value 
> > will be used for the compiler selection, else it will get set to 
> > msvc for windows as can be seen on line 18 of compilers.xml.
> >
> > I think the way this should ship is to have several 
> > platform.properties files for the different platform:
> >platform.properties.linux
> >platform.properties.windows
> >platform.properties.mac
> > Which will each have values pre configured for the corresponding 
> > platform. Then with either configure or a shell script, the platform

> > file wil be copied to platform.properties and the directory 
> > properties will be set accordingly.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 7:08 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > I ran into a couple of issues tryingt o run this ant build. Firstly 
> > I got an error with a path 
> > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down 
> > to the fact that the property core.dir is set in the top level 
> > build.xml to "runtime/core/src" and in the 
> > runtime/core/src/build.xml the same property name is used and set tu

> > "tuscany/sca/core". It looks to me like the second defintion of 
> > core.dir is being ignored. I'm not an ant expert ... do properties
get propagated from higher level build files?
> > I got around this by changing the name of core.dir to src.dir in one

> > of the files.
> >
> > Rather than specifying the paths to the source code etc in the 
> > platform.properties I would prefer to set these automatically so in 
> > the top level build.xml I added:
> >
> > 
> >
> > and then based other properties from this. It seemed to work!
> >
> > Do these changes make sense?
> >
> > Cheers,
> >
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'd like some info on what I need to edit in the
platform.properties.
> > > Particularly:
> > >
> > > platform.compiler-definition=g++m32
> > > platform=rhas4u4_gcc346
> > >
> > > One good thing about automake is that it detects your 
> > > platform/compiler etc automatically.
> > >
> > > Cheers,
> > >
> > >
> > > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > I put together some documentation for using ant with TuscanySCA
> > Native.
> > > >
> > > > How's this?
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA Rogue Wave Software - 
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > Using ant to build TuscanySCA Native
> > > >
> > > >
> > > >
> > > > 1. Required Software to build TuscanySCA Native with ant:
> > > >
> > > > Ant:
> > > >Ant comes installed with almost all Linux distributions
> > > >version 1.6 or later
> > > >Download: http://ant.apache.org/
> > > >
> > > > antcontrib:
> > > >version 1.

[jira] Resolved: (TUSCANY-1271) tuscany-implementation-java-xml module contains some annotations in org.apache.tuscany.api.annotation

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1271.
-

Resolution: Fixed

These annotations are obsolete, not used and not implemented. I removed them, 
only kept @Resource in the impl package for now as it's used to flag annotated 
context setters/fields.

We'll need to support the standard javax.annotations.Resource instead at some 
point, if there's any volunteers to help implement this support.

> tuscany-implementation-java-xml module contains some annotations in 
> org.apache.tuscany.api.annotation
> -
>
> Key: TUSCANY-1271
> URL: https://issues.apache.org/jira/browse/TUSCANY-1271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> tuscany-implementation-java-xml module contains some annotations in 
> org.apache.tuscany.api.annotation
> That doesn't seem right, which module should these be in?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1174) Need to implement support for @ComponentName

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1174.
-

Resolution: Fixed

Fixed under SVN revision r557289.

> Need to implement support for @ComponentName
> 
>
> Key: TUSCANY-1174
> URL: https://issues.apache.org/jira/browse/TUSCANY-1174
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-M2
>Reporter: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> Failing tests under testing/sca/iTest/spec as @ComponentName is not 
> implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-1346) Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reassigned TUSCANY-1346:
---

Assignee: Jean-Sebastien Delfino

> Resolution to TUSCANY-1332 assumes a closed top-level composite that does not 
> support addition of new components
> 
>
> Key: TUSCANY-1346
> URL: https://issues.apache.org/jira/browse/TUSCANY-1346
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model, Java SCA Core Runtime, Java SCA 
> Embedded Runtime
>Affects Versions: Java-SCA-0.90, Java-SCA-0.91
>Reporter: Matthew Sykes
>Assignee: Jean-Sebastien Delfino
>
> The resolution to TUSCANY-1332 involved exploitation of the composite include 
> function to "include" all known deployable composites into the domain such 
> that the components contained within the deployable composites would be wired 
> together when the domain level composite was activated.  While this resolved 
> the issues of wiring across multiple composites contained within different 
> contributions, this approach requires that the system know of all composites 
> that may be part of the domain at the time the domain is activated.
> When embedding Tuscany in a server runtime, however, deployment and 
> activation of composites may occur after the domain is activated.  With the 
> current implementation that is contained with EmbeddedSCADomain, runtimes 
> that consume Tuscany would have to stop and restart the domain composite to 
> deploy and activate new components and their services.  While this may be 
> appropriate for small systems, it's not workable in complex environments.
> I believe Tuscany needs a wiring and activation model that is more dynamic 
> such that components can be added to (or removed from) the domain and wired 
> after the domain composite was initially activated.  This flexibility would 
> have implications to the way wiring is done and how multiplicity is validated 
> as the shape of the domain changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-1430) SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls

[Kelvin Goodson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513610
 ] 

Kelvin Goodson commented on TUSCANY-1430:
-

The symptoms that led to this JIRA are described in 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01266.html


> SDO codegen is needs to use internal property numbers for inverseAdd, 
> inverseRemove, and notify calls
> -
>
> Key: TUSCANY-1430
> URL: https://issues.apache.org/jira/browse/TUSCANY-1430
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Tools
>Affects Versions: Java-SDO-beta1
>Reporter: Frank Budinsky
> Fix For: Java-SDO-1.0
>
>
> The SDOClass.javajet needs to use INTERNAL_ features when calling 
> inverseAdd(), inverseRemove(), and notify() methods. ChangeSummary doesn't 
> work properly otherwise.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

That's a good idea. Then the only thing that really need to be set in
platform.properties file would be:
   tuscanySCA.install.dir
   and any possible overides

I'll put that together real quick and upload it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 9:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > Thanks for trying out the ant build scripts.
> >
> > Regarding core.dir, you're right, the name will need to change. I
> > can do that no problem.
> >
> > As for the "tuscanySCA.root.dir" : Your suggestion will work if you
> > only execute ant from the root directory, but not if you execute ant

> > from the runtime/core/src directory. That's why I put it in the
> > platform.properties, which is accessed by all build.xml's. Its
> > better ant coding style to have anything that needs to be configured

> > in a properties file, not in an ant build.xml file.
> >
>
> Yes... I realized that would limit you to running ant from the top
> level. So, as most of the info in platform.properties can be deduced
> would a better solution be to have a top level (or in antscripts dir)
> platform-properties.xml that
>  a) imports platform.properties for any overrides
>  b) sets the properties conditional on the platform.
>
> e.g.
>  
>
>  
>  
>
>  
>  
>
>  
>

the build.xml files would all import this top level file:


> > As for the platform.properties file for windows:
> > The property platform can/should be removed, its not necessary. If
> > the property "platform.compiler-definition" is set, then that value
> > will be used for the compiler selection, else it will get set to
> > msvc for windows as can be seen on line 18 of compilers.xml.
> >
> > I think the way this should ship is to have several
> > platform.properties files for the different platform:
> >platform.properties.linux
> >platform.properties.windows
> >platform.properties.mac
> > Which will each have values pre configured for the corresponding
> > platform. Then with either configure or a shell script, the platform

> > file wil be copied to platform.properties and the directory
> > properties will be set accordingly.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 7:08 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > I ran into a couple of issues tryingt o run this ant build. Firstly
> > I got an error with a path
> > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down
> > to the fact that the property core.dir is set in the top level
> > build.xml to "runtime/core/src" and in the
> > runtime/core/src/build.xml the same property name is used and set tu

> > "tuscany/sca/core". It looks to me like the second defintion of
> > core.dir is being ignored. I'm not an ant expert ... do properties
get propagated from higher level build files?
> > I got around this by changing the name of core.dir to src.dir in one

> > of the files.
> >
> > Rather than specifying the paths to the source code etc in the
> > platform.properties I would prefer to set these automatically so in
> > the top level build.xml I added:
> >
> > 
> >
> > and then based other properties from this. It seemed to work!
> >
> > Do these changes make sense?
> >
> > Cheers,
> >
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'd like some info on what I need to edit in the
platform.properties.
> > > Particularly:
> > >
> > > platform.compiler-definition=g++m32
> > > platform=rhas4u4_gcc346
> > >
> > > One good thing about automake is that it detects your
> > > platform/compiler etc automatically.
> > >
> > > Cheers,
> > >
> > >
> > > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > I put together some documentation for using ant with TuscanySCA
> > Native.
> > > >
> > > > How's this?
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA Rogue Wave Software -
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > Using ant to build TuscanySCA Native
> > > >
> > > >
> > > >
> > > > 1. Required Software to build TuscanySCA Native with ant:
> > > >
> > > > Ant:
> > > >Ant com

[jira] Assigned: (TUSCANY-1319) contribution meta documents not merged

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende reassigned TUSCANY-1319:


Assignee: Luciano Resende

> contribution meta documents not merged
> --
>
> Key: TUSCANY-1319
> URL: https://issues.apache.org/jira/browse/TUSCANY-1319
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Reporter: Huang Kai
>Assignee: Luciano Resende
> Fix For: Java-SCA-Next
>
>
> in SCA spec 1.10.2.2 write: "...accommodate this, it is also possible to have 
> an identically structured document at 
> META-INF/sca-contribution-generated.xml. If this document exists (or is 
> generated on an as-needed basis), it will be merged into the contents of 
> sca-contribution.xml, with the entries in sca-contribution.xml taking 
> priority if there are any conflicting declarations."
> Tuscany seems won't load sca-contribution-generated.xml if 
> sca-contribution.xml exists.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-915) User level documentation

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende resolved TUSCANY-915.
-

Resolution: Fixed

Fixed, Thanks Kevin and Amita for all your contributions

> User level documentation
> 
>
> Key: TUSCANY-915
> URL: https://issues.apache.org/jira/browse/TUSCANY-915
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS Documentation
>Reporter: Kevin Williams
> Fix For: Java-DAS-Next
>
>
> User level documentation for major DAS features

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-1328) can not locate service from a component whose implementation is composite

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reassigned TUSCANY-1328:
---

Assignee: Jean-Sebastien Delfino

> can not locate service from a component whose implementation is composite
> -
>
> Key: TUSCANY-1328
> URL: https://issues.apache.org/jira/browse/TUSCANY-1328
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-0.90
> Environment: Windows XP
>Reporter: Yang Lei
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> default.composite:
>local="true"
>   name="Iteration3Composite"
>   policySets="sns:secure" requires="cns:confidentiality"
>   targetNamespace="http://foo";
>   xmlns:foo="http://foo";
>   xmlns="http://www.osoa.org/xmlns/sca/1.0";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 
> http://www.osoa.org/xmlns/sca/1.0 ">
>
>  name="foo:MySimpleService"/>
>
> 
> MySimpleService.composite:
>local="true"
>   name="MySimpleService"
>   policySets="sns:secure" requires="cns:confidentiality"
>   targetNamespace="http://foo";
>   xmlns:foo="http://foo";
>   xmlns="http://www.osoa.org/xmlns/sca/1.0";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 
> http://www.osoa.org/xmlns/sca/1.0 ">
>promote="MyServiceComponentOrig/MyService">
> interface="mysca.test.myservice.MyService"/>
>   
>
>   class="mysca.test.myservice.impl.MyServiceImpl"/>
>
> 
> MyServiceImpl
> @Service(interfaces={MyService.class, MyServiceByDate.class, 
> MyListService.class, MyListServiceByYear.class})
> public class MyServiceImpl implements MyService, MyServiceByDate, 
> MyListService, MyListServiceByYear{
> ...
> }
> When I try to locateService of  "MySimpleServiceInRecursive/MyServiceOrig1", 
> got the following exception
> org.osoa.sca.ServiceRuntimeException: Service not found: 
> MySimpleServiceInRecursive/MyServiceOrig1 at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
>  at 
> org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
>  at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke
> Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (TUSCANY-353) The helloword sidefile (with no annotations) test I created does not read the default value from the side files

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-353.
--

Resolution: Fixed

no relevant now

> The helloword sidefile (with no annotations) test I created does not read the 
> default value from the  side files
> 
>
> Key: TUSCANY-353
> URL: https://issues.apache.org/jira/browse/TUSCANY-353
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
> Environment: Fedora Core 5
>Reporter: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: helloworld2.tar
>
>
> I attached the sample as a tar file. It looks like this...
> > hellworld2
> > src
> >   main
> > java - where the java source files go
> >   org
> > sample
> >   helloworld
> > HelloWorldService.java
> > HelloWorldServiceImpl.java
> > HelloWorldClient.java
> > resource - where data and configuration files go
> >   org
> > sample
> >   helloworld
> > HelloWorldServiceImpl.componentType
> >   sca.module
> >   test
> > java - where the files used to test the above source files go
> > target
> >   classes - where the compile class files will go
> > compile.sh
> > run.sh
> If you put this in a directory alongside the tuscany project and you have 
> populated target/j2se then compile.sh and run.sh should work, i.e.
> somedir
> helloworld2
> tuscany
>   java 
> target
>   j2se
> lots of jars
> when I run the test the property value null is returned and I was expecting 
> the default value from the side file so I expect I have done something stupid!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-1270) ArtifactProcessorExtensionPoint getProcessor methods aren't generic

[Luciano Resende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luciano Resende reassigned TUSCANY-1270:


Assignee: Luciano Resende

> ArtifactProcessorExtensionPoint getProcessor methods aren't generic
> ---
>
> Key: TUSCANY-1270
> URL: https://issues.apache.org/jira/browse/TUSCANY-1270
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: ant elder
>Assignee: Luciano Resende
>Priority: Trivial
> Fix For: Java-SCA-Next
>
>
> ArtifactProcessorExtensionPoint getProcessor methods aren't generic so for 
> example with a StAXArtifactProcessorExtensionPoint instance called 
> staxProcessors:
> staxProcessors.addArtifactProcessor(new MyBindingXMLProcessor());
> This does not work: MyBindingXMLProcessor p = 
> staxProcessors.getProcessor(MyXMLProcessor.class);
> It needs to be: MyBindingXMLProcessor p = (MyXMLProcessor) 
> staxProcessors.getProcessor(MyXMLProcessor.class);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1310) Port the feed aggregator sample from SCA Native to SCA Java

[Simon Laws (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws resolved TUSCANY-1310.
-

Resolution: Fixed

AlertAggregator now checked in under sca/demos

> Port the feed aggregator sample from SCA Native to SCA Java
> ---
>
> Key: TUSCANY-1310
> URL: https://issues.apache.org/jira/browse/TUSCANY-1310
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-Next
>Reporter: Simon Laws
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-Next
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-1208) Service using callback and methods that don't perform callback over WS binding hangs

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reassigned TUSCANY-1208:
---

Assignee: Simon Nash

Assigning to you ot check if your recent changes to the callback implementation 
fix this issue. Thanks.

> Service using callback and methods that don't perform callback over WS 
> binding hangs
> 
>
> Key: TUSCANY-1208
> URL: https://issues.apache.org/jira/browse/TUSCANY-1208
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
>
> I have a service exposed over the WS binding.   The service interface has 
> multiple methods.  Some methods perform callbacks and others do not.  The 
> methods that performs the callback functions while the others hang and 
> eventually timeout.  It appears that the binding is expecting all methods to 
> perform a 
> callback.  It appears that other have observed the same behavior.  I have not 
> seen this same behavior with the default binding.
> From muhwas:
>  yeah i had the same problem so i thought we can't
> inculde sync and async method together in one
> Interface. so i created two interfaces and two service
> one sync and other async.
> From post to list: 
> Service using WS Binding with Calback and multiple methods on interface hangs
> Lou Amodeo
> Thu, 12 Apr 2007 18:55:05 -0700
> I am seeing a hang when using the Web Services bindings to access a service
> that has a callback reference.  In this particular case the service expose
> several methods on the interface.  Only one of the methods invokes a method
> on the callback  reference.  The method that invokes the callback functions
> fine.  The issue is with the other methods on the interface.  It appears
> that the binding is expecting every request to the service to perfrom a
> callback.  What I have found is the latch associated with doneSignal.await()
> is never freed up.   Also since this method did not use invoke a callback
> not sure why it would be using an Async message receiver rather than the
> Sync version?  Its almost as if the binding is anticipating a mandatory
> callback rather than waiting for one to actually be called.  After about 5
> minutes the request will timeout.   Thanks for your help.
> *public* Axis2ServiceInOutAsyncMessageReceiver() {
> }
> *public* *final* *void* receive(*final* MessageContext messageCtx) {
> *try* {
> Object messageId = messageCtx.getMessageID();
> *if* (messageId == *null*) {
> messageId = *new* MessageId();
> }
> // Now use message id as index to context to be used by callback
> // target invoker
> CountDownLatch doneSignal = *new* CountDownLatch(1);
> InvocationContext invCtx =
> service.*new* InvocationContext(messageCtx, operation,
> getSOAPFactory(messageCtx), doneSignal);
> service.addMapping(messageId, invCtx);
> invokeBusinessLogic(messageCtx, messageId);
> *try* {
> doneSignal.await();
> } *catch*(InterruptedException e) {
> e.printStackTrace();
> Timeout occurs after 5 minutes:
> [4/12/07 21:49:43:529 EDT] 002b SystemErr R Exception in thread "Axis2
> Task" *org.apache.tuscany.spi.wire.InvocationRuntimeException*:
> org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
> *java.net.SocketTimeoutException*: Async operation timed out
> [4/12/07 21:49:43:529 EDT] 002b SystemErr R at
> org.apache.tuscany.binding.axis2.Axis2ReferenceCallback.onError(*
> Axis2ReferenceCallback.java:54*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
> (*OutInAxisOperation.java:417*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> (*ThreadPoolExecutor.java:665*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
> (*ThreadPoolExecutor.java:690*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at java.lang.Thread.run(*
> Thread.java:803*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R Caused by:
> org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
> *java.net.SocketTimeoutException*: Async operation timed out
> at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(*
> HTTPTransportSender.java:271*)
> at org.apache.axis2.engine.AxisEngine.send(*AxisEngine.java:464*)
> at org.apache.axis2.description.OutInAxisOperationClient.send(*
> OutInAxisOperation.java:325*)
> at
> org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
> (*OutInAxisOperation.java:400*)
> at

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

I have now ported 4 or 5 fixes that had been made to the trunk but not to
the branch (task 3).  While we are in this pre-release phase if you could
create a patch of your local workspace when working in the trunk before
committing and attach it to the JIRA,  then that eases the task of porting
to the branch.  Better still would be to apply the patch to the branch too.

Now I'm going to look at the samples javadoc issues,   phase 1 = tasks 11,
12, 13, 14

Regards, Kelvin.

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


just did 4,5,7,8,9,10(a) -- still not run the linux script
so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly numbered
as 12,13,14 -- doh!)

2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
10b ensure that the runsamples.sh script runs ok in a linux env
11 fix up bad javadoc links in samples index.html
12 exclude samples infrastructure classes from samples javadoc
13 fix link back to tuscany site from overview.html to point to the get
involved page
14 incorporate Haleh's suggested paragraph [1] into overview.html
15 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
16 put an overview doc into the sdo lib project's javadoc
17 add the change summary aspects of the medical scenario sample

I'm going to tackle 3 now

Kelvin.

On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> I'm going to number off the non jira related tasks so that its easy to
> reference them
>
> I just did 1 and now plan to do 4,5,7,8,9
>
> 1 the pom has a "provided scope" dependency on stax  -- I will fix this
> as per my note to tuscany-dev
> 2 use rat results to fix license header issues and post rat results
> 3 check that all recent fixes in the trunk since the branch was made
> have equivalent fixes in the branch
>
> the following have been raised by comments on RC1
>
> 4 NOTICE files (create separate ones for impl and bin and ensure no
> disclaimer contained)
> 5 need to update release notes with descriptive para and fixed jiras
> 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> 7 should remove EPL license from src distro
> 8 add stax reference in bin distro license
> 9 add readme to bin distro samples folder
> 10 fix up runsamples scripts to be more robust/helpful and ensure that
> the runsamples.sh script runs ok in a linux env
> 11 fix up bad javadoc links in samples index.html
> 12 exclude samples infrastructure classes from samples javadoc
> 13 fix link back to tuscany site from overview.html to point to the get
> involved page
> 14 incorporate Haleh's suggested paragraph [1] into overview.html
>
> and some of my own todos that I hope to get to
> 12 ensure consistency of each sample program's javadoc to point back to
> central instructions for running samples
> 13 put an overview doc into the sdo lib project's javadoc
> 14 add the change summary aspects of the medical scenario sample
>
> Regards, Kelvin
>
> On 17/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > This release is running later than I had hoped due to extra jiras
> > being added to the plan, and a few issues that have come up after recent
> > fixe, so we are a bit behind where I'd proposed we should be in terms of
> > getting this release out.  Please help with some of these TODOs if you can.
> > If you plan to tackle anything please post here so that we don't overlap;
> > I'll do the same.
> >
> > these are the things that I think are "must-fix"
> >
> > 1143 -- the issues re test failures are being resolved   -- david's
> > working on this
> > 1429 -- i've looked at this and it is fine apart from the casting to
> > HelperContextImpls -- i put a note on the jira,
> > 1428 -- note appended to jira asking for code to exercise/demonstrate
> > the fix
> >
> > other issues raised on the list
> >
> > the pom has a "provided scope" dependency on stax  -- I will fix this
> > as per my note to tuscany-dev
> > use rat results to fix license header issues and post rat results
> > check that all recent fixes in the trunk since the branch was made
> > have equivalent fixes in the branch
> >
> > the following have been raised by comments on RC1
> >
> > NOTICE files (create separate ones for impl and bin and ensure no
> > disclaimer contained)
> > need to update release notes with descriptive para and fixed jiras
> > need to remove dependencies on snapshot plugins (rfeng 13/7)
> > should remove EPL license from src distro
> > add stax reference in bin distro license
> > add readme to bin distro samples folder
> > fix up runsamples scripts to be more robust/helpful and ensure that
> > the runsamples.sh script runs ok in a linux env
> > fix up bad javadoc links in samples index.html
> > exclude samples infrastructure classes from samples javadoc
> > fix link back to tusc

[jira] Resolved: (TUSCANY-1267) Provide a way for binding extensions to get at the interface defined on the associated service or reference

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1267.
-

Resolution: Fixed

A reference binding provider is given the reference configured with the 
binding, from it it can get the interface contract specified on the reference.

Please reopen if this does not meet your requirement. Thanks.

> Provide a way for binding extensions to get at the interface defined on the 
> associated service or reference
> ---
>
> Key: TUSCANY-1267
> URL: https://issues.apache.org/jira/browse/TUSCANY-1267
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: ant elder
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> With the following:
>  promote="HelloWorldServiceComponent/helloWorldService">
>  interface="http://helloworld#wsdl.interface(HelloWorld)" />
>  wsdlElement="http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)"/>
> 
> it doesn't look like there is any way for the Axis2 binding or WebService 
> binding to get at the interface.wsdl definition ascociated with the 
> reference. A similar problem exists for  although it is possible to 
> get to the interface there from one of the runtime objects.
> I wondered if o.a.t.assembly.Binding could have an interfaceContract which 
> could be set by the runtime before calling the Binding resolve method.
> This would also make all the extension code which needs to mess about with 
> binding interfaces much simpler. 
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: SDO Snapshot, was Re: Build break in implementation-das?

[kelvin goodson]

I just published a fresh SDO snapshot
Kelvin.

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


Kelvin or others working more closely with SDO, could someone please
publish the latest SDO Snapshots ?

On 7/18/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> I did a clean checkout this morning my time and built SCA from an
> empty Maven repo.  I got the same build error in implementation-das
> that Sebastien was seeing.
>
> I was hoping that starting with an empty maven repo would cause the
> correct levels of SDO and DAS to be downloaded but it seems that this
> is not the case.
>
> Is it always necessary to build SDO and/or DAS before building SCA?
> When will the correct SDO and DAS levels be published as snapshots so
> that this is not necessary?
>
> For now I have commented out implementation-das from my build so that
> I can make progress.
>
>Simon
>
> Jean-Sebastien Delfino wrote:
>
> > Luciano Resende wrote:
> >
> >> Everything is building ok for me too, is this the only module that is
> >> failing for you ?
> >>
> >>
> >
> > It works now, see:
> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20174.html
> >
> > Thanks
> > --
> > Jean-Sebastien
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Resolved: (TUSCANY-897) BPEL container based on Apache Ode

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-897.


Resolution: Fixed

Thanks for the patches. It looks like the BPEL implementation extension is 
going again, so I'm assuming that we can mark this JIRA resolve. Please reopen 
or even better create a new JIRA for new contributions based on the latest 
Tuscany code base. Thanks.

> BPEL container based on Apache Ode
> --
>
> Key: TUSCANY-897
> URL: https://issues.apache.org/jira/browse/TUSCANY-897
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA BPEL Implementation Extension
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
> Attachments: BpelServerLoader.java, container.bpel.zip, 
> container.bpel_edited.zip, Ode_Jar_New1.zip, Ode_Jar_New2.zip
>
>
> JIRA for attaching patches to create the Tuscany BPEL container based on 
> Apache Ode.
> There's a white paper on SCA and BPEL at: 
> http://osoa.org/display/Main/Service+Component+Architecture+Specifications
> A draft specification is available at: 
> http://osoa.org/display/Main/Service+Component+Architecture+Specifications
> The Tuscany container is at: 
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (TUSCANY-966) getRequestContext() does not return a Context

[Jean-Sebastien Delfino (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513633
 ] 

Jean-Sebastien Delfino commented on TUSCANY-966:


Different symptom with the Trunk level. ComponentContext.getRequestContext() 
returns null.

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Integration Tests
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (TUSCANY-966) getRequestContext() does not return a Context

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reassigned TUSCANY-966:
--

Assignee: Jean-Sebastien Delfino

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Integration Tests
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1429) Using default helper context got ClassCastException due to T-1317

[Fuhwei Lwo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fuhwei Lwo updated TUSCANY-1429:


Attachment: 1429.patch

Just found out the existing SDOUtil.createXMLStreamHelper(HelperContext hc) has 
satisfied the requirement of getting the XMLStreamHelper without casting. I 
have changed the test cases to use the existing SDOUtil API.

> Using default helper context got ClassCastException due to T-1317
> -
>
> Key: TUSCANY-1429
> URL: https://issues.apache.org/jira/browse/TUSCANY-1429
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-SDO-M2
> Environment: WinXP
>Reporter: Fuhwei Lwo
> Fix For: Java-SDO-1.0
>
> Attachments: 1429.patch, 1429.patch
>
>
> Starting from T-1317, we started to use HelperContext as the scope instead of 
> TypeHelper or XSDHelper. The ClassCastException problem starts to appear when 
> we need to cast HelperContext to HelperContextImpl to access the 
> XMLStreamHelperImpl which is not a spec compliant Helper because the default 
> helper context is not an instance of HelperContextImpl.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

11 seemed to be a no-op
13 is done
14 is done

leaving ...

2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
10b ensure that the runsamples.sh script runs ok in a linux env
12 exclude samples infrastructure classes from samples javadoc
15 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
16 put an overview doc into the sdo lib project's javadoc
17 add the change summary aspects of the medical scenario sample


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


I have now ported 4 or 5 fixes that had been made to the trunk but not to
the branch (task 3).  While we are in this pre-release phase if you could
create a patch of your local workspace when working in the trunk before
committing and attach it to the JIRA,  then that eases the task of porting
to the branch.  Better still would be to apply the patch to the branch too.

Now I'm going to look at the samples javadoc issues,   phase 1 = tasks 11,
12, 13, 14

Regards, Kelvin.

On 18/07/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
>
> just did 4,5,7,8,9,10(a) -- still not run the linux script
> so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly
> numbered as 12,13,14 -- doh!)
>
> 2 use rat results to fix license header issues and post rat results
> 3 check that all recent fixes in the trunk since the branch was made
> have equivalent fixes in the branch
> 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> 10b ensure that the runsamples.sh script runs ok in a linux env
> 11 fix up bad javadoc links in samples index.html
> 12 exclude samples infrastructure classes from samples javadoc
> 13 fix link back to tuscany site from overview.html to point to the get
> involved page
> 14 incorporate Haleh's suggested paragraph [1] into overview.html
> 15 ensure consistency of each sample program's javadoc to point back to
> central instructions for running samples
> 16 put an overview doc into the sdo lib project's javadoc
> 17 add the change summary aspects of the medical scenario sample
>
> I'm going to tackle 3 now
>
> Kelvin.
>
> On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > I'm going to number off the non jira related tasks so that its easy to
> > reference them
> >
> > I just did 1 and now plan to do 4,5,7,8,9
> >
> > 1 the pom has a "provided scope" dependency on stax  -- I will fix
> > this as per my note to tuscany-dev
> > 2 use rat results to fix license header issues and post rat results
> > 3 check that all recent fixes in the trunk since the branch was made
> > have equivalent fixes in the branch
> >
> > the following have been raised by comments on RC1
> >
> > 4 NOTICE files (create separate ones for impl and bin and ensure no
> > disclaimer contained)
> > 5 need to update release notes with descriptive para and fixed jiras
> > 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> > 7 should remove EPL license from src distro
> > 8 add stax reference in bin distro license
> > 9 add readme to bin distro samples folder
> > 10 fix up runsamples scripts to be more robust/helpful and ensure that
> > the runsamples.sh script runs ok in a linux env
> > 11 fix up bad javadoc links in samples index.html
> > 12 exclude samples infrastructure classes from samples javadoc
> > 13 fix link back to tuscany site from overview.html to point to the
> > get involved page
> > 14 incorporate Haleh's suggested paragraph [1] into overview.html
> >
> > and some of my own todos that I hope to get to
> > 12 ensure consistency of each sample program's javadoc to point back
> > to central instructions for running samples
> > 13 put an overview doc into the sdo lib project's javadoc
> > 14 add the change summary aspects of the medical scenario sample
> >
> > Regards, Kelvin
> >
> > On 17/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > >
> > > This release is running later than I had hoped due to extra jiras
> > > being added to the plan, and a few issues that have come up after recent
> > > fixe, so we are a bit behind where I'd proposed we should be in terms of
> > > getting this release out.  Please help with some of these TODOs if you 
can.
> > > If you plan to tackle anything please post here so that we don't overlap;
> > > I'll do the same.
> > >
> > > these are the things that I think are "must-fix"
> > >
> > > 1143 -- the issues re test failures are being resolved   -- david's
> > > working on this
> > > 1429 -- i've looked at this and it is fine apart from the casting to
> > > HelperContextImpls -- i put a note on the jira,
> > > 1428 -- note appended to jira asking for code to
> > > exercise/demonstrate the fix
> > >
> > > other issues raised on the list
> > >
> > > the pom has a "provided scope" dependency on stax  -- I will fix
> > > this as per my note to tusc

[jira] Commented: (TUSCANY-1208) Service using callback and methods that don't perform callback over WS binding hangs

[Simon Nash (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513645
 ] 

Simon Nash commented on TUSCANY-1208:
-

This is a known limitation of the current Web Service binding implementation of 
callbacks, which uses the reply message to carry the callback request.  The 
client always blocks and waits for the reply message because it might contain a 
callback.  When the reply message comes back, the client invokes the callback 
asynchronously using the arguments passed on the reply message, and also 
releases the waiting caller thread to that it returns from the forward call.  
If the server side does not do a callback, the client never returns from the 
called method.

I am working on a spec-compliant version of the Web Service binding 
implementation of callbacks, which will resolve this issue.  This will use 
WS-Addressing for the callback rather than overloading the reply message.

> Service using callback and methods that don't perform callback over WS 
> binding hangs
> 
>
> Key: TUSCANY-1208
> URL: https://issues.apache.org/jira/browse/TUSCANY-1208
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
>
> I have a service exposed over the WS binding.   The service interface has 
> multiple methods.  Some methods perform callbacks and others do not.  The 
> methods that performs the callback functions while the others hang and 
> eventually timeout.  It appears that the binding is expecting all methods to 
> perform a 
> callback.  It appears that other have observed the same behavior.  I have not 
> seen this same behavior with the default binding.
> From muhwas:
>  yeah i had the same problem so i thought we can't
> inculde sync and async method together in one
> Interface. so i created two interfaces and two service
> one sync and other async.
> From post to list: 
> Service using WS Binding with Calback and multiple methods on interface hangs
> Lou Amodeo
> Thu, 12 Apr 2007 18:55:05 -0700
> I am seeing a hang when using the Web Services bindings to access a service
> that has a callback reference.  In this particular case the service expose
> several methods on the interface.  Only one of the methods invokes a method
> on the callback  reference.  The method that invokes the callback functions
> fine.  The issue is with the other methods on the interface.  It appears
> that the binding is expecting every request to the service to perfrom a
> callback.  What I have found is the latch associated with doneSignal.await()
> is never freed up.   Also since this method did not use invoke a callback
> not sure why it would be using an Async message receiver rather than the
> Sync version?  Its almost as if the binding is anticipating a mandatory
> callback rather than waiting for one to actually be called.  After about 5
> minutes the request will timeout.   Thanks for your help.
> *public* Axis2ServiceInOutAsyncMessageReceiver() {
> }
> *public* *final* *void* receive(*final* MessageContext messageCtx) {
> *try* {
> Object messageId = messageCtx.getMessageID();
> *if* (messageId == *null*) {
> messageId = *new* MessageId();
> }
> // Now use message id as index to context to be used by callback
> // target invoker
> CountDownLatch doneSignal = *new* CountDownLatch(1);
> InvocationContext invCtx =
> service.*new* InvocationContext(messageCtx, operation,
> getSOAPFactory(messageCtx), doneSignal);
> service.addMapping(messageId, invCtx);
> invokeBusinessLogic(messageCtx, messageId);
> *try* {
> doneSignal.await();
> } *catch*(InterruptedException e) {
> e.printStackTrace();
> Timeout occurs after 5 minutes:
> [4/12/07 21:49:43:529 EDT] 002b SystemErr R Exception in thread "Axis2
> Task" *org.apache.tuscany.spi.wire.InvocationRuntimeException*:
> org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
> *java.net.SocketTimeoutException*: Async operation timed out
> [4/12/07 21:49:43:529 EDT] 002b SystemErr R at
> org.apache.tuscany.binding.axis2.Axis2ReferenceCallback.onError(*
> Axis2ReferenceCallback.java:54*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
> (*OutInAxisOperation.java:417*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> (*ThreadPoolExecutor.java:665*)
> [4/12/07 21:49:43:539 EDT] 002b SystemErr R at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
> (*ThreadPoolExecutor.java:690*)
> [4/12/07 21:49:43:539 EDT] 002b System

[jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-1431:
-

Attachment: net.sf.saxon.8.9.zip

as long as maven repos does not contain required version of saxon, this zip 
file can 
be extracted in M2_REPO

> DAS with XQuery based data access support
> -
>
> Key: TUSCANY-1431
> URL: https://issues.apache.org/jira/browse/TUSCANY-1431
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java DAS XQuery
>Affects Versions: Java-DAS-Next
>Reporter: Amita Vadhavkar
> Fix For: Java-DAS-Next
>
> Attachments: 1431.patch, 1431.patch, 1431_api.patch, 
> 1431_xquery.patch, net.sf.saxon.8.9.zip
>
>
> place for submitting incremental patches for the ground work of XQuery DAS

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Website ACL

[Venkata Krishnan]

Thank you, Ant.

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

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

   ...ant

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



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

Question on callback bindings

[Raymond Feng]

Hi,

Assuming we have the following declaration: reference r1 is wired to service 
s1.



   http://ns1#wsdl.interface(Service1)" 
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>

   
   
   
   



   http://ns1#wsdl.interface(Service1)" 
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>

   
   
   
   


Then the callback path seems to be following: s1 (binding.ws) ---> r1 
(binding.ws). Is this like another web service call? or is it really that 
the s1 provides asynchronous response to the web service layer and the web 
service client is making a callback?


For the forward call, r1 --> ws client ..(soap/http) .ws 
service -->s1. Which path should be used for the callback?


1) s1--> ws client ..(soap/http) .ws service -->r1 (another regular 
ws call)

or
2) s1--(ws-callback)--> ws server ...(soap/http) ... ws 
client --(ws-callback)-->r1 (over ws callback MEP)


Thanks,
Raymond




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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

There is a problem now with this build on a clean system.
tuscany-sca-config.h is a header generated by automake that contains
directives (IS_DARWIN for example). We will need to have the ant build
set compiler options for our conditional compiles instead of this.

Cheers,

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> That's a good idea. Then the only thing that really need to be set in
> platform.properties file would be:
>tuscanySCA.install.dir
>and any possible overides
>
> I'll put that together real quick and upload it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:00 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > Thanks for trying out the ant build scripts.
> > >
> > > Regarding core.dir, you're right, the name will need to change. I
> > > can do that no problem.
> > >
> > > As for the "tuscanySCA.root.dir" : Your suggestion will work if you
> > > only execute ant from the root directory, but not if you execute ant
>
> > > from the runtime/core/src directory. That's why I put it in the
> > > platform.properties, which is accessed by all build.xml's. Its
> > > better ant coding style to have anything that needs to be configured
>
> > > in a properties file, not in an ant build.xml file.
> > >
> >
> > Yes... I realized that would limit you to running ant from the top
> > level. So, as most of the info in platform.properties can be deduced
> > would a better solution be to have a top level (or in antscripts dir)
> > platform-properties.xml that
> >  a) imports platform.properties for any overrides
> >  b) sets the properties conditional on the platform.
> >
> > e.g.
> >  
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
>
> the build.xml files would all import this top level file:
>
>
> > > As for the platform.properties file for windows:
> > > The property platform can/should be removed, its not necessary. If
> > > the property "platform.compiler-definition" is set, then that value
> > > will be used for the compiler selection, else it will get set to
> > > msvc for windows as can be seen on line 18 of compilers.xml.
> > >
> > > I think the way this should ship is to have several
> > > platform.properties files for the different platform:
> > >platform.properties.linux
> > >platform.properties.windows
> > >platform.properties.mac
> > > Which will each have values pre configured for the corresponding
> > > platform. Then with either configure or a shell script, the platform
>
> > > file wil be copied to platform.properties and the directory
> > > properties will be set accordingly.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 18, 2007 7:08 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > I ran into a couple of issues tryingt o run this ant build. Firstly
> > > I got an error with a path
> > > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down
> > > to the fact that the property core.dir is set in the top level
> > > build.xml to "runtime/core/src" and in the
> > > runtime/core/src/build.xml the same property name is used and set tu
>
> > > "tuscany/sca/core". It looks to me like the second defintion of
> > > core.dir is being ignored. I'm not an ant expert ... do properties
> get propagated from higher level build files?
> > > I got around this by changing the name of core.dir to src.dir in one
>
> > > of the files.
> > >
> > > Rather than specifying the paths to the source code etc in the
> > > platform.properties I would prefer to set these automatically so in
> > > the top level build.xml I added:
> > >
> > > 
> > >
> > > and then based other properties from this. It seemed to work!
> > >
> > > Do these changes make sense?
> > >
> > > Cheers,
> > >
> > >
> > > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > I'd like some info on what I need to edit in the
> platform.properties.
> > > > Particularly:
> > > >
> > > > platform.compiler-definition=g++m32
> > > > platform=rhas4u4_gcc346
> > > >
> > > > One good thing about automake is that it detects your
> > > > platform/compiler etc automatically.
> > > >
> > > > Ch

Re: SDO Snapshot, was Re: Build break in implementation-das?

[Simon Nash]

I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
maven repo, then doing a complete clean and rebuild.  I got the same
failure as shown below.  Any ideas?

  Simon

Running org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.tuscany.sca.implementation.das.DASTestCase
Initializing DAS
java.lang.UnsupportedOperationException
at 
org.apache.tuscany.sdo.impl.DataObjectBase.getStaticType(DataObjectBase.java:393)
at 
org.apache.tuscany.sdo.impl.DataObjectBase.eStaticClass(DataObjectBase.java:388)
at 
org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eClass(ExtensibleDataObjectImpl.java:118)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processObject(XMLHandler.java:2161)
at 
org.eclipse.emf.ecore.xmi.impl.SAXXMLHandler.processObject(SAXXMLHandler.java:93)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFeatureType(XMLHandler.java:1926)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:1791)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1569)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(XMLHandler.java:1237)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1165)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1247)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:883)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:866)
at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(SDOXMLResourceImpl.java:401)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:779)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at 
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266)
at 
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239)
at 
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at 
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
at 
org.apache.tuscany.das.rdb.util.ConfigUtil.loadConfig(ConfigUtil.java:52)
at org.apache.tuscany.das.rdb.impl.DASImpl.(DASImpl.java:62)
at 
org.apache.tuscany.das.rdb.impl.DASFactoryImpl.createDAS(DASFactoryImpl.java:31)
at 
org.apache.tuscany.sca.implementation.das.provider.DataAccessEngineManager.initializeDAS(DataAccessEngineManager.java:45)
at 
org.apache.tuscany.sca.implementation.das.provider.DataAccessEngineManager.getDAS(DataAccessEngineManager.java:65)
at 
org.apache.tuscany.sca.implementation.das.provider.DASImplementationProvider.createInvoker(DASImplementationProvider.java:52)
at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.addImplementationInterceptor(CompositeActivatorImpl.java:641)
at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createServiceWire(CompositeActivatorImpl.java:600)
at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:556)
at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:376)
at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorI

[jira] Resolved: (TUSCANY-1270) ArtifactProcessorExtensionPoint getProcessor methods aren't generic

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1270.
-

Resolution: Fixed

Fixed, getProcessor is generic now

> ArtifactProcessorExtensionPoint getProcessor methods aren't generic
> ---
>
> Key: TUSCANY-1270
> URL: https://issues.apache.org/jira/browse/TUSCANY-1270
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
>Reporter: ant elder
>Assignee: Luciano Resende
>Priority: Trivial
> Fix For: Java-SCA-Next
>
>
> ArtifactProcessorExtensionPoint getProcessor methods aren't generic so for 
> example with a StAXArtifactProcessorExtensionPoint instance called 
> staxProcessors:
> staxProcessors.addArtifactProcessor(new MyBindingXMLProcessor());
> This does not work: MyBindingXMLProcessor p = 
> staxProcessors.getProcessor(MyXMLProcessor.class);
> It needs to be: MyBindingXMLProcessor p = (MyXMLProcessor) 
> staxProcessors.getProcessor(MyXMLProcessor.class);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: SDO Snapshot, was Re: Build break in implementation-das?

[Jean-Sebastien Delfino]

Simon Nash wrote:

I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
maven repo, then doing a complete clean and rebuild.  I got the same
failure as shown below.  Any ideas?

  Simon

Running 
org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.tuscany.sca.implementation.das.DASTestCase
Initializing DAS
java.lang.UnsupportedOperationException
at 
org.apache.tuscany.sdo.impl.DataObjectBase.getStaticType(DataObjectBase.java:393) 

at 
org.apache.tuscany.sdo.impl.DataObjectBase.eStaticClass(DataObjectBase.java:388) 

at 
org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.eClass(ExtensibleDataObjectImpl.java:118) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processObject(XMLHandler.java:2161) 

at 
org.eclipse.emf.ecore.xmi.impl.SAXXMLHandler.processObject(SAXXMLHandler.java:93) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFeatureType(XMLHandler.java:1926) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:1791) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1569) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(XMLHandler.java:1237) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1165) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1247) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:883) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:866) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627) 

at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(SDOXMLResourceImpl.java:401) 

at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) 

at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330) 

at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:779) 

at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) 

at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) 

at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) 

at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) 

at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) 

at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) 


at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at 
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)
at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666) 

at 
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:585) 

at 
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634) 

at 
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:266) 

at 
org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:239) 

at 
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:97)
at 
org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:79)
at 
org.apache.tuscany.das.rdb.util.ConfigUtil.loadConfig(ConfigUtil.java:52)

at org.apache.tuscany.das.rdb.impl.DASImpl.(DASImpl.java:62)
at 
org.apache.tuscany.das.rdb.impl.DASFactoryImpl.createDAS(DASFactoryImpl.java:31) 

at 
org.apache.tuscany.sca.implementation.das.provider.DataAccessEngineManager.initializeDAS(DataAccessEngineManager.java:45) 

at 
org.apache.tuscany.sca.implementation.das.provider.DataAccessEngineManager.getDAS(DataAccessEngineManager.java:65) 

at 
org.apache.tuscany.sca.implementation.das.provider.DASImplementationProvider.createInvoker(DASImplementationProvider.java:52) 

at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.addImplementationInterceptor(CompositeActivatorImpl.java:641) 

at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createServiceWire(CompositeActivatorImpl.java:600) 

at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:556) 

at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:376) 

at 
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:790) 

at 
org.apache.tuscany.sca

Handling of self references, was: Fixes for Tuscany SCA Java 0.91 RC4?

[Jean-Sebastien Delfino]

ant elder wrote:

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


...


and other bindings that don't support references) break
when initializing self references



Isn't this a more general problem with the way self references are handle
right now? What was the fix that was done for this, I can't see any 
commit

comments mentioning it?

  ...ant



Raymond may be able to give more details, but it looks like it was a 
change in CompositeActivator in the commit for TUSCANY-1435.


We currently create self references for all services of a component to 
allow the component to get a self reference (see 
ComponentContext.createSelfReference) and for top level components this 
also allows SCADomain.locateService to work off that reference.


Some bindings do not support references, so we need to be able to detect 
that (I guess they don't have a ReferenceBindingProvider) and for 
services configured with these bindings createSelfReference should throw 
an exception.


I think we could improve the code to detect that a binding does not 
handle references early on, instead of just catching an exception like 
we do now. Any other concrete proposal to improve the handling of self 
references?


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-1451) Fix the algorithm to determine references for an unannotated java class

[Raymond Feng (JIRA)]

Fix the algorithm to determine references for an unannotated java class
---

 Key: TUSCANY-1451
 URL: https://issues.apache.org/jira/browse/TUSCANY-1451
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
Reporter: Raymond Feng


http://www.osoa.org/display/Main/Errata+for+Java+Component+Implementation+V1.00
4. Fix and clarify algorithm for determining references of an unannotated POJO 
(section 1.2.7)
Replace the algorithm on lines 369-377 with the following:

1) If the Java type is an interface annotated with @Remotable, then it's a
reference.

2) Otherwise, if the Java type is an array whose element type is an
interface annotated with @Remotable, then it's a reference.

3) Otherwise, if the Java type is a java.util.Collection or a 
sub-interface
or sub-class of it, if the parameterized type of the collection is an
interface annotated with @Remotable, then it's a reference.

4) Otherwise it's a property.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1441) Core wiring framework should treat SCA binding like other bindings

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng resolved TUSCANY-1441.
---

Resolution: Fixed

Patch applied. Thanks!

> Core wiring framework should treat SCA binding like other bindings
> --
>
> Key: TUSCANY-1441
> URL: https://issues.apache.org/jira/browse/TUSCANY-1441
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.91
> Environment: Windows XP
>Reporter: Simon Nash
>Assignee: Simon Nash
> Fix For: Java-SCA-Next
>
> Attachments: newfiles.zip, svndiff
>
>
> The core wiring framework should treat the SCA binding just like any other 
> binding.  The code to handle direct local "short circuit" target invocation 
> should be within the SCA binding and not done by having special wiring logic 
> in CompositeActivatorImpl. 
> This patch also adds an SCABindingProcessor to enable  elements 
> to be specified in SCDL.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1145) DefaultSCAContainer.stop()/LauncherImpl.shutdownRuntime() is leaking memory

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1145.
-

Resolution: Fixed

I tried to change the PropertyTest test case to init/destroy on a test method 
basis, and I'm not seeing an out of memory exception anymore. The leak has been 
fixed.

> DefaultSCAContainer.stop()/LauncherImpl.shutdownRuntime()  is leaking memory
> 
>
> Key: TUSCANY-1145
> URL: https://issues.apache.org/jira/browse/TUSCANY-1145
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-M2
>Reporter: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> The PropertyTestCase from iTest-propertyTest suite is failing with 
> OutOfMemoryError. It has 18 test methods. As a result, the SCAContainer is 
> started and stopped for 18 times. The last two methods run out of memory due 
> to leaks in stop(). If we comment out a few methods or just run the failing 
> methods, it works fine. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Fixes for Tuscany SCA Java 0.91 RC4?

[Jean-Sebastien Delfino]

Venkata Krishnan wrote:

Thanks Raymond.

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

Hi,

I have merged the fix from trunk into 0.91 branch under r557146. We 
can pull

it into RC4 if we decide the re-spin.

Thanks,
Raymond

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


> It looks like there are still some issues with our 0.91 RC3.
>
> In addition to the issues reported on incubator-general in:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg14743.html
>
> I'd like to see two code issues fixed:
> - Using two bindings that extend PojoBinding in the same composite 
(e.g.

> JSON and EJB) causes an ClassCastException
> - JSON binding (and other bindings that don't support references) 
break

> when initializing self references
>
> Both issues are serious, but have been fixed by Raymond in trunk. 
Details

> and subversion commits can be found at
> http://issues.apache.org/jira/browse/TUSCANY-1435.
>
> Any chance to get this fix merged into 0.91 RC4?
>
> --
> Jean-Sebastien
>
>


Also there's a workaround:
- don't use tuscany-sca-all.jar if you want to use the JSON binding, add 
the specific binding JAR you need to your classpath (or package it in 
your WAR if you're running in a Web app)
- move your  element out of  and use a 
/ instead.


--
Jean-Sebastien


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

Re: SDO Snapshot, was Re: Build break in implementation-das?

[Simon Nash]

Jean-Sebastien Delfino wrote:


Simon Nash wrote:


I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
maven repo, then doing a complete clean and rebuild.  I got the same
failure as shown below.  Any ideas?

  Simon

Running 
org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.tuscany.sca.implementation.das.DASTestCase
Initializing DAS
(cut)


That's what I was seeing too. Rebuilding SDO and DAS locally fixed the 
problem for me. I guess the SDO snapshots need to be republished.



According to Kelvin, the SDO snapshots were republished before I
cleaned out my repo and reran the build.  I can work around it by
doing what you have done, but it should be possible to get a clean
build of SCA from published snapshots of SDO and DAS.

  Simon



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

[jira] Created: (TUSCANY-1452) InterfaceContract and its associated objects should be Cloneable

[Matthew Sykes (JIRA)]

InterfaceContract and its associated objects should be Cloneable


 Key: TUSCANY-1452
 URL: https://issues.apache.org/jira/browse/TUSCANY-1452
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Assembly Model, Java SCA Core Runtime
Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next
Reporter: Matthew Sykes


Given the current infrastructure in 0.90, it is difficult for a binding 
provider to setup a binding-specific databinding on the binding 
InterfaceContract because the InterfaceContract, Interface, and Operation model 
objects can't be easily cloned.

While the binding providers are allowed to give the runtime an 
InterfaceContract for the binding, if the data describing the interface comes 
from something other than the binding configuration the binding will typically 
use the InterfaceContract from the componentType.  Without a way to copy the 
InterfaceContract, the binding provider will need to create an interface from 
scratch by using one of the interface processors or the assembly model 
factories and custom logic.

For example, the axis2 binding will use the portType from wsdl document 
associated with the  element in scdl to create an 
InterfaceContract or the binding.  This approach requires the 
WebServiceBindngProcessor to access the interface introspector and introspect 
an interface contract.

I've discussed this a bit with Raymond who has agreed that making the 
InterfaceContract, Interface, Operation, and associated objects cloneable would 
allow a binding provider implementation to get an instance of the interface 
contract that could be updated with a binding-specific databinding.  This is 
similar to what existed in the M2 branches of days gone by.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1396) org.apache.tuscany.sca.assembly.Implementation interface needs to expose getMaxAge() and getMaxIdleTime()

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1396.
-

Resolution: Fixed

MaxAge and MaxIdleTime are specific to the Java implementation type, so I don't 
think that they should be added to oat.assembly.Implementation, but they are on 
the oat.assembly.implementation.JavaImplementation SPI interface, allowing you 
to get it without having to depend on the JavaImplementationImpl implementation 
class.

> org.apache.tuscany.sca.assembly.Implementation interface  needs to expose 
> getMaxAge() and getMaxIdleTime()
> --
>
> Key: TUSCANY-1396
> URL: https://issues.apache.org/jira/browse/TUSCANY-1396
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-0.90
>Reporter: Lou Amodeo
>
> I am trying to  access the getMaxAge() and getMaxIdleTime attribute for a 
> java implementation using getImplementation() from RuntimeComponent and the 
> returned interface org.apache.tuscany.sca.assembly.Implementation  does not 
> expose these getters.  They are however available on the underlying 
> JavaImplementationImpl.   Can we get these getters added to this interface?   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Fwd: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field

[Kevin Williams]

-- Forwarded message --
From: Kevin Williams <[EMAIL PROTECTED]>
Date: Jul 18, 2007 1:33 PM
Subject: Re: How to do if I need the DAS and SDO to support reading
and writing the BLOB or CLOB field
To: [EMAIL PROTECTED], [EMAIL PROTECTED]


Hello Li Taojian,

You have uncovered a bug and also found a good fix.  It would be very
helpful if you could open a JIRA for this bug and also submit your fix
as a patch.  You can find instruction for doing this here:
http://incubator.apache.org/tuscany/issue-tracking.html

It would be even better if you could submit an addition to the DAS
testuite to verify your fix.

Thanks for your interest in the DAS.

--Kevin

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


Hi All ,
I modified  the ByteArry and BLOB  to Bytes in  the
ResultSetTypeMap.java   , and then I could run a sample of reading the BLOB
field ,
I test the sample on Mysql 5.0  , It could  run  correctly .

Maybe this is a bug .

ResultSetTypeMap.java

case Types.BINARY:
case Types.VARBINARY:
case Types.LONGVARBINARY:
 return helper.getType("commonj.sdo", "Bytes");  // before
is return helper.getType("commonj.sdo", "ByteArray");

case Types.BLOB:
return helper.getType("commonj.sdo", "Bytes"); // before is
return helper.getType("commonj.sdo", "Blob");



-邮件原件-
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
发送时间: 2007年7月18日 16:54
收件人: [EMAIL PROTECTED]
主题: How to do if I need the DAS and SDO to support reading and writing the
BLOB or CLOB field


Hi  All ,

 I  need the DAS to support  reading and write the BLOB field , but
TypeHelper.getType("commonj.sdo", "Blob") is return null  , Could you give
me some tips to implement the function or fix out the bugs ?
Or How could I implement the function immediately ?


Li Taojian .






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

Re: [RDB DAS] Wrong Query Result when SELECT misses PKs

[Brent Daniel]

Amita,

Definitely, the DAS should enforce the requirement that the PK should
be returned for each table in the results. I would consider this a
case where the DAS should throw an exception.

Brent

On 7/18/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Sorry for the leng  thy mail

Tried to check the case when the database has parent-child tables and DAS
SELECT Command may/may not
contain the PKs of the tables. And found some quite confusing cases/results,
which are effectively giving
user a wrong impression of the data in tables.

Looks like there are places where we are allowing partial results, wrong
association in parent and child rows.
As RDB DAS logic revolves around PKs, can we state clearly that
"When Query SELECT does not include PK for a table, the data graph will be
empty for that table"
? i.e. in the below analysis, instead of giving wrong/partial result, at
least consistently give no result?
And make necessary code corrections to adhere to this statement?

Or any alternative approaches?

What DAS C++ is doing for this case? Just curious.
-
Say, take below data -
Parent: SINGER(ID, NAME), Child:SONG (ID, TITLE, SINGERID)
Data:
SINGER
ID NAME

1  Jonh
2  Jane

SONG
ID   TITLE   SINGERID
-
10   ABCD  1
20   Lamb   1
30   La ra ra2

There are total 8 cases that I can see. viz.

No relationship in config
--
parent PK in SEL   child PK in SELResult
--
[1]   present  presentcorrect
[2]   present  missingwrong
[3]   missing  presentwrong
[4]   missing  missing   wrong

Relationship in config
[5]   presentpresent correct
[6]   presentmissing wrong
[7]   missingpresent wrong
[8]   missingmissingwrong
-
When relationship is not defined in DAS Config
DAS Client code:

DAS das = DAS.FACTORY.createDAS(getConfig("cfg.xml"), getConnection());
Command select = das.getCommand("withNoRel-5/6/7/8");
DataObject root = select.executeQuery();
List singers = root.getList("SINGER");
if(singers != null){
System.out.println("Singer size:"+singers.size());
for(int i=0; i

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

Re: SDO Snapshot, was Re: Build break in implementation-das?

[Luciano Resende]

I have just replublished DAS snapshots based on the same level of SDO
snapshots. And verified that it builds after cleaning my repo. Could
you please verify if you still have any issues ?

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


Jean-Sebastien Delfino wrote:

> Simon Nash wrote:
>
>> I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
>> maven repo, then doing a complete clean and rebuild.  I got the same
>> failure as shown below.  Any ideas?
>>
>>   Simon
>>
>> Running
>> org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
>> Running org.apache.tuscany.sca.implementation.das.DASTestCase
>> Initializing DAS
>> (cut)
>
> That's what I was seeing too. Rebuilding SDO and DAS locally fixed the
> problem for me. I guess the SDO snapshots need to be republished.
>
According to Kelvin, the SDO snapshots were republished before I
cleaned out my repo and reran the build.  I can work around it by
doing what you have done, but it should be possible to get a clean
build of SCA from published snapshots of SDO and DAS.

   Simon



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





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Assigned: (TUSCANY-1217) Loading nested includes.

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reassigned TUSCANY-1217:
---

Assignee: Jean-Sebastien Delfino

> Loading nested includes. 
> -
>
> Key: TUSCANY-1217
> URL: https://issues.apache.org/jira/browse/TUSCANY-1217
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
> Environment: All
>Reporter: Simon Laws
>Assignee: Jean-Sebastien Delfino
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> Lest we forget...
> Currently there is code in WSDLDocumentProcessor.read()  (the two lines with 
> the comment above them).
> // Read inline schemas
> Types types = definition.getTypes();
> if (types != null) {
> wsdlDefinition.getInlinedSchemas().setSchemaResolver(new 
> URIResolverImpl());
> for (Object ext : types.getExtensibilityElements()) {
> if (ext instanceof Schema) {
> Element element = ((Schema)ext).getElement();
> // TODO: temporary fix to make includes in imported
> //   schema work. The XmlSchema library was 
> crashing
> //   because the base uri was not set. This 
> doesn't
> //   affect imports.
> XmlSchemaCollection schemaCollection = 
> wsdlDefinition.getInlinedSchemas();   
> 
> schemaCollection.setBaseUri(((Schema)ext).getDocumentBaseURI());
> wsdlDefinition.getInlinedSchemas().read(element, 
> element.getBaseURI());
> }
> }
> }
> Which sets the base dir against which included XSD files are loaded.  However 
> this seems to mean that in the scenario:
> WSDL1 import---> XSD1 inlcude.---> XSD2
>  
> Then XSD2 has to be included relative to the location of WSDL1 which doesn't 
> sound right. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Need new DAS snapshot (was Re: SDO Snapshot, was Re: Build break in implementation-das?)

[Simon Nash]

I figured out what is causing the problem.  I rebuilt SDO and the
problem still occurred.  I then rebuilt DAS and the problem went away.
So it seems that we need a new published snapshot of DAS that is
compatible with the trunk version of sca/modules/implementation-das.

  Simon

Simon Nash wrote:



Jean-Sebastien Delfino wrote:


Simon Nash wrote:


I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
maven repo, then doing a complete clean and rebuild.  I got the same
failure as shown below.  Any ideas?

  Simon

Running 
org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.tuscany.sca.implementation.das.DASTestCase
Initializing DAS
(cut)



That's what I was seeing too. Rebuilding SDO and DAS locally fixed the 
problem for me. I guess the SDO snapshots need to be republished.



According to Kelvin, the SDO snapshots were republished before I
cleaned out my repo and reran the build.  I can work around it by
doing what you have done, but it should be possible to get a clean
build of SCA from published snapshots of SDO and DAS.

  Simon






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

Re: Need new DAS snapshot (was Re: SDO Snapshot, was Re: Build break in implementation-das?)

[kelvin goodson]

Simon,
 have you seen the response on the thread "SDO Snapshot, was Re: Build
break in implementation-das?" from luciano saying that he published a DAS
snapshot just a few minutes ago.   I guess you may have run your build just
a few minutes too early to catch it?

Regards Kelvin.

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


I figured out what is causing the problem.  I rebuilt SDO and the
problem still occurred.  I then rebuilt DAS and the problem went away.
So it seems that we need a new published snapshot of DAS that is
compatible with the trunk version of sca/modules/implementation-das.

   Simon

Simon Nash wrote:

>
> Jean-Sebastien Delfino wrote:
>
>> Simon Nash wrote:
>>
>>> I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
>>> maven repo, then doing a complete clean and rebuild.  I got the same
>>> failure as shown below.  Any ideas?
>>>
>>>   Simon
>>>
>>> Running
>>>
org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04sec
>>> Running org.apache.tuscany.sca.implementation.das.DASTestCase
>>> Initializing DAS
>>> (cut)
>>
>>
>> That's what I was seeing too. Rebuilding SDO and DAS locally fixed the
>> problem for me. I guess the SDO snapshots need to be republished.
>>
> According to Kelvin, the SDO snapshots were republished before I
> cleaned out my repo and reran the build.  I can work around it by
> doing what you have done, but it should be possible to get a clean
> build of SCA from published snapshots of SDO and DAS.
>
>   Simon
>
>



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

XMLHelper not found in binary beta 1 release when using XSD2JavaGenerator

[Sam Griffith]

Hello,

 

I posted this on the user list as well, but it is relevant to the
developers as well and I could also use some help pretty urgently.

 

Hello,

 

I am porting a preexisting code base that worked with

the M2 release, so have working code to go from.

 

Anyway, I've added all the new libs and am trying to get my generation

to work again with the new libs. When I run our old command line program

to do the generation with the XSD2JavaGenerator, I get this error:

 

-

C:\dmstrunk\dmsbuild\tools>xsdgenerate.bat

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

-

 

 

Here is my batch file for further help so you can see I have the classes

included in the class path correctly:

 

 



@echo off

 

set CP=%~dp0\..\dms\lib\tuscany-sdo-impl-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\stax-api-1.0.1.jar

set CP=%CP%;%~dp0\..\dms\lib\wstx-asl-3.2.0.jar

set CP=%CP%;%~dp0\..\dms\lib\tuscany-sdo-impl-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\sdo-api-r2.1.1-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\tuscany-sdo-tools-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\common-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-xmi-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\xsd-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\codegen-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\codegen-ecore-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-change-2.2.2.jar

 

 

set GENERATOR=org.apache.tuscany.sdo.generate.XSD2JavaGenerator

 

rem copy \com.pervasive.dms\dms\src\com\pervasive\dms\*.xsd

java -classpath %CP% %GENERATOR% -noEmf -noInterfaces -targetDirectory .

%~dp0\..\dms\src\com\pervasive\dms\Common.xsd

java -classpath %CP% %GENERATOR% -noEmf -noInterfaces -prefix

BatchResult -targetDirectory .

%~dp0\..\dms\src\com\pervasive\dms\BatchResponse.xsd

rem /com.pervasive.dms/dms/src Common.xsd

-

 

If I then turn on verbose mode for java, I get this output that tells me

it can't find XSDHelper class, but from the class path, it should be

found.

 

-

[Loaded java.security.Policy$UnsupportedEmptyCollection from shared

objects file]

[Loaded java.io.FilePermissionCollection from shared objects file]

[Loaded java.security.AllPermission from shared objects file]

[Loaded java.security.UnresolvedPermission from shared objects file]

[Loaded java.security.BasicPermissionCollection from shared objects

file]

[Loaded java.security.Principal from shared objects file]

[Loaded java.security.cert.Certificate from shared objects file]

[Loaded org.apache.tuscany.sdo.generate.JavaGenerator from

file:/C:/dmstrunk/dmsbuild/dms/lib/tuscany-sdo-tools-1.0-i

bating-beta1.jar]

[Loaded org.apache.tuscany.sdo.generate.XSD2JavaGenerator from

file:/C:/dmstrunk/dmsbuild/dms/lib/tuscany-sdo-tools-1

incubating-beta1.jar]

[Loaded java.lang.IllegalArgumentException from shared objects file]

[Loaded org.eclipse.emf.common.util.Monitor from

file:/C:/dmstrunk/dmsbuild/dms/lib/common-2.2.2.jar]

[Loaded org.eclipse.emf.common.notify.Notifier from

file:/C:/dmstrunk/dmsbuild/dms/lib/common-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EObject from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EModelElement from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.ENamedElement from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EPackage from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EPackage$Registry from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.util.ExtendedMetaData from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

[Loaded java.util.AbstractList$Itr from shared objects file]

[Loaded java.util.IdentityHashMap$KeySet from shared objects file]

[Loaded java.util.IdentityHashMap$IdentityHashMapIterator from shared

objects file]

[Loaded java.util.IdentityHashMap$KeyIterator from shared objects file]

[Loaded java.io.DeleteOnExitHook from shared objects file]

[Loaded java.util.LinkedHashSet from shared objects file]

[Loaded java.util.HashMap$KeySet from shared objects file]

[Loaded java.util.LinkedHashMap$LinkedHashIterator from shared objects

file]

[Loaded java.util.LinkedHashMap$KeyIterator from shared objects file]

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

 

C:\dmstrunk\dmsbuild\tools>

-

 

Any help or suggestions would be greatly appreciated...

 

Thanks,

 

Sam Griffith

Developer

Pervasive Software

 

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

Oops,  I copied 3 across unnecessarily-- it's done.  I'm back looking at 12
now.
Kelvin.

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


11 seemed to be a no-op
13 is done
14 is done

leaving ...

2 use rat results to fix license header issues and post rat results
3 check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch
6 need to remove dependencies on snapshot plugins (rfeng 13/7)
10b ensure that the runsamples.sh script runs ok in a linux env
12 exclude samples infrastructure classes from samples javadoc
15 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
16 put an overview doc into the sdo lib project's javadoc
17 add the change summary aspects of the medical scenario sample


On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> I have now ported 4 or 5 fixes that had been made to the trunk but not
> to the branch (task 3).  While we are in this pre-release phase if you could
> create a patch of your local workspace when working in the trunk before
> committing and attach it to the JIRA,  then that eases the task of porting
> to the branch.  Better still would be to apply the patch to the branch too.
>
> Now I'm going to look at the samples javadoc issues,   phase 1 = tasks
> 11, 12, 13, 14
>
> Regards, Kelvin.
>
> On 18/07/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
> >
> > just did 4,5,7,8,9,10(a) -- still not run the linux script
> > so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly
> > numbered as 12,13,14 -- doh!)
> >
> > 2 use rat results to fix license header issues and post rat results
> > 3 check that all recent fixes in the trunk since the branch was made
> > have equivalent fixes in the branch
> > 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> > 10b ensure that the runsamples.sh script runs ok in a linux env
> > 11 fix up bad javadoc links in samples index.html
> > 12 exclude samples infrastructure classes from samples javadoc
> > 13 fix link back to tuscany site from overview.html to point to the
> > get involved page
> > 14 incorporate Haleh's suggested paragraph [1] into overview.html
> > 15 ensure consistency of each sample program's javadoc to point back
> > to central instructions for running samples
> > 16 put an overview doc into the sdo lib project's javadoc
> > 17 add the change summary aspects of the medical scenario sample
> >
> > I'm going to tackle 3 now
> >
> > Kelvin.
> >
> > On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > >
> > > I'm going to number off the non jira related tasks so that its easy
> > > to reference them
> > >
> > > I just did 1 and now plan to do 4,5,7,8,9
> > >
> > > 1 the pom has a "provided scope" dependency on stax  -- I will fix
> > > this as per my note to tuscany-dev
> > > 2 use rat results to fix license header issues and post rat results
> > > 3 check that all recent fixes in the trunk since the branch was made
> > > have equivalent fixes in the branch
> > >
> > > the following have been raised by comments on RC1
> > >
> > > 4 NOTICE files (create separate ones for impl and bin and ensure no
> > > disclaimer contained)
> > > 5 need to update release notes with descriptive para and fixed jiras
> > > 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> > > 7 should remove EPL license from src distro
> > > 8 add stax reference in bin distro license
> > > 9 add readme to bin distro samples folder
> > > 10 fix up runsamples scripts to be more robust/helpful and ensure
> > > that the runsamples.sh script runs ok in a linux env
> > > 11 fix up bad javadoc links in samples index.html
> > > 12 exclude samples infrastructure classes from samples javadoc
> > > 13 fix link back to tuscany site from overview.html to point to the
> > > get involved page
> > > 14 incorporate Haleh's suggested paragraph [1] into overview.html
> > >
> > > and some of my own todos that I hope to get to
> > > 12 ensure consistency of each sample program's javadoc to point back
> > > to central instructions for running samples
> > > 13 put an overview doc into the sdo lib project's javadoc
> > > 14 add the change summary aspects of the medical scenario sample
> > >
> > > Regards, Kelvin
> > >
> > > On 17/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > This release is running later than I had hoped due to extra jiras
> > > > being added to the plan, and a few issues that have come up after recent
> > > > fixe, so we are a bit behind where I'd proposed we should be in terms of
> > > > getting this release out.  Please help with some of these TODOs if you 
can.
> > > > If you plan to tackle anything please post here so that we don't 
overlap;
> > > > I'll do the same.
> > > >
> > > > these are the things that I think are "must-fix"
> > > >
> > > > 1143 -- the issues re test failures are being resolved   --
> > > > david's working on this
> > > > 1429 -- i've looked at this and it is fine apa

Re: [RDB DAS] Wrong Query Result when SELECT misses PKs

[Adriano Crestani]

Amita,

There is now way for DAS to  keep the  relationship  data  consistence if
both, pk and fk, are not completely defined. Without them DAS cannot predict
the relationship.

As Brent said, I think it could throw an exception when the PK is missing,
no matter if there are relationships or not. Because, as far as I know, a
table that has no complete PK retrieved on the ResultSet  is being omitted
from the graph and I don't think this is a good approach.

But when only the fk is missing, I think it is ok to omit the relationship
between the data objects on the graph. This way the user has the option to
decide if the references(relationships) will be included or not on the
graph.

Regards,
Adriano Crestani

On 7/18/07, Brent Daniel <[EMAIL PROTECTED]> wrote:


Amita,

Definitely, the DAS should enforce the requirement that the PK should
be returned for each table in the results. I would consider this a
case where the DAS should throw an exception.

Brent

On 7/18/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> Sorry for the leng  thy mail
>
> Tried to check the case when the database has parent-child tables and
DAS
> SELECT Command may/may not
> contain the PKs of the tables. And found some quite confusing
cases/results,
> which are effectively giving
> user a wrong impression of the data in tables.
>
> Looks like there are places where we are allowing partial results, wrong
> association in parent and child rows.
> As RDB DAS logic revolves around PKs, can we state clearly that
> "When Query SELECT does not include PK for a table, the data graph will
be
> empty for that table"
> ? i.e. in the below analysis, instead of giving wrong/partial result, at
> least consistently give no result?
> And make necessary code corrections to adhere to this statement?
>
> Or any alternative approaches?
>
> What DAS C++ is doing for this case? Just curious.
>
-
> Say, take below data -
> Parent: SINGER(ID, NAME), Child:SONG (ID, TITLE, SINGERID)
> Data:
> SINGER
> ID NAME
> 
> 1  Jonh
> 2  Jane
>
> SONG
> ID   TITLE   SINGERID
> -
> 10   ABCD  1
> 20   Lamb   1
> 30   La ra ra2
>
> There are total 8 cases that I can see. viz.
>
> No relationship in config
> --
> parent PK in SEL   child PK in SELResult
> --
> [1]   present  presentcorrect
> [2]   present  missingwrong
> [3]   missing  presentwrong
> [4]   missing  missing   wrong
>
> Relationship in config
> [5]   presentpresent correct
> [6]   presentmissing wrong
> [7]   missingpresent wrong
> [8]   missingmissingwrong
>
-
> When relationship is not defined in DAS Config
> DAS Client code:
> 
> DAS das = DAS.FACTORY.createDAS(getConfig("cfg.xml"), getConnection());
> Command select = das.getCommand("withNoRel-5/6/7/8");
> DataObject root = select.executeQuery();
> List singers = root.getList("SINGER");
> if(singers != null){
> System.out.println("Singer size:"+singers.size());
> for(int i=0; i System.out.println("SINGER NAME:"+
> ((DataObject)singers.get(i)).getString("NAME"));
> }
>
> }
>
> List songs = root.getList("SONG");//as there is no relationship
> (explicit/implicit)
>
> if(songs != null){
> System.out.println("Songs size "+songs .size());
> for(int ii=0; ii System.out.println("SONG TITLE:"+
> ((DataObject)songs.get(ii)).getString("TITLE"));
> }
> }
>
> }
>
-
> Result:
>
-
> [1] SELECT SINGER.ID, SINGER.NAME, SONG.ID, SONG.TITLE FROM SINGER, SONG
> WHERE SINGER.ID = SONG.SINGERID
> Singer size:2
> SINGER NAME:John
> SINGER NAME:Jane
> Songs size 3
> SONG TITLE:ABCD
> SONG TITLE:Lamb
> SONG TITLE:La ra ra
>
> [2] SELECT SINGER.ID, SINGER.NAME, SONG.TITLE FROM SINGER, SONG WHERE
> SINGER.ID = SONG.SINGERID
> Singer size:2
> SINGER NAME:John
> SINGER NAME:Jane
> Songs size 1
> SONG TITLE:ABCD
>
> [3] SELECT SINGER.NAME, SONG.ID, SONG.TITLE FROM SINGER, SONG WHERE
> SINGER.ID = SONG.SINGERID
> Singer size:1
> SINGER NAME:John
> Songs size 3
> SONG TITLE:ABCD
> SONG TITLE:Lamb
> SONG TITLE:La ra ra
>
> [4] SELECT SINGER.NAME, SONG.TITLE FROM SINGER, SONG WHERE SINGER.ID =
> SONG.SINGERID
> Singer size:1
> SINGER NAME:John
> Songs size 1
> SONG TITLE:ABCD
>
-

[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant

[Brady Johnson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brady Johnson updated TUSCANY-1438:
---

Attachment: tuscany_patch_update2_jira1438


Pete Robbins has added the necessary ant build files to the svn repository. 

Following is a description of this upload that goes on top of what he added:

Changed the name of compilers.xml to system.xml.

This update has better support for a platform.properties file that is 
completely empty. That is,
all of the platform dependent items are figured out by ant. If they are set in 
the platform.properties
file then they override the ant determination.

Better directory path management has been added to the root build.xml and 
runtime/core/src/build.xml
files.

The install and clean targets in runtime/core/src have been completed.


Following is a nice way to test the build files.

cd 
ant 

cd runtime/core/src
ant clean

ant

cd 
ant clean




> Change TuscanySCA Native build system to use ant
> 
>
> Key: TUSCANY-1438
> URL: https://issues.apache.org/jira/browse/TUSCANY-1438
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ SCA
>Affects Versions: Cpp-Next
> Environment: all platforms
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
> Attachments: tuscany_patch_update2_jira1438, 
> tuscanySCAnative_ant.tar.gz, tuscanySCAnative_ant_update1.tar.gz
>
>
> In an effort to simplify the build process, I would like to propose switching 
> over to use ant instead of automake. It will be much easier to maintain, and 
> is used by many more developers today than automake.
> Per a request by Pete Robbins to show what the build scripts would look like 
> for cpp/sca/runtime/core, I will attach a patch with the build infrastructure 
> to build, link, and install said library.
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: [SCA Native] preliminary ant build

[Brady Johnson]

I uploaded a patch on top of what you submit to svn.

Here is a description of what I changed:

- Changed the name of compilers.xml to system.xml. 

- This update has better support for a platform.properties file that is
completely empty.
  That is, all of the platform dependent items are figured out by ant.
If they are set in
  the platform.properties file then they override the ant determination.

- Better directory path management has been added to the root build.xml
and 
  runtime/core/src/build.xml files.

- The install and clean targets in runtime/core/src have been completed.


With respect to your latest post regarding "tuscany-sca-config.h":
I knew this was a problem on clean systems and had envisioned either
running a script or using a slimmed down automake/configure to setup
this file and any platform specific parameters. That's certainly
something we'll have to address, what do you think?



Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 9:22 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> That's a good idea. Then the only thing that really need to be set in 
> platform.properties file would be:
>tuscanySCA.install.dir
>and any possible overides
>
> I'll put that together real quick and upload it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:00 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > Thanks for trying out the ant build scripts.
> > >
> > > Regarding core.dir, you're right, the name will need to change. I 
> > > can do that no problem.
> > >
> > > As for the "tuscanySCA.root.dir" : Your suggestion will work if 
> > > you only execute ant from the root directory, but not if you 
> > > execute ant
>
> > > from the runtime/core/src directory. That's why I put it in the 
> > > platform.properties, which is accessed by all build.xml's. Its 
> > > better ant coding style to have anything that needs to be 
> > > configured
>
> > > in a properties file, not in an ant build.xml file.
> > >
> >
> > Yes... I realized that would limit you to running ant from the top 
> > level. So, as most of the info in platform.properties can be deduced

> > would a better solution be to have a top level (or in antscripts 
> > dir) platform-properties.xml that
> >  a) imports platform.properties for any overrides
> >  b) sets the properties conditional on the platform.
> >
> > e.g.
> >  
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
>
> the build.xml files would all import this top level file:
>
>
> > > As for the platform.properties file for windows:
> > > The property platform can/should be removed, its not necessary. If

> > > the property "platform.compiler-definition" is set, then that 
> > > value will be used for the compiler selection, else it will get 
> > > set to msvc for windows as can be seen on line 18 of
compilers.xml.
> > >
> > > I think the way this should ship is to have several 
> > > platform.properties files for the different platform:
> > >platform.properties.linux
> > >platform.properties.windows
> > >platform.properties.mac
> > > Which will each have values pre configured for the corresponding 
> > > platform. Then with either configure or a shell script, the 
> > > platform
>
> > > file wil be copied to platform.properties and the directory 
> > > properties will be set accordingly.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA Rogue Wave Software - 
> > > [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 18, 2007 7:08 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > I ran into a couple of issues tryingt o run this ant build. 
> > > Firstly I got an error with a path 
> > > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this 
> > > down to the fact that the property core.dir is set in the top 
> > > level build.xml to "runtime/core/src" and in the 
> > > runtime/core/src/build.xml the same property name is used and set 
> > > tu
>
> > > "tuscany/sca/core". It looks to me like the second defintion of 
> > >

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I uploaded a patch on top of what you submit to svn.

Here is a description of what I changed:

- Changed the name of compilers.xml to system.xml.

- This update has better support for a platform.properties file that is
completely empty.
 That is, all of the platform dependent items are figured out by ant.
If they are set in
 the platform.properties file then they override the ant determination.

- Better directory path management has been added to the root build.xml
and
 runtime/core/src/build.xml files.

- The install and clean targets in runtime/core/src have been completed.


With respect to your latest post regarding "tuscany-sca-config.h":
I knew this was a problem on clean systems and had envisioned either
running a script or using a slimmed down automake/configure to setup
this file and any platform specific parameters. That's certainly
something we'll have to address, what do you think?



The only reason we use this automake generated file is to set the
IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a
different technique in ant to set this flag. Is there a "family=mac"
or somesuch in ant? The automake simply runs a 'uname -s' command to
figure it out.

I think a goal for this shoul be that I can do a clean extract from
svn and type "ant" in the top level directory and it will build with
everything defaulted. We need various pre-reqs defined (SDO loccation,
+ other pre-reqs) but we should try to make this as simple as
possible.

Cheers,





Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 9:22 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> That's a good idea. Then the only thing that really need to be set in
> platform.properties file would be:
>tuscanySCA.install.dir
>and any possible overides
>
> I'll put that together real quick and upload it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:00 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > Thanks for trying out the ant build scripts.
> > >
> > > Regarding core.dir, you're right, the name will need to change. I
> > > can do that no problem.
> > >
> > > As for the "tuscanySCA.root.dir" : Your suggestion will work if
> > > you only execute ant from the root directory, but not if you
> > > execute ant
>
> > > from the runtime/core/src directory. That's why I put it in the
> > > platform.properties, which is accessed by all build.xml's. Its
> > > better ant coding style to have anything that needs to be
> > > configured
>
> > > in a properties file, not in an ant build.xml file.
> > >
> >
> > Yes... I realized that would limit you to running ant from the top
> > level. So, as most of the info in platform.properties can be deduced

> > would a better solution be to have a top level (or in antscripts
> > dir) platform-properties.xml that
> >  a) imports platform.properties for any overrides
> >  b) sets the properties conditional on the platform.
> >
> > e.g.
> >  
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
>
> the build.xml files would all import this top level file:
>
>
> > > As for the platform.properties file for windows:
> > > The property platform can/should be removed, its not necessary. If

> > > the property "platform.compiler-definition" is set, then that
> > > value will be used for the compiler selection, else it will get
> > > set to msvc for windows as can be seen on line 18 of
compilers.xml.
> > >
> > > I think the way this should ship is to have several
> > > platform.properties files for the different platform:
> > >platform.properties.linux
> > >platform.properties.windows
> > >platform.properties.mac
> > > Which will each have values pre configured for the corresponding
> > > platform. Then with either configure or a shell script, the
> > > platform
>
> > > file wil be copied to platform.properties and the directory
> > > properties will be set accordingly.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA Rogue Wave Software -
> > > [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMA

Re: Need new DAS snapshot (was Re: SDO Snapshot, was Re: Build break in implementation-das?)

[Simon Nash]

I tried this and it works OK now.  Thanks, Kelvin and Luciano!

  Simon

kelvin goodson wrote:


Simon,
 have you seen the response on the thread "SDO Snapshot, was Re: Build
break in implementation-das?" from luciano saying that he published a DAS
snapshot just a few minutes ago.   I guess you may have run your build just
a few minutes too early to catch it?

Regards Kelvin.

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



I figured out what is causing the problem.  I rebuilt SDO and the
problem still occurred.  I then rebuilt DAS and the problem went away.
So it seems that we need a new published snapshot of DAS that is
compatible with the trunk version of sca/modules/implementation-das.

   Simon

Simon Nash wrote:

>
> Jean-Sebastien Delfino wrote:
>
>> Simon Nash wrote:
>>
>>> I tried removing commonj/* and org/apache/tuscany/sdo/* from my local
>>> maven repo, then doing a complete clean and rebuild.  I got the same
>>> failure as shown below.  Any ideas?
>>>
>>>   Simon
>>>
>>> Running
>>>
org.apache.tuscany.sca.implementation.das.company.CompanyServiceTestCase
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.04sec

>>> Running org.apache.tuscany.sca.implementation.das.DASTestCase
>>> Initializing DAS
>>> (cut)
>>
>>
>> That's what I was seeing too. Rebuilding SDO and DAS locally fixed the
>> problem for me. I guess the SDO snapshots need to be republished.
>>
> According to Kelvin, the SDO snapshots were republished before I
> cleaned out my repo and reran the build.  I can work around it by
> doing what you have done, but it should be possible to get a clean
> build of SCA from published snapshots of SDO and DAS.
>
>   Simon
>




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

Re: XMLHelper not found in binary beta 1 release when using XSD2JavaGenerator

[kelvin goodson]

I posted a response to this on the tuscany user ML to say that the class can
be found in the beta1 binary distro in the
sdo-api-r2.1-1.0-incubating-beta1.jar file.

Kelvin.

On 18/07/07, Sam Griffith <[EMAIL PROTECTED]> wrote:


Hello,



I posted this on the user list as well, but it is relevant to the
developers as well and I could also use some help pretty urgently.



Hello,



I am porting a preexisting code base that worked with

the M2 release, so have working code to go from.



Anyway, I've added all the new libs and am trying to get my generation

to work again with the new libs. When I run our old command line program

to do the generation with the XSD2JavaGenerator, I get this error:



-

C:\dmstrunk\dmsbuild\tools>xsdgenerate.bat

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

-





Here is my batch file for further help so you can see I have the classes

included in the class path correctly:







@echo off



set CP=%~dp0\..\dms\lib\tuscany-sdo-impl-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\stax-api-1.0.1.jar

set CP=%CP%;%~dp0\..\dms\lib\wstx-asl-3.2.0.jar

set CP=%CP%;%~dp0\..\dms\lib\tuscany-sdo-impl-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\sdo-api-r2.1.1-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\tuscany-sdo-tools-1.0-incubating-beta1.jar

set CP=%CP%;%~dp0\..\dms\lib\common-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-xmi-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\xsd-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\codegen-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\codegen-ecore-2.2.2.jar

set CP=%CP%;%~dp0\..\dms\lib\ecore-change-2.2.2.jar





set GENERATOR=org.apache.tuscany.sdo.generate.XSD2JavaGenerator



rem copy \com.pervasive.dms\dms\src\com\pervasive\dms\*.xsd

java -classpath %CP% %GENERATOR% -noEmf -noInterfaces -targetDirectory .

%~dp0\..\dms\src\com\pervasive\dms\Common.xsd

java -classpath %CP% %GENERATOR% -noEmf -noInterfaces -prefix

BatchResult -targetDirectory .

%~dp0\..\dms\src\com\pervasive\dms\BatchResponse.xsd

rem /com.pervasive.dms/dms/src Common.xsd

-



If I then turn on verbose mode for java, I get this output that tells me

it can't find XSDHelper class, but from the class path, it should be

found.



-

[Loaded java.security.Policy$UnsupportedEmptyCollection from shared

objects file]

[Loaded java.io.FilePermissionCollection from shared objects file]

[Loaded java.security.AllPermission from shared objects file]

[Loaded java.security.UnresolvedPermission from shared objects file]

[Loaded java.security.BasicPermissionCollection from shared objects

file]

[Loaded java.security.Principal from shared objects file]

[Loaded java.security.cert.Certificate from shared objects file]

[Loaded org.apache.tuscany.sdo.generate.JavaGenerator from

file:/C:/dmstrunk/dmsbuild/dms/lib/tuscany-sdo-tools-1.0-i

bating-beta1.jar]

[Loaded org.apache.tuscany.sdo.generate.XSD2JavaGenerator from

file:/C:/dmstrunk/dmsbuild/dms/lib/tuscany-sdo-tools-1

incubating-beta1.jar]

[Loaded java.lang.IllegalArgumentException from shared objects file]

[Loaded org.eclipse.emf.common.util.Monitor from

file:/C:/dmstrunk/dmsbuild/dms/lib/common-2.2.2.jar]

[Loaded org.eclipse.emf.common.notify.Notifier from

file:/C:/dmstrunk/dmsbuild/dms/lib/common-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EObject from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EModelElement from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.ENamedElement from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EPackage from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.EPackage$Registry from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

[Loaded org.eclipse.emf.ecore.util.ExtendedMetaData from

file:/C:/dmstrunk/dmsbuild/dms/lib/ecore-2.2.2.jar]

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper

[Loaded java.util.AbstractList$Itr from shared objects file]

[Loaded java.util.IdentityHashMap$KeySet from shared objects file]

[Loaded java.util.IdentityHashMap$IdentityHashMapIterator from shared

objects file]

[Loaded java.util.IdentityHashMap$KeyIterator from shared objects file]

[Loaded java.io.DeleteOnExitHook from shared objects file]

[Loaded java.util.LinkedHashSet from shared objects file]

[Loaded java.util.HashMap$KeySet from shared objects file]

[Loaded java.util.LinkedHashMap$LinkedHashIterator from shared objects

file]

[Loaded java.util.LinkedHashMap$KeyIterator from shared objects file]

Exception in thread "main" java.lang.NoClassDefFoundError:

commonj/sdo/helper/XSDHelper



C:\dmstrunk\dmsbuild\tools>

-

Re: Adding support for Contribution Import/Export

[Luciano Resende]

Trying to go further with the support of import/export, looks like at
some cases we need specialized resolvers that understand better the
specifics of the artifact type being resolved, I started looking into
this piece and will start adding some support for plugable resolvers
in the contribution service and then integrate then with the current
support for import/export.

Thoughts ?

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

I have just committed initial support for import/export, the
integration tests exercise and demonstrates the usage of multiple
contributions using import/export scenarios, there is also a strawman
documentation available on the wiki [1].

This is working in progress, and I will look a little more into it to
optimize the algorithm being used on the resolution mechanism of the
imports.

[1] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+-+Import+and+Export

On 7/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I have started looking into contribution import/export as defined in
> the SCA 1.0 Assembly spec. I've started putting together some test
> cases around the following scenarios :
>
>- Two contributions, where C1 defines and exports CompositeA and C2
> imports and reference it trough a 
>- Two contributions, where C1 defines a WSDL contract and export
> it's namespace, and C2 imports and reference it through a ws-binding.
>- Two contributions, where C1 defines some interfaces and export
> it's package, and C2 imports and reference these interfaces
>
> I'll start checking in the test-cases, and then working on adding
> support for contribution service to handle these cases.
>
> Please comment on these scenarios, and feel free to add to it, and off
> course, help is always welcome.
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: [SDO Java] things to be done for SDO release - please help

[kelvin goodson]

12 is done

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


Oops,  I copied 3 across unnecessarily-- it's done.  I'm back looking at
12 now.
Kelvin.

On 18/07/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
>
> 11 seemed to be a no-op
> 13 is done
> 14 is done
>
> leaving ...
>
> 2 use rat results to fix license header issues and post rat results
> 3 check that all recent fixes in the trunk since the branch was made
> have equivalent fixes in the branch
> 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> 10b ensure that the runsamples.sh script runs ok in a linux env
> 12 exclude samples infrastructure classes from samples javadoc
> 15 ensure consistency of each sample program's javadoc to point back to
> central instructions for running samples
> 16 put an overview doc into the sdo lib project's javadoc
> 17 add the change summary aspects of the medical scenario sample
>
>
> On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > I have now ported 4 or 5 fixes that had been made to the trunk but not
> > to the branch (task 3).  While we are in this pre-release phase if you could
> > create a patch of your local workspace when working in the trunk before
> > committing and attach it to the JIRA,  then that eases the task of porting
> > to the branch.  Better still would be to apply the patch to the branch too.
> >
> > Now I'm going to look at the samples javadoc issues,   phase 1 = tasks
> > 11, 12, 13, 14
> >
> > Regards, Kelvin.
> >
> > On 18/07/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
> > >
> > > just did 4,5,7,8,9,10(a) -- still not run the linux script
> > > so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly
> > > numbered as 12,13,14 -- doh!)
> > >
> > > 2 use rat results to fix license header issues and post rat results
> > > 3 check that all recent fixes in the trunk since the branch was made
> > > have equivalent fixes in the branch
> > > 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> > > 10b ensure that the runsamples.sh script runs ok in a linux env
> > > 11 fix up bad javadoc links in samples index.html
> > > 12 exclude samples infrastructure classes from samples javadoc
> > > 13 fix link back to tuscany site from overview.html to point to the
> > > get involved page
> > > 14 incorporate Haleh's suggested paragraph [1] into overview.html
> > > 15 ensure consistency of each sample program's javadoc to point back
> > > to central instructions for running samples
> > > 16 put an overview doc into the sdo lib project's javadoc
> > > 17 add the change summary aspects of the medical scenario sample
> > >
> > > I'm going to tackle 3 now
> > >
> > > Kelvin.
> > >
> > > On 18/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I'm going to number off the non jira related tasks so that its
> > > > easy to reference them
> > > >
> > > > I just did 1 and now plan to do 4,5,7,8,9
> > > >
> > > > 1 the pom has a "provided scope" dependency on stax  -- I will fix
> > > > this as per my note to tuscany-dev
> > > > 2 use rat results to fix license header issues and post rat
> > > > results
> > > > 3 check that all recent fixes in the trunk since the branch was
> > > > made have equivalent fixes in the branch
> > > >
> > > > the following have been raised by comments on RC1
> > > >
> > > > 4 NOTICE files (create separate ones for impl and bin and ensure
> > > > no disclaimer contained)
> > > > 5 need to update release notes with descriptive para and fixed
> > > > jiras
> > > > 6 need to remove dependencies on snapshot plugins (rfeng 13/7)
> > > > 7 should remove EPL license from src distro
> > > > 8 add stax reference in bin distro license
> > > > 9 add readme to bin distro samples folder
> > > > 10 fix up runsamples scripts to be more robust/helpful and ensure
> > > > that the runsamples.sh script runs ok in a linux env
> > > > 11 fix up bad javadoc links in samples index.html
> > > > 12 exclude samples infrastructure classes from samples javadoc
> > > > 13 fix link back to tuscany site from overview.html to point to
> > > > the get involved page
> > > > 14 incorporate Haleh's suggested paragraph [1] into overview.html
> > > >
> > > > and some of my own todos that I hope to get to
> > > > 12 ensure consistency of each sample program's javadoc to point
> > > > back to central instructions for running samples
> > > > 13 put an overview doc into the sdo lib project's javadoc
> > > > 14 add the change summary aspects of the medical scenario sample
> > > >
> > > > Regards, Kelvin
> > > >
> > > > On 17/07/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > This release is running later than I had hoped due to extra
> > > > > jiras being added to the plan, and a few issues that have come up 
after
> > > > > recent fixe, so we are a bit behind where I'd proposed we should be 
in terms
> > > > > of getting this release out.  Please help with some of these TODOs if 
you
> > > > > can.  If you plan to tackle anything please pos

RE: [SCA Native] preliminary ant build

[Brady Johnson]

If that's all we need the tuscany_sca_config.h file for then, yes this
just got a whole lot easier. We can do the following on the
Tuscany-BaseCompiler 

  

  

  



 


  


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 3:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I uploaded a patch on top of what you submit to svn.
>
> Here is a description of what I changed:
>
> - Changed the name of compilers.xml to system.xml.
>
> - This update has better support for a platform.properties file that 
> is completely empty.
>  That is, all of the platform dependent items are figured out by ant.
> If they are set in
>  the platform.properties file then they override the ant
determination.
>
> - Better directory path management has been added to the root 
> build.xml and  runtime/core/src/build.xml files.
>
> - The install and clean targets in runtime/core/src have been
completed.
>
>
> With respect to your latest post regarding "tuscany-sca-config.h":
> I knew this was a problem on clean systems and had envisioned either 
> running a script or using a slimmed down automake/configure to setup 
> this file and any platform specific parameters. That's certainly 
> something we'll have to address, what do you think?
>

The only reason we use this automake generated file is to set the
IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a
different technique in ant to set this flag. Is there a "family=mac"
or somesuch in ant? The automake simply runs a 'uname -s' command to
figure it out.

I think a goal for this shoul be that I can do a clean extract from svn
and type "ant" in the top level directory and it will build with
everything defaulted. We need various pre-reqs defined (SDO loccation,
+ other pre-reqs) but we should try to make this as simple as
possible.

Cheers,


>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:22 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> the install dir defaults to sca/deploy so I think we don't need any 
> properties other than overrides.
>
> I'll check in what I have. so youi can see.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > That's a good idea. Then the only thing that really need to be set 
> > in platform.properties file would be:
> >tuscanySCA.install.dir
> >and any possible overides
> >
> > I'll put that together real quick and upload it.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:00 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > Thanks for trying out the ant build scripts.
> > > >
> > > > Regarding core.dir, you're right, the name will need to change. 
> > > > I can do that no problem.
> > > >
> > > > As for the "tuscanySCA.root.dir" : Your suggestion will work if 
> > > > you only execute ant from the root directory, but not if you 
> > > > execute ant
> >
> > > > from the runtime/core/src directory. That's why I put it in the 
> > > > platform.properties, which is accessed by all build.xml's. Its 
> > > > better ant coding style to have anything that needs to be 
> > > > configured
> >
> > > > in a properties file, not in an ant build.xml file.
> > > >
> > >
> > > Yes... I realized that would limit you to running ant from the top

> > > level. So, as most of the info in platform.properties can be 
> > > deduced
>
> > > would a better solution be to have a top level (or in antscripts
> > > dir) platform-properties.xml that
> > >  a) imports platform.properties for any overrides
> > >  b) sets the properties conditional on the platform.
> > >
> > > e.g.
> > >  
> > >
> > >  
> > >  
> > >
> > >  
> > >  
> > >
> > >  
> > >
> >
> > the build.xml files would all import this top level file:
> >
> >
> > > > As for the platform.properties file for windows:
> > > > The property platform can/should be removed, its not necessary. 
> > > > If
>
> > > > the property "platform.compiler-definition" is set, then that 
> > > > value will be used for the compiler selection, else it will get 
> > > > set to msvc for windows as can be 

Re: [SCA Native] preliminary ant build

[Pete Robbins]

Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


If that's all we need the tuscany_sca_config.h file for then, yes this
just got a whole lot easier. We can do the following on the
Tuscany-BaseCompiler

 
   
 

 
   
   
   

   
   
 


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 3:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I uploaded a patch on top of what you submit to svn.
>
> Here is a description of what I changed:
>
> - Changed the name of compilers.xml to system.xml.
>
> - This update has better support for a platform.properties file that
> is completely empty.
>  That is, all of the platform dependent items are figured out by ant.
> If they are set in
>  the platform.properties file then they override the ant
determination.
>
> - Better directory path management has been added to the root
> build.xml and  runtime/core/src/build.xml files.
>
> - The install and clean targets in runtime/core/src have been
completed.
>
>
> With respect to your latest post regarding "tuscany-sca-config.h":
> I knew this was a problem on clean systems and had envisioned either
> running a script or using a slimmed down automake/configure to setup
> this file and any platform specific parameters. That's certainly
> something we'll have to address, what do you think?
>

The only reason we use this automake generated file is to set the
IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a
different technique in ant to set this flag. Is there a "family=mac"
or somesuch in ant? The automake simply runs a 'uname -s' command to
figure it out.

I think a goal for this shoul be that I can do a clean extract from svn
and type "ant" in the top level directory and it will build with
everything defaulted. We need various pre-reqs defined (SDO loccation,
+ other pre-reqs) but we should try to make this as simple as
possible.

Cheers,


>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:22 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> the install dir defaults to sca/deploy so I think we don't need any
> properties other than overrides.
>
> I'll check in what I have. so youi can see.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > That's a good idea. Then the only thing that really need to be set
> > in platform.properties file would be:
> >tuscanySCA.install.dir
> >and any possible overides
> >
> > I'll put that together real quick and upload it.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:00 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > Thanks for trying out the ant build scripts.
> > > >
> > > > Regarding core.dir, you're right, the name will need to change.
> > > > I can do that no problem.
> > > >
> > > > As for the "tuscanySCA.root.dir" : Your suggestion will work if
> > > > you only execute ant from the root directory, but not if you
> > > > execute ant
> >
> > > > from the runtime/core/src directory. That's why I put it in the
> > > > platform.properties, which is accessed by all build.xml's. Its
> > > > better ant coding style to have anything that needs to be
> > > > configured
> >
> > > > in a properties file, not in an ant build.xml file.
> > > >
> > >
> > > Yes... I realized that would limit you to running ant from the top

> > > level. So, as most of the info in platform.properties can be
> > > deduced
>
> > > would a better solution be to have a top level (or in antscripts
> > > dir) platform-properties.xml that
> > >  a) imports platform.properties for any overrides
> > >  b) sets the properties conditional on the platform.
> > >
> > > e.g.
> > >  
> > >
> > >  
> > >  
> > >
> > >  
> > >  
> > >
> > >  
> > >
> >
> > the build.xml files would all import this top level file:
> >
> >
> > > > As for the platform.properties file for windows:
> > > > The property platform can/should be removed, its not necessary

RE: [SCA Native] preliminary ant build

[Brady Johnson]

Ok, I wasn't aware that I had changed the tools.

I simply did a "svn diff . > patch_file" from the tuscany root dir. You
can disregard the tools changes. I'll look into it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED] 


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 4:16 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> If that's all we need the tuscany_sca_config.h file for then, yes this

> just got a whole lot easier. We can do the following on the 
> Tuscany-BaseCompiler
>
>  
>
>  
>
>   exceptions="true" rtti="true">
> define="WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS"/>
>
>
> 
>
>
>  
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 3:41 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I uploaded a patch on top of what you submit to svn.
> >
> > Here is a description of what I changed:
> >
> > - Changed the name of compilers.xml to system.xml.
> >
> > - This update has better support for a platform.properties file that

> > is completely empty.
> >  That is, all of the platform dependent items are figured out by
ant.
> > If they are set in
> >  the platform.properties file then they override the ant
> determination.
> >
> > - Better directory path management has been added to the root 
> > build.xml and  runtime/core/src/build.xml files.
> >
> > - The install and clean targets in runtime/core/src have been
> completed.
> >
> >
> > With respect to your latest post regarding "tuscany-sca-config.h":
> > I knew this was a problem on clean systems and had envisioned either

> > running a script or using a slimmed down automake/configure to setup

> > this file and any platform specific parameters. That's certainly 
> > something we'll have to address, what do you think?
> >
>
> The only reason we use this automake generated file is to set the 
> IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a

> different technique in ant to set this flag. Is there a "family=mac"
> or somesuch in ant? The automake simply runs a 'uname -s' command to 
> figure it out.
>
> I think a goal for this shoul be that I can do a clean extract from 
> svn and type "ant" in the top level directory and it will build with 
> everything defaulted. We need various pre-reqs defined (SDO loccation,
> + other pre-reqs) but we should try to make this as simple as
> possible.
>
> Cheers,
>
>
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:22 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > the install dir defaults to sca/deploy so I think we don't need any 
> > properties other than overrides.
> >
> > I'll check in what I have. so youi can see.
> >
> > Cheers,
> >
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > That's a good idea. Then the only thing that really need to be set

> > > in platform.properties file would be:
> > >tuscanySCA.install.dir
> > >and any possible overides
> > >
> > > I'll put that together real quick and upload it.
> > >
> > > Thanks
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA Rogue Wave Software - 
> > > [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 18, 2007 9:00 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Pete,
> > > > >
> > > > > Thanks for trying out the ant build scripts.
> > > > >
> > > > > Regarding core.dir, you're right, the name will need to
change.
> > > > > I can do that no problem.
> > > > >
> > > > > As for the "tuscanySCA.root.dir" : Your suggestion will work 
> > > > > if you only execute ant from the root directory, but not if 
> > > > > you execute ant
> > >
> > > > > from the runtime/core/src directory. That's why I put it in 
> > > > > the platform.properties, which is accessed by all build.xml's.

> > > > > Its better ant coding style to 

Re: [SCA Native] preliminary ant build

[Pete Robbins]

yeah I figured that... I did exactly the same when committing changes
earlier! I dodn't commit the changes inthe tools folder.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Ok, I wasn't aware that I had changed the tools.

I simply did a "svn diff . > patch_file" from the tuscany root dir. You
can disregard the tools changes. I'll look into it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 4:16 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> If that's all we need the tuscany_sca_config.h file for then, yes this

> just got a whole lot easier. We can do the following on the
> Tuscany-BaseCompiler
>
>  
>
>  
>
>   exceptions="true" rtti="true">
> define="WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS"/>
>
>
> 
>
>
>  
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 3:41 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I uploaded a patch on top of what you submit to svn.
> >
> > Here is a description of what I changed:
> >
> > - Changed the name of compilers.xml to system.xml.
> >
> > - This update has better support for a platform.properties file that

> > is completely empty.
> >  That is, all of the platform dependent items are figured out by
ant.
> > If they are set in
> >  the platform.properties file then they override the ant
> determination.
> >
> > - Better directory path management has been added to the root
> > build.xml and  runtime/core/src/build.xml files.
> >
> > - The install and clean targets in runtime/core/src have been
> completed.
> >
> >
> > With respect to your latest post regarding "tuscany-sca-config.h":
> > I knew this was a problem on clean systems and had envisioned either

> > running a script or using a slimmed down automake/configure to setup

> > this file and any platform specific parameters. That's certainly
> > something we'll have to address, what do you think?
> >
>
> The only reason we use this automake generated file is to set the
> IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a

> different technique in ant to set this flag. Is there a "family=mac"
> or somesuch in ant? The automake simply runs a 'uname -s' command to
> figure it out.
>
> I think a goal for this shoul be that I can do a clean extract from
> svn and type "ant" in the top level directory and it will build with
> everything defaulted. We need various pre-reqs defined (SDO loccation,
> + other pre-reqs) but we should try to make this as simple as
> possible.
>
> Cheers,
>
>
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:22 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > the install dir defaults to sca/deploy so I think we don't need any
> > properties other than overrides.
> >
> > I'll check in what I have. so youi can see.
> >
> > Cheers,
> >
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > That's a good idea. Then the only thing that really need to be set

> > > in platform.properties file would be:
> > >tuscanySCA.install.dir
> > >and any possible overides
> > >
> > > I'll put that together real quick and upload it.
> > >
> > > Thanks
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA Rogue Wave Software -
> > > [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 18, 2007 9:00 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Pete,
> > > > >
> > > > > Thanks for trying out the ant build scripts.
> > > > >
> > > > > Regarding core.dir, you're right, the name will need to
change.
> > > > > I can do that no problem.
> > > > >
> > > > > As for the "tuscanySCA.root.dir" : Your suggestion will work
> > > > > if you only execute ant from the root directory, but not if
> > > > > you execute ant
> > >
> > > 

RE: [SCA Native] preliminary ant build

[Brady Johnson]

I did the following diff command and got quite a lot of changes (listed
below):

# diff tuscany_sca_config.h.in tuscany_sca_config.h

Are these not needed?
If not, I can get to work on removing all references to the
file.
If so, then we still need to figure out how to create the file.

I just realized, its 23:30, there... Go to bed! ;)


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


0a1
> /* tuscany_sca_config.h.  Generated by configure.  */
4c5
< #undef CLOSEDIR_VOID
---
> /* #undef CLOSEDIR_VOID */
8c9
< #undef HAVE_DIRENT_H
---
> #define HAVE_DIRENT_H 1
11c12
< #undef HAVE_DLFCN_H
---
> #define HAVE_DLFCN_H 1
14c15
< #undef HAVE_DOPRNT
---
> /* #undef HAVE_DOPRNT */
17c18
< #undef HAVE_GETCWD
---
> #define HAVE_GETCWD 1
20c21
< #undef HAVE_INTTYPES_H
---
> #define HAVE_INTTYPES_H 1
23c24
< #undef HAVE_MEMORY_H
---
> #define HAVE_MEMORY_H 1
26c27
< #undef HAVE_NDIR_H
---
> /* #undef HAVE_NDIR_H */
29c30
< #undef HAVE_PUTENV
---
> #define HAVE_PUTENV 1
33c34
< #undef HAVE_STAT_EMPTY_STRING_BUG
---
> /* #undef HAVE_STAT_EMPTY_STRING_BUG */
36c37
< #undef HAVE_STDBOOL_H
---
> #define HAVE_STDBOOL_H 1
39c40
< #undef HAVE_STDINT_H
---
> #define HAVE_STDINT_H 1
42c43
< #undef HAVE_STDLIB_H
---
> #define HAVE_STDLIB_H 1
45c46
< #undef HAVE_STRDUP
---
> #define HAVE_STRDUP 1
48c49
< #undef HAVE_STRINGS_H
---
> #define HAVE_STRINGS_H 1
51c52
< #undef HAVE_STRING_H
---
> #define HAVE_STRING_H 1
55c56
< #undef HAVE_SYS_DIR_H
---
> /* #undef HAVE_SYS_DIR_H */
59c60
< #undef HAVE_SYS_NDIR_H
---
> /* #undef HAVE_SYS_NDIR_H */
62c63
< #undef HAVE_SYS_STAT_H
---
> #define HAVE_SYS_STAT_H 1
65c66
< #undef HAVE_SYS_TIME_H
---
> #define HAVE_SYS_TIME_H 1
68c69
< #undef HAVE_SYS_TYPES_H
---
> #define HAVE_SYS_TYPES_H 1
71c72
< #undef HAVE_UNISTD_H
---
> #define HAVE_UNISTD_H 1
74c75
< #undef HAVE_VPRINTF
---
> #define HAVE_VPRINTF 1
77c78
< #undef HAVE__BOOL
---
> #define HAVE__BOOL 1
80c81
< #undef IS_DARWIN
---
> /* #undef IS_DARWIN */
84c85
< #undef LSTAT_FOLLOWS_SLASHED_SYMLINK
---
> #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
87c88
< #undef PACKAGE
---
> #define PACKAGE "tuscany_sca_native"
90c91
< #undef PACKAGE_BUGREPORT
---
> #define PACKAGE_BUGREPORT ""
93c94
< #undef PACKAGE_NAME
---
> #define PACKAGE_NAME "tuscany_sca_native"
96c97
< #undef PACKAGE_STRING
---
> #define PACKAGE_STRING "tuscany_sca_native 1.0-incubator-M3"
99c100
< #undef PACKAGE_TARNAME
---
> #define PACKAGE_TARNAME "tuscany_sca_native"
102c103
< #undef PACKAGE_VERSION
---
> #define PACKAGE_VERSION "1.0-incubator-M3"
105c106
< #undef STDC_HEADERS
---
> #define STDC_HEADERS 1
108c109
< #undef VERSION
---
> #define VERSION "1.0-incubator-M3"
111c112
< #undef const
---
> /* #undef const */
116c117
< #undef inline
---
> /* #undef inline */


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 18, 2007 4:22 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

yeah I figured that... I did exactly the same when committing changes
earlier! I dodn't commit the changes inthe tools folder.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Ok, I wasn't aware that I had changed the tools.
>
> I simply did a "svn diff . > patch_file" from the tuscany root dir. 
> You can disregard the tools changes. I'll look into it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 4:16 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> Cool! I've applied this change as well. The update2 patch contained 
> changes to the tools/TuscanyDriver/build.xml. This doesn't work so you

> may want to look at it.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > If that's all we need the tuscany_sca_config.h file for then, yes 
> > this
>
> > just got a whole lot easier. We can do the following on the 
> > Tuscany-BaseCompiler
> >
> >  
> >
> >  
> >
> >   > exceptions="true" rtti="true">
> > > define="WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS"/>
> >
> >
> > 
> >
> >
> >  
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 3:41 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > I uploaded a patch on top of what you submit to svn.
> > >
> > > Here is a description of what I changed:
> > >
> > > - Changed the name of compilers.xml to system.xml.
> > >
> > > - This update has better support for a platform.properties file 
> > > that
>
> 

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

[haleh mahbod]

Ant,
will this get generated on each save? I typically do many saves when working
on a page. I'd like to understand this to avoid flooding the mailing list.

Haleh

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


   Page Edited : TUSCANY: 
SCA
Java 
binding.jsonrpc

SCA Java 
binding.jsonrpchas
 been edited by
ant  (Jul 18, 2007).

(View 
changes)
Content:
 Unable to render {include} Couldn't find a page to include called: Repeating
Menu
*Documentation*

User 
Guide
Architecture 
Guide
Developer 
Guide
Extension Developer 
Guide
 *Resources*

FAQ
Source Code 
  

Tuscany supports JSON-RPC  as a protcol for use with
SCA services by using the  SCDL extension. This enables
remote web browser clients to easily make RPC style calls to server-side SCA
components.

This binding has no attributes or elements so to include it on a SCA
service simply requires the following SCDL:



 Also see 
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.ajax>which
 provides some similar function.

Any JSON-RPC client may be used to access SCA services which use <
binding.jsonrpc>, but to simplify the task for web browsers the binding
can generate a script which may be included within an HTML document to set
up proxy objects for each SCA service within the HTML page environment.

This script is used by simply including the following script tag within
the HTML page:



 This initializes the proxys for the SCA services which can then be used
make requests to the server-side components. For example, if there was a
service named "myService" which had operations "aOnewayRequest" and
"anRpcRequest" the scripts in the HTML page could now invoke these
opperations with the following:

myService.aOnewayRequest(args);

 or

myService.anRpcRequest(args, responseFunction);

 In that example 'responseFunction' is the name of a function which is
called to process the response and which gets called asynchronously on
another thread when the response is avaialble. RPC requests are done this
way instead of the simpler "answer = myService.anRpcRequest(args)" to
avoid hanging the browser while the (potentialy slow) request is being
processed. An example of the responseFunction for the previous example is:

function responseFunction(answer){
  // do something with answer
}

 Using SCA JSON-RPC services with Dojo

Apache Tuscany JSON-RPC services provide built-in support for Dojo 
RPC.
The Dojo  toolkit is a popular framework for
writing Ajax/Web 2.0 style browser client applications. Tuscany SCA
services which use  will by default support the Simple
Method Description (SMD)  protocol. SMD is
similar to ?wsdl for Web services, entering a service endpoint appended with
?smd will return a SMD descriptor for the service.

Using Tuscany SCA services with Dojo can therefore be as simple as the
following:

var myService = new dojo.rpc.JsonService("SCA/SCADomain/myService?smd");

 Some examples:

There are two samples showing using , one which uses the
Dojo Toolkit on the client, and another which uses the Tuscany
scaDomain.js script. The samples are 
helloworld-dojoand
helloworld-jsonrpc
.
*Differences between  and *

The current Tuscany SCA runtime supports  and <
binding.ajax> which provide similar functionality. The differences are:

   -  supports the SMD protocol enabling easy use with
   Dojo,  does not support SMD
   -  supports SCA references and using 
COMETstyle asynchronous operation, 
<
   binding.jsonrpc> does not
   -  uses the standard JSON-RPCprotocol, 
<
   binding.ajax> uses a proprietry protocol using DWR

These differences should be resolved by the Tuscany SCA 1.0

Re: [RDB DAS] Wrong Query Result when SELECT misses PKs

[haleh mahbod]

It is best to throw an exception for PK not being there, otherwise an empty
result set can have two meaning:Empty or something went wrong

On 7/18/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:


Amita,

There is now way for DAS to  keep the  relationship  data  consistence if
both, pk and fk, are not completely defined. Without them DAS cannot
predict
the relationship.

As Brent said, I think it could throw an exception when the PK is missing,
no matter if there are relationships or not. Because, as far as I know, a
table that has no complete PK retrieved on the ResultSet  is being omitted
from the graph and I don't think this is a good approach.

But when only the fk is missing, I think it is ok to omit the relationship
between the data objects on the graph. This way the user has the option to
decide if the references(relationships) will be included or not on the
graph.

Regards,
Adriano Crestani

On 7/18/07, Brent Daniel <[EMAIL PROTECTED]> wrote:
>
> Amita,
>
> Definitely, the DAS should enforce the requirement that the PK should
> be returned for each table in the results. I would consider this a
> case where the DAS should throw an exception.
>
> Brent
>
> On 7/18/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > Sorry for the leng  thy mail
> >
> > Tried to check the case when the database has parent-child tables and
> DAS
> > SELECT Command may/may not
> > contain the PKs of the tables. And found some quite confusing
> cases/results,
> > which are effectively giving
> > user a wrong impression of the data in tables.
> >
> > Looks like there are places where we are allowing partial results,
wrong
> > association in parent and child rows.
> > As RDB DAS logic revolves around PKs, can we state clearly that
> > "When Query SELECT does not include PK for a table, the data graph
will
> be
> > empty for that table"
> > ? i.e. in the below analysis, instead of giving wrong/partial result,
at
> > least consistently give no result?
> > And make necessary code corrections to adhere to this statement?
> >
> > Or any alternative approaches?
> >
> > What DAS C++ is doing for this case? Just curious.
> >
>
-
> > Say, take below data -
> > Parent: SINGER(ID, NAME), Child:SONG (ID, TITLE, SINGERID)
> > Data:
> > SINGER
> > ID NAME
> > 
> > 1  Jonh
> > 2  Jane
> >
> > SONG
> > ID   TITLE   SINGERID
> > -
> > 10   ABCD  1
> > 20   Lamb   1
> > 30   La ra ra2
> >
> > There are total 8 cases that I can see. viz.
> >
> > No relationship in config
> > --
> > parent PK in SEL   child PK in SELResult
> > --
> > [1]   present  presentcorrect
> > [2]   present  missingwrong
> > [3]   missing  presentwrong
> > [4]   missing  missing   wrong
> >
> > Relationship in config
> > [5]   presentpresent correct
> > [6]   presentmissing wrong
> > [7]   missingpresent wrong
> > [8]   missingmissingwrong
> >
>
-
> > When relationship is not defined in DAS Config
> > DAS Client code:
> > 
> > DAS das = DAS.FACTORY.createDAS(getConfig("cfg.xml"),
getConnection());
> > Command select = das.getCommand("withNoRel-5/6/7/8");
> > DataObject root = select.executeQuery();
> > List singers = root.getList("SINGER");
> > if(singers != null){
> > System.out.println("Singer size:"+singers.size());
> > for(int i=0; i > System.out.println("SINGER NAME:"+
> > ((DataObject)singers.get(i)).getString("NAME"));
> > }
> >
> > }
> >
> > List songs = root.getList("SONG");//as there is no relationship
> > (explicit/implicit)
> >
> > if(songs != null){
> > System.out.println("Songs size "+songs .size());
> > for(int ii=0; ii > System.out.println("SONG TITLE:"+
> > ((DataObject)songs.get(ii)).getString("TITLE"));
> > }
> > }
> >
> > }
> >
>
-
> > Result:
> >
>
-
> > [1] SELECT SINGER.ID, SINGER.NAME, SONG.ID, SONG.TITLE FROM SINGER,
SONG
> > WHERE SINGER.ID = SONG.SINGERID
> > Singer size:2
> > SINGER NAME:John
> > SINGER NAME:Jane
> > Songs size 3
> > SONG TITLE:ABCD
> > SONG TITLE:Lamb
> > SONG TITLE:La ra ra
> >
> > [2] SELECT SINGER.ID, SINGER.NAME, SONG.TITLE FROM SINGER, SONG WHERE
> > SINGER.ID = SONG.SINGERID
> > Singer size:2
> > SINGER NAME:John
> > SINGER NAME:Jane
> > Songs size 1

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

[ant elder]

It will, just like when we commit code to SVN. I think its necessary if
we're to provide proper oversight of whats happening on our website,  do
others agree?

  ...ant

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


Ant,
will this get generated on each save? I typically do many saves when
working
on a page. I'd like to understand this to avoid flooding the mailing list.

Haleh

On 7/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>Page Edited : TUSCANY<
http://cwiki.apache.org/confluence/display/TUSCANY>: SCA
> Java binding.jsonrpc<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc
>
>
> SCA Java binding.jsonrpc<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc>has
been edited by
> ant  (Jul 18, 2007).
>
> (View changes)<
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=54462&originalVersion=17&revisedVersion=18
>
> Content:
>  Unable to render {include} Couldn't find a page to include called:
Repeating
> Menu<
http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=TUSCANY&title=Repeating+Menu&linkCreation=true&fromPageId=54462
>
> *Documentation*
>
> User Guide<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+User+Guide>
> Architecture Guide<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide
>
> Developer Guide<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Development+Guide
>
> Extension Developer Guide<
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Extension+Development+Guide
>
>  *Resources*
>
> FAQ<
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Java+-+FAQ>
> Source Code 
>   
>
> Tuscany supports JSON-RPC  as a protcol for use
with
> SCA services by using the  SCDL extension. This enables
> remote web browser clients to easily make RPC style calls to server-side
SCA
> components.
>
> This binding has no attributes or elements so to include it on a SCA
> service simply requires the following SCDL:
>
> 
>
>  Also see http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.ajax>which
provides some similar function.
>
> Any JSON-RPC client may be used to access SCA services which use <
> binding.jsonrpc>, but to simplify the task for web browsers the binding
> can generate a script which may be included within an HTML document to
set
> up proxy objects for each SCA service within the HTML page environment.
>
> This script is used by simply including the following script tag within
> the HTML page:
>
> 
>
>  This initializes the proxys for the SCA services which can then be used
> make requests to the server-side components. For example, if there was a
> service named "myService" which had operations "aOnewayRequest" and
> "anRpcRequest" the scripts in the HTML page could now invoke these
> opperations with the following:
>
> myService.aOnewayRequest(args);
>
>  or
>
> myService.anRpcRequest(args, responseFunction);
>
>  In that example 'responseFunction' is the name of a function which is
> called to process the response and which gets called asynchronously on
> another thread when the response is avaialble. RPC requests are done
this
> way instead of the simpler "answer = myService.anRpcRequest(args)" to
> avoid hanging the browser while the (potentialy slow) request is being
> processed. An example of the responseFunction for the previous example
is:
>
> function responseFunction(answer){
>   // do something with answer
> }
>
>  Using SCA JSON-RPC services with Dojo
>
> Apache Tuscany JSON-RPC services provide built-in support for Dojo RPC<
http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book9>.
> The Dojo  toolkit is a popular framework for
> writing Ajax/Web 2.0 style browser client applications. Tuscany SCA
> services which use  will by default support the Simple
> Method Description (SMD)  protocol. SMD is
> similar to ?wsdl for Web services, entering a service endpoint appended
with
> ?smd will return a SMD descriptor for the service.
>
> Using Tuscany SCA services with Dojo can therefore be as simple as the
> following:
>
> var myService = new dojo.rpc.JsonService("SCA/SCADomain/myService?smd");
>
>  Some examples:
>
> There are two samples showing using , one which uses
the
> Dojo Toolkit on the client, and another which uses the Tuscany
> scaDomain.js script. The samples are helloworld-dojo<
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-dojo/
>and
> helloworld-jsonrpc<
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-jsonrpc/
>
> .
> *Differences between  and *
>
> The current Tuscany SCA runtime supports  and <
> binding.ajax> which provide similar functionality. The differences are:
>
>-  supports the SMD protocol enabling easy use with
> 

[jira] Assigned: (TUSCANY-1331) createSelfReferences resultes in SCA binding references with $self$ style URIs

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng reassigned TUSCANY-1331:
-

Assignee: Raymond Feng

> createSelfReferences resultes in SCA binding references with $self$ style URIs
> --
>
> Key: TUSCANY-1331
> URL: https://issues.apache.org/jira/browse/TUSCANY-1331
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
> Environment: sca-java-0.90, IBM JDK5
>Reporter: Matthew Sykes
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> During a discussion on the behavior of the implementation of 
> createSelfReference, rfeng had indicated that the URI of the original service 
> binding should have been preserved when creating the reference binding:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL 
> PROTECTED]
> In the current implementation, SCABinding instances are created based on the 
> generated name of the reference and, as such, the URI from the target service 
> was not preserved.
> As a quick hack to get around the issue, I've changed CompositeBuilderImpl's 
> createSCABindings to remove the $self$. from the reference binding's URI but 
> I expect this is not an appropriate way to address the problem. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

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

[Simon Laws]

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


It will, just like when we commit code to SVN. I think its necessary if
we're to provide proper oversight of whats happening on our website,  do
others agree?

   ...ant

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

[jira] Resolved: (TUSCANY-966) getRequestContext() does not return a Context

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng resolved TUSCANY-966.
--

Resolution: Fixed

I checked the URI and it's fixed in the trunk already.

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Integration Tests
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Question on callback bindings

[Simon Laws]

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


Hi,

Assuming we have the following declaration: reference r1 is wired to
service
s1.


http://ns1#wsdl.interface(Service1)"
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>







http://ns1#wsdl.interface(Service1)"
callbackInterface="http://ns1#wsdl.interface(Service1Callback)"/>






Then the callback path seems to be following: s1 (binding.ws) ---> r1
(binding.ws). Is this like another web service call? or is it really that
the s1 provides asynchronous response to the web service layer and the web
service client is making a callback?

For the forward call, r1 --> ws client ..(soap/http) .ws
service -->s1. Which path should be used for the callback?

1) s1--> ws client ..(soap/http) .ws service -->r1 (another
regular
ws call)
or
2) s1--(ws-callback)--> ws server ...(soap/http) ... ws
client --(ws-callback)-->r1 (over ws callback MEP)

Thanks,
Raymond




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

Well 1) would be useful if the callback occurs outside of the context of

the original call or if the callback doesn't happen for a really long time,
i.e. long enough for connection timeouts. Downside, I guess, is to do the
plumbing to host the callback.

Simon

[jira] Commented: (TUSCANY-966) getRequestContext() does not return a Context

[Jean-Sebastien Delfino (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513755
 ] 

Jean-Sebastien Delfino commented on TUSCANY-966:


ComponentContext.getRequestContext() now returns a correct RequestContext.

However RequestContext.getCallback() fails with an NPE.

To reproduce this error, run the CallbackApiTest test case.

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Integration Tests
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Reopened: (TUSCANY-966) getRequestContext() does not return a Context

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino reopened TUSCANY-966:



Raymond, I suppose you meant to close a different JIRA issue, this one has 
nothing to do with a URI :)

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Integration Tests
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1331) createSelfReferences resultes in SCA binding references with $self$ style URIs

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1331.
-

Resolution: Fixed

This is now fixed in trunk.

> createSelfReferences resultes in SCA binding references with $self$ style URIs
> --
>
> Key: TUSCANY-1331
> URL: https://issues.apache.org/jira/browse/TUSCANY-1331
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-0.90
> Environment: sca-java-0.90, IBM JDK5
>Reporter: Matthew Sykes
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> During a discussion on the behavior of the implementation of 
> createSelfReference, rfeng had indicated that the URI of the original service 
> binding should have been preserved when creating the reference binding:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL 
> PROTECTED]
> In the current implementation, SCABinding instances are created based on the 
> generated name of the reference and, as such, the URI from the target service 
> was not preserved.
> As a quick hack to get around the issue, I've changed CompositeBuilderImpl's 
> createSCABindings to remove the $self$. from the reference binding's URI but 
> I expect this is not an appropriate way to address the problem. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-1437) SDO API project has inappropriate groupId and artifact name

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino updated TUSCANY-1437:


Component/s: (was: Java DAS RDB)
 (was: Java SCA Data Binding Runtime)

JIRA was assigned to incorrect component.

> SDO API project has inappropriate groupId and artifact name
> ---
>
> Key: TUSCANY-1437
> URL: https://issues.apache.org/jira/browse/TUSCANY-1437
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation, Java Spec APIs
>Affects Versions: Java-SDO-beta1
>Reporter: Kelvin Goodson
>
> A point has come up on the discussion of the SDO Java release candidate that 
> the groupid of the tuscany sdo-api maven project should be 
> org.apache.tuscany.sdo and the jar should have a tuscany-prefix.  I think  
> this is the right thing to do, and I'm going to make the change in the 
> 1.0-incubating branch.
> I'll need to make the equivalent change in the trunk some time soon,  which 
> will either break builds that have a dependency on the SDO API in the trunk 
> (if there's no local maven repo caching the old commonj groupid version of 
> the project) or it will cause them not to see updates to the SDO trunk. This 
> requires a bit of coordination.  Perhaps people familiar with thos projects 
> gould point me to the dependencies, or better still create patches for their 
> poms and attach them here, so that I the updates can be made in one commit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: An idea of WS Service address

[ant elder]

On 7/18/07, shaoguang geng <[EMAIL PROTECTED]> wrote:


When I work on the svn code, I found that the service address of a <
binding.ws> depends on it's uri attribute, not the  inside
the wsdl file. If the  is some thing different from the <
binding.ws>'s uri, or it does not exists absolutely, the client will get a
confusion form it http://[host]:[port]/[servicename]?wsdl,

  If I don't give a , I will see a warn, but without the <
binding.ws>' uri, Tuscany runs without any message.



The WS service address is calculated based on section 2.1.1 of the WS
binding spec and section 1.7.2.1 of the assembly spec (see [1]), and there's
a bit about it in the Tuscany doc at [2]. From that, Tuscany should be using
the  from the WSDL if you reference the WSDL port from the <
binding.ws wsdlElement= ...>, the uri attribute is only used if you don't
reference the wsdl port or if it is a relative url. Not sure if that answers
you question though?

  ...ant

[1]
http://osoa.org/display/Main/Service+Component+Architecture+Specifications
[2] http://incubator.apache.org/tuscany/sca-java-bindingws.html

[jira] Resolved: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino resolved TUSCANY-1347.
-

Resolution: Cannot Reproduce

I am running into a completely different issue in trunk:

java.lang.NullPointerException
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:85)
at 
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:87)
at $Proxy8.echoResults(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.AsyncEchoServiceImpl.echo(AsyncEchoServiceImpl.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:85)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy7.echo(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.EchoServiceImpl.asyncEcho(EchoServiceImpl.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:85)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy6.asyncEcho(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.RelayServiceImpl.asyncEcho(RelayServiceImpl.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)
at 
org.apache.tuscany.sca.implementation.java.invocation.PassByValueInvoker.invoke(PassByValueInvoker.java:61)
at 
org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46)
at 
org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41)
at 
org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:85)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73)
at $Proxy6.asyncEcho(Unknown Source)
at 
org.apache.tuscany.sca.test.echoService.EchoServiceTestCase.test_asyncEchoService(EchoServiceTestCase.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingM

[jira] Updated: (TUSCANY-876) JDBC Stored proceduce container using DAS

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino updated TUSCANY-876:
---

Component/s: (was: Java SCA Java Implementation Extension)
 Java DAS RDB

> JDBC Stored proceduce container using DAS
> -
>
> Key: TUSCANY-876
> URL: https://issues.apache.org/jira/browse/TUSCANY-876
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java DAS RDB
>Affects Versions: Java-SCA-Next
>Reporter: Amita Vadhavkar
> Fix For: Java-SCA-Next
>
>
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09892.html
> So, initially this JIRA will be used to implement for stored procedure 
> feature and later can be linked to the generic JIRA
>  http://issues.apache.org/jira/browse/TUSCANY-864  for the entire integration

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (TUSCANY-966) getRequestContext() does not return a Context

[Jean-Sebastien Delfino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Sebastien Delfino updated TUSCANY-966:
---

Component/s: (was: Java SCA Integration Tests)

Updated JIRA component.

> getRequestContext() does not return a Context
> -
>
> Key: TUSCANY-966
> URL: https://issues.apache.org/jira/browse/TUSCANY-966
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-M2
>Reporter: Lou Amodeo
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
>
> Remote Service hangs obtaining the request context using getRequestContext(). 
>  
> [INFO] [tuscany-itest:start {execution: start}]
> [INFO] Starting Tuscany...
> [INFO] [tuscany-itest:test {execution: test}]
> [INFO] Executing tests...
> CallBackApiServiceImpl message received: Knock Knock
> CallBackApiServiceImpl getting request context
> [INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] There were test failures
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time: 37 seconds
> [INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
> [INFO] Final Memory: 7M/18M
> [INFO] 
> 
> ---
> Test set: org.apache.tuscany.sca.test.CallBackApiITest
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec 
> <<< FAILURE!
> testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest)  Time 
> elapsed: 30.023 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: CallBackBasicITest expected: 
> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:81)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
>   at 
> org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
>   at 
> org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
> package org.apache.tuscany.sca.test;
> import org.osoa.sca.annotations.Service;
> import org.osoa.sca.annotations.Context;
> import org.osoa.sca.CompositeContext;
> import org.osoa.sca.RequestContext;
> @Service(CallBackApiService.class)
> public class CallBackApiServiceImpl implements CallBackApiService {
>   @Context
>   protected CompositeContext compositeContext;
>   protected CallBackApiCallBack callback;   
>   
>   public void knockKnock(String aString) { 
>   
>   System.out.println("CallBackApiServiceImpl message received: " + 
> aString);
>   callback = this.getCallBackInterface(); 
>   callback.callBackMessage("Who's There"); 
>   System.out.println("CallBackApiServiceImpl response sent"); 
>   return; 
> 
>   }  
>   private CallBackApiCallBack getCallBackInterface()
>   {   
> System.out.println("CallBackApiServiceImpl getting request context"); 
> 
> RequestContext rc = compositeContext.getRequestContext();
> System.out.println("CallBackApiServiceImpl getting callback from 
> request context");   
> callback =  (CallBackApiCallBack) 
> rc.getServiceReference().getCallback();
> System.out.println("CallBackApiServiceImpl returning callback");  
> return callback;
> 
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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