Re: [C++] Mac OS X port, was: Removing dependency on Axis2C

[Pete Robbins]

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


[snip]
Pete Robbins wrote:
> I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
> that Oisin started.
>

Pete,

I am trying to clean up our JIRA backlog and wondering if TUSCANY-681
can be closed now (https://issues.apache.org/jira/browse/TUSCANY-681).
What is the status of the patch in TUSCANY-681? Has it been included as
part of the Mac OS X port you've been working on?



Oisin's patch has been applied but there's still more to do so I was leaving
this open. The build for samples needs to be checked in. Once I've done that
I'll close 681 and open new Jiras for any problems.

Cheers,





--
Pete

Re: [C++] Running sample with Apache Httpd

[Andrew Borley]

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

Andrew Borley wrote:
> On 12/5/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> Andrew Borley wrote:
>> > On 11/20/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >> Jean-Sebastien Delfino wrote:
>> >> > Hi,
>> >> >
>> >> > I checked in a version of Bigbank configured to run with Apache
>> Httpd
>> >> > (instead of the Axis2 mini HTTP server) under
>> >> > cpp/sca/samples/HttpdBigbank. This is a slightly more distributed
>> >> > version of the original Ruby Bigbank app, with the account
>> service and
>> >> > account data service in different SCA composites. The httpserver
>> >> > directory contains scripts to start/stop Httpd and a very minimal
>> >> > Httpd configuration, tested on Linux with Apache httpd 2.2.3.
>> You will
>> >> > need to complete this conf to make it point to your Axis2C home
>> >> > directory, as described in the README file.
>> >> >
>> >> > I'd like to have all our samples running like this behind Apache
>> >> > httpd. Could you please take a look? see if it can work the same
>> way
>> >> > on Windows, and let me know your comments? Thanks.
>> >> >
>> >>
>> >> I further simplified the configuration, with revision r476996 you
>> don't
>> >> need to make any changes to httpd.conf. The start script now
>> generates
>> >> it for you.
>> >>
>> >
>> > I've just committed a few files to allow this sample to run under
>> > windows - unfortunately there's a Ruby bug at the moment so it
>> > currently segv's, but it was pretty much working before I did an svn
>> > up, so I've put it in!
>> >
>> > Cheers
>> >
>> > Andy
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> Cool! What is causing a segv? Is there a bug in the Ruby interpreter? or
>> is this a bug in our code that we can fix?
>>
>
> I believe it's in our code - none of the Ruby samples currently work.
> I haven't had time to pin it down yet..
>
> Andy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Andy,

Which Ruby binary distribution are you using? I remember Simon saying he
had trouble with the Cigwin Ruby based distribution. I have installed
the one click ruby installer for windows at
http://rubyinstaller.rubyforge.org/wiki/wiki.pl and will give it a try
as well.


I now have the other Ruby samples working, but the HttpdBigBank is
still falling over. Debugging it inside httpd is near impossible, so I
was going to get a local client running - I'm wondering if it's
something to do with the multiple calls into the Axis2C stack that the
sample does, but at this point it's mostly conjecture.

Cheers
Andy

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

[VOTE] Release incubator-M2 version of SCA for Java

[Jeremy Boynes]

Please vote to approve the release of the incubator-M2 version of  
Apache Tuscany SCA for Java.


These archives are -incubator- rather than -incubating- for  
consistency with the SDO and DAS M2 releases.
As before, none of the distributions have a top level directory  
reflecting the version.


RAT reports are included for the source and samples distributions.

Thanks
--
Jeremy

Source distribution:
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-src.tar.gz
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-src.zip
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2.rat


Binary distribution:
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-bin.tar.gz
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-bin.zip


Samples:
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-samples.tar.gz
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-samples.zip
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-samples.rat


Javadoc:
http://people.apache.org/~jboynes/tuscany-M2/tuscany-sca-1.0- 
incubator-M2-javadoc.zip


Artifacts in the Maven repo at
http://people.apache.org/repo/m2-incubating-repository/

org/apache/tuscany/sca/parent/1.0-incubator-M2/parent-1.0-incubator- 
M2.pom
org/apache/tuscany/sca/kernel/parent/1.0-incubator-M2/parent-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/kernel/tuscany-api/1.0-incubator-M2/tuscany- 
api-1.0-incubator-M2.jar
org/apache/tuscany/sca/kernel/tuscany-api/1.0-incubator-M2/tuscany- 
api-1.0-incubator-M2-javadoc.jar
org/apache/tuscany/sca/kernel/tuscany-host-api/1.0-incubator-M2/ 
tuscany-host-api-1.0-incubator-M2.jar
org/apache/tuscany/sca/kernel/tuscany-host-api/1.0-incubator-M2/ 
tuscany-host-api-1.0-incubator-M2-javadoc.jar
org/apache/tuscany/sca/kernel/tuscany-spi/1.0-incubator-M2/tuscany- 
spi-1.0-incubator-M2.jar
org/apache/tuscany/sca/kernel/tuscany-spi/1.0-incubator-M2/tuscany- 
spi-1.0-incubator-M2-javadoc.jar
org/apache/tuscany/sca/kernel/core/1.0-incubator-M2/core-1.0- 
incubator-M2.jar

org/apache/tuscany/sca/test/1.0-incubator-M2/test-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/parent/1.0-incubator-M2/parent-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/services/idl/parent/1.0-incubator-M2/ 
parent-1.0-incubator-M2.pom
org/apache/tuscany/sca/services/idl/wsdl/1.0-incubator-M2/wsdl-1.0- 
incubator-M2.jar
org/apache/tuscany/sca/services/containers/parent/1.0-incubator-M2/ 
parent-1.0-incubator-M2.pom
org/apache/tuscany/sca/services/containers/javascript/1.0-incubator- 
M2/javascript-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/containers/ruby/1.0-incubator-M2/ 
ruby-1.0-incubator-M2.jar
org/apache/tuscany/sca/runtime/parent/1.0-incubator-M2/parent-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/runtime/webapp/1.0-incubator-M2/webapp-1.0- 
incubator-M2.jar
org/apache/tuscany/sca/services/containers/spring/1.0-incubator-M2/ 
spring-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/databinding/parent/1.0-incubator-M2/ 
parent-1.0-incubator-M2.pom
org/apache/tuscany/sca/services/databinding/databinding-axiom/1.0- 
incubator-M2/databinding-axiom-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/databinding/databinding-sdo/1.0- 
incubator-M2/databinding-sdo-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/bindings/parent/1.0-incubator-M2/ 
parent-1.0-incubator-M2.pom
org/apache/tuscany/sca/services/bindings/axis2/1.0-incubator-M2/ 
axis2-1.0-incubator-M2.jar
org/apache/tuscany/sca/services/bindings/rmi/1.0-incubator-M2/rmi-1.0- 
incubator-M2.jar
org/apache/tuscany/sca/services/maven/1.0-incubator-M2/maven-1.0- 
incubator-M2.jar
org/apache/tuscany/sca/runtime/webapp-host/1.0-incubator-M2/webapp- 
host-1.0-incubator-M2.jar
org/apache/tuscany/sca/runtime/standalone/1.0-incubator-M2/ 
standalone-1.0-incubator-M2.jar
org/apache/tuscany/sca/runtime/standalone-host/1.0-incubator-M2/ 
standalone-host-1.0-incubator-M2.jar
org/apache/tuscany/sca/commands/parent/1.0-incubator-M2/parent-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/commands/launcher/1.0-incubator-M2/ 
launcher-1.0-incubator-M2.jar
org/apache/tuscany/sca/sca-tools/1.0-incubator-M2/sca-tools-1.0- 
incubator-M2.jar
org/apache/tuscany/sca/plugins/parent/1.0-incubator-M2/parent-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/plugins/tuscany-war-plugin/1.0-incubator-M2/ 
tuscany-war-plugin-1.0-incubator-M2.jar
org/apache/tuscany/sca/plugins/tuscany-plugin-wsdl2java/1.0-incubator- 
M2/tuscany-plugin-wsdl2java-1.0-incubator-M2.jar
org/apache/tuscany/sca/plugins/tuscany-plugin-java2wsdl/1.0-incubator- 
M2/tuscany-plugin-java2wsdl-1.0-incubator-M2.jar
org/apache/tuscany/sca/distribution/1.0-incubator-M2/distribution-1.0- 
incubator-M2.pom
org/apache/tuscany/sca/distribution/1.0-incubator-M2/distribution-1.0- 
incubator-M2-bin.zip
org/apache/tuscany/sca/distribution/1.0-incubator-M2/distribution-1.0- 
i

Suggestion for try and catch

[Adriano Crestani]

I was executing a query using a stored procedure that was defined in a .xml
file. The procedure was a simple select:  where I just
need to set one parameter. But I mistakenly set 2 parameters. Then I ran the
application, there was no exception, but it didn't worked as expected. So I
debugged the code and I found what was happening. The DAS tried to execute
the query, but as there was more parameters than expected it threw an
exception inside the method
org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(). I don't know
if the jdbc generated this exception or whatever, but the point is that a
problem occurs and no exception was reported and I couldn't know what was
happening. I suggest that if an exception be thrown it should be reported to
the user, in the SDO/DAS case, the coder, in other words, at least an
Exception.printStackTrace() should be called. Anyway, this is only my
suggestion ; )

Adriano Crestani

Re: Anyone else seing build broken : unable to unable to download org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

[David Sanders]

Adding version element to several pom files fixed the build problem for me.
Since I'm new to Maven, this workaround may not be the correct solution,
though.

Workaround:  Add version, e.g.,

   
   org.apache.felix.plugins
   maven-osgi-plugin
   0.8.0-SNAPSHOT
   ...

to all (may be overkill) pom files referencing felix.

$ grep -rl --include=pom.xml 'felix' .
./java/sampleapps/pom.xml
./java/sca/pom.xml
./java/sca/runtime/osgi/pom.xml
./java/spec/commonj/pom.xml
./java/spec/sca/pom.xml
./java/spec/sdo-api/pom.xml
./java/testing/sca/pom.xml





On 12/6/06, Luciano Resende <[EMAIL PROTECTED]> wrote:


I'm not sure... i searched all our pom files and does not look like we
have
explicitly set 0.9.0 as the dependency version...

Here is some more info...


[INFO]   Tuscany Standalone Distribution
[INFO]   Tuscany Project
Downloading:

http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/felix/0.9.0-incubator-SNAPSHOT/felix-0.9.0-incubator-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots (
http://people.apache.org/repo/m2-snapshot-repository)


.

how to override the reference and property?

[Hu hao]

Hi all,

When using composites as component implementations, how to override the
reference and property in the nested composite? Could M2 support this
feature?
I have tried a few variations on this, but there are some exceptions when I
deployed the project. The property and reference are incorrectly.

The next snappet shows default.scdl


http://www.osoa.org/xmlns/sca/1.0"; xmlns:rmi="
http://incubator.apache.org/tuscany/xmlns/binding/rmi/1.0-incubator-M2";
name="PropertyComposite">

 
 
 EFComponent




 e Property in PropertyComposite
 OverrideServiceComponent








The next snappet shows efcomposite.scdl

http://www.osoa.org/xmlns/sca/1.0"; xmlns:rmi="
http://incubator.apache.org/tuscany/xmlns/binding/rmi/1.0-incubator-M2";
xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance"; name="EFcomposite">

 
 EFCompositeComponent


 
 e Property in efcomposite
  OverrideService


  
   
   



Hu hao

[jira] Commented: (TUSCANY-817) Memory leak, data passed through Operation objects is never freed

[Jean-Sebastien Delfino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-817?page=comments#action_12456281 
] 

Jean-Sebastien Delfino commented on TUSCANY-817:


Pressed send too soon, here's the link:

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL 
PROTECTED]


