[C++] Loading the PHP extension on Linux, was: [C++] First pass PHP extesion

[Jean-Sebastien Delfino]

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
> > 
> >
> >  When the script has classes and functions
> > 
> >
> > 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
implement

[jira] Updated: (TUSCANY-715) Update tools module to use latest XmlSchema version

[Venkatakrishnan (JIRA)]

 [ 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

[Venkata Krishnan]

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

[Jeremy Boynes (JIRA)]

[ 
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

[Jeremy Boynes]

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

[Frank Budinsky (JIRA)]

[ 
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

[cr22rc]

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

[David T. Adcox (JIRA)]

 [ 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

[Frank Budinsky (JIRA)]

 [ 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

[Kapil Katyal]

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

[Geoff Winn (JIRA)]

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::list
 >::_Const_iterator<1>::_Compat(const
std::list
 >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
309 + 0x17 bytesC++

tuscany_sdo.dll!std::list
 >::_Const_iterator<1>::operator==(const
std::list
 >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
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

[Jean-Sebastien Delfino]

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

[Geoff Winn (JIRA)]

 [ 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::list
>  >::_Const_iterator<1>::_Compat(const
> std::list
>  >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
> 309 + 0x17 bytesC++
> tuscany_sdo.dll!std::list
>  >::_Const_iterator<1>::operator==(const
> std::list
>  >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
> 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

[Geoffrey Winn]

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

[Jean-Sebastien Delfino]

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

[Jeremy Boynes]

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=rev&rev=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=auto&rev=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(eReferen

Re: Binding Context?

[Raymond Feng]

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

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

[Jean-Sebastien Delfino (JIRA)]

[ 
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::list
>  >::_Const_iterator<1>::_Compat(const
> std::list
>  >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
> 309 + 0x17 bytesC++
> tuscany_sdo.dll!std::list
>  >::_Const_iterator<1>::operator==(const
> std::list
>  >::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
> 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?

[Jeremy Boynes]

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?

[Peter Cousins]

 

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

[Luciano Resende (JIRA)]

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

[Luciano Resende (JIRA)]

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

[Jeremy Boynes]

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=rev&rev=442812
Log:
change version to 1.0-incubator-M2-SNAPSHOT



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

IRC chat log (1st hour)

[kelvin goodson]

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]  kgoodson: you here?
[11/09/2006 16:21]  hi, yes
[11/09/2006 16:21]  jboynes,  was away
[11/09/2006 16:21]  np
[11/09/2006 16:22]  what do you need to know about releasing sdo?
[11/09/2006 16:22]  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]  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]  :)
[11/09/2006 16:26]  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]  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]  yes - a real release can't have any SNAPSHOT
dependencies in it
[11/09/2006 16:27]  e.g. we have the same thing in sca with a
dependency on SNAPSHOTs of axis
[11/09/2006 16:28]  we can't finalize the release until they cut
1.1
[11/09/2006 16:28]  (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]  anyway, getting artifacts into the mvn repo is
fairly easy
[11/09/2006 16:30]  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]  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]  is that necessary at this time?
[11/09/2006 16:32]  and if so I would suggest creating a branch
rather than use the sandbox
[11/09/2006 16:34]  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]  you'll need a version # :)
[11/09/2006 16:36]  is everyone ok with 1.0-incubator-M2 ?
[11/09/2006 16:36]  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]  I don't think sdo and sca need to be in lock
step
[11/09/2006 16:37]  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]  but sca needs an sdo release before or at the
same time :)
[11/09/2006 16:37]  but before is ok
[11/09/2006 16:38]  ok, thanks, so once we've cut our distribution
we switch back to development mode,  and t

[jira] Closed: (TUSCANY-716) Improve Ruby Container to support method calls over Ruby Classes

[ant elder (JIRA)]

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

Re: [jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version

[Venkata Krishnan]

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

Re: [jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version

[Venkata Krishnan]

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

Ruby extension, was Re: Ruby for the Java runtime? (was: Re: [C++] Beginning of a Ruby extension available)

[Jean-Sebastien Delfino]

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:

   
   class="CalculatorImpl"/>

   

- 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:
 
   
   name="divideService">DivideComponent/DivideService

 

- 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:
 
   
   true
 

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

[Meeraj Kunnumpurath]

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

[Geoff Winn (JIRA)]

[ 
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:
> http://www.w3.org/2001/XMLSchema"; 
>   targetNamespace="http://ConvertedStockQuote";>
>   
> 
>   
> 
>   
> 
>   
> 
> When the ticker element's value is not nil, the output is:
> 
> http://ConvertedStockQuote"; xsi:type="getQuote" 
> xmlns:tns="http://ConvertedStockQuote"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>   IBM
> 
> but when it is nil, my user gets:
> 
> http://ConvertedStockQuote"; xsi:type="getQuote" 
> xmlns:tns="http://ConvertedStockQuote"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>   http://ConvertedStockQuote"; xsi:nil="true"/>
> 
> 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

[Geoff Winn (JIRA)]

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

[Rick]

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

[Venkata Krishnan]

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

[Jeremy Boynes]

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

[Kapil Katyal (JIRA)]

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

[Kapil Katyal (JIRA)]

 [ 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)

[ant elder]

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:




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

DivideComponent/DivideService
  

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

true
  

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)

[Jean-Sebastien Delfino]

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

[Frank Budinsky (JIRA)]

[ 
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

[Jean-Sebastien Delfino]

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] 
> 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]
> 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]
> 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::list
>::_Const_iterator<1>::_Compat(const
std::list
>::_Const_iterator<1> & _Right={first=3452816845
second={...} })  Line
309 + 0x17 bytesC++


tuscany_sdo.dll!std::list
>::_Const_iterator<1>::operator==(const
std::list
>::_Const_iterator<1> & _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::RefCountingPointer::~RefCountingPointer()
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();
   

[jira] Resolved: (TUSCANY-714) Bug in registry that maps the URI to a factory class in DataObjectUtil

[Frank Budinsky (JIRA)]

 [ 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.(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.in