Re: DAS Java Convention Over Configuration question

Thanks Kelvin ; )(again) Adriano Crestani On 4/4/07, Kevin Williams [EMAIL PROTECTED] wrote: Hello Adriano, This use of convention is actually for the write side of things. A PK is needed to generate correct update commands based on the SDO Change Summary. In the absence of a defined PK,

Integrated core-spi and host-spi in the build, was svn commit: r525710 [1/2] - in /incubator/tuscany/java/sca/modules/core-spi

[EMAIL PROTECTED] wrote: Author: rfeng Date: Wed Apr 4 22:47:55 2007 New Revision: 525710 URL: http://svn.apache.org/viewvc?view=revrev=525710 Log: Port the core SPIs to use the new assembly model I integrated your new core-spi and host-spi in the build under tuscany/java/sca/modules.

Re: [DAS Java] created SDO graph doubt

Thanks kelvin ; ) Adriano Crestani On 4/4/07, Kevin Williams [EMAIL PROTECTED] wrote: The RDB DAS will only populate a graph with data returned from the used query. If you want a graph that contains data from related tables then the query provided must return that data (typically a join).

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

I have added the Contribution Service implementation to the build. On 4/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi, Yes, what Luciano is suggesting here makes sense to me as well. Thanks - Venkat On 4/4/07, Luciano

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

Just to note, in order for this build to work from a fresh empty maven local repo, you'll need to run mvn from the /java/spec/sca-api-r1.0/ directory first. -Bert On 4/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi, Yes, what

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

Bert Lamb wrote: Just to note, in order for this build to work from a fresh empty maven local repo, you'll need to run mvn from the /java/spec/sca-api-r1.0/ directory first. -Bert Good point. I had forgotten to commit my change to java/sca/pom.xml to include the spec-api in the top-down

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

Hi, For SCA, I suggest that we further move it to modules/spec-sca-api-r1.0. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, April 05, 2007 8:36 AM Subject: Re: Build update, was: SCA source tree and

problem Introspecting DataBinding for Fault types

I wonder if the DataBindingJavaInterfaceProcessor should be introspecting the FaultBean rather than the exception type itself in order to calculate the databinding. In the code we do: for (org.apache.tuscany.spi.model.DataType? d : operation.getFaultTypes()) {

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

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

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

Yes and I very faintly remember this to be the reason why we moved the specs out to where it is now. Isn't it ? - Venkat On 4/5/07, Luciano Resende [EMAIL PROTECTED] wrote: I was under the impression that the spec-sca-api-r1.0 module would be a stable one unless the spec changes. Isn't right

DataBindingInteceptor spelling?

Would any of the committers be interested in making the minor spelling change for this class? Another couple cleanup items (assuming they haven't already been made as I'm not looking at the latest. * removing duplicated classes in both the W2J/J2W projects * is getWapperHandler() a misspelling

Re: DataBindingInteceptor spelling?

Hi, I'll fix the getWapperHandler. Raymond - Original Message - From: Scott Kurz [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, April 05, 2007 10:23 AM Subject: DataBindingInteceptor spelling? Would any of the committers be interested in making the minor spelling

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

Good points. I agree it's probably better to keep it at sca/spec level. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, April 05, 2007 10:15 AM Subject: Re: Build update, was: SCA source tree and build

Re: [VOTE] Adriano Crestani for Tuscany Committer

Here is my late but enthusiastic +1. Luciano Resende wrote: I'd like to nominate Adriano Crestani to become a Tuscany committer. Adriano started by helping on Java DAS, and recently is contributing a new DAS C++ Implementation, he has also participated in discussions and is helping expand

[jira] Updated: (TUSCANY-826) Containment cycle should result in Exception

[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Murray updated TUSCANY-826: - Attachment: Updated826.zip Attaching Updated826.zip. The ZIP file includes a few deltas to the

[jira] Created: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl

Yet another AccessViolation in DataObjectImpl::~DataObjectImpl -- Key: TUSCANY-1203 URL: https://issues.apache.org/jira/browse/TUSCANY-1203 Project: Tuscany Issue Type: Bug

Moving spec/sca-api module under sca? was: Build update

Raymond Feng wrote: Good points. I agree it's probably better to keep it at sca/spec level. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, April 05, 2007 10:15 AM Subject: Re: Build update, was: SCA source

Re: Moving spec/sca-api module under sca? was: Build update

But we probably want to release 2 things, sca-spec and sca, right ? and then in subsequent releases of sca, we are only going to release sca, unless the spec changes and we need to update sca-spec jar. On 4/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond Feng wrote: Good

[jira] Updated: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl

[ https://issues.apache.org/jira/browse/TUSCANY-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1203: -- Attachment: Tuscany-1203.patch My solution is to check the property value as well as

Re: Moving spec/sca-api module under sca? was: Build update

[snip] Luciano Resende wrote: But we probably want to release 2 things, sca-spec and sca, right ? and then in subsequent releases of sca, we are only going to release sca, unless the spec changes and we need to update sca-spec jar. [snip] I could be convinced, but I'm not sure I

[jira] Updated: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()

[ https://issues.apache.org/jira/browse/TUSCANY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1202: -- Attachment: Tuscany-1202.patch I'm not convinced that it's worth the trouble of

[jira] Updated: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()

[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1147: -- Attachment: Tuscany-combined.patch I've appended a combined patch for 1147, 1202 and

[jira] Updated: (TUSCANY-1202) AccessViolation in DataObjectImpl::logDeletion()

[ https://issues.apache.org/jira/browse/TUSCANY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1202: -- Patch Info: [Patch Available] I'vve added to 1147 a combined patch for 1147, 1202

[jira] Updated: (TUSCANY-1203) Yet another AccessViolation in DataObjectImpl::~DataObjectImpl

[ https://issues.apache.org/jira/browse/TUSCANY-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1203: -- Patch Info: [Patch Available] I'vve added to 1147 a combined patch for 1147, 1202

{SDO C++] Untangling the graph without access violations

Memory leaks are a major concern for PHP users in a long-running web server. For some time we've had a problem that we cannot reliably drop a datagraph because of various access violations which may occur, depending on the order in which the data objects are released. We've bypassed the access