> Memory leak, data passed through Operation objects is never freed
> -
>
> Key: TUSCANY-817
> URL: http://issues.apache.org/jira/browse/TUSCANY-817
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
>Affects Versions: Cpp-current
>Reporter: Jean-Sebastien Delfino
> Fix For: Cpp-current
>
>
> This issue has been covered in two email threads:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL 
> PROTECTED]
> and
> TBD: add link to the subject email thread as soon as it gets archived

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: querying when patches are available for jiras

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

ant elder wrote:
I agree this would be really useful. I'm a JIRA admin so I think I 
should be

able to set it up, I can find various things related to it in the admin
panels, but unfortunately I can't figure out how it all hangs 
together. I
did find some emails in the harmony lists [1] saying Geir set this up 
for

Harmony, so I'll CC him and see if he can tell us how to do it.

  ...ant

[1]
http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg17264.html 



On 11/7/06, kelvin goodson <[EMAIL PROTECTED]> wrote:


I notice from the "filters" link from the jira browse page (i.e.
http://issues.apache.org/jira/secure/popups/savedfilters.jsp) that
projects
such as Derby and Geronimo are able to search on whether a patch is
pending.  This seems to be possible because their search editing 
panel has

a
custom field "Patch Available".  It would be really helpful if we could
switch this behaviour on for Tuscany.  Anyone know how to do that?

Regards, Kelvin.






Ant,

Any update on this?

http://issues.apache.org/jira/secure/IssueNavigator.jspa allows you to 
query issues with Patch Available or Patch Reviewed status, but I 
don't see these fields on the JIRA create issue / edit issue forms.


Do we need a JIRA administrator to configure these fields in the JIRA 
"Field Configuration Scheme"?


Thanks,
**



Trying again :) Ant, did you find how to track JIRAs containing patches?

--
Jean-Sebastien


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

Re: [C++] Running sample with Apache Httpd

[Jean-Sebastien Delfino]

Andrew Borley wrote:

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

Andrew Borley wrote:
> On 11/20/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> Jean-Sebastien Delfino wrote:
>> > Hi,
>> >
>> > I checked in a version of Bigbank configured to run with Apache 
Httpd

>> > (instead of the Axis2 mini HTTP server) under
>> > cpp/sca/samples/HttpdBigbank. This is a slightly more distributed
>> > version of the original Ruby Bigbank app, with the account 
service and

>> > account data service in different SCA composites. The httpserver
>> > directory contains scripts to start/stop Httpd and a very minimal
>> > Httpd configuration, tested on Linux with Apache httpd 2.2.3. 
You will

>> > need to complete this conf to make it point to your Axis2C home
>> > directory, as described in the README file.
>> >
>> > I'd like to have all our samples running like this behind Apache
>> > httpd. Could you please take a look? see if it can work the same 
way

>> > on Windows, and let me know your comments? Thanks.
>> >
>>
>> I further simplified the configuration, with revision r476996 you 
don't
>> need to make any changes to httpd.conf. The start script now 
generates

>> it for you.
>>
>
> I've just committed a few files to allow this sample to run under
> windows - unfortunately there's a Ruby bug at the moment so it
> currently segv's, but it was pretty much working before I did an svn
> up, so I've put it in!
>
> Cheers
>
> Andy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Cool! What is causing a segv? Is there a bug in the Ruby interpreter? or
is this a bug in our code that we can fix?



I believe it's in our code - none of the Ruby samples currently work.
I haven't had time to pin it down yet..

Andy

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




Andy,

Which Ruby binary distribution are you using? I remember Simon saying he 
had trouble with the Cigwin Ruby based distribution. I have installed 
the one click ruby installer for windows at 
http://rubyinstaller.rubyforge.org/wiki/wiki.pl and will give it a try 
as well.


--
Jean-Sebastien


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

[jira] Created: (TUSCANY-979) Docs need to point people to the specific Ruby and Python distros we've tested with

[Jean-Sebastien Delfino (JIRA)]

Docs need to point people to the specific Ruby and Python distros we've tested 
with
---

 Key: TUSCANY-979
 URL: http://issues.apache.org/jira/browse/TUSCANY-979
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SCA
Affects Versions: Cpp-current
 Environment: Windows
Reporter: Jean-Sebastien Delfino
 Fix For: Cpp-current


The docs need to pont people to the specific Ruby and Python distributions 
we've tested with. For example we currently support the MSVC based Ruby 
distribution but not the Cygwin based one (as far as I know).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-817) Memory leak, data passed through Operation objects is never freed

[Jean-Sebastien Delfino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-817?page=comments#action_12456280 
] 

Jean-Sebastien Delfino commented on TUSCANY-817:


Added link to the email thread covering that issue.

> Memory leak, data passed through Operation objects is never freed
> -
>
> Key: TUSCANY-817
> URL: http://issues.apache.org/jira/browse/TUSCANY-817
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
>Affects Versions: Cpp-current
>Reporter: Jean-Sebastien Delfino
> Fix For: Cpp-current
>
>
> This issue has been covered in two email threads:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL 
> PROTECTED]
> and
> TBD: add link to the subject email thread as soon as it gets archived

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[C++] Mac OS X port, was: Removing dependency on Axis2C

[Jean-Sebastien Delfino]

[snip]
Pete Robbins wrote:

I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
that Oisin started.



Pete,

I am trying to clean up our JIRA backlog and wondering if TUSCANY-681 
can be closed now (https://issues.apache.org/jira/browse/TUSCANY-681). 
What is the status of the patch in TUSCANY-681? Has it been included as 
part of the Mac OS X port you've been working on?


Thanks

--
Jean-Sebastien


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

[jira] Resolved: (TUSCANY-852) Missing description of how to deploy an SCA WS with Apache HTTPD and mod_axis2

[Jean-Sebastien Delfino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-852?page=all ]

Jean-Sebastien Delfino resolved TUSCANY-852.


Resolution: Fixed

Verified that the integration with HTTPD works (had to fix a few bugs in our 
code) and added a sample (HttpdBigBank) with a minimal HTTPD configuration and 
instructions to start the server and verify that it works.

> Missing description of how to deploy an SCA WS with Apache HTTPD and mod_axis2
> --
>
> Key: TUSCANY-852
> URL: http://issues.apache.org/jira/browse/TUSCANY-852
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
>Affects Versions: Cpp-current
>Reporter: Jean-Sebastien Delfino
> Assigned To: Jean-Sebastien Delfino
> Fix For: Cpp-current
>
>
> The SCA WS documentation should include the steps to deploy a Web Service 
> using Apache HTTPD and mod_axis2.
> I don't think this is really a release blocker but we should get this 
> documentation on the Web site at least shortly after the release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Updated: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages

[Matthew Sykes (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-978?page=all ]

Matthew Sykes updated TUSCANY-978:
--

Attachment: AccountService.wsdl

WSDL in a more convenient form...

> Tuscany WSDL2Java can't handle WSDL fault messages
> --
>
> Key: TUSCANY-978
> URL: http://issues.apache.org/jira/browse/TUSCANY-978
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Tools
>Affects Versions: Java-M2
> Environment: Tuscany Java-M2 and current trunk
>Reporter: Matthew Sykes
> Attachments: AccountService.wsdl
>
>
> I've been playing with the BigBank sample and have added a fault to the 
> AccountService's withdraw operation.  After changing the AccountService.wsdl 
> (attached), the Tuscany WSDL2Java no longer works:
> [INFO] Generating Java service interfaces from 
> /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: 
> org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped 
> to the name insufficientFundsFault with namespace 
> http://www.bigbank.com/account
> [INFO] 
> 
> [INFO] Trace
> java.lang.IllegalArgumentException: 
> org.apache.axis2.wsdl.codegen.CodeGenerationException: 
> org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped 
> to the name insufficientFundsFault with namespace 
> http://www.bigbank.com/account
> at 
> org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244)
> at 
> org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: 
> org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped 
> to the name insufficientFundsFault with namespace 
> http://www.bigbank.com/account
> at 
> org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178)
> at 
> org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242)
> ... 19 more
> Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type 
> was mapped to the name insufficientFundsFault with namespace 
> http://www.bigbank.com/account
> at 
> org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73)
> at 
> org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958)
> at 
> org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867)
> at 
> org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEm

[jira] Created: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages

[Matthew Sykes (JIRA)]

Tuscany WSDL2Java can't handle WSDL fault messages
--

 Key: TUSCANY-978
 URL: http://issues.apache.org/jira/browse/TUSCANY-978
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Tools
Affects Versions: Java-M2
 Environment: Tuscany Java-M2 and current trunk
Reporter: Matthew Sykes


I've been playing with the BigBank sample and have added a fault to the 
AccountService's withdraw operation.  After changing the AccountService.wsdl 
(attached), the Tuscany WSDL2Java no longer works:

[INFO] Generating Java service interfaces from 
/home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to 
the name insufficientFundsFault with namespace http://www.bigbank.com/account
[INFO] 
[INFO] Trace
java.lang.IllegalArgumentException: 
org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to 
the name insufficientFundsFault with namespace http://www.bigbank.com/account
at 
org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244)
at 
org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: 
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to 
the name insufficientFundsFault with namespace http://www.bigbank.com/account
at 
org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178)
at 
org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242)
... 19 more
Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type 
was mapped to the name insufficientFundsFault with namespace 
http://www.bigbank.com/account
at 
org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1618)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1533)
at 
org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:740)
at 
org.apache.tuscany.to

Re: [C++] SDO: mixing DataObjects from different DataFactory instances

[Yang ZHONG]

I agree we don't need the same-DataFactory restriction.

There might be historical reason(s) for such implementation.
Without knowing the details, I don't see the restriction make sense from
modeling perspective.

A Type's Property's Type may come from a different DataFactory/scope,
and it may also be extended/inherited/XsiTyped by Types from a different
DataFactory/scope.

More importantly, for a Type having "any" element or anyAttribute, why do we
want to restrict values from any other DataFactory/scope?


On 12/6/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


There is a restriction in the current implementation that forces all
DataObjects in a graph to belong to the same DataFactory. I'm not
convinced
we need this. Currently if you create a DataObject (do1) from a
DataFactory
(df1) and then set that as a property on DataObject (do2) that was created
from DataFactory (df2) the code:

  1. Iterates over all the types and properties of do1 recursively
  checking that the types are defined in df2
  2. Iterates through all the instance properties of do1 (recursively
  for props that are DOs) changing the DataFacory of each to df2
  3. burns the cpu out while doing this
  4. crashes as there are many bugs in this logic

While looking into a fix for this I think the easiest solution is to just
not have the restriction at all. The only check that is necessary is that
the Type of do1 matches the Type of the property being set on do2. do1
still
remembers that its DataFactory is df1.This "appears" to work but I'm sure
some corner cases may turn up that require fixing.

Am I missing something obvious here?

Cheers,

--
Pete





--

Yang ZHONG

[jira] Commented: (TUSCANY-928) Define Tuscany SDO options for XMLHelper load and save operations

