Re: Improving Tuscany Website/Wiki

Luciano, Thanks for reviewing the website changes. 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

The pluggability for Tuscany runtime extensions

Hi, As the core moves away from using SCA composite to compose the Tuscany system, we have been working on a simple way to extend the Tuscany system. 1) Define an ExtensionPointRegistry [1] public interface ExtensionPointRegistry { void addExtensionPoint(Class extensionPointType, T exten

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 chil

Re: svn commit: r526948 - in /incubator/tuscany/java: pom.xml sca/pom.xml

Luciano Resende wrote: Hi Sebastien Looks like you changed the parent pom to be built from java/sca/pom.xml only. The parent pom is referenced by java/sca/pom.xml and as a result still built when you build java/pom.xml. This will probably cause problem as all sub-projects like SDO, DAS,

Re: svn commit: r526948 - in /incubator/tuscany/java: pom.xml sca/pom.xml

Hi Sebastien Looks like you changed the parent pom to be built from java/sca/pom.xml only. This will probably cause problem as all sub-projects like SDO, DAS, etc also use this as it's parent pom. Would it be OK to require at least a top-level build before being able to build only at the sub-p

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

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

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 se

Tuscany Weekly IRC chat log - April 09 2007

hi Hi Raymond... hi all oh .. hi luciano.. * jsdelfino has joined #tuscany hi all Hi.. I guess its holiday in the UK and may not be able to see Ant or Simon Nash for that matter yes, simon laws is probably on vacation as well i think we can start, any specific topics people want to discu

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

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: Sent: Monday, April 09, 2007 3:29 PM Subject: Dependency on Fel

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: org.apache.felix.plugins maven-osgi-plugin 0.8.0-SNAPSHOT Any idea what this is used for? If not, then could we remove this dependency on a SNAPSHOT? Thanks -- Jean-Sebastien --

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 java

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 t

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 runtime/standalone/standalone-ho

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

[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: https://issues.apache.or

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

Hope it's ok that I piggy back with a somewhat related question. Does SDO a container for Type instances (the equivalent to an EMF EPackage)? In the EMF API I would do something like DataType dataType = EcoreFactory.eINSTANCE.createDataType(); //Initialize the dataType //Add it to an ePackage c

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 opt

Changes to the ArtifactProcessor API

I'd like to make a few minor changes to the ArtifactProcessor API: Add inputStream/outputStreams to the URLArtifactProcessor.read/write() methods. This will help centralize the code to get the inputStream from a URL instead of repeating it in all URLArtifactProcessors. Also, it will allow the

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 namespa

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 > test.sca.ws.st

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

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

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

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 catc

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 r

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

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

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 o

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, --Ke