Re: [DAS Java] created SDO graph doubt

Hello Adriano, To return a graph of related elements, the RDB DAS depends on the user providing a Query that expresses the relationship between the elements. This is most often done by providing a query that includes a join. See the relationship examples in the DAS test suite. Thanks,

Re: DAS Java Convention Over Configuration question

All convention info should probably be added to the RDB DAS User's Guide: http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_Java_User_Guide Thanks, --Kevin haleh mahbod wrote: Hi Adriano, It would be good to document any conventions that others need to know about also

Re: [DAS Java] created SDO graph doubt 2

I responded before this was moved to ... graph doubt 2. See my answer there. Adriano Crestani wrote: Another doubt: I have the following tables on my database: create table B ( ID INTEGER NOT NULL PRIMARY KEY ); create table A ( ID INTEGER NOT NULL PRIMARY KEY, B_ID INTEGER,

Basic SDO question: no built-in types?

This is maybe an SDO for dummies question. Are there any built-in SDO types, say, corresponding to int which I can work with as a generic DataObject in the manner that java.lang.Integer is a java.lang.Object corresponding to int? (I'm not seeing anything from a quick scan of the source or spec

Re: Basic SDO question: no built-in types?

Scott, Section 8 of the SDO spec describes all the standard built-in types. Types like java.lang.Integer are SDO datatypes which correspond to XSD simpleTypes. They are not SDO DataObjects. DataObjects correspond to XSD complexTypes. Frank. Scott Kurz [EMAIL PROTECTED] wrote on 04/09/2007

Re: [DAS Java] created SDO graph doubt 2

Hi Guys, The foreign key convention is supported and is demonstrated in this test:ImpliedRelationshipTests.testAddNewOrder() The convention is lightly documented here: http://wiki.apache.org/ws/ConventionOverConfiguration Thanks, --Kevin Luciano Resende wrote: Have you setup the

Re: Contribution services and SCDL4J

More answers inline. Venkata Krishnan wrote: Hi Sebastien, First, many thanks for this very explanatory reply. Please find further queries below. Thanks. - Venkat On 4/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Some answers inline. Venkata Krishnan wrote: Hi, I am catching

[jira] Commented: (TUSCANY-394) NPE when running wsdl2java tool with xsd:anyType in the schema

[ https://issues.apache.org/jira/browse/TUSCANY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487580 ] Scott Kurz commented on TUSCANY-394: To me it looks like this is no longer a problem. I'm not sure in what

Re: Basic SDO question: no built-in types?

Scott, SDO built-in types were defined in the sdoModel.xsd under tuscany/java/spec/sdo-api/src/main/resources/xml directory. The mapping from XSD to Java is described in the spec section 9.4. The instances of SDO built-in types will be instances of commonj.sdo.Type. So if you have a SDO type

[Java SDO] - Is name mangling on generated Java package necessary?

I ran XSD2JavaGenerator with namespace like test.sca.ws.static.import.schema.helloworld and the Java package was generated with test.sca.ws.static_.import_.schema.helloworld. Is this type of name mangling necessary? Thanks. - Fuhwei

Re: Transition from CompositeContext to ComponentContext

Kevin Williams wrote: I am interested in the transition from the the 0.95 locateService API to the 1.0 APIs. Has there been any work done in this area? In particular, I am interested in the look up of the context associated with a service since CurrentCompositeContext is removed from 1.0 and

Re: [Java SDO] - Is name mangling on generated Java package necessary?

static and import are Java keywords, so they can't be used as identifiers. Frank. Fuhwei Lwo [EMAIL PROTECTED] wrote on 04/09/2007 01:13:12 PM: I ran XSD2JavaGenerator with namespace like test.sca.ws.static. import.schema.helloworld and the Java package was generated with

Re: [Java SDO] - Is name mangling on generated Java package necessary?

Thanks. You were right static and import are reserved and not valid Java identifiers. Frank Budinsky [EMAIL PROTECTED] wrote: static and import are Java keywords, so they can't be used as identifiers. Frank. Fuhwei Lwo wrote on 04/09/2007 01:13:12 PM: I ran XSD2JavaGenerator with namespace

Re: Basic SDO question: no built-in types?

Thanks Fuhwei, Frank that helps me under the SDO view of the built-in types. I wonder how useful it would be to allow WSDL2Java to generate a Type, then, instead of an int or String, when the -dynamicSDO option is chosen. There would need to be some runtime databinding-sdo support for this

[jira] Created: (TUSCANY-1206) DataBinding support for transform of Fault DataTypes should account for wrappered FaultBean in JAX-WS style

DataBinding support for transform of Fault DataTypes should account for wrappered FaultBean in JAX-WS style --- Key: TUSCANY-1206 URL:

Re: Cleaning up the tree under java/sca, was: SCA source tree and build structure

I would like to understand how this cleanup impacts users of the old modules, ie, the code under java/sca, in particular: java/sca kernel/core kernel/spi runtime/itest/plugin runtime/standalone/assembly runtime/standalone/launcher runtime/standalone/standalone-host http.jetty I have been

Re: Cleaning up the tree under java/sca, was: SCA source tree and build structure

Ignacio Silva-Lepe wrote: I would like to understand how this cleanup impacts users of the old modules, ie, the code under java/sca, in particular: java/sca kernel/core kernel/spi runtime/itest/plugin runtime/standalone/assembly runtime/standalone/launcher

Duplicate parent and buildtools modules in the top-down build, was: svn commit: r526907 - /incubator/tuscany/java/sca/pom.xml

Won't this break if I just build java/sca/pom.xml without having done a full build of java/pom.xml first? I think we need to find a way to have parent and buildtools built automatically when we build from java/pom.xml and built as well when we build from java/sca/pom.xml, but not twice. I'll

Re: Duplicate parent and buildtools modules in the top-down build, was: svn commit: r526907 - /incubator/tuscany/java/sca/pom.xml

Comments inline On 4/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Won't this break if I just build java/sca/pom.xml without having done a full build of java/pom.xml first? Yes I think we need to find a way to have parent and buildtools built automatically when we build from

Dependency on Felix plugin snapshot in commonj and SDO API modules

The following poms: ./spec/commonj/pom.xml ./spec/sdo-api/pom.xml depend on this plugin: groupIdorg.apache.felix.plugins/groupId artifactIdmaven-osgi-plugin/artifactId version0.8.0-SNAPSHOT/version Any idea what this is used for? If not, then could we remove this dependency on a SNAPSHOT?

Re: Dependency on Felix plugin snapshot in commonj and SDO API modules

It was initially there to package the jars as OSGi bundles. I don't see any need at this point. So I suggest that we remove it. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, April 09, 2007 3:29 PM

Re: Dependency on Felix plugin snapshot in commonj and SDO API modules

Just in case it helps, there was a discussion[1] around why the specific version is being used. [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg11598.html On 4/9/07, Raymond Feng [EMAIL PROTECTED] wrote: It was initially there to package the jars as OSGi bundles. I don't see

Tuscany Weekly IRC chat log - April 09 2007

rfeng hi Venkat Hi Raymond... lresende hi all Venkat oh .. hi luciano.. * jsdelfino has joined #tuscany jsdelfino hi all Venkat Hi.. Venkat I guess its holiday in the UK and may not be able to see Ant Venkat or Simon Nash for that matter jsdelfino yes, simon laws is probably on vacation as well

DAS build failure

Building the whole Tuscany project from tuscany/java breaks with the following errors in the DAS module. Could somebody please fix them or temporarily take the modules that break out of the main top-down build? Thanks Tests run: 160, Failures: 0, Errors: 9, Skipped: 0, Time elapsed: 32.649

Re: DAS build failure

Hi Sebastien I can't reproduce this on my environment (Win2k + JDK 5_0_11). although I had some other issue around building DAS that I'm investigating... but I could workaround this by doing a mvn from java/das. Could you please let me know if you experience a successful build if you start

Re: [DAS Java] created SDO graph doubt 2

Hello Adriano, To return a graph of related elements, the RDB DAS depends on the user providing a Query that expresses the relationship between the elements. This is most often done by providing a query that includes a join. See the relationship examples in the DAS test suite. Thanks, --Kevin

Re: Duplicate parent and buildtools modules in the top-down build, was: svn commit: r526907 - /incubator/tuscany/java/sca/pom.xml

Luciano Resende wrote: Comments inline On 4/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Won't this break if I just build java/sca/pom.xml without having done a full build of java/pom.xml first? Yes I think we need to find a way to have parent and buildtools built automatically

Re: DAS build failure

This is what I get when I run the DAS build with a clean maven repo, I'll investigate fixing this. Missing: -- 1) org.apache.tuscany.das:tuscany-das-rdb:jar:1.0-incubator-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn

Re: [DAS Java] created SDO graph doubt 2

It would be possible to support what you are asking but then the DAS runtime would have to process and relate all the returned rows. I think this work is better suited to the Database which is optimized for to do this as part of a join. --Kevin Adriano Crestani wrote: Hello Adriano, To

Re: Improving Tuscany Website/Wiki

It's actually looking much better, some small comments below : Some outline menus have entries all with same name (e.g all DAS pages have a link to [Architecture Guide]. Looks like the Wiki is smart enough to link to a page independent of where the page is located, instead of looking only on