[Yang ZHONG (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-928?page=comments#action_12456240 
] 

Yang ZHONG commented on TUSCANY-928:


To brainstorm, where to host the options and which are the options?

How about XMLHelperImpl/XMLDocumentImpl to host the options? e.g. 
XMLHelperImpl.LOAD_XXX and XMLHelperImpl.SAVE_XXX.
Or SDOUtil? e.g. SDOUtil.XML_LOAD_XXX and SDOUtil.XML_SAVE_XXX.

How about these options to start with?
Boolean LOAD_SCHEMA
Boolean SAVE_DocType
Integer SAVE_LineWidth
String  SAVE_LineBreak
String  SAVE_INDENT
String  SAVE_MARGIN

> Define Tuscany SDO options for XMLHelper load and save operations
> -
>
> Key: TUSCANY-928
> URL: http://issues.apache.org/jira/browse/TUSCANY-928
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
>
> XMLHelper's load and save operations take an Object argument  "options", 
> which is currently cast to a Map and forwarded to EMF.  Anyone wishing to 
> influence the behaviour of the save/load operations must understand this 
> aspect of EMF and use EMF artifacts in their programs.  We need to design and 
> implement an SDO approach to passing options,  hiding the implementation 
> details completely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[C++] SDO: mixing DataObjects from different DataFactory instances

[Pete Robbins]

There is a restriction in the current implementation that forces all
DataObjects in a graph to belong to the same DataFactory. I'm not convinced
we need this. Currently if you create a DataObject (do1) from a DataFactory
(df1) and then set that as a property on DataObject (do2) that was created
from DataFactory (df2) the code:

  1. Iterates over all the types and properties of do1 recursively
  checking that the types are defined in df2
  2. Iterates through all the instance properties of do1 (recursively
  for props that are DOs) changing the DataFacory of each to df2
  3. burns the cpu out while doing this
  4. crashes as there are many bugs in this logic

While looking into a fix for this I think the easiest solution is to just
not have the restriction at all. The only check that is necessary is that
the Type of do1 matches the Type of the property being set on do2. do1 still
remembers that its DataFactory is df1.This "appears" to work but I'm sure
some corner cases may turn up that require fixing.

Am I missing something obvious here?

Cheers,

--
Pete

Re: Anyone else seing build broken : unable to unable to download org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

[Luciano Resende]

I'm not sure... i searched all our pom files and does not look like we have
explicitly set 0.9.0 as the dependency version...

Here is some more info...


[INFO]   Tuscany Standalone Distribution
[INFO]   Tuscany Project
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/felix/0.9.0-incubator-SNAPSHOT/felix-0.9.0-incubator-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots (
http://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/felix/0.9.0-incubator-SNAPSHOT/felix-0.9.0-incubator-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots (
http://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://snapshots.repository.codehaus.org/org/apache/felix/felix/0.9.0-incubator-SNAPSHOT/felix-0.9.0-incubator-SNAPSHOT.pom
[WARNING] Unable to get resource from repository codehaus-snapshot (
http://snapshots.repository.codehaus.org)
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/felix/felix/0.9.0-incubator-SNAPSHOT/felix-0.9.0-incubator-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people.apache.org/repo/m2-incubating-repository)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.




[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving
version for 'org.apache.felix.plugins:maven-osgi-plugin': Unable to read the
metadata file for artifact 'org.apache.felix.plugins:maven-osgi-plugin:pom':
Cannot find parent: org.apache.felix:felix for project:
org.apache.felix.plugins:maven-osgi-plugin:maven-plugin:0.9.0-incubator-20061206.161951-1
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(
DefaultLifecycleExecutor.java:1261)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findArtifactTypeHandlers
(DefaultLifecycleExecutor.java:1171)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(
DefaultLifecycleExecutor.java:173)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:138)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.version.PluginVersionResolutionException:
Error resolving version for 'org.apache.felix.plugins:maven-osgi-plugin':
Unable to read the metadata file for artifact '
org.apache.felix.plugins:maven-osgi-plugin:pom': Cannot find parent:
org.apache.felix:felix for project:
org.apache.felix.plugins:maven-osgi-plugin:maven-plugin:0.9.0-incubator-20061206.161951-1
   at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion
(DefaultPluginVersionManager.java:678)
   at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion
(DefaultPluginVersionManager.java:183)
   at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion
(DefaultPluginVersionManager.java:87)
   at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(
DefaultPluginManager.java:158)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(
DefaultLifecycleExecutor.java:1252)
   ... 14 more
Caused by:
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException:
Unable to read the metadata file for artifact '
org.apache.felix.plugins:maven-osgi-plugin:pom': Cannot find parent:
org.apache.felix:felix for project:
org.apache.felix.plugins:maven-osgi-plugin:maven-plugin:0.9.0-incubator-20061206.161951-1
   at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(
MavenMetadataSource.java:131)
   at
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion
(DefaultPluginVersionManager.java:669)
   ... 18 more
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
parent: org.apache.felix:felix for project:
org.apache.felix.plugins:maven-osgi-plugin:maven-plugin:0.9.0-incubator-20061206.161951-1
   at org.apache.maven.project.DefaultMavenProject

Re: [C++] Who is working on which SDO problems

[Pete Robbins]

Thanks Yang. I'm going to have a trawl throught the Jiras and prioritise.
There are some I know about that I haven't raised yet that could be quite
large pieces of work, for instance there seems to be a performance issue
loading large schema which contain lots of ref="..." elements. I'll post a
first take on what I think are the major issues so we can discuss here.
Hopefully I can do that tomorrow.

Cheers,


On 06/12/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:


I'd like to help, so which other SDO defects are holding folk up?

On 12/5/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> I have just checked in a new fix for 963.
>
> Which other SDO defects are holfing folk up?
>
> Cheers,
>
> --
> Pete
>
>


--

Yang ZHONG





--
Pete

[jira] Updated: (TUSCANY-976) Multiple Callbacks fail

[Lou Amodeo (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-976?page=all ]

Lou Amodeo updated TUSCANY-976:
---

Attachment: test-CallBackBasic.zip

I have attached my test case. Thank You.

> Multiple Callbacks fail
> ---
>
> Key: TUSCANY-976
> URL: http://issues.apache.org/jira/browse/TUSCANY-976
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Reporter: Lou Amodeo
> Assigned To: Ignacio Silva-Lepe
> Attachments: test-CallBackBasic.zip
>
>
> I have a stateless service that performs multiple callbacks.  The first 
> callback is successful.  The next callback hangs during the call to the 
> callback method.   
>  public void multiCallBack(String aString) { 
>   
> System.out.println("CallBackBasicServiceImpl message received: " + 
> aString);
> callback.callBackIncrement("Who's There 1"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 2"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 3"); 
> System.out.println("CallBackBasicServiceImpl response sent");  
> return; 
> 
>   }  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Anyone else seing build broken : unable to unable to download org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

[Jeremy Boynes]

Yep 0.8.0 seems to be the latest - do you know which pom is looking  
for 0.9.0?

--
Jeremy

On Dec 6, 2006, at 11:57 AM, Luciano Resende wrote:


Looks like there is only a 0.8.0 snapshot available there...
http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
felix/felix/



[INFO]
-- 
--

[ERROR] BUILD ERROR
[INFO]
-- 
--

[INFO] Failed to resolve artifact.

GroupId: org.apache.felix
ArtifactId: felix
Version: 0.9.0-incubator-SNAPSHOT

Reason: Unable to download the artifact from any repository

 org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache.incubator (http://people.apache.org/repo/m2-incubating- 
repository),
 apache.snapshots (http://people.apache.org/repo/m2-snapshot- 
repository),

 codehaus-snapshot (http://snapshots.repository.codehaus.org)

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



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

Re: [C++] Who is working on which SDO problems

[Yang ZHONG]

I'd like to help, so which other SDO defects are holding folk up?

On 12/5/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


I have just checked in a new fix for 963.

Which other SDO defects are holfing folk up?

Cheers,

--
Pete





--

Yang ZHONG

[jira] Updated: (TUSCANY-972) commonj.sdo/xml namespace should be supported by SDO runtime by default

[Yang ZHONG (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-972?page=all ]

Yang ZHONG updated TUSCANY-972:
---

Attachment: TypeHelperImpl.972
newMainSrc.zip

The attached implementation of this feature has passed all build tests.

> commonj.sdo/xml namespace should be supported by SDO runtime by default
> ---
>
> Key: TUSCANY-972
> URL: http://issues.apache.org/jira/browse/TUSCANY-972
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Fuhwei Lwo
> Attachments: newMainSrc.zip, TypeHelperImpl.972
>
>
> Currently commonj.sdo and commonj.sdo/java namespaces are supported by SDO 
> runtime by default.  Commonj.sdo/xml should be supported as part of SDO 
> runtime model too.  Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Anyone else seing build broken : unable to unable to download org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

[Luciano Resende]

Looks like there is only a 0.8.0 snapshot available there...
http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/felix/


[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

GroupId: org.apache.felix
ArtifactId: felix
Version: 0.9.0-incubator-SNAPSHOT

Reason: Unable to download the artifact from any repository

 org.apache.felix:felix:pom:0.9.0-incubator-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache.incubator (http://people.apache.org/repo/m2-incubating-repository),
 apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
 codehaus-snapshot (http://snapshots.repository.codehaus.org)

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

Re: Moving DAS samples that demonstrate SCA integration

[Luciano Resende]

Done at revision : 483195

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


As discussed on the following thread, the DAS samples that explore DAS as
an SCA integration were generating a circular reference

   http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10662.html

If people are ok, I'd like to go ahead and move these projects to the
/java/sampleapps :


Today
  - das/samples/das.service
  - das/samples/das.service.client


Proposed change

  - sampleApps/das.pojo.service/service
  - sampleApps/das.pojo.service/webclient


Toughts ? If people are ok I'll go ahead and commit these changes...

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





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

Re: UnsupportedOperationException on conversation sample, databinding issue?

[Ignacio Silva-Lepe]

You could check for operation.isNonBlocking and
operation.getCallbackName != null.


On 12/6/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

We used to have a shortcut for null value to by pass data transformation
which had caused problems in document-literal wrapped WSDL operations with
empty input or output. With the fixes, we try to set the null value back
even it's not changed and that's why you got the exception.

What's the best way to test if the operation is one-way? I can use it to
not
reset the body. Or as a workaround, I can test if the value hasn't been
changed, then we don't call the Message.setBody().

Thanks,
Raymond

- Original Message -
From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]>
To: "Tuscany Dev List" 
Sent: Wednesday, December 06, 2006 10:59 AM
Subject: UnsupportedOperationException on conversation sample, databinding
issue?


> After an update that picks up some databinding changes, I am getting the
> following error on the local conversation sample, which used to be
> working.
> Notice that the operation being invoked is annotated @OneWay and so
> it has no return value, which is why the ImmutableMessage is being used.
> I have updated to level r483175.
>
> Running loanappconversation.LoanAppConversationTestCase
> Applied: Loan application: [Customer: John Doe, loan amount: 1000.0],
> term:
> 0, s
> tatus: open
> Loan approved: false
> java.lang.UnsupportedOperationException
>at
> org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$Immutable
> Message.setBody(NonBlockingBridgingInterceptor.java:131)
>at
> org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke
> (DataBindingInteceptor.java:88)
>at
> org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(
> AbstractOutboundInvocationHandler.java:91)
>at
> org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(
> JDKOutboundInvocationHandler.java:149)
>at $Proxy20.cancelApplication(Unknown Source)
>at
> loanappconversation.LoanClientImpl.cancelLoan(LoanClientImpl.java
> :55)
>
>at loanappconversation.LoanAppConversationTestCase.test
> (LoanAppConversat
>


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

Re: [DAS]Approach for JIRA-948

[Brent Daniel]

Luciano,

I'm referring  to the changes to the DAS config model in Amita's patch.

Brent

On 12/6/06, Luciano Resende <[EMAIL PROTECTED]> wrote:

Hi Brent, are you recommending these changes in the SCDL ? Or in the DAS
config itself to better handle other types of connections in J2SE
environments ?

- Luciano

On 12/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
>
> Amita,
>
>   Thanks for working on this. One thing I would like to see is the
> DataSource properties seperated from the J2SE Connection properties.
> Maybe something like:
>
> 
> 
>
> or
>
> 
>   
> 
>
> The seperation just makes it clearer that your application should use
> one or the other approaches.
>
> Also, are all of the properties you have added necessary? In
> particular, I'm not sure what we would use databaseVendor for since it
> shouldn't have an effect on how we obtain the connection.
>
> I didn't look deeply enough to see if your code addresses this, but if
> we're adding a password field we will need to have a way to
> encrypt/decrypt the field.
>
> Thanks,
> Brent
>
> On 12/6/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > Hi Kevin, Luciano and All,
> > I tried to implement support for DAS config connection for J2SE env.
> Please
> > see the attachment for what changes are done. Tried to modify config.xsdand
> > related code changes. Please let me know your feedback on this approach
> > and the alternative approaches.
> >
> > Can we have a discussion on same and also please let me know if I can
> work
> > on this
> > JIRA.
> >
> > Regards,
> > Amita
> > -
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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




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

[jira] Created: (TUSCANY-977) NoRegisteredCallbackException not thrown to client

[Lou Amodeo (JIRA)]

NoRegisteredCallbackException not thrown to client
--

 Key: TUSCANY-977
 URL: http://issues.apache.org/jira/browse/TUSCANY-977
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Reporter: Lou Amodeo


NoRegisteredCallbackException not thrown to client.  

The client does not implement the callback interface and does not call 
setCallback prior to calling the service.   I was expecting to receive an 
exception and instead the service was invoked.  

try
 {
   aCallBackService.knockKnock("Knock Knock");
 }
 catch (NoRegisteredCallbackException NotRegEx)
 {
correctException = true; 
 }  
 catch (Exception ex)
 {
  ex.printStackTrace();  
 }   
  



[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
CallBackBasicServiceImpl message received: Knock Knock
java.lang.NullPointerException
at org.apache.tuscany.sca.test.CallBackSetCallbackServiceImpl.knockKnock
(CallBackSetCallbackServiceImpl.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT
arget(JavaTargetInvoker.java:71)
at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target
InvokerExtension.java:64)
at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce
ptor.java:44)
at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non
BlockingBridgingInterceptor.java:80)
at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2
37Work.run(Jsr237WorkScheduler.java:212)
at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo
rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:665)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:690)
at java.lang.Thread.run(Thread.java:797)
[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: 9 seconds
[INFO] Finished at: Wed Dec 06 14:06:57 EST 2006
[INFO] Final Memory: 7M/19M
[INFO] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: UnsupportedOperationException on conversation sample, databinding issue?

[Raymond Feng]

Hi,

We used to have a shortcut for null value to by pass data transformation 
which had caused problems in document-literal wrapped WSDL operations with 
empty input or output. With the fixes, we try to set the null value back 
even it's not changed and that's why you got the exception.


What's the best way to test if the operation is one-way? I can use it to not 
reset the body. Or as a workaround, I can test if the value hasn't been 
changed, then we don't call the Message.setBody().


Thanks,
Raymond

- Original Message - 
From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]>

To: "Tuscany Dev List" 
Sent: Wednesday, December 06, 2006 10:59 AM
Subject: UnsupportedOperationException on conversation sample, databinding 
issue?




After an update that picks up some databinding changes, I am getting the
following error on the local conversation sample, which used to be 
working.

Notice that the operation being invoked is annotated @OneWay and so
it has no return value, which is why the ImmutableMessage is being used.
I have updated to level r483175.

Running loanappconversation.LoanAppConversationTestCase
Applied: Loan application: [Customer: John Doe, loan amount: 1000.0], 
term:

0, s
tatus: open
Loan approved: false
java.lang.UnsupportedOperationException
   at
org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$Immutable
Message.setBody(NonBlockingBridgingInterceptor.java:131)
   at
org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:88)
   at
org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(
AbstractOutboundInvocationHandler.java:91)
   at
org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(
JDKOutboundInvocationHandler.java:149)
   at $Proxy20.cancelApplication(Unknown Source)
   at 
loanappconversation.LoanClientImpl.cancelLoan(LoanClientImpl.java

:55)

   at loanappconversation.LoanAppConversationTestCase.test
(LoanAppConversat




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

Re: [DAS]Approach for JIRA-948

[Luciano Resende]

Hi Brent, are you recommending these changes in the SCDL ? Or in the DAS
config itself to better handle other types of connections in J2SE
environments ?

- Luciano

On 12/6/06, Brent Daniel <[EMAIL PROTECTED]> wrote:


Amita,

  Thanks for working on this. One thing I would like to see is the
DataSource properties seperated from the J2SE Connection properties.
Maybe something like:




or


  


The seperation just makes it clearer that your application should use
one or the other approaches.

Also, are all of the properties you have added necessary? In
particular, I'm not sure what we would use databaseVendor for since it
shouldn't have an effect on how we obtain the connection.

I didn't look deeply enough to see if your code addresses this, but if
we're adding a password field we will need to have a way to
encrypt/decrypt the field.

Thanks,
Brent

On 12/6/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> Hi Kevin, Luciano and All,
> I tried to implement support for DAS config connection for J2SE env.
Please
> see the attachment for what changes are done. Tried to modify config.xsdand
> related code changes. Please let me know your feedback on this approach
> and the alternative approaches.
>
> Can we have a discussion on same and also please let me know if I can
work
> on this
> JIRA.
>
> Regards,
> Amita
> -
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

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





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

Re: [DAS]Approach for JIRA-948

[Brent Daniel]

Amita,

 Thanks for working on this. One thing I would like to see is the
DataSource properties seperated from the J2SE Connection properties.
Maybe something like:




or


 


The seperation just makes it clearer that your application should use
one or the other approaches.

Also, are all of the properties you have added necessary? In
particular, I'm not sure what we would use databaseVendor for since it
shouldn't have an effect on how we obtain the connection.

I didn't look deeply enough to see if your code addresses this, but if
we're adding a password field we will need to have a way to
encrypt/decrypt the field.

Thanks,
Brent

On 12/6/06, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Hi Kevin, Luciano and All,
I tried to implement support for DAS config connection for J2SE env. Please
see the attachment for what changes are done. Tried to modify config.xsd and
related code changes. Please let me know your feedback on this approach
and the alternative approaches.

Can we have a discussion on same and also please let me know if I can work
on this
JIRA.

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





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

[jira] Commented: (TUSCANY-976) Multiple Callbacks fail

[Ignacio Silva-Lepe (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-976?page=comments#action_12456163 
] 

Ignacio Silva-Lepe commented on TUSCANY-976:


Can you attach a trace and possibly some additional relevant code? Thanks

> Multiple Callbacks fail
> ---
>
> Key: TUSCANY-976
> URL: http://issues.apache.org/jira/browse/TUSCANY-976
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Reporter: Lou Amodeo
> Assigned To: Ignacio Silva-Lepe
>
> I have a stateless service that performs multiple callbacks.  The first 
> callback is successful.  The next callback hangs during the call to the 
> callback method.   
>  public void multiCallBack(String aString) { 
>   
> System.out.println("CallBackBasicServiceImpl message received: " + 
> aString);
> callback.callBackIncrement("Who's There 1"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 2"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 3"); 
> System.out.println("CallBackBasicServiceImpl response sent");  
> return; 
> 
>   }  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-976) Multiple Callbacks fail

[Ignacio Silva-Lepe (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-976?page=all ]

Ignacio Silva-Lepe reassigned TUSCANY-976:
--

Assignee: Ignacio Silva-Lepe

> Multiple Callbacks fail
> ---
>
> Key: TUSCANY-976
> URL: http://issues.apache.org/jira/browse/TUSCANY-976
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Reporter: Lou Amodeo
> Assigned To: Ignacio Silva-Lepe
>
> I have a stateless service that performs multiple callbacks.  The first 
> callback is successful.  The next callback hangs during the call to the 
> callback method.   
>  public void multiCallBack(String aString) { 
>   
> System.out.println("CallBackBasicServiceImpl message received: " + 
> aString);
> callback.callBackIncrement("Who's There 1"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 2"); 
> System.out.println("CallBackBasicServiceImpl response sent");
> callback.callBackIncrement("Who's There 3"); 
> System.out.println("CallBackBasicServiceImpl response sent");  
> return; 
> 
>   }  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

UnsupportedOperationException on conversation sample, databinding issue?

[Ignacio Silva-Lepe]

After an update that picks up some databinding changes, I am getting the
following error on the local conversation sample, which used to be working.
Notice that the operation being invoked is annotated @OneWay and so
it has no return value, which is why the ImmutableMessage is being used.
I have updated to level r483175.

Running loanappconversation.LoanAppConversationTestCase
Applied: Loan application: [Customer: John Doe, loan amount: 1000.0], term:
0, s
tatus: open
Loan approved: false
java.lang.UnsupportedOperationException
   at
org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$Immutable
Message.setBody(NonBlockingBridgingInterceptor.java:131)
   at
org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke
(DataBindingInteceptor.java:88)
   at
org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(
AbstractOutboundInvocationHandler.java:91)
   at
org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(
JDKOutboundInvocationHandler.java:149)
   at $Proxy20.cancelApplication(Unknown Source)
   at loanappconversation.LoanClientImpl.cancelLoan(LoanClientImpl.java
:55)

   at loanappconversation.LoanAppConversationTestCase.test
(LoanAppConversat

[jira] Created: (TUSCANY-976) Multiple Callbacks fail

[Lou Amodeo (JIRA)]

Multiple Callbacks fail
---

 Key: TUSCANY-976
 URL: http://issues.apache.org/jira/browse/TUSCANY-976
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Reporter: Lou Amodeo


I have a stateless service that performs multiple callbacks.  The first 
callback is successful.  The next callback hangs during the call to the 
callback method.   

 public void multiCallBack(String aString) { 

  System.out.println("CallBackBasicServiceImpl message received: " + 
aString);
  callback.callBackIncrement("Who's There 1"); 
  System.out.println("CallBackBasicServiceImpl response sent");
  callback.callBackIncrement("Who's There 2"); 
  System.out.println("CallBackBasicServiceImpl response sent");
  callback.callBackIncrement("Who's There 3"); 
  System.out.println("CallBackBasicServiceImpl response sent");  
  return; 
  
}  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Switch to SDO 2.1 HelperContext for SDO databinding in trunk

[Raymond Feng]

Hi,

I have made changes locally to switch to SDO 2.1 HelperContext to replace some 
deprecated SDOUtil APIs. If there are no other concerns, I'll commit them into 
trunk.

Thanks,
Raymond

Re: svn commit: r483110 - in /incubator/tuscany/tags/java/sca/1.0-incubator-M2: ./ commands/ commands/launcher/ distribution/ kernel/ kernel/api/ kernel/core/ kernel/host-api/ kernel/spi/ plugins/ plu

[Raymond Feng]

Hi,

I attach it again in ".txt" suffix. Please let me know if you get it. 
Otherwise I'll create a JIRA to attach it.


Thanks,
Raymond

- Original Message - 
From: "Jeremy Boynes" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, December 06, 2006 10:16 AM
Subject: Re: svn commit: r483110 - in 
/incubator/tuscany/tags/java/sca/1.0-incubator-M2: ./ commands/ 
commands/launcher/ distribution/ kernel/ kernel/api/ kernel/core/ 
kernel/host-api/ kernel/spi/ plugins/ plugins/plugin.java2wsdl/ 
plugins/plugin.war/ plugins/plugi




On Dec 6, 2006, at 8:26 AM, Raymond Feng wrote:


Hi, Jeremy.

I'm not sure if you use the sca/distribution/build.xml to create  distros 
for M2. The build.xml tagged for M2 still has references to  svn M2 
branches. Attached is a patch to fix it (I'll let you decide  if we 
commit it).


I think the patch was stripped.

Last time I cut the binaries I did not use that script as I wasn't  clear 
on what it was going to do. I was planing on doing that again.


--
Jeremy

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


Index: build.xml
===
--- build.xml   (revision 483131)
+++ build.xml   (working copy)
@@ -148,7 +148,7 @@



-
+



@@ -157,7 +157,7 @@



-
+



@@ -172,7 +172,7 @@



-
+



@@ -181,7 +181,7 @@



-
+




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

[jira] Created: (TUSCANY-975) Scope object factory not registered for scope [CONVERSATION]

[Lou Amodeo (JIRA)]

Scope object factory not registered for scope [CONVERSATION]


 Key: TUSCANY-975
 URL: http://issues.apache.org/jira/browse/TUSCANY-975
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Reporter: Lou Amodeo


Conversation scope is not recognized. 


[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Scope object factory not registered for scope [CONVERSATION]
[INFO] 
[INFO] Trace
org.apache.tuscany.spi.component.ScopeNotFoundException: Scope object factory n
t registered for scope [CONVERSATION]
at org.apache.tuscany.core.component.scope.ScopeRegistryImpl.getScopeCo
tainer(ScopeRegistryImpl.java:65)
at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.bui
d(JavaComponentBuilder.java:76)
at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.bui
d(JavaComponentBuilder.java:53)
at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderReg
stryImpl.java:115)
at org.apache.tuscany.core.implementation.composite.CompositeBuilder.bu
ld(CompositeBuilder.java:93)
at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderReg
stryImpl.java:115)
at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.jav
:115)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.ja
a:81)
at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScd
(AbstractRuntime.java:136)
at org.apache.tuscany.sca.plugin.itest.MavenEmbeddedRuntime.initialize(
avenEmbeddedRuntime.java:85)
at org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(Tuscany
tartMojo.java:102)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlug
nManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Def
ultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithL
fecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defa
ltLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa
dleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme
ts(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultL
fecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Dec 06 13:43:48 EST 2006
[INFO] Final Memory: 6M/17M
[INFO] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: HTTPSession state

[Jim Marino]

On Dec 6, 2006, at 10:27 AM, Jeremy Boynes wrote:



What notification? Change detection and/or optimization is  
something the servlet container needs to do as it own the session  
state.
Yes I agree. I didn't say that :-) If a state change occurs on a  
session-scoped object, the servlet context needs to be notified. This  
is generally done by resetting the object into the servlet context.  
This doesn't have anything to do with replicating diffs (although a  
fail-over mechanism may do that, e.g. Terracotta). This should be  
done by Tuscany, probably after an invoke, not by the application  
since it would tie the app to the servlet container and is generally  
a PITA for developers (many web apps today don't get this right).


Jim

We need to delegate all state to it otherwise we will risk partial  
replication (i.e. broken data) if the servlet container decides to  
migrate the session. Efficiency of this is down to the servlet  
container's implementation.




Intent is a separate issue and we don't even have basic support  
for that yet (or do we?). Even if we did we can map this to  
whether the servlet is  or not.


Servlet? Some components we may want fail-over for, some we may  
not. We need a way to distinguish this.


Nice feature but for now we have none and doing this would give us  
an option. Cherry picking which at a component by component level  
can be done later (e.g. when we have something like the intent  
mechanism that allows the distinction to made).


--
Jeremy


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




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

Re: HTTPSession state

[Jeremy Boynes]

On Dec 6, 2006, at 10:17 AM, Jim Marino wrote:



On Dec 6, 2006, at 10:04 AM, Jeremy Boynes wrote:


On Dec 6, 2006, at 9:05 AM, Jim Marino (JIRA) wrote:

[ http://issues.apache.org/jira/browse/TUSCANY-973? 
page=comments#action_12456118 ]


Jim Marino commented on TUSCANY-973:


This needs to implement semantics similar to conversational  
persistence and not just use the ServletContext as a container  
for replication to work properly. At a certain point, the servlet  
engine needs to be notified of a series of changes through  
setAttribute. This is the same pattern we have with  
conversational scope. We should also have a mechanism based on  
intents that specify whether a particular instance should  
failover, otherwise, we don't need to store it in the Servlet  
context.


I don't see this. The conversation scope here is the HTTP session  
and that is represented by the HTTPSession managed by the  
ServletContext. That seems an obvious place to be placing the state.
Yes that is exactly what I am saying. However, notification that  
state has changed needs to be done similar to the way we are  
handling conversation persistence. None of this would use the  
conversational scope container.


What notification? Change detection and/or optimization is something  
the servlet container needs to do as it own the session state. We  
need to delegate all state to it otherwise we will risk partial  
replication (i.e. broken data) if the servlet container decides to  
migrate the session. Efficiency of this is down to the servlet  
container's implementation.




Intent is a separate issue and we don't even have basic support  
for that yet (or do we?). Even if we did we can map this to  
whether the servlet is  or not.


Servlet? Some components we may want fail-over for, some we may  
not. We need a way to distinguish this.


Nice feature but for now we have none and doing this would give us an  
option. Cherry picking which at a component by component level can be  
done later (e.g. when we have something like the intent mechanism  
that allows the distinction to made).


--
Jeremy


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

Re: HTTPSession state, was: [jira] Commented: (TUSCANY-973) HttpSessionScopeContainer should use the HttpSession for session persistance

[Jim Marino]

On Dec 6, 2006, at 10:04 AM, Jeremy Boynes wrote:


On Dec 6, 2006, at 9:05 AM, Jim Marino (JIRA) wrote:

[ http://issues.apache.org/jira/browse/TUSCANY-973? 
page=comments#action_12456118 ]


Jim Marino commented on TUSCANY-973:


This needs to implement semantics similar to conversational  
persistence and not just use the ServletContext as a container for  
replication to work properly. At a certain point, the servlet  
engine needs to be notified of a series of changes through  
setAttribute. This is the same pattern we have with conversational  
scope. We should also have a mechanism based on intents that  
specify whether a particular instance should failover, otherwise,  
we don't need to store it in the Servlet context.


I don't see this. The conversation scope here is the HTTP session  
and that is represented by the HTTPSession managed by the  
ServletContext. That seems an obvious place to be placing the state.
Yes that is exactly what I am saying. However, notification that  
state has changed needs to be done similar to the way we are handling  
conversation persistence. None of this would use the conversational  
scope container.


Intent is a separate issue and we don't even have basic support for  
that yet (or do we?). Even if we did we can map this to whether the  
servlet is  or not.


Servlet? Some components we may want fail-over for, some we may not.  
We need a way to distinguish this.

--
Jeremy


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




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

Re: svn commit: r483110 - in /incubator/tuscany/tags/java/sca/1.0-incubator-M2: ./ commands/ commands/launcher/ distribution/ kernel/ kernel/api/ kernel/core/ kernel/host-api/ kernel/spi/ plugins/ plu

[Jeremy Boynes]

On Dec 6, 2006, at 8:26 AM, Raymond Feng wrote:


Hi, Jeremy.

I'm not sure if you use the sca/distribution/build.xml to create  
distros for M2. The build.xml tagged for M2 still has references to  
svn M2 branches. Attached is a patch to fix it (I'll let you decide  
if we commit it).


I think the patch was stripped.

Last time I cut the binaries I did not use that script as I wasn't  
clear on what it was going to do. I was planing on doing that again.


--
Jeremy

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

HTTPSession state, was: [jira] Commented: (TUSCANY-973) HttpSessionScopeContainer should use the HttpSession for session persistance

[Jeremy Boynes]

On Dec 6, 2006, at 9:05 AM, Jim Marino (JIRA) wrote:

[ http://issues.apache.org/jira/browse/TUSCANY-973? 
page=comments#action_12456118 ]


Jim Marino commented on TUSCANY-973:


This needs to implement semantics similar to conversational  
persistence and not just use the ServletContext as a container for  
replication to work properly. At a certain point, the servlet  
engine needs to be notified of a series of changes through  
setAttribute. This is the same pattern we have with conversational  
scope. We should also have a mechanism based on intents that  
specify whether a particular instance should failover, otherwise,  
we don't need to store it in the Servlet context.


I don't see this. The conversation scope here is the HTTP session and  
that is represented by the HTTPSession managed by the ServletContext.  
That seems an obvious place to be placing the state.


Intent is a separate issue and we don't even have basic support for  
that yet (or do we?). Even if we did we can map this to whether the  
servlet is  or not.


--
Jeremy


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

[jira] Commented: (TUSCANY-973) HttpSessionScopeContainer should use the HttpSession for session persistance

[Jim Marino (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-973?page=comments#action_12456118 
] 

Jim Marino commented on TUSCANY-973:


This needs to implement semantics similar to conversational persistence and not 
just use the ServletContext as a container for replication to work properly. At 
a certain point, the servlet engine needs to be notified of a series of changes 
through setAttribute. This is the same pattern we have with conversational 
scope. We should also have a mechanism based on intents that specify whether a 
particular instance should failover, otherwise, we don't need to store it in 
the Servlet context.

> HttpSessionScopeContainer should use the HttpSession for session persistance
> 
>
> Key: TUSCANY-973
> URL: http://issues.apache.org/jira/browse/TUSCANY-973
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Affects Versions: Java-M2
>Reporter: ant elder
> Assigned To: ant elder
> Fix For: Java-Mx
>
>
> The HttpSessionScopeContainer should use the HttpSession for session 
> persistance instead of the HashMap it currently uses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (TUSCANY-521) Hide special Sequence-type properties from SDO Types

[Frank Budinsky (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-521?page=comments#action_12456105 
] 

Frank Budinsky commented on TUSCANY-521:


Thanks Kapil. I'll apply both patches and see how it works, but I probably 
won't get to it for a couple of days.


> Hide special Sequence-type properties from SDO Types
> 
>
> Key: TUSCANY-521
> URL: http://issues.apache.org/jira/browse/TUSCANY-521
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-M2
>Reporter: Frank Budinsky
> Fix For: Java-Mx
>
> Attachments: hideprops_rt.patch, hideprops_tools.patch
>
>
> Type,getProperties() often includes several Sequence-type properites (e.g., 
> "mixed", "group", "any", etc.). These properties are used by the underlying 
> EMF implementation to provide full XSD support, but they aren't described in 
> the SDO spec and therefore should not be exposed to clients. They should be 
> hidden from the getProperties() list and instead be accessable via new 
> SDOUtil methods, similar to the way substitution groups are handled in 
> TUSCANY-503.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Updated: (TUSCANY-713) Discover and regiester new SDO types during the time of loading the XML instance document

[Kelvin Goodson (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-713?page=all ]

Kelvin Goodson updated TUSCANY-713:
---

Attachment: SDOUtil.java
SchemaLocationTestCase.java
SchemaLocationTestCase.xml

The SDOUtil.java attachment contains a method of achieving the desired result 
in the processSchemaLocations() method, thanks to Yang for this, but the 
solution has been overtaken by events,  and we should use technical elements of 
this solution within the broader scope of the solution to TUSCANY-928 to 
achieve our aims.

The test case will obviously need to be reworked a little in the light ot 
TUSCANY-928 also.

> Discover and regiester new SDO types during the time of loading the XML 
> instance document
> -
>
> Key: TUSCANY-713
> URL: http://issues.apache.org/jira/browse/TUSCANY-713
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Implementation
>Affects Versions: Wish list
>Reporter: Fuhwei Lwo
> Fix For: Wish list
>
> Attachments: SchemaLocationTestCase.java, SchemaLocationTestCase.xml, 
> SDOUtil.java
>
>
> Current SDO implementation requires one to register the SDO types before 
> loading their instances from XML document.  The new scenario is to load the 
> XML document before registering the types.  The SDO may require the XML 
> document to provide some information to locate its schema or metadata 
> location.  Annotation may be one way to do it. The schemaLocation attribute 
> is not sufficient because it's only a hint not necessarily a physical 
> location.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: How to make sub-project build/participation easier?

[Jeremy Boynes]

On Dec 6, 2006, at 3:57 AM, kelvin goodson wrote:


I pressed send too early on my last note.

So now we have a version of the parent pom with the 2-incubator- 
SNAPSHOT

version tag and a version of buildtools with the
1.0-incubator-SNAPSHOTavailable from the m2-snapshot-repository,
meaning that you no longer need
to do a source build on these projects to get the artifacts into  
your local

repo. All of the Tuscany java projects depend on these artifacts.


Thanks Kelvin.

In general though, our cross-module dependencies should not be on  
SNAPSHOTs but on released versions. For example, I don't think  
buildtools has changed since M2 and so we could rely on the stable M2  
version. Similarly DAS and SCA would be better to rely on the M2  
version of SDO, at least until they need some of the new function.




We'll need to be aware that if we change anything in these projects  
we ought

to update the snapshot repo.  I have done a chmod 755 on the directory
hierarchies in the repository so that other committers can make the  
updates

if and when necessary.


I have a section in my ~/.m2/settings.xml file that does that  
automatically during "deploy":


  

  apache.releases
  775
  644

... repeated for each repo we deploy to ...

I'm not sure if this can be specified in the   
section.


--
Jeremy


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

Re: New proposal to make DAS/SDO HOW TO

[Willian Yabusame Maja]

Hi Adriano!
   I had alredy talked with Luciano about uploading the librarys in a link. 
He said that it's better to give the link to the downloads area from Tuscany 
Project.
   This is the link to the wiki page: 
http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_HOWTO_HelloDASApp . 
If you still have problem, I can help you. But first you need to create an 
account there.


   About the How To. I think now we need to put our comments, teach and 
give ideas about implementation.


Willian Yabusame Maja

- Original Message - 
From: "Adriano Crestani" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, December 06, 2006 3:12 AM
Subject: Re: New proposal to make DAS/SDO HOW TO



I made the first draft of the howTo. Sorry, I am still posting it here,
cause I didn't find out how to post it on the wiki (can will teach me how
Willian? please). As Luciano said the howTo doesn't need to be an entire
webapp, so I just commented what is needed to integrate the SDO/DAS with 
an

webapp. But I think that is necessary to comment where the libraries could
be easily downloaded, do you know Luciano?

Here is the howTo, feel free to edit or even to delete everything ; )

Willian and me wrote this HowTo to demonstrate the usage of SDO/DAS on a
WebApp using the MySql Server 5.0 as the database server. This HowTo will
cover how to store, get and delete any data from a database using a
ShoppingCart sample code running. A. Downloading the Libraries:

*The required libraries are:*

  1. common-{latest version}.jar
  2. ecore-{latest version}.jar
  3. ecore-change-{latest version}.jariv) ecore-xmi-{lateste
  version}.jarv) log4j-{latest version}.jar
  4. sdo-api-xxx.jar
  5. tuscany-das-rdb-xxx.jar
  6. tuscany-sdo-xxx.jarix) xsd-{latest version}.jar
  7. mysql-connector-java-{latest version}.jar -> *This is the JDBC
  connector, It'll be used to connect to Mysql database.*

B. Creating ShoppingCart Database

After the setting up your enviroment, the next step will be to create the
database where the DAS will connect and manage the transaction with the 
SDO

features.

*1- Run the following commands in the Mysql Command Shell*

create database shoppingcart; -> *This command will create the 
ShoppingCart

database*.use shoppingcart; -> *Set the shell to work with shoppingcart
database*.



*2- Create a text file and name it as "shoppingcart.sql", you should 
insert

the following lines in this file:*


CREATE TABLE CART (
 ID INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
 SUB_TOTAL DOUBLE,
 TAX DOUBLE,
 TOTAL DOUBLE,
 CONFIRMED INTEGER
);

CREATE TABLE ITEM (
 ID INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
 DESCR CHAR(30),
 UNITS INTEGER
);

CREATE TABLE CART_ITEM (
 ID INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
 CART_ID INTEGER,
 ITEM_ID INTEGER,
 QUANTITY INTEGER,
 FOREIGN KEY (CART_ID) REFERENCES CART(ID),
 FOREIGN KEY (ITEM_ID) REFERENCES ITEM(ID)
);

*3- Run the following command in the Mysql Shell *

source {path}/shoppingcart.sql -> *Executes the script to create tables,
constraints, etc.*


C. Creating XML configuration file

*1- Create the file
ShoppingCartConfig.xml
in the same directory that you will create the ShoppingCart.class, edit it
and write the following code: *


http:///org.apache.tuscany.das.rdb/config.xsd";>








AND ITEM_ID = ?" kind="Select"/>


?" kind="Select"/>















*2- Save the file. *

C. Creating the Servlet ClassThis ShoppingCart class is just a
collection of methods that create and get carts or items, add or remove
items from a cart and cofirm an order. Then you can call these methods
directly from your .jsp. This class try to connect to database using the
user "root" and the password "tuscany", but you may modify it in the 
method

getConnection().

import java.io.IOException;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Vector;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.tuscany.das.rdb.Command;
import org.apache.tuscany.das.rdb.DAS;

import commonj.sdo.DataObject;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

public class ShoppingCart extends HttpServlet {

   private static final long serialVersionUID = 1922159305255311505L;

   public ShoppingCart () {}

   @Override
   protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1)
throws ServletException, IOException {

   }

   public DataObject getItem(int itemId) {
   DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream("ShoppingCartConfig.xml"),
getConnection());

   Command command = das.getCommand("get item");
   command.setParameter(1, itemId);
   DataObject item = command.executeQuery();

   return item.getDataObject("ITEM[1]");

   }

   public void newCart(

[jira] Updated: (TUSCANY-521) Hide special Sequence-type properties from SDO Types

[Kapil Katyal (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-521?page=all ]

Kapil Katyal updated TUSCANY-521:
-

Attachment: hideprops_tools.patch

Hi Frank / Yang,

I manually merged the code gen changes for the hidden properties fix with the 
latest Tuscany revision and generated a new patch.  I wasn't able to test it 
because I was getting errors when applying the runtime patch on the latest 
Tuscany.  Can you or Yang give it a try and let me know if there are any issues?

Thanks,
Kapil

> Hide special Sequence-type properties from SDO Types
> 
>
> Key: TUSCANY-521
> URL: http://issues.apache.org/jira/browse/TUSCANY-521
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SDO Implementation
>Affects Versions: Java-M2
>Reporter: Frank Budinsky
> Fix For: Java-Mx
>
> Attachments: hideprops_rt.patch, hideprops_tools.patch
>
>
> Type,getProperties() often includes several Sequence-type properites (e.g., 
> "mixed", "group", "any", etc.). These properties are used by the underlying 
> EMF implementation to provide full XSD support, but they aren't described in 
> the SDO spec and therefore should not be exposed to clients. They should be 
> hidden from the getProperties() list and instead be accessable via new 
> SDOUtil methods, similar to the way substitution groups are handled in 
> TUSCANY-503.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[c++] Help Reqruied - PHP SCA extension for C++ SCA

[Simon Laws]

As one of the maintainers of the SCA_SDO PECL project I've naturally started
thinking about how we build a PHP extension for the C++ SCA runtime based on
the PHP SCA implementation we have recently released (
http://pecl.php.net/package/sca_sdo). I'm cross posting this as it involves
both Tuscany and the SCA_SDO pecl project.

You may have noticed that the C++ SCA codebase already has a PHP extension
of sorts. I have just brought this back to life using a new VCExpress
makefile and using PHP 5.2.0 GA. The patch for these changes is in
http://issues.apache.org/jira/browse/TUSCANY-974.

The current extension is very limited and it would be interesting to see if
we can make the PHP SCA implementation run inside the C++ container. This
means quite a few changes to what's there already in the C++ SCA PHP
extension.  To date I have read though  a lot of the PHP and C++ SCA source
code to try and learn what's going on. I made some very high level notes on
what I thought was important as I went through (
http://www.osoa.org/display/PHP/PHP+SCA+Extension+For+Tuscany+C+++SCA). What
I have written may not be 100% true so I'm keen to find out from the experts
where the holes are. You will see I have started to make a list of the
things to be done. This is high level at the moment


  1. Embedding PHP - improve the PHP Embedding SAPI use in the PHP
  extension
 1. There is currently a memory deallocation SEGV. I have
 commented out the clean up to avoid it at present
 2. Only primitive types are handled
 3. Needs to align with PHP SCA infrastructure - need an new
 wrapper of some form in PHP
 4. Need to decide if we are going to support PHP
 SCA/Scripts/Functions/Class members as options
  2. Meta Data Exchange
 1. Mechanism/protocol for extracting data from the PHP SCA
 annotation based model.
 2. Need an extension to the C++ SCA model implementation to
 allow for it to be dynamically extended with information from PHP SCA
 3. At some point we may want to pass meta data from the C++
 model to the PHP model
 4. We also need to tidy the PHP SCA model to make it more
 efficient and easier to use
  3. Reference implementation
 1. Implement a new proxy to take calls from PHP, through PHP
 extension code and into the right place in C++ SCA
 2. Need a mechanism to find the right proxy in C++ SCA to call.
 Look at how Python/Ruby extensions do this
  4. Bindings and Data bindings - not explicitly on the previous
  diagrams but...
 1. Known to require improvement in PHP SCA. We need simple
 pluggable approach so that we can easily add new bindings. This will, at
 some point, have an impact on how we tie C++ and PHP SCA together
 2. In C++ the data binding picture is currently in flux and so
 this will also have an impact on this work


This list will grow as we learn more so feel free to make comments. Also If
anyone fancies having a look at any of these tasks then please make a
suggestion. I'm afraid the web site link I gave above is not publically
writeable but I'll update it form any conversation that happens here. Or, if
you feel you need to go and update it directly, suggest somewhere else where
we can put the information.

It think we can approach this problem in stages. i.e. we don't necessarily
have to do everything up front, although we do need to do a few things to
get going. In my mind the initial pieces of work involve:

1.1
1.3
2.1
2.2

Shortly followed by 3.1 and  3.2.

Over the next couple of days I am going to start looking at 2.1 directly and
I'll need some help with 2.2. (which has to work together with 2.1).

Regards

Simon

[jira] Updated: (TUSCANY-974) Bring PHP extension up to date with latest core and new build files

[Simon Laws (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-974?page=all ]

Simon Laws updated TUSCANY-974:
---

Attachment: phpextension-JIRA974.txt

Bring the PHP extension up to date. Apply to cpp project.

> Bring PHP extension up to date with latest core and new build files
> ---
>
> Key: TUSCANY-974
> URL: http://issues.apache.org/jira/browse/TUSCANY-974
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ SCA
>Affects Versions: Cpp-current
> Environment: XP
>Reporter: Simon Laws
>Priority: Minor
> Attachments: phpextension-JIRA974.txt
>
>
> The PHP extension needs bringing up to date with the latest SCA core, the new 
> VCExpress makefiles and it needs a test. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-974) Bring PHP extension up to date with latest core and new build files

[Simon Laws (JIRA)]

Bring PHP extension up to date with latest core and new build files
---

 Key: TUSCANY-974
 URL: http://issues.apache.org/jira/browse/TUSCANY-974
 Project: Tuscany
  Issue Type: Improvement
  Components: C++ SCA
Affects Versions: Cpp-current
 Environment: XP
Reporter: Simon Laws
Priority: Minor


The PHP extension needs bringing up to date with the latest SCA core, the new 
VCExpress makefiles and it needs a test. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-973) HttpSessionScopeContainer should use the HttpSession for session persistance

[ant elder (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-973?page=all ]

ant elder reassigned TUSCANY-973:
-

Assignee: ant elder

> HttpSessionScopeContainer should use the HttpSession for session persistance
> 
>
> Key: TUSCANY-973
> URL: http://issues.apache.org/jira/browse/TUSCANY-973
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Affects Versions: Java-M2
>Reporter: ant elder
> Assigned To: ant elder
> Fix For: Java-Mx
>
>
> The HttpSessionScopeContainer should use the HttpSession for session 
> persistance instead of the HashMap it currently uses

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-973) HttpSessionScopeContainer should use the HttpSession for session persistance

[ant elder (JIRA)]

HttpSessionScopeContainer should use the HttpSession for session persistance


 Key: TUSCANY-973
 URL: http://issues.apache.org/jira/browse/TUSCANY-973
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core
Affects Versions: Java-M2
Reporter: ant elder
 Fix For: Java-Mx


The HttpSessionScopeContainer should use the HttpSession for session 
persistance instead of the HashMap it currently uses


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: How to make sub-project build/participation easier?

[kelvin goodson]

I pressed send too early on my last note.

So now we have a version of the parent pom with the 2-incubator-SNAPSHOT
version tag and a version of buildtools with the
1.0-incubator-SNAPSHOTavailable from the m2-snapshot-repository,
meaning that you no longer need
to do a source build on these projects to get the artifacts into your local
repo. All of the Tuscany java projects depend on these artifacts.

We'll need to be aware that if we change anything in these projects we ought
to update the snapshot repo.  I have done a chmod 755 on the directory
hierarchies in the repository so that other committers can make the updates
if and when necessary.

Regards, Kelvin.

On 05/12/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Dec 5, 2006, at 1:38 AM, kelvin goodson wrote:

> I had a little dig around and I'm tring to work out if the purpose
> of the
> people.apache.org m2-snapshot-repository is right for solving this
> issue.
> If we can post an incubator-SNAPSHOT version of buildtools and
> parent pom
> there, then I think that would solve this issue.

+1

I think we should start publishing occasional snapshots of trunk
projects to the snapshot repo so that most modules can be built
separately.

--
Jeremy

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

Re: Are we ready to release M2?

[Simon Nash]

I have now run all the samples successfully, using only the jars that
are deployed to maven when using the -Prelease flag.

The only other issue I had with the previous release candidate was the
packaging and formal release voting for the spec APIs that we need from
org.osoa and commonj.  These need to be available as binaries, source,
and javadoc.

  Simon

Simon Nash wrote:


On further investigation, this is caused by a mismatch betweeen the
sample instructions in readme.html and the artifacts built by the sample.

The instructions give the following command to run:
  java -jar target/distribution/bin/launcher.jar 
target/sample-helloworldwsclient-async-1.0-incubator-M2.jar


However, the name of the jar file as currently built is
  target/sample-helloworldwsclient-async-1.0-incubator-M2-SNAPSHOT.jar

Looking into this a bit more, I noticed that some samples (like this one)
build executable jars with the suffix
  1.0-incubator-M2-SNAPSHOT
whereas others (like greeterwsclient-oneway) build jars with the suffix
  1.0-incubator-M2
and others (like calculator) have no suffix at all.

This is not a showstopper for releasing M2, but we should agree on and use
a consistent naming convention for these artifacts.

  Simon

Simon Nash wrote:


I checked out the M2 branch, cleaned out my local Maven .m2 repo,
built the runtime using -Prelease, built the samples, and ran all
the samples.  The main purpose of doing this was to ensure that
the -Prelease flag had not removed any artifacts that were needed
to successfully build and run the samples.

All was going well until I got the following error from the
helloworldwsclient-async sample:

Exception in thread "main" java.lang.NullPointerException
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:102) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39) 

at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159) 

at 
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76) 

at 
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) 

at 
org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87) 

at 
org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:83) 



Can anyone else confirm this problem?  I will continue looking at
my setup to see if I can find out more about what is going on.

  Simon





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







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

Re: How to make sub-project build/participation easier?

[kelvin goodson]

I have done this for parent pom and buildtools.
Regards, Kelvin.

On 05/12/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Dec 5, 2006, at 1:38 AM, kelvin goodson wrote:

> I had a little dig around and I'm tring to work out if the purpose
> of the
> people.apache.org m2-snapshot-repository is right for solving this
> issue.
> If we can post an incubator-SNAPSHOT version of buildtools and
> parent pom
> there, then I think that would solve this issue.

+1

I think we should start publishing occasional snapshots of trunk
projects to the snapshot repo so that most modules can be built
separately.

--
Jeremy

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

Re: Are we ready to release M2?

[Simon Nash]

On further investigation, this is caused by a mismatch betweeen the
sample instructions in readme.html and the artifacts built by the sample.

The instructions give the following command to run:
  java -jar target/distribution/bin/launcher.jar 
target/sample-helloworldwsclient-async-1.0-incubator-M2.jar

However, the name of the jar file as currently built is
  target/sample-helloworldwsclient-async-1.0-incubator-M2-SNAPSHOT.jar

Looking into this a bit more, I noticed that some samples (like this one)
build executable jars with the suffix
  1.0-incubator-M2-SNAPSHOT
whereas others (like greeterwsclient-oneway) build jars with the suffix
  1.0-incubator-M2
and others (like calculator) have no suffix at all.

This is not a showstopper for releasing M2, but we should agree on and use
a consistent naming convention for these artifacts.

  Simon

Simon Nash wrote:


I checked out the M2 branch, cleaned out my local Maven .m2 repo,
built the runtime using -Prelease, built the samples, and ran all
the samples.  The main purpose of doing this was to ensure that
the -Prelease flag had not removed any artifacts that were needed
to successfully build and run the samples.

All was going well until I got the following error from the
helloworldwsclient-async sample:

Exception in thread "main" java.lang.NullPointerException
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:102) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57) 

