Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
With the change in r442461 you say ComponentType files are now optional and
the Ruby implementation now automatically creates a default serviceType and
referenceTypes as needed. Could you say a bit about how that works so we
can try and do the same for the Java runtime?
...ant
On 9/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hi,
This time around I am stuck with passing java object instances to
ruby. I
need this to enable service reference calls from Ruby. I want to be
able
to pass to ruby an instance of a Java proxy to an external service (say
StockQuote). Then from ruby I want to make service method calls over
this
proxy.
I have tried setting the java object to a ruby global variable, after
converting the java object to a ruby object ofcourse. But this does not
work as it seems like I must instantiate the object from within the ruby
context.
Is there any other way to do this?
- Thanks
- Venkat
On 9/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Simon, Jean-Sebastien and Ant,
Thanks. I see it working now :-). The leads that each of you gave is
all that is to it.
Ant, I will put in a patch with this update soon. Thanks for taking
the
pains and trying it yourself.
- Venkat
On 9/8/06, ant elder [EMAIL PROTECTED] wrote:
After playing around with this I think what Simon and Jean-Sebastien
have
already said is correct, its the .new that does it. Right now the
createInstance method is:
public RubyScriptInstance createScriptInstance() {
return new RubyScriptInstance(rubyEngine.evalScript
(getScript()),
responseClasses);
}
Assuming you add a class attribute to the scdl and store that value
in a
className field in RubyScript then I think the following should work:
public RubyScriptInstance createScriptInstance() {
IRubyObject rubyInstance =
rubyEngine.evalScript(getScript());
if (className != null) {
rubyInstance = rubyEngine.evalScript (className +
.new);
}
return new RubyScriptInstance(rubyInstance ,
responseClasses);
}
...ant
On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hi
The current implementation of Ruby in Java works only for scripts
that
have
global methods. I am interested getting this work for methods
inside
classes.. But then I am not able to figure out a way of doing
this.
Can somebody help me with clues on the following... maybe even if
the
C++
guys are able to provide me some hints conceptually I can map
it to
the
JRuby stuff. Here is what I do...
1) I load the script into the Ruby engine and get a RubyObject
out
of it
2) call the invoke method on the Ruby object to invoke the Ruby
functions
- in this invoke method there is no way I am able to specify
the
RubyClass whos method I should invoke. All that it takes is the
method name
as a string. I tried using ruby classname.ruby methodname
for
the
method argument but failed.
So how do I specify the class?
Thanks
- Venkat
On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote:
On 9/8/06, ant elder [EMAIL PROTECTED] wrote:
Yes we should be able to do the same type of thing with
Java. Is
the PHP
SDO
API the same as the C++ API or is it simplified?
I think for most if not all the Java based scripting
languages we
can
just
expose the Java SDO API to the scripting language (at one
point
we
had a
JavaScript version of the Big Bank sample account module
that did
this),
but
there are probably ways to use the dynamic nature of the
script
languages
to
come up with a simplify SDO API.
...ant
On 9/7/06, Simon Laws [EMAIL PROTECTED] wrote:
In PHP we have an implementation of SDO that is fully
based
on
the
C++
SDO
implementation. I'm not sure if it will be instructive
in the
java
space
but
we have pretty much just wrapped the C++ SDO interfaces
and
exposed
them
as
native PHP objects. I guess you would have to do a similar
thing in
Ruby
or
any other extension for that matter. The solution will
depend
on how
you
construct extensions to your scripting language. In PHP it
just
so
happens
you have to do it in C/C++ but I would hope you can do
it in
Java
for
JVM
based environments.
S
The SDO API in PHP is fairly similar to the C++ SDO but is
simplified
and
in particular it tries to take avantage of the features of PHP
so
that it
is
comfortable to use for the PHP programmer. For example, a
typical
user of
the XML DAS might do
M2 TODO List on Wiki
Hi, I have cleaned up the wiki a bit @ http://wiki.apache.org/ws/Tuscany/TuscanyJava/. I have pushed all old information under 'M1 Related Info'. Please check if there is something that should be moved out of that. Now in the cleaned up page I have created a section called 'Development Related' and in that a link to the page http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks. The intention of creating this page is to start capturing the TODOs for M2. Can we start collating info there so that we call all sync as a team on the TODOs to make M2 happen ? This is nothing different from what was already done for M1. Thanks - Venkat
IRC chat log (1st hour)
Here's a log of the first hour of yesterday's chat. I had to leave at the end of the formal meeting time, so I'm not sure if it went on any longer. If so, and someone else has the log then please append it. Most of the chat was discussion about the process for the M2 release. [11/09/2006 15:51] [INFO] Channel view for ``#Tuscany'' opened. [11/09/2006 15:51] === *** Your host is calvino.freenode.net[ calvino.freenode.net/6667], running version hyperion-1.0.2 [11/09/2006 15:51] =-= User mode for kgoodson is now +i [11/09/2006 15:51] === idoru set your hostname to nat/ibm/x-adff53a076dfd56c [11/09/2006 15:51] --| YOU (kgoodson) have joined #Tuscany [11/09/2006 15:51] [INFO] This channel requires that you have registered and identified yourself with the network's nickname registration services (e.g. NickServ). Please see the documentation of this network's nickname registration services that should be found in the MOTD (/motd to display it). [11/09/2006 15:53] |-- bertlamb has left irc.freenode.net (Trillian ( http://www.ceruleanstudios.com;) [11/09/2006 15:54] =-= ant is now known as ant_away [11/09/2006 15:58] --| bertlamb ([EMAIL PROTECTED]/ibm/x-0319cfd37df678a2) has joined #Tuscany [11/09/2006 16:04] --| YangZHONG (n= [EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:10] --| rfeng (n= [EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:13] jboynes kgoodson: you here? [11/09/2006 16:21] kgoodson hi, yes [11/09/2006 16:21] kgoodson jboynes, was away [11/09/2006 16:21] jboynes np [11/09/2006 16:22] jboynes what do you need to know about releasing sdo? [11/09/2006 16:22] jboynes or, are you volunteering to be release manager for sdo? :-) [11/09/2006 16:23] --| monxton ([EMAIL PROTECTED]/ibm/x-3295f699fcb15aa6) has joined #Tuscany [11/09/2006 16:24] --| bhdaniel (n= [EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:24] kgoodson ok, so about 3 projects ago, when I was using sccs and make, i was on top of my build environment and knew lots about packaging etc, but ever since then I've always had a new build env that someone else handles and I just need to know how to crank the handle. So, now I've put my head above the parapet and volunteered for this, I'm not really sure what I have to do. I do have a couple of specific pointts, but other than that I was looking for dont forget to type comments [11/09/2006 16:25] jboynes :) [11/09/2006 16:26] jboynes well, there are two parts to the release: getting artifacts into a mvn repo, and bundling them up into a download [11/09/2006 16:26] kgoodson one specific point is handling our EMF dependency, which currently shifts eash week and the thing that was called EMF-2.2.1-SNAPSHOT.hjar or the like is a different thing, and we need to make sure the release references something that doesnt shift under our feet (EMF are planning a new named build in the correct timeframe, so we are in luck there) [11/09/2006 16:27] --| jsdelfino (n= [EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:27] jboynes yes - a real release can't have any SNAPSHOT dependencies in it [11/09/2006 16:27] jboynes e.g. we have the same thing in sca with a dependency on SNAPSHOTs of axis [11/09/2006 16:28] jboynes we can't finalize the release until they cut 1.1 [11/09/2006 16:28] jboynes (well, we can also do our own build but that leads to other problems) [11/09/2006 16:28] --| jervisliu ([EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:30] jboynes anyway, getting artifacts into the mvn repo is fairly easy [11/09/2006 16:30] jboynes you can use the deploy goal for that (it does all the uploading and checksumming) [11/09/2006 16:30] --| oisin ([EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:31] kgoodson my second point is how we chill the code and preserve the development stream --- e.g. do we copy development into the sandbox for a while [11/09/2006 16:32] jboynes is that necessary at this time? [11/09/2006 16:32] jboynes and if so I would suggest creating a branch rather than use the sandbox [11/09/2006 16:34] jboynes the bundling things up side should be handled by the assembly plugin in dsitribution/sdo [11/09/2006 16:34] --| dwheeler (n= [EMAIL PROTECTED]) has joined #Tuscany [11/09/2006 16:35] jboynes you'll need a version # :) [11/09/2006 16:36] jboynes is everyone ok with 1.0-incubator-M2 ? [11/09/2006 16:36] kgoodson ok, we might be able to get away without a branch, but I don't have a firm idea of for how long that might tie our hands with continued development, for instance, we would clearly be impacted by the date that out EMF dependency was satisfied, but would we be lock stepped with SCA at all, and therefore e.g. dependent upon the axis release? [11/09/2006 16:37] jboynes I don't think sdo and sca need to be in lock step [11/09/2006 16:37] kgoodson 1.0-incubator-M2 still ok with me [11/09/2006 16:37] |-- isilval has left irc.freenode.net (Trillian ( http://www.ceruleanstudios.com;) [11/09/2006 16:37] jboynes but sca needs an sdo release before
[jira] Closed: (TUSCANY-716) Improve Ruby Container to support method calls over Ruby Classes
[ http://issues.apache.org/jira/browse/TUSCANY-716?page=all ] ant elder closed TUSCANY-716. - Resolution: Fixed Patch applied. Thanks Venkat. Improve Ruby Container to support method calls over Ruby Classes Key: TUSCANY-716 URL: http://issues.apache.org/jira/browse/TUSCANY-716 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-Mx Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-Ruby-Container-Update-Sept-11.diff Enable called service methods of Ruby Classes. Currently only global methods can be called. Enable component type introspection on lines with what exists for the JavaScript Container -- 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]
Ruby extension, was Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
ant elder wrote: [snip] With the change in r442461 you say ComponentType files are now optional and the Ruby implementation now automatically creates a default serviceType and referenceTypes as needed. Could you say a bit about how that works so we can try and do the same for the Java runtime? ...ant The RubyCalculator sample under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/sample.calculator/ shows the programming model for Ruby, as implemented in the Tuscany/C++ Ruby extension: - A client can get a proxy to a service with: require(libtuscany_sca_ruby) and calculator = SCA::locateService(CalculatorComponent/CalculatorService) - You then simply call a business method on calculator, like this: x = calculator.add(1, 2) - A Ruby component is implemented by either functions in a Ruby module or a Ruby class, like this: component name=CalculatorComponent implementation.ruby script=CalculatorImpl.rb class=CalculatorImpl/ /component - Public attributes of a Ruby component implementation class can be wired to target services, like this: class CalculatorImpl attr_writer :divideService def div(arg1, arg2) print Ruby - CalculatorImpl.div\n @divideService.divide(arg1, arg2) end end and in your composite file: component name=CalculatorComponent implementation.ruby script=CalculatorImpl.rb class=CalculatorImpl/ reference name=divideServiceDivideComponent/DivideService/reference /component - Public attributes of a Ruby component implementation class can be configured as component properties, like this: class DivideImpl attr_writer :round def divide(arg1, arg2) res = arg1.to_f / arg2.to_f if @round then res = res.round end res end and in your composite file: component name=DivideComponent implementation.ruby script=DivideImpl.rb class=DivideImpl/ property name=roundtrue/property /component Lastly, you can write a componentType file for your Ruby component, but you don't have to, the Ruby extension introspects Ruby component implementation classes for you and binds public attributes to references and properties. The runtime extension uses the Ruby C API. The Ruby interpreter is written in C with a nice API so it's a pretty good fit. I'm not sure how much of the design you can transpose to JRuby, but here's a summary: - The Tuscany C++ Ruby extension embeds the Ruby interpreter. This allows the runtime to run a Ruby component from any other SCA component, the Axis2 HTTP server or the Axis2 Apache mod when running behind the HTTP server. - The extension also acts as a Ruby extension library, to allow standalone Ruby scripts to invoke SCA services. - SCA::locateService is declared to Ruby as a module function in module SCA. Again I am using the Ruby C API to declare the module and the function. - I am also using the Ruby C API to introspect each Ruby component implementation class, find public setter methods, and the Ruby attributes to SCA references and properties. - SCA references are handled by a Ruby proxy class, defined by the extension (written in C), which exposes a Ruby interface and dispatches all calls to the C++ runtime to handle the SCA invocation. - The extension currently handles the conversion of simple types between Ruby and C types. I'll probably map DataObjects to Ruby strings for now unless somebody is interested in implementing an SDO Ruby language binding. The code of the Tuscany/C++ Ruby extension is there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sample components
Jeremy, From what I see, the stuff that is duplicated are hello world service and implementation. I can move it to a separate project and have all the other sample projects that use them to depend on it. Only trouble is the RMI binding as that the methods declare to throw RemoteException. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath Sent: 11 September 2006 07:55 To: 'tuscany-dev@ws.apache.org' Subject: RE: Sample components Can I volunteer? -Original Message- From: Venkata Krishnan [mailto:[EMAIL PROTECTED] Sent: 11 September 2006 06:52 To: tuscany-dev@ws.apache.org Subject: Re: Sample components +1. This really makes a great deal of sense to me. Infact this will +get the 'solution assembly' message a lot clear. - Venkat On 9/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We have quite a few samples that have copies of the same components and the services that they implement. I think we should separate the components from the samples themselves and move them to a common sample-components project that just contains the implementations; this could then be used by the different samples that illustrate the SCA concepts. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-705) XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true
[ http://issues.apache.org/jira/browse/TUSCANY-705?page=comments#action_12434141 ] Geoff Winn commented on TUSCANY-705: There's a bit more to this. The patch supplied works on XP when built with MSVC 7.1. However, when built with MSVC 6 one of the standard tests fails producing invalid XML (the tag and part of a namespace attribute are omitted). I am looking into this. XMLHelperImpl::createDocument() gives invalid XML when the element has xsi:nil=true --- Key: TUSCANY-705 URL: http://issues.apache.org/jira/browse/TUSCANY-705 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: WinXP Reporter: Caroline Maynard Priority: Critical Attachments: bug8506.patch, bug8506.patch See http://pecl.php.net/bugs/bug.php?id=8506 for the test example. The schema is: xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=http://ConvertedStockQuote; xs:element name=getQuote xs:complexType xs:sequence xs:element name=ticker type=xs:string nillable=true/ /xs:sequence /xs:complexType /xs:element /xs:schema When the ticker element's value is not nil, the output is: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; tickerIBM/ticker /getQuote but when it is nil, my user gets: ?xml version=1.0 encoding=UTF-8? getQuote xmlns=http://ConvertedStockQuote; xsi:type=getQuote xmlns:tns=http://ConvertedStockQuote; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; getQuote xmlns=http://ConvertedStockQuote; xsi:nil=true/ /getQuote I've attached a proposed patch. I removed the namespace URI to be consistent with the non-nil case, apologies if this is incorrect. -- 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-717) Source code changes required by Apache stdcxx library
Source code changes required by Apache stdcxx library - Key: TUSCANY-717 URL: http://issues.apache.org/jira/browse/TUSCANY-717 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: XP Reporter: Geoff Winn Priority: Minor TUSCANY-683 requests the option to build SDO using the Apache stdcxx library as the standard C++ library. That will obviously require changes to the build system but in fact also requires code changes to include header files and to correct improper use of iterators. -- 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: Sample components
For what it's worth we've been down this path once before with sharing the implementation. As I recall there was negative feed back that the dependencies was only captured in maven which not all understand and that these simple beginner samples should stand on their own. It also made it more difficult to just copy, paste and edit to start a new sample to play with. Meeraj Kunnumpurath wrote: Jeremy, From what I see, the stuff that is duplicated are hello world service and implementation. I can move it to a separate project and have all the other sample projects that use them to depend on it. Only trouble is the RMI binding as that the methods declare to throw RemoteException. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath Sent: 11 September 2006 07:55 To: 'tuscany-dev@ws.apache.org' Subject: RE: Sample components Can I volunteer? -Original Message- From: Venkata Krishnan [mailto:[EMAIL PROTECTED] Sent: 11 September 2006 06:52 To: tuscany-dev@ws.apache.org Subject: Re: Sample components +1. This really makes a great deal of sense to me. Infact this will +get the 'solution assembly' message a lot clear. - Venkat On 9/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We have quite a few samples that have copies of the same components and the services that they implement. I think we should separate the components from the samples themselves and move them to a common sample-components project that just contains the implementations; this could then be used by the different samples that illustrate the SCA concepts. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - 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: Sample components
Hi Meeraj, The RMIBinding sample needs a rework which I will do soon. The binding does not require the interface to be Remote or the service methods to throw RemoteException anymore. To get a idea of what I mean please take a look at the testcase that is a part of the RMIBinding implementation. Thanks - Venkat On 9/12/06, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Jeremy, From what I see, the stuff that is duplicated are hello world service and implementation. I can move it to a separate project and have all the other sample projects that use them to depend on it. Only trouble is the RMI binding as that the methods declare to throw RemoteException. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath Sent: 11 September 2006 07:55 To: 'tuscany-dev@ws.apache.org' Subject: RE: Sample components Can I volunteer? -Original Message- From: Venkata Krishnan [mailto:[EMAIL PROTECTED] Sent: 11 September 2006 06:52 To: tuscany-dev@ws.apache.org Subject: Re: Sample components +1. This really makes a great deal of sense to me. Infact this will +get the 'solution assembly' message a lot clear. - Venkat On 9/10/06, Jeremy Boynes [EMAIL PROTECTED] wrote: We have quite a few samples that have copies of the same components and the services that they implement. I think we should separate the components from the samples themselves and move them to a common sample-components project that just contains the implementations; this could then be used by the different samples that illustrate the SCA concepts. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Release name
1.0-incubator-M2 rfeng, dkulp, lresende, bdaniel, kgoodson 0.95-incubatorvenkat, aborley I included dkulp's proposal on the format. Looks like the preference is for 1.0-incubator-M2 so I will start to update the poms to that. -- Jeremy On Sep 8, 2006, at 10:17 AM, Jeremy Boynes wrote: Before publishing artifacts to the snapshot repo I need to make sure all the versions contain incubator which means updating all the POMs. I would like to change this to the version of this next release and so would like input on what that should be: [ ] 1.0-M2-incubator [ ] 1.0-alpha-incubator [ ] 1.0-incubator [ ] 0.95-incubator [ ] 0.2-incubator [ ] something else Please respond one way or another :-) -- 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]
[jira] Created: (TUSCANY-718) make -noEMF code generation the default
make -noEMF code generation the default --- Key: TUSCANY-718 URL: http://issues.apache.org/jira/browse/TUSCANY-718 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-Mx Reporter: Kapil Katyal Priority: Minor Need to make the noEMF option on the codegen tool the default immediately after M2 -- 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-718) make -noEMF code generation the default
[ http://issues.apache.org/jira/browse/TUSCANY-718?page=all ] Kapil Katyal updated TUSCANY-718: - Attachment: patch1.txt Here is a patch to make noEMF option the default make -noEMF code generation the default --- Key: TUSCANY-718 URL: http://issues.apache.org/jira/browse/TUSCANY-718 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-Mx Reporter: Kapil Katyal Priority: Minor Attachments: patch1.txt Need to make the noEMF option on the codegen tool the default immediately after M2 -- 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: Ruby extension, was Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
So the services, references and properties are untyped right? ...ant On 9/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: [snip] With the change in r442461 you say ComponentType files are now optional and the Ruby implementation now automatically creates a default serviceType and referenceTypes as needed. Could you say a bit about how that works so we can try and do the same for the Java runtime? ...ant The RubyCalculator sample under http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/sample.calculator/ shows the programming model for Ruby, as implemented in the Tuscany/C++ Ruby extension: - A client can get a proxy to a service with: require(libtuscany_sca_ruby) and calculator = SCA::locateService(CalculatorComponent/CalculatorService) - You then simply call a business method on calculator, like this: x = calculator.add(1, 2) - A Ruby component is implemented by either functions in a Ruby module or a Ruby class, like this: component name=CalculatorComponent implementation.ruby script=CalculatorImpl.rb class=CalculatorImpl/ /component - Public attributes of a Ruby component implementation class can be wired to target services, like this: class CalculatorImpl attr_writer :divideService def div(arg1, arg2) print Ruby - CalculatorImpl.div\n @divideService.divide(arg1, arg2) end end and in your composite file: component name=CalculatorComponent implementation.ruby script=CalculatorImpl.rb class=CalculatorImpl/ reference name=divideServiceDivideComponent/DivideService/reference /component - Public attributes of a Ruby component implementation class can be configured as component properties, like this: class DivideImpl attr_writer :round def divide(arg1, arg2) res = arg1.to_f / arg2.to_f if @round then res = res.round end res end and in your composite file: component name=DivideComponent implementation.ruby script=DivideImpl.rb class=DivideImpl/ property name=roundtrue/property /component Lastly, you can write a componentType file for your Ruby component, but you don't have to, the Ruby extension introspects Ruby component implementation classes for you and binds public attributes to references and properties. The runtime extension uses the Ruby C API. The Ruby interpreter is written in C with a nice API so it's a pretty good fit. I'm not sure how much of the design you can transpose to JRuby, but here's a summary: - The Tuscany C++ Ruby extension embeds the Ruby interpreter. This allows the runtime to run a Ruby component from any other SCA component, the Axis2 HTTP server or the Axis2 Apache mod when running behind the HTTP server. - The extension also acts as a Ruby extension library, to allow standalone Ruby scripts to invoke SCA services. - SCA::locateService is declared to Ruby as a module function in module SCA. Again I am using the Ruby C API to declare the module and the function. - I am also using the Ruby C API to introspect each Ruby component implementation class, find public setter methods, and the Ruby attributes to SCA references and properties. - SCA references are handled by a Ruby proxy class, defined by the extension (written in C), which exposes a Ruby interface and dispatches all calls to the C++ runtime to handle the SCA invocation. - The extension currently handles the conversion of simple types between Ruby and C types. I'll probably map DataObjects to Ruby strings for now unless somebody is interested in implementing an SDO Ruby language binding. The code of the Tuscany/C++ Ruby extension is there: http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/ Hope this helps... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ruby extension, was Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)
ant elder wrote: [snip] So the services, references and properties are untyped right? ...ant Yes -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-711) Tuscany SDO generates invalid namespace prefixes for namespaces that end with a '-' followed by a number
[ http://issues.apache.org/jira/browse/TUSCANY-711?page=comments#action_12434198 ] Frank Budinsky commented on TUSCANY-711: Thank you Ron and Yang for doing the background work. I think the correct answer is #3. Yang, we can't rename the static getDefaultPackageName() method (as you suggested in 2-1) because it's called by other components (SCA tools). I also noticed that once we override qualifiedPackageName(), I think there's no need for the getEcoreAttribute() override in SDOXSDEcoreBuilder, because all it will be doing now is setting the package name to the same thing as qualifiedPackageName returned. So, I commeted out that method as well. I committed the fix in revision 442625. I think it would be good to add a JUnit for this. Thanks, Frank. Tuscany SDO generates invalid namespace prefixes for namespaces that end with a '-' followed by a number Key: TUSCANY-711 URL: http://issues.apache.org/jira/browse/TUSCANY-711 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M1 Environment: Win2K Sun JDK 1.4.2_11 Reporter: Ron Gavlin Priority: Critical The Tuscany SDO Serializer generates an invalid namespace prefix for namespaces that end with a '-' followed by a number. For example, Tuscany SDO generates the invalid namespace prefix 1 for namespace http://www.example.com/simple-1. Any DataObjects saved with the .../simple-1 namespace cannot be subsequently loaded. I suspect this may be an EMF bug. -- 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: Exception in SDO runtime on Windows, was: [C++] windows build system
Geoffrey Winn wrote:
Jean-Sebastian,
I've stepped through the code and I believe the problem arises because
of an incorrect check for a reference counted pointer being null.
However, I can't reproduce this particular problem so could you try
applying the patch that I've attached to this note and let me know if
it helps? I've run it against the usual SDO test suite so at least it
shouldn't do any harm.
Geoff.
On 08/09/06, *Geoffrey Winn* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
That code is called frequently in the SDo test suite so I've been
stepping through it in the debugger to try to get a feel for what
it is doing. At the moment the execution sequence I'm seeing makes
no sense. If I step over the line
unset((*i).first);
I'd expect to reach the if statement on the following line. In
fact the debugger jumps to the
PropertyValueMap::iterator i = PropertyValues.begin();
which doesn't make much sense. This is true whether I use the
Microsoft or stdcxx libraries. Since this is happening in a
destructor I'm wondering if maybe something has been deallocated
too soon. Anyway,
1. I can't immediately see anything wrong with the use of the iterator
2. I'm looking into it.
Geoff.
On 07/09/06, *Geoffrey Winn* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Jean-Sebastian,
By an odd coincidence I'm currently looking at a list iterator
bug in SDO that is exposed when I build against the stdcxx
library rather than the standard Microsoft one. Is thsi issue
urgent? If possible I'd like to re-visit your case after I've
resolved the stdcxx one (hopefully later today) By then I
might understand it all :-)
On 07/09/06, *Jean-Sebastien Delfino* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
[snip]
I just tried it and was able to import our VC7 solution
into it. I ran
into two issues:
- A minor issue, I had to remove the ODBC libraries from
the link
configuration
- A more serious issue, the SDO runtime breaks with
exceptions
complaining about incompatible list iterators in
DataObjectImpl::~DataObjectImpl()
This is probably easy to fix - although I have no idea
how to fix it :)
Geoff,
Here's the Exception and call stack I'm getting from
sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no
symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845
second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845
second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar
deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19
bytesC++
sdo_test.exe!main(int argc=1, char * *
argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19
bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont !=
_Right._Mycont)
{
_DEBUG_ERROR(list iterators
incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
[jira] Resolved: (TUSCANY-714) Bug in registry that maps the URI to a factory class in DataObjectUtil
[ http://issues.apache.org/jira/browse/TUSCANY-714?page=all ] Frank Budinsky resolved TUSCANY-714. Resolution: Fixed Fixed revision 442644. I didn't use the supplied patch, so please verify that it's still properly fixed. Thanks. Bug in registry that maps the URI to a factory class in DataObjectUtil -- Key: TUSCANY-714 URL: http://issues.apache.org/jira/browse/TUSCANY-714 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: ALL Reporter: Hasan Muhammad Attachments: sdo_patch.patch There is a registry that maps the extension of the URI to a factory class. In this case, the URI was an XSD, so it should have returned a factory to create an XSDResourceImpl, but instead it used the default factory which creates an XMLResourceImpl, hence the classcastexception error. The following is the exception: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at com.ibm.ws.soa.sca.admin.config.loader.ConfigLoaderFactory.initLoader(ConfigLoaderFactory.java:126) at com.ibm.ws.soa.sca.admin.config.loader.ConfigLoaderFactory.init(ConfigLoaderFactory.java:69) at com.ibm.ws.soa.sca.admin.config.loader.ConfigLoaderFactory.getInstance(ConfigLoaderFactory.java:56) at com.ibm.ws.soa.sca.admin.cdf.content.operation.CreateScaAssetConfig.execute(CreateScaAssetConfig.java:116) at com.ibm.wsspi.management.bla.deployment.common.Phase.execute(Unknown Source) at com.ibm.wsspi.management.bla.deployment.common.DeployOperation._doExecute(Unknown Source) at com.ibm.wsspi.management.bla.deployment.common.DeployOperation.execute(Unknown Source) at com.ibm.ws.management.bla.deployment.commands.BLACommandProvider.addAsset(Unknown Source) 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 com.ibm.websphere.management.cmdframework.provider.SimpleCommandProvider.executeReal(SimpleCommandProvider.java:147) at com.ibm.websphere.management.cmdframework.provider.SimpleCommandProvider.execute(SimpleCommandProvider.java:133) at com.ibm.websphere.management.cmdframework.provider.SimpleAdminCommand.execute(SimpleAdminCommand.java:57) at com.ibm.ws.management.bla.deployment.commands.BLACommandProvider.createBLA(Unknown Source) 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 com.ibm.websphere.management.cmdframework.provider.SimpleCommandProvider.executeReal(SimpleCommandProvider.java:147) at com.ibm.websphere.management.cmdframework.provider.SimpleCommandProvider.execute(SimpleCommandProvider.java:133) at com.ibm.websphere.management.cmdframework.provider.SimpleAdminCommand.execute(SimpleAdminCommand.java:57) at com.ibm.ws.management.cmdframework.impl.RemoteCommandMgrImpl.execute(RemoteCommandMgrImpl.java:120) 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
[C++] Loading the PHP extension on Linux, was: [C++] First pass PHP extesion
Simon Laws wrote: On 9/8/06, Simon Laws [EMAIL PROTECTED] wrote: On 9/8/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Earlier I created a patch for a first pass at a PHP extension for C++ SCA ( http://issues.apache.org/jira/browse/TUSCANY-698 ) This follows the pattern layed down by Andy with the Python extension and has many limitations:: Services only. No references. Basic input types only. No arrays or SDOs Single valued return values only. No arrays or SDOs C++ .h interface Error handling is not properly tied into SCA I used this as an exercise to understand what Pete/Andy had done. As such I have taken the most basic approach to integrating with PHP possible. This is not the way I recommend doing it in the long term. In the future I would want to change at least the following. The embed API needs to be replaced with the PHP SAPI References should be supported using annotations and injection SDO should be supported as a databinding I would prefer to go to using WSDL interface descriptions I have currently followed the pattern and gone with the following implementation descriptions: When the script just has functions implementation.phpmodule=DivideServiceImpl/ When the script has classes and functions implementation.phpmodule=DivideServiceImpl class=DivideClass/ I wanted to go with module=DivideServiceImpl but the code at present adds .componentType to the end of the module name to get the component type information. I didn;t feel that DivideServiceImpl.php.componentTypewas right but I'm prepared to be convinced. In the longer term I think it may be sensible to ditch the function only approach as it makes the reference handling less obvious. I haven't included the build file at present because we need to sort out the windows build system and me adding yet another flavour of dev studio will not help. I have though included Calculator sample files that use the extension as per Andy's sample so you can look even if you can't run. Lots more work to do but it's a start. Simon Simon, I adjusted our Linux build to integrate your PHP extension, it builds OK for me on Linux using a php-devel-5.0.4-10.5.rpm after a few changes to Makefile.am (I also made a minor change to remove the dependency on CPPInterface like we did in the other extensions). The build requires the following environment variables: PHP_INCLUDE=/usr/include/php PHP_LIB=/usr/lib/httpd/modules Which version of PHP did you use on Windows? I tried PHP 5.1.6-2 first but I'm guessing that you used an older PHP level on Windows since your code uses php_embed.h, which does not seem to exist anymore on 5.1.6.2. I'm OK to stay on that older level if it's simpler for you on Windows for now, or help build and test on a newer level. Let me know... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien Thanks for doing the linux build and for fixing up the dependency on the C++ extension. I really need to make a README describing how to build it. The detail is a little opaque as I haven't made a patch for the windows build files yet. I'm having a little difficulty in getting the right version of the Microsoft Developer Tools. Anyhow... I'm using PHP5.1.4 on Windows but 5.1.6 should be OK. On windows you will have to get the source to get the headers but php5embed.lib is provided. Strange huh. To run the calculator sample you need to do a couple of things 1/ make sure that the directory holding php5embed.lib is on the path, for example, create a version of runclient.bat with ... set PHP_HOME= where ever PHP is installed set PATH=%PHP_HOME%;%TUSCANY_SCACPP%\bin;%TUSCANY_SCACPP%\extensions\cpp\bin;%TUSCANY_SDOCPP%\bin;%AXIS2C_HOME%\lib;%PATH% Client.exe %* 2/ make sure that php.ini includes a reference to the directory which holds the .php file you are going to run as a component, for example, my php.ini is in the same directory as the php.exe and at the end of the file I have include_path=.;C:\simon\Projects\Eclipse3.2\cpp\sca\samples\Calculator\deploy\packages\CalculatorComposite you can use php -i to find where php is looking for you php.ini files. 4th or 5th line down should tell you. Apologies again for not yet providing a README that describes all this. I'll get to it shortly. Let me know if this doesn't help. Regards Simon I should add to the wording of step 1/ make sure that the directory holding php5embed.lib is on the path a little more detail, i.e. because this is the place that you will also find php5ts.dll wich is the shared library that php5embed.lib provides a front end to and which actually implements the PHP engine S Simon, I am trying to
[jira] Updated: (TUSCANY-715) Update tools module to use latest XmlSchema version
[ http://issues.apache.org/jira/browse/TUSCANY-715?page=all ] Venkatakrishnan updated TUSCANY-715: Attachment: Tuscany-SCA-Tools-Patch-Sept-12.diff Hi Jeremy, Here is a patch for this. I have successfully built the sca/tools project after the changes. Let me know if this ok. Thanks - Venkat Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical Attachments: Tuscany-SCA-Tools-Patch-Sept-12.diff The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- 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: [jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version
Hi Jeremy, I have submitted a patch for this. Please take a look and let me know if it is ok. Also, in the IRC you were mentioning about some bug in the wsdl module that hacked to fix and you wanted me to take a look. Could you please give me a little more info about this? Thanks. - Venkat On 9/12/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I did an update and noticed that the pom has been updated. So I will get started with this. - Venkat On 9/12/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Jeremy, I can help with this. Please help with answers to the following: - - which is the verison currently in use. I did see that mail from you on picking up from the M1 snapshot. So what is the change I do to the poms. - once the poms are upto date, then it is only a question of getting the sca tools module successfully built right. Is there anything else to this. Thanks - Venkat On 9/11/06, Jeremy Boynes (JIRA) tuscany-dev@ws.apache.org wrote: Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- 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-715) Update tools module to use latest XmlSchema version
[ http://issues.apache.org/jira/browse/TUSCANY-715?page=comments#action_12434221 ] Jeremy Boynes commented on TUSCANY-715: --- Patch applied - thanks Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical Attachments: Tuscany-SCA-Tools-Patch-Sept-12.diff The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- 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: [jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version
On Sep 12, 2006, at 10:18 AM, Venkata Krishnan wrote: Hi Jeremy, I have submitted a patch for this. Please take a look and let me know if it is ok. Also, in the IRC you were mentioning about some bug in the wsdl module that hacked to fix and you wanted me to take a look. Could you please give me a little more info about this? Thanks. In r441995 I had to make some changes to deal with the API changes in XmlSchemaCollection - I basically picked the first element out of the array that is being returned. I'm not very familiar with XmlSchema and am not sure that's the right way to fix it. Some review would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-707) IllegalArgumentException at o.a.t.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1782) w/dual-core CPU
[ http://issues.apache.org/jira/browse/TUSCANY-707?page=comments#action_12434224 ] Frank Budinsky commented on TUSCANY-707: It sounds like maybe the threads are running before the actual metadata has been properly initialized. It seems that the only way you could not find a property (that is defined in the type) is if the call to getProperties() in initAliasNames() isn't returning the complete list of properties. It seems to me that would only be possible if one thread is running while another is still initializing the model. How is the metadata initialized in your application? Are you using dynamic SDO or generated classes? Can you try to delay starting all the threads until after the metadata is initialized? IllegalArgumentException at o.a.t.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1782) w/dual-core CPU -- Key: TUSCANY-707 URL: http://issues.apache.org/jira/browse/TUSCANY-707 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M1 Environment: WinXP Professional w/dual-core CPU Reporter: Ron Gavlin Priority: Critical I have a load test which concurrently interrogates properties from different myDataObject instances in different threads. When the test is run on a dual-core PC, several threads throw the following IllegalArgumentException while other threads execute without problem. When I run the test on a single-processor PC, no exception is thrown. Any suggestions? Thanks in advance for your assistance. - Ron java.lang.IllegalArgumentException: Class 'MyDataObject' does not have a feature named 'myChildDataObject' at org.apache.tuscany.sdo.util.DataObjectUtil.getOpenFeature(DataObjectUtil.java:1782) at org.apache.tuscany.sdo.util.DataObjectUtil.getProperty(DataObjectUtil.java:2345) at org.apache.tuscany.sdo.impl.DataObjectImpl.getProperty(DataObjectImpl.java:1284) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2032) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2139) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:739) at org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:213) ... -- 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: [jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version
I'll take a look at it. -- not sure if XmlSclschema was directly used, but I I need tools for interop stuff anyway. Jeremy Boynes wrote: On Sep 12, 2006, at 10:18 AM, Venkata Krishnan wrote: Hi Jeremy, I have submitted a patch for this. Please take a look and let me know if it is ok. Also, in the IRC you were mentioning about some bug in the wsdl module that hacked to fix and you wanted me to take a look. Could you please give me a little more info about this? Thanks. In r441995 I had to make some changes to deal with the API changes in XmlSchemaCollection - I basically picked the first element out of the array that is being returned. I'm not very familiar with XmlSchema and am not sure that's the right way to fix it. Some review would be appreciated. -- 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]
[jira] Updated: (TUSCANY-627) Cross Scope Copy Helper
[ http://issues.apache.org/jira/browse/TUSCANY-627?page=all ] David T. Adcox updated TUSCANY-627: --- Attachment: crossScope.zip This is a collection of new files and a patch that should address this functionality. Cross Scope Copy Helper --- Key: TUSCANY-627 URL: http://issues.apache.org/jira/browse/TUSCANY-627 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Kelvin Goodson Attachments: crossScope.zip -- 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] Resolved: (TUSCANY-627) Cross Scope Copy Helper
[ http://issues.apache.org/jira/browse/TUSCANY-627?page=all ] Frank Budinsky resolved TUSCANY-627. Resolution: Fixed Committed revision 442701. Cross Scope Copy Helper --- Key: TUSCANY-627 URL: http://issues.apache.org/jira/browse/TUSCANY-627 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Kelvin Goodson Attachments: crossScope.zip -- 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]
Tomcat Integration
Hi, Does anyone know if the following document regarding Tomcat integration is currently up to date: http://wiki.apache.org/ws/Tuscany/TuscanyJava/TomcatIntegration I don't see the following jars in my current repository: tuscany-common-SNAPSHOT.jar tuscany-container-java-SNAPSHOT.jar tuscany-core-SNAPSHOT.jar tuscany-model-SNAPSHOT.jar tuscany-tomcat-SNAPSHOT.jar I checked an old repository and found the jars there, so I tried them and now I'm getting the following error: Caused by: java.lang.NoClassDefFoundError: org/osoa/sca/ModuleContext Has anyone been able to get the Tuscany environment working on Tomcat recently? Thanks, Kapil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Priority: Minor
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
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++] New scheme for passing data around in tuscany::sca::Operation
While working on our Ruby component implementation extension I ran into a few issues with how parameters and return values are passed to the tuscany::sca::Operation objects representing SCA invocations. An Operation object carries the parameters and return value of an SCA invocation. The Operation also keeps track of the C++ types of its parameters and return value. Before my changes our code was forcing the client of an invocation to decide ahead of time the type of the return value (as well as allocate storage for it). Also our Web service binding relied partly on the type information in incoming SDOs, partly on the type information from the WSDL/XSD defining the service interface, and partly on the type information associated with the Operation parameters and return value. This approach works OK in pure statically typed environments (e.g. C++ components with C++ interfaces, WSDL/XSD defining the service interfaces, and no use of xsd:Any) but starts to break when components exchange data without having pre-defined all the types (typical with scripting languages like Ruby, Python, or Javascript), when we want to allow for type conversions (int to a long, long to a double etc.) or when we start to use xsd:any in service interfaces. I also ran into a number of memory violation problems when a callee would store data allocated on the stack into a return value, and the data would become invalid once the callee returned. Finally we currently have memory leaks as the parameters and return values allocated on the heap never seem to be freed. To start fixing these issues I implemented the following simple scheme: - A service proxy gets parameters in some form from its client (the WSServiceProxy gets data out of DataObject, the RubyServiceProxy gets Ruby VALUEs). - The proxy is responsible for converting the parameters to the corresponding C++ types, then adds them to the Operation. - A service wrapper gets the parameters out of the Operation, looks at the C++ types recorded in the Operation, and converts them to the types expected by the wrapped service (for example the WSServiceWrapper populates properties of a DataObject, the RubyServiceWrapper converts the data to Ruby VALUEs). - The service wrapper then gets back a result from the wrapped service (out of a DataObject in WSServiceWrapper, a Ruby VALUE in RubyServiceWrapper), converts it to the corresponding C++ type, and stores it in the Operation's returnValue. - The client service proxy then gets the Operation's returnValue, and is responsible for converting it to the expected type on the client side (set it into a DataObject property in WSServiceProxy or convert it to a Ruby VALUE in RubyServiceProxy). Basically, the sender converts data to the corresponding/closest C++ type, the receiver looks at the type of the data and performs the necessary conversion, if any. In most cases there is no conversion at all. I also adjusted the XSLT used to generate CPP proxies to implement that scheme and call Operation::getReturnValue() in proxy methods to get the up-to-date pointer to the return value. Could you guys please take a look at what I did and let me know if you think that there is any problem with this approach. We still have the memory leak issue as I have not added the missing free() calls yet, but at least assignments and type conversions are working now and I see no memory segmentation violation or garbage data in return values anymore. Thanks... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
[ http://issues.apache.org/jira/browse/TUSCANY-719?page=all ]
Geoff Winn updated TUSCANY-719:
---
Attachment: TUSCANY-jsd.patch
I've stepped through the code and I believe the problem arises because of an
incorrect check for a reference counted pointer being null. However, I can't
reproduce this particular problem so could you try applying the patch that I've
attached to this note and let me know if it helps? I've run it against the
usual SDO test suite so at least it shouldn't do any harm.
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Priority: Minor
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
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: Exception in SDO runtime on Windows, was: [C++] windows build system
Hi. I've created JIRA 719 describing this issue and attached the patch file to it. Geoff. On 12/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi Geoff, Thanks! I'm now ready to test again on Windows with VC++ express 2005, but for some reason I can't get the attachment out of this email. Could you please attach it to a JIRA issue, or can it be committed directly if as you say it doesn't do any harm? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in SDO runtime on Windows, was: [C++] windows build system
Geoffrey Winn wrote: Hi. I've created JIRA 719 describing this issue and attached the patch file to it. Geoff. On 12/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi Geoff, Thanks! I'm now ready to test again on Windows with VC++ express 2005, but for some reason I can't get the attachment out of this email. Could you please attach it to a JIRA issue, or can it be committed directly if as you say it doesn't do any harm? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, trying it now... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Files headers, was: svn commit: r442701
Please can we make sure the ASF header is included on the source files.
--
Jeremy
On Sep 12, 2006, at 1:57 PM, [EMAIL PROTECTED] wrote:
Author: frankb
Date: Tue Sep 12 13:57:00 2006
New Revision: 442701
URL: http://svn.apache.org/viewvc?view=revrev=442701
Log:
Fix for TUSCANY-627
Added:
incubator/tuscany/java/sdo/impl/src/main/java/org/apache/
tuscany/sdo/helper/CrossScopeCopyHelperImpl.java
incubator/tuscany/java/sdo/impl/src/test/java/org/apache/
tuscany/sdo/test/CrossScopeCopyTestCase.java
incubator/tuscany/java/sdo/impl/src/test/resources/bank.xsd
Modified:
incubator/tuscany/java/sdo/impl/src/main/java/org/apache/
tuscany/sdo/util/SDOUtil.java
Added: incubator/tuscany/java/sdo/impl/src/main/java/org/apache/
tuscany/sdo/helper/CrossScopeCopyHelperImpl.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/
src/main/java/org/apache/tuscany/sdo/helper/
CrossScopeCopyHelperImpl.java?view=autorev=442701
==
--- incubator/tuscany/java/sdo/impl/src/main/java/org/apache/
tuscany/sdo/helper/CrossScopeCopyHelperImpl.java (added)
+++ incubator/tuscany/java/sdo/impl/src/main/java/org/apache/
tuscany/sdo/helper/CrossScopeCopyHelperImpl.java Tue Sep 12
13:57:00 2006
@@ -0,0 +1,236 @@
+package org.apache.tuscany.sdo.helper;
+
+import java.util.Iterator;
+import java.util.Map;
+
+import org.eclipse.emf.ecore.EAttribute;
+import org.eclipse.emf.ecore.EClass;
+import org.eclipse.emf.ecore.EObject;
+import org.eclipse.emf.ecore.EReference;
+import org.eclipse.emf.ecore.EStructuralFeature;
+import org.eclipse.emf.ecore.util.EcoreUtil;
+import org.eclipse.emf.ecore.util.FeatureMap;
+import org.eclipse.emf.ecore.util.FeatureMapUtil;
+import org.eclipse.emf.ecore.util.InternalEList;
+import org.eclipse.emf.ecore.util.EcoreUtil.Copier;
+
+import commonj.sdo.DataObject;
+import commonj.sdo.Type;
+import commonj.sdo.helper.CopyHelper;
+import commonj.sdo.helper.TypeHelper;
+
+/**
+ * A CopyHelper implementation that creates the copy objects in a
specific metadata scope.
+ * The target scope must contain a compatible version of the Types
needed to create the copy objects.
+ */
+public class CrossScopeCopyHelperImpl implements CopyHelper
+{
+ protected TypeHelper scope;
+
+ public CrossScopeCopyHelperImpl(TypeHelper targetScope)
+ {
+scope = targetScope;
+ }
+
+ public DataObject copyShallow(DataObject dataObject)
+ {
+Copier copier = new CrossScopeCopier()
+{
+ protected void copyContainment(EReference eReference,
EObject eObject, EObject copyEObject)
+ {
+ }
+ protected void copyAttribute(EAttribute eAttribute, EObject
eObject, EObject copyEObject)
+ {
+if (eObject.eIsSet(eAttribute) !
FeatureMapUtil.isFeatureMap(eAttribute))
+ {
+ super.copyAttribute(eAttribute,eObject,copyEObject);
+ }
+ }
+};
+EObject result = copier.copy((EObject)dataObject);
+copier.copyReferences();
+return (DataObject)result;
+ }
+
+ public DataObject copy(DataObject dataObject)
+ {
+Copier copier = new CrossScopeCopier();
+DataObject result = (DataObject)copier.copy((EObject)dataObject);
+copier.copyReferences();
+return (DataObject)result;
+ }
+
+ protected class CrossScopeCopier extends EcoreUtil.Copier
+ {
+protected boolean useOriginalReferences = false;
+
+protected EClass getTarget(EClass eClass)
+{
+ EClass target = (EClass)get(eClass);
+ if (target == null)
+ {
+Type type = (Type)eClass;
+target = (EClass)scope.getType(type.getURI(), type.getName
());
+ }
+ return target;
+}
+
+protected EStructuralFeature getTarget(EStructuralFeature
eStructuralFeature)
+{
+ EClass eClass = getTarget
(eStructuralFeature.getEContainingClass());
+ EStructuralFeature targetEf = eClass.getEStructuralFeature
(eStructuralFeature.getName());
+ return targetEf;
+}
+
+/**
+ * This Method WILL BE REMOVED when EMF 3.0 is available
+ */
+public void copyReferences()
+{
+ for (Iterator i = entrySet().iterator(); i.hasNext();)
+ {
+Map.Entry entry = (Map.Entry)i.next();
+EObject eObject = (EObject)entry.getKey();
+EObject copyEObject = (EObject)entry.getValue();
+EClass eClass = eObject.eClass();
+for (int j = 0, size = eClass.getFeatureCount(); j size;
++j)
+{
+ EStructuralFeature eStructuralFeature =
eClass.getEStructuralFeature(j);
+ if (eStructuralFeature.isChangeable() !
eStructuralFeature.isDerived())
+ {
+if (eStructuralFeature instanceof EReference)
+{
+ EReference eReference = (EReference)eStructuralFeature;
+ if (!eReference.isContainment() !
eReference.isContainer())
+ {
+copyReference(eReference,
Re: Binding Context?
Hi, Peter. Thank you for bringing this requirement to the table even though we don't have this feature in Tuscany yet. First of all, I think it's a valid requirement to support context propagation for service invocations, especially for remote service over a protocol such as SOAP or JMS. By my experience, we need to have the following pieces: a) The invocation message should be able to convey context (as headers) in addtion to the business data (body) accross wirings b) Binding extensions will be responsible to exchange context between the binding-specific protocol and the SCA component infrastructure. c) Context can be produced and consumed by interceptors and binding/component extensions. d) Need some API to allow applications to produce/consume context in certain scopes. Any contributions are welcome. Thanks, Raymond - Original Message - From: Peter Cousins [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Tuesday, September 12, 2006 1:25 PM Subject: Binding Context? I want to access context information specific to a binding in my server component implementation in Tuscany. Examples of binding specific context are: JMS queue name or message properties, HTTP headers, and so on. JBI/JSR208 use the NMR message header to provide access to such information. Celtix provides a thread local context object to provide such access. The usage scenario where I would need this is when my server component is a router for other services and needs to route based upon this information. Is there a threadlocal for it? Is there already a standard way of doing this across all bindings, or is it binding proprietary? I didn't see this in other bindings unless I am missing something. Any pointer to examples or source code showing how this is supported, or suggestions on adding it would be appreciated. Thanks...PC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception in SDO runtime on Windows
Jean-Sebastien Delfino wrote: Geoffrey Winn wrote: Hi. I've created JIRA 719 describing this issue and attached the patch file to it. Geoff. On 12/09/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi Geoff, Thanks! I'm now ready to test again on Windows with VC++ express 2005, but for some reason I can't get the attachment out of this email. Could you please attach it to a JIRA issue, or can it be committed directly if as you say it doesn't do any harm? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, trying it now... Hi Geoff, I tried your patch on Windows / VC++ express 2005 and got the same exception as before: incompatible list iterator. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-719) Exception in SDO runtime on Windows using VC++ Express 2005
[
http://issues.apache.org/jira/browse/TUSCANY-719?page=comments#action_12434304
]
Jean-Sebastien Delfino commented on TUSCANY-719:
Hi Geoff,
I tried your patch on Windows / VC++ express 2005 and got the same exception as
before: incompatible list iterator
Exception in SDO runtime on Windows using VC++ Express 2005
---
Key: TUSCANY-719
URL: http://issues.apache.org/jira/browse/TUSCANY-719
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Environment: Windows and VC++ Express 2005
Reporter: Geoff Winn
Priority: Minor
Attachments: TUSCANY-jsd.patch
Here's the Exception and call stack I'm getting from sdo_test on
Windows, built with VC++ Express 2005:
msvcp80d.dll!104f9961()
[Frames below may be incorrect and/or missing, no symbols loaded
for msvcp80d.dll]
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'() + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
69 + 0x4c bytesC++
sdo_test.exe!commonj::sdo::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
Line 133 + 0x15 bytesC++
sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
0x5 bytesC++
sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup() Line 403C
The exception is raised in list.cpp - line 309:
#if _HAS_ITERATOR_DEBUGGING
void _Compat(const _Myt_iter _Right) const
{// test for compatible iterator pair
if (this-_Mycont == 0 || this-_Mycont != _Right._Mycont)
{
_DEBUG_ERROR(list iterators incompatible); There
_SCL_SECURE_TRAITS_INVALID_ARGUMENT;
}
}
This is called from DataObjectImpl::~DataObjectImpl():
PropertyValueMap::iterator i = PropertyValues.begin();
while (i != PropertyValues.end())
{
unset((*i).first);
if (i == PropertyValues.begin()) -- There
{
// unset has not removed the item from the list - do it
// here instead
PropertyValues.erase(i);
}
i = PropertyValues.begin();
}
And I am a little puzzled by the code in the above loop... Although I
didn't spend much time trying to grasp the logic here, and I have not
been playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually a
sure way to shoot yourself in the foot :) so I may be wrong but I sense
a bug somewhere in this loop...
--
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: Binding Context?
On Sep 12, 2006, at 3:18 PM, Raymond Feng wrote: Hi, Peter. Thank you for bringing this requirement to the table even though we don't have this feature in Tuscany yet. First of all, I think it's a valid requirement to support context propagation for service invocations, especially for remote service over a protocol such as SOAP or JMS. By my experience, we need to have the following pieces: a) The invocation message should be able to convey context (as headers) in addtion to the business data (body) accross wirings b) Binding extensions will be responsible to exchange context between the binding-specific protocol and the SCA component infrastructure. c) Context can be produced and consumed by interceptors and binding/ component extensions. d) Need some API to allow applications to produce/consume context in certain scopes. Any contributions are welcome. What concerns me is leaking wiring information to the component implementations. That basically violates the entire goal of SCA assembly as it puts wiring and infrastructure back into application code. What Peter is describing sounds more like an infrastructure component (tied to the IT structure) rather than true business (application) function. One could say that the application here is an IT one and wants the entire JMS/SOAP/XML/RMI message - and that the application in this case is wiring-aware (e.g. an RMI mediator may not work well with a SOAP message). I think this can be done using normal SCA components whose service interfaces have parameters that are IT data objects - for example, Peter's router could be passed a SDO DataObject containing the full message (with headers) or an alternative implementation could be passed a JAXB object. It could flow that on by invoking the appropriate target reference passing the same or a mutated object. There is a separate issue about flow-through context that transfers from a inbound request to an outbound one. However, this is state managed totally by the framework and would never need to be exposed in the application programming model. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Binding Context?
Please forgive the cross post. A friend at IONA suggested I use this list instead since the project is still incubatingPC I want to access context information specific to a binding in my server component implementation in Tuscany. Examples of binding specific context are: JMS queue name or message properties, HTTP headers, and so on. JBI/JSR208 use the NMR message header to provide access to such information. Celtix provides a thread local context object to provide such access. The usage scenario where I would need this is when my server component is a router for other services and needs to route based upon this information. Is there a threadlocal for it? Is there already a standard way of doing this across all bindings, or is it binding proprietary? I didn't see this in other bindings unless I am missing something. Any pointer to examples or source code showing how this is supported, or suggestions on adding it would be appreciated. Thanks...PC
[jira] Created: (TUSCANY-720) DAS Companyweb sample missing companyConfig.xml
DAS Companyweb sample missing companyConfig.xml --- Key: TUSCANY-720 URL: http://issues.apache.org/jira/browse/TUSCANY-720 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 The companyweb sample war file is missing the companyConfig.xml -- 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-720) DAS Companyweb sample missing companyConfig.xml
[ http://issues.apache.org/jira/browse/TUSCANY-720?page=all ] Luciano Resende updated TUSCANY-720: Attachment: tuscany720.lresende.20060912.txt Updated pom file and run the samples tomcat integration to verify the fix. DAS Companyweb sample missing companyConfig.xml --- Key: TUSCANY-720 URL: http://issues.apache.org/jira/browse/TUSCANY-720 Project: Tuscany Issue Type: Bug Components: Java DAS Samples Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Fix For: Java-M2 Attachments: tuscany720.lresende.20060912.txt The companyweb sample war file is missing the companyConfig.xml -- 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]
Update version, was: svn commit: r442812 [1/2]
I have modified most of the POMs to make the version 1.0-incubator-M2- SNAPSHOT but I have not yet done the sca samples and distribution - they are commented out of the build for now. I plan to get to them later tonight or tomorrow. One thing that made this quite painful is the number that needed to be changed. I did do some clean-up on the poms to reduce the number of duplicates, trying to make use of values from the parent POMs but there is still quite a bit of duplication. I have uploaded the following modules to the snapshot repo at http:// people.apache.org/repo/m2-snapshot-repository/ * pom/parent * buildtools * spec * sdo * sca/kernel The build is based on r442855. -- Jeremy On Sep 12, 2006, at 8:25 PM, [EMAIL PROTECTED] wrote: Author: jboynes Date: Tue Sep 12 20:25:36 2006 New Revision: 442812 URL: http://svn.apache.org/viewvc?view=revrev=442812 Log: change version to 1.0-incubator-M2-SNAPSHOT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