at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39) 

at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159) 

at 
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at 
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) 

at 
org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87) 

at 
org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:83) 



Can anyone else confirm this problem?  I will continue looking at
my setup to see if I can find out more about what is going on.

  Simon





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

Re: Are we ready to release M2?

[Simon Nash]

I checked out the M2 branch, cleaned out my local Maven .m2 repo,
built the runtime using -Prelease, built the samples, and ran all
the samples.  The main purpose of doing this was to ensure that
the -Prelease flag had not removed any artifacts that were needed
to successfully build and run the samples.

All was going well until I got the following error from the
helloworldwsclient-async sample:

Exception in thread "main" java.lang.NullPointerException
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:102)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at 
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at 
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at 
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136)
at 
org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87)
at 
org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:83)

Can anyone else confirm this problem?  I will continue looking at
my setup to see if I can find out more about what is going on.

  Simon

Jeremy Boynes wrote:

I think resolves the last issue - does anyone have anything else to  
bring up? If not, I will start to package another release candidate.

--
Jeremy

On Dec 5, 2006, at 8:50 AM, ant elder wrote:

Yes!  Jeremy, as release manager what do you say, would you make us  
another

release candidate to review and vote on?

  ...ant

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



Hi,

Considering the axiom SNAPSHOT dependency puzzle has been figured  out,
should we go ahead to push M2 release out?

Thanks,
Raymond

- Original Message -
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: 
Sent: Monday, December 04, 2006 12:10 PM
Subject: Re: Much ado about nothing (Re: WSCOMMONS-131 and options  for
Tuscany SCA Java M2 release)


> Hi,
>
> I did some further investigations with Ant and here are some
observations:
>
> 1) maven2 build will pull in axis2 artifacts from maven1 or  maven2 
repo
> randomly. I even see a mixture that the pom is downloaded from a  
m1 repo

> while the jar from a m2 repo.
>
> 2) axis2-kernel 1.1 pom from maven2 repo is invalid. It has a  
dependency

> on "org.apache.ws.commons.neethi:neethi"
> 
>org.apache.ws.commons.neethi
>neethi
> 
>
> But the axis2-parent pom has "org.apache.neethi:neethi" instead.
>
> 
>org.apache.neethi
>neethi
>2.0
> 
>
> As a result, the pom fails to pass the validation and it's  treated 
as an

> invalid pom. Transative dependency is not activated at all for
> axis2-kernel 1.1.
>
> To conclude, no matter axis2 1.1 is downloaded from m1 or m2  repo, 
the

pom
> is invalid and transative dependency is not activated at all for
> axis2-kernel. The bug becomes good news to us: the SNAPSHOT  
version of

> axiom-api will NOT be used by Tuscany runtime.
>
> Do we feel safe to release our M2 now without waiting for further
releases
> from axis2?
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, December 04, 2006 12:31 AM
> Subject: Re: Much ado about nothing (Re: WSCOMMONS-131 and  options 
for

> Tuscany SCA Java M2 release)
>
>
>> I'm starting to wonder if the subject line is even more apt  than we
>> realize
>> and we're just assuming this is a significant problem without
>> investigating.
>>
>>
>> AFAICT the only thing thats happening is what I originally  
reported -

you
>> see log messages about the AXIOM API SNAPSHOT when using the WS
>> samples...but it doesn't look like that SNAPSHOT jar is actually
getting
>> used by anything.
>>
>> - If you delete if from your repository the samples run fine.  You 
can

run
>> the samples in offline mode and not have that SNAPSHOT jar in your
>> repository and the samples still run fine.
>>
>> - If you build the sample webapps with  loadExtensionDependencies 
set to

>> true
>> then the SNAPSHOT jar is *not* included in the WAR repository  and 
the

>> samples still run fine even in offline mode.
>>
>> - If you make incompatible changes to classes in the SNAPSHOT  jar in
your
>> local repository, eg change the OMElement interface to have no  
methods,

>> the
>> samples still run fine.
>>
>> Additionally debugging in the MavenHelper class you can see the
SNAPSHOT
>> messages are coming from the  artifactResolver.resolveTransitively 
ca

Re: Pass-by-value support for remotable interfaces

[Jim Marino]

On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:


Hi,

Is there any way I can control the order in which the  
WirePostProcessors are
loaded.  For example I would always want the PassByValue processor  
to be
called last so that I ensure that the PassByValue interceptor is at  
the head

of the invocation chain.

The best way to handle this is by implementing a phase mechanism. I  
can look into adding this. BTW, why is this a WirePostProcessor vs. a  
TargetPolicyBuilder (which has phases)?


Jim


Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


HI Jim,

Yes, the pass-by-value interceptor will come first exactly for the  
reasons

you have mentioned.  I will get a testcase across soon.

Thanks

- Venkat

On 12/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I think I managed to figure this out now.  After your  
explanation I

> > could
> > follow the Connector a little better.  Its just that the outbound
> > (of the
> > source component) and inbound chains (of the target component)  
are

> > fused
> > thro the bridge interceptor.
> >
> > Given this if I added an interceptor to the begining of the
> > target's inbound
> > chain then I must have to reset the source's tail interceptor to
> > point this
> > this added interceptor as its next.  (Infact I found this code
> > marked as
> > "HACK" further down the DataBindingWirePostProcessor).  This  
is what I

>
> > intend to do.
> We probably should do something to make this less error-prone in  
the

> fabric...I'll take a look.
> >
> > On the other hand if I were to add an intercetpr to the end of  
the

> > target's
> > inbound chain then I end with an exception because the tail is
> > already an
> > InvokerInterceptor and nothing can be added beyond that.
> The pass-by-reference interceptor needs to come first since
> interceptors could modify a the payload of a message. This can
> violate pass-by-value semantics if a copy is not made beforehand.
>
> > So in this case I
> > have to probably iterate thro all interceptors and then insert  
just

> > before
> > the InvokerInterceptor.
> >
> > So.. I am moving forward for now.  Thanks for the help.
> >
> Can you post a testcase so I can see how best to make this less  
error-

> prone as mentioned above? Thanks.
>
> Jim
>
> > - Venkat
> >
> >
> >
> >
> >
> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
> >>
> >> > Hi Jim,
> >> >
> >> > Thanks for helping :).  Well, let me ask away very simply
> >> >
> >> > What I am doing here is just about trying to insert an
> >> interceptor for
> >> > enforcing pass-by-value semantics in the case of compoments
> >> > implementing a
> >> > Remotable interface - i.e. an interceptor to take care of  
making

> >> > copies of
> >> > arguments and return values.
> >> >
> >> > Since I understand that the best place to perform such a  
copying

> >> > would be
> >> > just before the serving (or provider) component actually  
gets to

> >> > service the
> >> > request, I had thought of inserting this interceptor into the
> >> > InboundInvocation chain of the server component.
> >> >
> >> > For example if component A that has a reference to Component B
> >> whose
> >> > interface is remotable.  Then I am trying to insert this
> >> > interceptor into
> >> > Component B's Inbound wire's invocation chain.  This I do  
in the

> >> > DataBindingWirePostProcessor.process(OutboundWire source,
> >> InboundWire
> >> > target) wherein 'target' is the wire where I am doing the
> >> insertion.
> >> Pass-by-val should probably be enforced in another wire  
processor
> >> since it is a separate concern (this isn't related to the  
problem

> >> though)
> >> > (Component A being the source and Component B being the  
target).

> >> > When I
> >> > tested this, the interceptor seemed to not get invoked.
> >> >
> >> > However, when I added this interceptor to the source  
component's

> >> > outbound
> >> > chain i.e. in DataBindingWirePostProcessor.process 
(OutboundWire

> >> > source,
> >> > InboundWire target) to the invocation chain of the 'source',
> >> then the
> >> > interceptor got invoked.
> >> >
> >> > So right now, I am wondering how to get the interceptor  
invoked

> >> > from the
> >> > Inbound invocation chain of Component B.
> >> >
> >> It sounds like something is not being setup properly
> >>
> >> > If I am still not clear please let me know and probably  
testcase is

>
> >> > the only
> >> > way out.
> >> >
> >> This would be the easiest way (you can probably copy the  
testcase I
> >> pointed to, so it's not that much work). Such a testcase will  
allow

> >> you to set a breakpoint and see if the target chains have been
> >> sequenced properly. It sounds like  upon insertion your  
interceptor

> >> is not being pointed to by the previous one in the chain. It is
> >> possible that there is a p

Re: Pass-by-value support for remotable interfaces

[Venkata Krishnan]

HI... I figure this out as something that can be done by setting the 'init'
attribute.  But then what is a safe value to ensure that this is the last
processor called.  Right now, ( to be very safe) I have put it as '10'.  Now
this processor gets invoked lastly.

Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

Is there any way I can control the order in which the WirePostProcessors
are loaded.  For example I would always want the PassByValue processor to be
called last so that I ensure that the PassByValue interceptor is at the head
of the invocation chain.

Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> HI Jim,
>
> Yes, the pass-by-value interceptor will come first exactly for the
> reasons you have mentioned.  I will get a testcase across soon.
>
> Thanks
>
> - Venkat
>
> On 12/6/06, Jim Marino < [EMAIL PROTECTED]> wrote:
> >
> >
> > On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
> >
> > > Hi,
> > >
> > > I think I managed to figure this out now.  After your explanation I
> > > could
> > > follow the Connector a little better.  Its just that the outbound
> > > (of the
> > > source component) and inbound chains (of the target component) are
> > > fused
> > > thro the bridge interceptor.
> > >
> > > Given this if I added an interceptor to the begining of the
> > > target's inbound
> > > chain then I must have to reset the source's tail interceptor to
> > > point this
> > > this added interceptor as its next.  (Infact I found this code
> > > marked as
> > > "HACK" further down the DataBindingWirePostProcessor).  This is what
> > I
> > > intend to do.
> > We probably should do something to make this less error-prone in the
> > fabric...I'll take a look.
> > >
> > > On the other hand if I were to add an intercetpr to the end of the
> > > target's
> > > inbound chain then I end with an exception because the tail is
> > > already an
> > > InvokerInterceptor and nothing can be added beyond that.
> > The pass-by-reference interceptor needs to come first since
> > interceptors could modify a the payload of a message. This can
> > violate pass-by-value semantics if a copy is not made beforehand.
> >
> > > So in this case I
> > > have to probably iterate thro all interceptors and then insert just
> > > before
> > > the InvokerInterceptor.
> > >
> > > So.. I am moving forward for now.  Thanks for the help.
> > >
> > Can you post a testcase so I can see how best to make this less error-
> > prone as mentioned above? Thanks.
> >
> > Jim
> >
> > > - Venkat
> > >
> > >
> > >
> > >
> > >
> > > On 12/5/06, Jim Marino < [EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
> > >>
> > >> > Hi Jim,
> > >> >
> > >> > Thanks for helping :).  Well, let me ask away very simply
> > >> >
> > >> > What I am doing here is just about trying to insert an
> > >> interceptor for
> > >> > enforcing pass-by-value semantics in the case of compoments
> > >> > implementing a
> > >> > Remotable interface - i.e. an interceptor to take care of making
> > >> > copies of
> > >> > arguments and return values.
> > >> >
> > >> > Since I understand that the best place to perform such a copying
> > >> > would be
> > >> > just before the serving (or provider) component actually gets to
> > >> > service the
> > >> > request, I had thought of inserting this interceptor into the
> > >> > InboundInvocation chain of the server component.
> > >> >
> > >> > For example if component A that has a reference to Component B
> > >> whose
> > >> > interface is remotable.  Then I am trying to insert this
> > >> > interceptor into
> > >> > Component B's Inbound wire's invocation chain.  This I do in the
> > >> > DataBindingWirePostProcessor.process(OutboundWire source,
> > >> InboundWire
> > >> > target) wherein 'target' is the wire where I am doing the
> > >> insertion.
> > >> Pass-by-val should probably be enforced in another wire processor
> > >> since it is a separate concern (this isn't related to the problem
> > >> though)
> > >> > (Component A being the source and Component B being the target).
> > >> > When I
> > >> > tested this, the interceptor seemed to not get invoked.
> > >> >
> > >> > However, when I added this interceptor to the source component's
> > >> > outbound
> > >> > chain i.e. in DataBindingWirePostProcessor.process(OutboundWire
> > >> > source,
> > >> > InboundWire target) to the invocation chain of the 'source',
> > >> then the
> > >> > interceptor got invoked.
> > >> >
> > >> > So right now, I am wondering how to get the interceptor invoked
> > >> > from the
> > >> > Inbound invocation chain of Component B.
> > >> >
> > >> It sounds like something is not being setup properly
> > >>
> > >> > If I am still not clear please let me know and probably testcase
> > is
> > >> > the only
> > >> > way out.
> > >> >
> > >> This would be the easiest way (you can probably copy the testcase I
> > >> pointed to, so it's not that much work

Re: Pass-by-value support for remotable interfaces

[Venkata Krishnan]

Hi,

Is there any way I can control the order in which the WirePostProcessors are
loaded.  For example I would always want the PassByValue processor to be
called last so that I ensure that the PassByValue interceptor is at the head
of the invocation chain.

Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


HI Jim,

Yes, the pass-by-value interceptor will come first exactly for the reasons
you have mentioned.  I will get a testcase across soon.

Thanks

- Venkat

On 12/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > I think I managed to figure this out now.  After your explanation I
> > could
> > follow the Connector a little better.  Its just that the outbound
> > (of the
> > source component) and inbound chains (of the target component) are
> > fused
> > thro the bridge interceptor.
> >
> > Given this if I added an interceptor to the begining of the
> > target's inbound
> > chain then I must have to reset the source's tail interceptor to
> > point this
> > this added interceptor as its next.  (Infact I found this code
> > marked as
> > "HACK" further down the DataBindingWirePostProcessor).  This is what I
>
> > intend to do.
> We probably should do something to make this less error-prone in the
> fabric...I'll take a look.
> >
> > On the other hand if I were to add an intercetpr to the end of the
> > target's
> > inbound chain then I end with an exception because the tail is
> > already an
> > InvokerInterceptor and nothing can be added beyond that.
> The pass-by-reference interceptor needs to come first since
> interceptors could modify a the payload of a message. This can
> violate pass-by-value semantics if a copy is not made beforehand.
>
> > So in this case I
> > have to probably iterate thro all interceptors and then insert just
> > before
> > the InvokerInterceptor.
> >
> > So.. I am moving forward for now.  Thanks for the help.
> >
> Can you post a testcase so I can see how best to make this less error-
> prone as mentioned above? Thanks.
>
> Jim
>
> > - Venkat
> >
> >
> >
> >
> >
> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
> >>
> >> > Hi Jim,
> >> >
> >> > Thanks for helping :).  Well, let me ask away very simply
> >> >
> >> > What I am doing here is just about trying to insert an
> >> interceptor for
> >> > enforcing pass-by-value semantics in the case of compoments
> >> > implementing a
> >> > Remotable interface - i.e. an interceptor to take care of making
> >> > copies of
> >> > arguments and return values.
> >> >
> >> > Since I understand that the best place to perform such a copying
> >> > would be
> >> > just before the serving (or provider) component actually gets to
> >> > service the
> >> > request, I had thought of inserting this interceptor into the
> >> > InboundInvocation chain of the server component.
> >> >
> >> > For example if component A that has a reference to Component B
> >> whose
> >> > interface is remotable.  Then I am trying to insert this
> >> > interceptor into
> >> > Component B's Inbound wire's invocation chain.  This I do in the
> >> > DataBindingWirePostProcessor.process(OutboundWire source,
> >> InboundWire
> >> > target) wherein 'target' is the wire where I am doing the
> >> insertion.
> >> Pass-by-val should probably be enforced in another wire processor
> >> since it is a separate concern (this isn't related to the problem
> >> though)
> >> > (Component A being the source and Component B being the target).
> >> > When I
> >> > tested this, the interceptor seemed to not get invoked.
> >> >
> >> > However, when I added this interceptor to the source component's
> >> > outbound
> >> > chain i.e. in DataBindingWirePostProcessor.process(OutboundWire
> >> > source,
> >> > InboundWire target) to the invocation chain of the 'source',
> >> then the
> >> > interceptor got invoked.
> >> >
> >> > So right now, I am wondering how to get the interceptor invoked
> >> > from the
> >> > Inbound invocation chain of Component B.
> >> >
> >> It sounds like something is not being setup properly
> >>
> >> > If I am still not clear please let me know and probably testcase is
>
> >> > the only
> >> > way out.
> >> >
> >> This would be the easiest way (you can probably copy the testcase I
> >> pointed to, so it's not that much work). Such a testcase will allow
> >> you to set a breakpoint and see if the target chains have been
> >> sequenced properly. It sounds like  upon insertion your interceptor
> >> is not being pointed to by the previous one in the chain. It is
> >> possible that there is a problem in the wiring infrastructure that is
> >> causing this to happen.
> >>
> >> Jim
> >>
> >>
> >>
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >> >
> >> >
> >> >
> >> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Comments inline...
> >> >>
> >> >> On Dec 5, 2006, at 12:29 AM, Venkata Kris