Re: Build errors
Jean-Sebastien Delfino wrote: ant elder wrote: I've not been able to recreate either of these problems yet. Could you give a bit more info about what you're doing - how you run the samples, what maven commands you use, and from what directory etc? ...ant Ant, Here's what I'm doing. To rebuild everything: rm -rf $HOME/.m2/repository cd tuscany/java mvn -Pall To build using the published spec and kernel snapshots: rm -rf $HOME/.m2/repository cd tuscany/java change pom files temporarily to not build the spec/sca and kernel modules (and get them downloaded from the snapshot repos) mvn -Pall Both sequences were failing before. The first sequence now builds OK for me. The second (using the 0.1-pre-spec snapshots) gets this error: [INFO] [INFO] Building Apache Tuscany Standalone SCA Runtime [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/pom.xml to /home/delfinoj/.m2/repository/org/apache/tuscany/sca/runtime/standalone/standalone/1.0-incubator-SNAPSHOT/standalone-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] Building Apache Tuscany Standalone Runtime [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Resource directory does not exist: /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/resources [INFO] Copying 2 resources to META-INF [INFO] [compiler:compile] [INFO] Compiling 3 source files to /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/java/org/apache/tuscany/runtime/standalone/StandaloneRuntimeInfoImpl.java:[55,8] cannot find symbol symbol : constructor AbstractRuntimeInfo(java.net.URI,java.io.File,java.net.URL,boolean,java.lang.String) location: class org.apache.tuscany.host.AbstractRuntimeInfo /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/java/org/apache/tuscany/runtime/standalone/StandaloneRuntimeInfoImpl.java:[71,16] getInstallDirectory() in org.apache.tuscany.runtime.standalone.StandaloneRuntimeInfoImpl cannot override getInstallDirectory() in org.apache.tuscany.host.AbstractRuntimeInfo; overridden method is final Making progress... I realized that the standalone runtime has also been published to the snapshot repos, so I should probably not try to build it from the trunk. I'd like to use the published 0.1-pre-spec snapshots without building them locally, but build the other pieces. Is there a simple way to do that? or do I need to make changes to the pom.xml to exclude the individual modules that have been published as 0.1-pre-spec snapshots? Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build errors
ant elder wrote: I've not been able to recreate either of these problems yet. Could you give a bit more info about what you're doing - how you run the samples, what maven commands you use, and from what directory etc? ...ant Ant, Here's what I'm doing. To rebuild everything: rm -rf $HOME/.m2/repository cd tuscany/java mvn -Pall To build using the published spec and kernel snapshots: rm -rf $HOME/.m2/repository cd tuscany/java change pom files temporarily to not build the spec/sca and kernel modules (and get them downloaded from the snapshot repos) mvn -Pall Both sequences were failing before. The first sequence now builds OK for me. The second (using the 0.1-pre-spec snapshots) gets this error: [INFO] [INFO] Building Apache Tuscany Standalone SCA Runtime [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/pom.xml to /home/delfinoj/.m2/repository/org/apache/tuscany/sca/runtime/standalone/standalone/1.0-incubator-SNAPSHOT/standalone-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] Building Apache Tuscany Standalone Runtime [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Resource directory does not exist: /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/resources [INFO] Copying 2 resources to META-INF [INFO] [compiler:compile] [INFO] Compiling 3 source files to /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/java/org/apache/tuscany/runtime/standalone/StandaloneRuntimeInfoImpl.java:[55,8] cannot find symbol symbol : constructor AbstractRuntimeInfo(java.net.URI,java.io.File,java.net.URL,boolean,java.lang.String) location: class org.apache.tuscany.host.AbstractRuntimeInfo /home/delfinoj/Tuscany/apache-repos/java/sca/runtime/standalone/standalone-api/src/main/java/org/apache/tuscany/runtime/standalone/StandaloneRuntimeInfoImpl.java:[71,16] getInstallDirectory() in org.apache.tuscany.runtime.standalone.StandaloneRuntimeInfoImpl cannot override getInstallDirectory() in org.apache.tuscany.host.AbstractRuntimeInfo; overridden method is final -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1076) Dynamic outbound wire for CompositeContext.locateService
Dynamic outbound wire for CompositeContext.locateService Key: TUSCANY-1076 URL: https://issues.apache.org/jira/browse/TUSCANY-1076 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-SCA-M3 Reporter: Rick Rineholt Fix For: Java-SCA-M3 CompositeContext.locateService requires an outbound wire to be created so for cases where bindings from the component/reference it locates are different from Java a databinding interceptor can be used to resolve difference in the expect data format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cleaning up services and references
FYI As part of the service and reference clean-up work, I'm going to remove BoundServiceDefinition and BoundReferenceDefintion, moving bindings (and target URI) up to ServiceDefintion and ReferenceDefinition. This allow us to remove the specializations around those sublcasses. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote: The C++ runtime allows bindings and component implementation types to share a common Tuscany namespace and updates to them do not require an update of the Kernel. We simply load the SCDL XSD files out of each runtime extension directory and they can contribute to a common namespace. As far as I know the Java runtime does not load or make any use of the SCDL XSDs at this point, so I don't understand what the issues would be with the Java runtime. The bindings and component implementation types defined by the OSOA specs are in a single OSOA namespace. I think that the bindings and component implementation types introduced by the Tuscany project should be in a single Tuscany namespace. Extensions provided by other projects can be in other namespaces obviously. How does this scheme address the versioning issues associated with XML namespaces? The spec addresses them by coordinating releases from all binding and implementation groups. Doing the same in Tuscany would take us back to a model where we need to coordinate kernel and all extension releases which is something we have decided not to do (for very good reasons). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic component/outbound wire for CompositeContext.locateService needed ?
On Jan 24, 2007, at 1:13 PM, Rick wrote:
While investigating TUSCANY-862 with some local modification for
other issues, I got as far as getting the message flowing ("hello")
to the reference however the
Axis2TargetInvoker.createOperationClient only expects an OMElement
and the message is still the Java String ("world"). Talking
briefly to Raymond he explained that the Databinding interceptor
won't get inserted cause the locateService does have a real SCA
component with an outbound wire behind it and thus won't add the
Databind inceptor. I'm kind of left wondering how we can support
this case. Should there be a dynamic (virtual) component created
for this case and out bound wire produced ?
I don't think there needs to be a component - just an outbound wire
from the proxy with the appropriate interceptor.
Jim
-
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: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Jim Marino wrote: On Jan 24, 2007, at 1:54 AM, ant elder wrote: On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote: > Jeremy Boynes wrote: >> -1 on the single namespace as it couples together all the >> extensions - we would need to create a new version of the >> namespace every time any extension changed its XML > > I prefer a single Tuscany namespace. This is what the OSOA specs > are doing as well with a single SCA namespace for everything. This > helps simplfy the programming model as application developers only > need to declare the single namespace at the top of an SCDL file > instead of having to list different namespaces for all the > bindings, implementation types, policies etc. that they use. A good goal but how is it achievable in a way that does not require us to rerelease the schema, the Java and C++ kernels, all extensions and anything else that references the schema in coordination every time any one of those makes a schema change? And how do we prevent changes in one extension impacting users who don't use that extension? BTW the OSOA specs do not assume a single namespace and AIUI they require extensions to be in different ones. There is even discussion in the spec group about associating user-specific namespaces with all SCDL definitions. Could you point to where in the specs it talks about requiring extensions to use different namespaces? The spec will not allow "non-spec SCA" extensions to pollute the SCA namespace. For example, any vendor or Tuscany extensions that do not correspond to an SCA specification are not supposed to use the SCA namespace. This should apply to Tuscany as well for extensions not part of the Tuscany project. All the extension spec drafts that I can find are using the single SCA namespace, are these drafts just out of date? I prefer as few namespaces as possible for now as well as it makes the SCDL so much simpler. How about using the single Tuscany namespace for now and any extension can change to use some other namespace in the future if required. In general I prefer avoiding namespace proliferation but Jeremy raises valid points. Do you have some ideas on how to address those? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The C++ runtime allows bindings and component implementation types to share a common Tuscany namespace and updates to them do not require an update of the Kernel. We simply load the SCDL XSD files out of each runtime extension directory and they can contribute to a common namespace. As far as I know the Java runtime does not load or make any use of the SCDL XSDs at this point, so I don't understand what the issues would be with the Java runtime. The bindings and component implementation types defined by the OSOA specs are in a single OSOA namespace. I think that the bindings and component implementation types introduced by the Tuscany project should be in a single Tuscany namespace. Extensions provided by other projects can be in other namespaces obviously. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic component/outbound wire for CompositeContext.locateService needed ?
While investigating TUSCANY-862 with some local modification for other
issues, I got as far as getting the message flowing ("hello") to the
reference however the Axis2TargetInvoker.createOperationClient only
expects an OMElement and the message is still the Java String
("world"). Talking briefly to Raymond he explained that the Databinding
interceptor won't get inserted cause the locateService does have a real
SCA component with an outbound wire behind it and thus won't add the
Databind inceptor. I'm kind of left wondering how we can support this
case. Should there be a dynamic (virtual) component created for this
case and out bound wire produced ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1034) Need to add support for business exceptions - at least in simple intra-Composite case to begin with
[
https://issues.apache.org/jira/browse/TUSCANY-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467148
]
Rick Rineholt commented on TUSCANY-1034:
I've produce a new iTest subdirectory
http://svn.apache.org/repos/asf/incubator/tuscany/java/testing/sca/itest/exceptionTests
The first test is intra-composite pojo component to pojo component. It
checks both checked and unchecked exceptions. This seems work, the source
component is capturing the exact application defined exceptions as expected.
Not 100% sure how to reproduce this in a local scenario.
The other wiring across bindings (web services) I'm not sure how to ser/des
exceptions so the are accurately produced by the same class. Would need to
look how SDO, JAXB, etc address (support) this. How would this work for C++,
PHP? They should be able to reproduce the exception too. (i.e. this shouldn't
be a Java only solution.)
> Need to add support for business exceptions - at least in simple
> intra-Composite case to begin with
> ---
>
> Key: TUSCANY-1034
> URL: https://issues.apache.org/jira/browse/TUSCANY-1034
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core
>Affects Versions: Java-SCA-M3
> Environment: M2- level code
>Reporter: Scott Kurz
> Assigned To: Rick Rineholt
> Fix For: Java-SCA-M3
>
>
> Not sure how to track this one. It's possible adding support for business
> exceptions is an effort which spans a bunch of different parts.
> To start with, as the comment acknowledges the DataBindingInteceptor (sic)
> needs to do something other than the current:
> // FIXME: How to deal with faults?
> if (resultMsg.isFault()) {
> // We need to figure out what fault type it is and then transform
> it back the source fault type
> throw new InvocationRuntimeException((Throwable) result);
> }
> If no transform was needed this code would have been fine simply doing:
> return resultMsg;
> If this would not be worked on more completely it might be worth enabling
> this simple case for the time being.
> Later, probably in another JIRA, code such as the Axis2 binding might need to
> be tweaked to handle business exceptions/faults. (For example we might
> unwrap an AxisFault). Depends on how this is
> handled.
> In the meantime I wanted to get this down as a TODO.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ki Park updated TUSCANY-1048: - Attachment: patch20070124.txt I'm attaching a patch file which contains updates included in previous ZIP file attachments from Robbie plus a few minor changes. Once you apply the patch on top of the CTS files from Tuscany, you should be at the same level as previous ZIP files including the minor changes. > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Fix For: Java-SDO-Mx > > Attachments: patch20070124.txt, tuscany-1048-paramatizedTests1.zip, > tuscanyHelper.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467138 ] Robbie Minshall commented on TUSCANY-1048: -- Adding a patch to convert from scenarios to paramatized tests. I have attempted to remove references to test cases that rely on static SDO. I have not added a patch for a new project to house the tuscany test helper implementation. In order to use this to execute I have been using junit and our own custom application harness. the initialization reads an environment variable for the test helper implementation, for example: I will attempt to create a project to execute CTS and use the tuscany test helper when I get some time ( perhaps friday ) - if anyone else would like to do it that would be good. Robbie > SDO CTS. Contribute Paramatized Test Cases, and application server test > harness > - > > Key: TUSCANY-1048 > URL: https://issues.apache.org/jira/browse/TUSCANY-1048 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Community Test Suite >Reporter: Robbie Minshall > Fix For: Java-SDO-Mx > > Attachments: tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip > > > An important attribute of sdo test cases is that the SDO APIs and scenarios > work for DataObjects that are created and populated in different ways. This > JIRA has been opened to contirbute > - modification to 'scenarios' in initial cts drop to paramatized junit tests > - Custom Junit Core and test application which facilitates the execution of > test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tuscany C++ sub-project name
On 23 Jan 2007, at 10:55, Pete Robbins wrote: I was wondering whether we should package a Tuscany C++ kernel, which is the core runtime and cpp language extension, and have a separate package for scripting extensions ?? +1 --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1000) Components do not support multiple services
[
https://issues.apache.org/jira/browse/TUSCANY-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng closed TUSCANY-1000.
-
> Components do not support multiple services
> ---
>
> Key: TUSCANY-1000
> URL: https://issues.apache.org/jira/browse/TUSCANY-1000
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core, Java SCA Integration Tests
>Affects Versions: Java-SCA-M3
>Reporter: Lou Amodeo
> Assigned To: Jim Marino
> Fix For: Java-SCA-M3
>
>
> I have a component that implements multiple service interfaces at runtime the
> locateService() receives an exception indicating that components can only
> have 1 service. The C&I spec states that a component can declare using
> @Service an array of interfaces.
> @Service(interfaces={ConversationsClient.class,ConversationsClient2.class})
> public class ConversationsClientImpl implements ConversationsClient,
> ConversationsClient2, ConversationsCallback {
> ---
> Test set: org.apache.tuscany.sca.test.ConversationsITest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec <<<
> FAILURE!
> testCallBackSetCallback(org.apache.tuscany.sca.test.ConversationsITest) Time
> elapsed: 0 sec <<< ERROR!
> org.apache.tuscany.spi.component.TargetException: Component must have exactly
> one service
> at
> org.apache.tuscany.core.implementation.java.JavaAtomicComponent.getServiceInstance(JavaAtomicComponent.java:72)
> at
> org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:268)
> at
> org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65)
> at
> org.apache.tuscany.sca.test.ConversationsITest.setUp(ConversationsITest.java:17)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> 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
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.run(TuscanyITestMojo.java:122)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.runSurefire(TuscanyITestMojo.java:88)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.execute(TuscanyITestMojo.java:77)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> 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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Lau
Re: why not query datas?
I agree with Luciano. It is likely that your query is not returning any
rows. You can verify this by running the query:
"select USER_ID,USER_NAME,PASSWORD from FM_TEST_CUSTOMER WHERE
USER_ID=2"
directly against the database using your database console tool. Is it
possible there is no row with "USER__ID = 2"?
--
Kevin
Luciano Resende wrote:
You might be getting the IndexOutOfBounds when the query returned 0
elements
and you are trying to access an element from SDO like in your example :
("FM_TEST_CUSTOMER[1]"); I'll take a look in details on your example
in the
morning.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move Tuscany wiki to Apache CWIKI?
Hi, FYI, I have added "edit" permissions to all registered users. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 24, 2007 4:59 AM Subject: Re: Move Tuscany wiki to Apache CWIKI? On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote: 2) I'm not proposing to change the "edit" policy. The http://cwiki.apache.org/CWIKI/ page also provides some guidances for cases that we use it as a sandbox (open to all registered users) or documentation site (open to folks with CLA on file). I also think all our content should be open to any registered user. We want everyone to help maintain it and thats going be more likely to happen if we make it easy for them. Its harder for users to send in patches for the wiki :) Can we get update emails sent to the dev list so we all can monitor the changes? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversion of samples
On Jan 24, 2007, at 4:31 AM, ant elder wrote: On 1/24/07, Jim Marino <[EMAIL PROTECTED]> wrote: I've converted most of the binding and container extensions to reference the 0.1-pre-spec-SNAPSHOT kernel. Also, I started to convert the samples under java/samples/sca/ specifically: - calculator - echo.binding - inner.composite - loanappconversation - simplecallback - spring - spring.simple - supplychain I *did not* convert any of the web app, binding or container extension samples (with the exception of Spring). As part of the reorganized build tree outlined by Jeremy, these samples will be grouped with their respective extensions. It would be helpful if people working in those extension areas can take this move on as well as change the samples to refer to the kernel 0.1-pre-spec-SNAPSHOT. This will allow the extensions to be developed and released individually. So if I was to go ahead and do this for things like Axis2 and the various dynamic language containers then what is the expected structure? Do they stay under services or move to new folder, and do they include things like the itests as well? For example: tuscany/java/sca/axis2/binding tuscany/java/sca/axis2/databinding tuscany/java/sca/axis2/itests tuscany/java/sca/axis2/samples tuscany/java/sca/axis2/tools Another question, so far the only things changed to use 0.1-pre-spec-SNAPSHOT are the containers, bindings, databindings, and samples, everything else, like other things in the services or the runtime folders haven't changed over. Is this just a point in time thing or is it not the intention to change them? I guess I'm not clear about if the kernel release is just the things in sca/kernel or if its also other things, and if so should there be some more restructuring of the folders? ...ant There were a few emails outlining this in detail a while back to the list. If you cannot find them, let me know and I will try and dig them up. Basically, the following: 1. Extensions will be grouped by how they are distributed. For example, Axis and the WSDL2Java tool will be grouped together. The JTA extension would be grouped by itself since it is released independently. We had planned to flatten the /services tree by renaming it to /extensions and including the extensions directly under it as opposed to grouping by binding or container. 2. Samples would be moved under their extensions. Where they specifically go is up to the extension. For example, samples could be their own separate distribution or they could be bundled directly with the extension. The would be housed under the extension, though. 3. For iTests, it depends on what they are. If they are integration tests for the extension, they should be under the respective extension directory. If not, I would just leave them where they are. Thanks for helping out. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
On Jan 24, 2007, at 1:54 AM, ant elder wrote: On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote: > Jeremy Boynes wrote: >> -1 on the single namespace as it couples together all the >> extensions - we would need to create a new version of the >> namespace every time any extension changed its XML > > I prefer a single Tuscany namespace. This is what the OSOA specs > are doing as well with a single SCA namespace for everything. This > helps simplfy the programming model as application developers only > need to declare the single namespace at the top of an SCDL file > instead of having to list different namespaces for all the > bindings, implementation types, policies etc. that they use. A good goal but how is it achievable in a way that does not require us to rerelease the schema, the Java and C++ kernels, all extensions and anything else that references the schema in coordination every time any one of those makes a schema change? And how do we prevent changes in one extension impacting users who don't use that extension? BTW the OSOA specs do not assume a single namespace and AIUI they require extensions to be in different ones. There is even discussion in the spec group about associating user-specific namespaces with all SCDL definitions. Could you point to where in the specs it talks about requiring extensions to use different namespaces? The spec will not allow "non-spec SCA" extensions to pollute the SCA namespace. For example, any vendor or Tuscany extensions that do not correspond to an SCA specification are not supposed to use the SCA namespace. This should apply to Tuscany as well for extensions not part of the Tuscany project. All the extension spec drafts that I can find are using the single SCA namespace, are these drafts just out of date? I prefer as few namespaces as possible for now as well as it makes the SCDL so much simpler. How about using the single Tuscany namespace for now and any extension can change to use some other namespace in the future if required. In general I prefer avoiding namespace proliferation but Jeremy raises valid points. Do you have some ideas on how to address those? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tuscany C++ sub-project name
Not sure if I get a vote having just joined the mailing list. However, I'll not let that put me off and +1 for Tuscany Native. Andrew
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
On Jan 24, 2007, at 5:30 AM, Rick wrote: Hello, Not XML schema guru but in the assembly spec don't extension fall in XML schemas given under "##other" imply a namespace other than the sca one ? Yes, that's what I was referring to. Also and etc. all use substitution groups to allow non-blessed versions from different namespaces. This was specifically done by the spec to allow vendors implementing it to release proprietary extensions independently. We need to do the same with Tuscany extensions so that they too can be released independently. -- Jeremy ant elder wrote: On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote: > Jeremy Boynes wrote: >> -1 on the single namespace as it couples together all the >> extensions - we would need to create a new version of the >> namespace every time any extension changed its XML > > I prefer a single Tuscany namespace. This is what the OSOA specs > are doing as well with a single SCA namespace for everything. This > helps simplfy the programming model as application developers only > need to declare the single namespace at the top of an SCDL file > instead of having to list different namespaces for all the > bindings, implementation types, policies etc. that they use. A good goal but how is it achievable in a way that does not require us to rerelease the schema, the Java and C++ kernels, all extensions and anything else that references the schema in coordination every time any one of those makes a schema change? And how do we prevent changes in one extension impacting users who don't use that extension? BTW the OSOA specs do not assume a single namespace and AIUI they require extensions to be in different ones. There is even discussion in the spec group about associating user-specific namespaces with all SCDL definitions. Could you point to where in the specs it talks about requiring extensions to use different namespaces? All the extension spec drafts that I can find are using the single SCA namespace, are these drafts just out of date? I prefer as few namespaces as possible for now as well as it makes the SCDL so much simpler. How about using the single Tuscany namespace for now and any extension can change to use some other namespace in the future if required. ...ant - 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-1075) Composite without an implementation causes BuilderConfigException
Composite without an implementation causes BuilderConfigException - Key: TUSCANY-1075 URL: https://issues.apache.org/jira/browse/TUSCANY-1075 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: Windows XP SP2, Tuscany M2 distribution Reporter: Andrew Schofield Priority: Minor Fix For: Java-SCA-M3 I've built the webapp/helloworldws sample and deployed it on Tomcat. I've also managed to invoke it using the standalone/helloworldwsclient sample. But, I was surprised to find that there was a (trivial) implementation in the composite of the client (HelloWorldServiceComponent) which just delegates the method calls to the back-end service. I'd really expected to write SCDL for a composite which wired a service directly to a reference with a Web-services binding. This would give a way of connecting an SCA client to an existing Web service without any implementation coding. Here's the SCDL that I tried: http://www.osoa.org/xmlns/sca/1.0"; xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT " name="helloworldwsclient"> http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2"; location="wsdl/helloworld.wsdl"/> http://www.w3.org/2006/01/wsdl-instance " interface="http://helloworld#wsdl.interface(HelloWorld) " wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" /> HelloWorldService http://www.w3.org/2006/01/wsdl-instance " interface="http://helloworld#wsdl.interface(HelloWorld) " wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" /> http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort)" location="wsdl/helloworld.wsdl" /> And here's the exception that I got (using Tuscany Java M2): Exception in thread "main" org.apache.tuscany.spi.builder.BuilderConfigException: No interceptor for operation [getGreetings] at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:336) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:278) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:389) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:163) at org.apache.tuscany.spi.extension.CompositeComponentExtension.prepare(CompositeComponentExtension.java:460) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:86) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) at org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87) at org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:83) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move Tuscany wiki to Apache CWIKI?
Two concerns come to mind if we make THE website: Is it backed up? can we get past revisions if needed ? Currently our website is in svn which covers that. The other is we have had past complaints that the site was not "fancy" organized etc, are we confident this wiki can handle this? I'm not against this, just cautious not being a wiki guru. ant elder wrote: On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote: 2) I'm not proposing to change the "edit" policy. The http://cwiki.apache.org/CWIKI/ page also provides some guidances for cases that we use it as a sandbox (open to all registered users) or documentation site (open to folks with CLA on file). I also think all our content should be open to any registered user. We want everyone to help maintain it and thats going be more likely to happen if we make it easy for them. Its harder for users to send in patches for the wiki :) Can we get update emails sent to the dev list so we all can monitor the changes? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Hello, Not XML schema guru but in the assembly spec don't extension fall in XML schemas given under other than the sca one ? ant elder wrote: On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote: > Jeremy Boynes wrote: >> -1 on the single namespace as it couples together all the >> extensions - we would need to create a new version of the >> namespace every time any extension changed its XML > > I prefer a single Tuscany namespace. This is what the OSOA specs > are doing as well with a single SCA namespace for everything. This > helps simplfy the programming model as application developers only > need to declare the single namespace at the top of an SCDL file > instead of having to list different namespaces for all the > bindings, implementation types, policies etc. that they use. A good goal but how is it achievable in a way that does not require us to rerelease the schema, the Java and C++ kernels, all extensions and anything else that references the schema in coordination every time any one of those makes a schema change? And how do we prevent changes in one extension impacting users who don't use that extension? BTW the OSOA specs do not assume a single namespace and AIUI they require extensions to be in different ones. There is even discussion in the spec group about associating user-specific namespaces with all SCDL definitions. Could you point to where in the specs it talks about requiring extensions to use different namespaces? All the extension spec drafts that I can find are using the single SCA namespace, are these drafts just out of date? I prefer as few namespaces as possible for now as well as it makes the SCDL so much simpler. How about using the single Tuscany namespace for now and any extension can change to use some other namespace in the future if required. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Extension mechanism and the REST binding
On 23/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Pete Robbins wrote: > Actually this is definitely a problem. The mechanism as it is today means > you can not have one extension library that depends on another unless we > separate out the static method into it's own dll for each extension. > It may > "work" on Linux but it probably shouldn't and it will not work on MacOS. > > So the tuscany_sca_rest_reference library can not link with > tuscany_sca_rest_interface as both define the same symbol. We could have > just one library that initializes all the rest extensions but either > way I > need to refactor this code OR we change the name of the initialization > method to something that the runtime can derive from the library name > itself... such as _initialize where library name is the > root > name for the library i.e. the "lib" and ".so" are removed (or the ".dll" > removed for windows) e.g. tuscany_sca_rest_interface > > This is probably a better solution as someone may wish to write an > extension > that extends the CPP extension for instance. > > Cheers, > > On 23/01/07, Pete Robbins <[EMAIL PROTECTED]> wrote: >> >> This seems to build fine on linux and does not warn about the duplicate >> symbol. I'll go back and check why Mac is complaining. >> >> Cheers, >> >> >> On 23/01/07, Pete Robbins <[EMAIL PROTECTED]> wrote: >> > >> > I've run in to a problem building the REST binding extension on MacOS. >> > Our extension mechanism works by having a well known exported >> method from a >> > library that implements an extension; >> tuscany_sca_extension_initialize() >> > >> > In the REST binding the extension is split into interface, service, >> > reterence and a mod_rest library. >> > The tuscany_sca_rest_reference library links with the >> > tuscany_sca_rest_interface library both of which export the same named >> > method. This causes linking problems on Mac. I'm not sure why we >> don't see >> > the same problem on Linux or Windows! >> > >> > Perhaps we need to refactor this code to have just one extension >> > initialization method for the whole REST binding?? >> > >> > Cheers, >> > >> > -- >> > Pete >> > >> >> >> >> -- >> Pete > > > > +1 for deriving the init method name from the library name. This resolves the name collision issue and allows for packaging of interface/service/reference extensions in their own libs and dependencies between them. -- Jean-Sebastien I've checked in a change to avoid name clashes with the initialization methods. -- Pete
Re: Move Tuscany wiki to Apache CWIKI?
On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote: 2) I'm not proposing to change the "edit" policy. The http://cwiki.apache.org/CWIKI/ page also provides some guidances for cases that we use it as a sandbox (open to all registered users) or documentation site (open to folks with CLA on file). I also think all our content should be open to any registered user. We want everyone to help maintain it and thats going be more likely to happen if we make it easy for them. Its harder for users to send in patches for the wiki :) Can we get update emails sent to the dev list so we all can monitor the changes? ...ant
Re: [C++] latest from svn gets axis error on build
On 1/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: On 1/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > Hi > > Am building C++ SCA/SDO from head on Fedora Core 6 using build.sh. and get > the following > > g++ -DHAVE_CONFIG_H -I. -I. -I../../../../../.. > -I../../../../../../runtime/core/src > -I/home/slaws/workspace/cpp/sdo/deploy/include -I/home/slaws/apps/axis2c- > bin-0.94-linux/include -D_DEBUG -g -O2 -MT Axis2Client.lo -MD -MP -MF > .deps/Axis2Client.Tpo -c tuscany/sca/ws/Axis2Client.cpp -fPIC -DPIC -o > .libs/Axis2Client.otuscany/sca/ws/Axis2Client.cpp: In member function > 'virtual void > tuscany::sca::ws::Axis2Client::invoke(tuscany::sca::Operation&)': > tuscany/sca/ws/Axis2Client.cpp:238: error: > 'AXIS2_OPTIONS_SET_XML_PARSER_RESET' was not declared in this scope > tuscany/sca/ws/Axis2Client.cpp:245: error: 'AXIS2_OPTIONS_SET_SOAP_ACTION' > was not declared in this scope > > I'm still at Axis 0.94. Is this something to do with Andy's axis upgrade? > > Simon > Think I've answered my own question. Greping for the offending string in 0.94 returns nothing while in 0.96 it returns something so I'll try moving to 0.96 and see what happens. Simon Yep - apologies for that. In my post yesterday I failed to say that we now require Axis2C 0.96 and nothing earlier due to fixes in Axis that we're taking advantage of. Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] latest from svn gets axis error on build
On 1/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: Hi Am building C++ SCA/SDO from head on Fedora Core 6 using build.sh. and get the following g++ -DHAVE_CONFIG_H -I. -I. -I../../../../../.. -I../../../../../../runtime/core/src -I/home/slaws/workspace/cpp/sdo/deploy/include -I/home/slaws/apps/axis2c- bin-0.94-linux/include -D_DEBUG -g -O2 -MT Axis2Client.lo -MD -MP -MF .deps/Axis2Client.Tpo -c tuscany/sca/ws/Axis2Client.cpp -fPIC -DPIC -o .libs/Axis2Client.otuscany/sca/ws/Axis2Client.cpp: In member function 'virtual void tuscany::sca::ws::Axis2Client::invoke(tuscany::sca::Operation&)': tuscany/sca/ws/Axis2Client.cpp:238: error: 'AXIS2_OPTIONS_SET_XML_PARSER_RESET' was not declared in this scope tuscany/sca/ws/Axis2Client.cpp:245: error: 'AXIS2_OPTIONS_SET_SOAP_ACTION' was not declared in this scope I'm still at Axis 0.94. Is this something to do with Andy's axis upgrade? Simon Think I've answered my own question. Greping for the offending string in 0.94 returns nothing while in 0.96 it returns something so I'll try moving to 0.96 and see what happens. Simon
[C++] latest from svn gets axis error on build
Hi Am building C++ SCA/SDO from head on Fedora Core 6 using build.sh. and get the following g++ -DHAVE_CONFIG_H -I. -I. -I../../../../../.. -I../../../../../../runtime/core/src -I/home/slaws/workspace/cpp/sdo/deploy/include -I/home/slaws/apps/axis2c- bin-0.94-linux/include -D_DEBUG -g -O2 -MT Axis2Client.lo -MD -MP -MF .deps/Axis2Client.Tpo -c tuscany/sca/ws/Axis2Client.cpp -fPIC -DPIC -o .libs/Axis2Client.otuscany/sca/ws/Axis2Client.cpp: In member function 'virtual void tuscany::sca::ws::Axis2Client::invoke(tuscany::sca::Operation&)': tuscany/sca/ws/Axis2Client.cpp:238: error: 'AXIS2_OPTIONS_SET_XML_PARSER_RESET' was not declared in this scope tuscany/sca/ws/Axis2Client.cpp:245: error: 'AXIS2_OPTIONS_SET_SOAP_ACTION' was not declared in this scope I'm still at Axis 0.94. Is this something to do with Andy's axis upgrade? Simon
Re: conversion of samples
On 1/24/07, Jim Marino <[EMAIL PROTECTED]> wrote: I've converted most of the binding and container extensions to reference the 0.1-pre-spec-SNAPSHOT kernel. Also, I started to convert the samples under java/samples/sca/ specifically: - calculator - echo.binding - inner.composite - loanappconversation - simplecallback - spring - spring.simple - supplychain I *did not* convert any of the web app, binding or container extension samples (with the exception of Spring). As part of the reorganized build tree outlined by Jeremy, these samples will be grouped with their respective extensions. It would be helpful if people working in those extension areas can take this move on as well as change the samples to refer to the kernel 0.1-pre-spec-SNAPSHOT. This will allow the extensions to be developed and released individually. So if I was to go ahead and do this for things like Axis2 and the various dynamic language containers then what is the expected structure? Do they stay under services or move to new folder, and do they include things like the itests as well? For example: tuscany/java/sca/axis2/binding tuscany/java/sca/axis2/databinding tuscany/java/sca/axis2/itests tuscany/java/sca/axis2/samples tuscany/java/sca/axis2/tools Another question, so far the only things changed to use 0.1-pre-spec-SNAPSHOT are the containers, bindings, databindings, and samples, everything else, like other things in the services or the runtime folders haven't changed over. Is this just a point in time thing or is it not the intention to change them? I guess I'm not clear about if the kernel release is just the things in sca/kernel or if its also other things, and if so should there be some more restructuring of the folders? ...ant
[jira] Commented: (TUSCANY-750) [SDO for C++] Schema Validation. Validate an XML document against a schema.
[ https://issues.apache.org/jira/browse/TUSCANY-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466983 ] Geoff Winn commented on TUSCANY-750: This subject is being actively debated by the specification group. It is clearly a complicated issue and not one that we are likely to resolve in advance of the spec so I propose closing this JIRA. > [SDO for C++] Schema Validation. Validate an XML document against a schema. > --- > > Key: TUSCANY-750 > URL: https://issues.apache.org/jira/browse/TUSCANY-750 > Project: Tuscany > Issue Type: Improvement > Components: C++ SDO >Affects Versions: Cpp-current > Environment: All >Reporter: Geoff Winn > Fix For: Cpp-M3 > > > We really need an ability to validate an XML document against a schema. > Ideally for the PHP user this would be possible in the context of libxml2, > rather than forcing a move to AXIS/2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Composite without an implementation?
I think this is a defect, would you raise a JIRA for it? There's a related JIRA for if you try to go directly to a reference, see: http://issues.apache.org/jira/browse/TUSCANY-862. ...ant On 1/22/07, Andrew Schofield <[EMAIL PROTECTED]> wrote: Hi, I've just started using Tuscany and I've been kicking around some of the samples to see what they do. I've managed to make them work without problems but I hit a snag when I tried to change one in particular. I've built the webapp/helloworldws sample and deployed it on Tomcat. I've also managed to invoke it using the standalone/helloworldwsclient sample. But, I was surprised to find that there was a (trivial) implementation in the composite of the client (HelloWorldServiceComponent) which just delegates the method calls to the back-end service. I'd really expected to write SCDL for a composite which wired a service directly to a reference with a Web-services binding. This would give a way of connecting an SCA client to an existing Web service without any implementation coding. Here's the SCDL that I tried: http://www.osoa.org/xmlns/sca/1.0"; xmlns:system="http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT"; name="helloworldwsclient"> http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2 " location="wsdl/helloworld.wsdl"/> http://www.w3.org/2006/01/wsdl-instance"; interface="http://helloworld#wsdl.interface(HelloWorld)" wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" /> HelloWorldService http://www.w3.org/2006/01/wsdl-instance"; interface="http://helloworld#wsdl.interface(HelloWorld)" wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" /> http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort)" location="wsdl/helloworld.wsdl" /> And here's the exception that I got (using Tuscany Java M2): Exception in thread "main" org.apache.tuscany.spi.builder.BuilderConfigException: No interceptor for operation [getGreetings] at org.apache.tuscany.core.builder.ConnectorImpl.connect( ConnectorImpl.java :336) at org.apache.tuscany.core.builder.ConnectorImpl.connect( ConnectorImpl.java :278) at org.apache.tuscany.core.builder.ConnectorImpl.connect( ConnectorImpl.java :389) at org.apache.tuscany.core.builder.ConnectorImpl.connect( ConnectorImpl.java :163) at org.apache.tuscany.spi.extension.CompositeComponentExtension.prepare( CompositeComponentExtension.java:460) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java :86) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl( AbstractRuntime.java:136) at org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize ( StandaloneRuntimeImpl.java:87) at org.apache.tuscany.launcher.MainLauncherBooter.main( MainLauncherBooter.java:83) Can anyone enlighten me about the cause of the problem? I think that a composite without an implementation should be OK, so I hope that it's just my SCDL at fault. Thanks in advance, Andrew Schofield
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote: > Jeremy Boynes wrote: >> -1 on the single namespace as it couples together all the >> extensions - we would need to create a new version of the >> namespace every time any extension changed its XML > > I prefer a single Tuscany namespace. This is what the OSOA specs > are doing as well with a single SCA namespace for everything. This > helps simplfy the programming model as application developers only > need to declare the single namespace at the top of an SCDL file > instead of having to list different namespaces for all the > bindings, implementation types, policies etc. that they use. A good goal but how is it achievable in a way that does not require us to rerelease the schema, the Java and C++ kernels, all extensions and anything else that references the schema in coordination every time any one of those makes a schema change? And how do we prevent changes in one extension impacting users who don't use that extension? BTW the OSOA specs do not assume a single namespace and AIUI they require extensions to be in different ones. There is even discussion in the spec group about associating user-specific namespaces with all SCDL definitions. Could you point to where in the specs it talks about requiring extensions to use different namespaces? All the extension spec drafts that I can find are using the single SCA namespace, are these drafts just out of date? I prefer as few namespaces as possible for now as well as it makes the SCDL so much simpler. How about using the single Tuscany namespace for now and any extension can change to use some other namespace in the future if required. ...ant
[jira] Resolved: (TUSCANY-1055) DataFactory.create(abstract_type) should throw an IllegalArgumentException
[ https://issues.apache.org/jira/browse/TUSCANY-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1055. - Resolution: Fixed applied Ki's patch > DataFactory.create(abstract_type) should throw an IllegalArgumentException > -- > > Key: TUSCANY-1055 > URL: https://issues.apache.org/jira/browse/TUSCANY-1055 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: You should see this error in any environment. >Reporter: Ki Park >Priority: Minor > Fix For: Java-SDO-Mx > > Attachments: TUSCANY-1055.patch > > > Use an Abstract type as a parameter of DataObject.create() and it works fine > now without any exception, but it should throw an exception. > According to the spec in section 3.7.2 Creating Data Objects, it reads: > - Type.dataType and abstract must be both fase. > - Throw an IllegalArgumentException if the instanceClass does not > correspond to a Type this factory can instantiate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to update the Tuscany website?
Thanks Luciano. On 1/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote: I've just done the svn update on the people machine. On 1/23/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi, > > I have been able to add pages to the WIKI and have added some skeleton > pages > for SCA, DAS and SDO FAQs. I am also ready with the updates to our site > to > point to these FAQs - just that I am not able to ssh to people.apache.orgto > refresh these updates. Hope to succeed in that sometime during the day. > > - Venkat > > On 1/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > > > Right. So how do we go about this. I wanted to create a new page on > > that WIKI but seems I have no permission. If somebody can help me about > how > > to do this, then I will create the page and post Geoffs q&a. I propose > > separate FAQ pages for SCA, DAS and SDO. Once this is done then I will > link > > up these pages from the website. > > > > Thanks > > > > - Venkat > > > > > > On 1/21/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > > > +1 to Haleh's suggestion > > > > > > This could be the first usage of the new wiki ? > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12897.html > > >http://cwiki.apache.org/TUSCANY/ > > > > > > On 1/20/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > > > +1 to Haleh's suggestion > > > > > > > > > > > > On 1/20/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > > > > I propose that we move FAQ to the Wiki and make it more > accessible > > > for > > > > > updates. > > > > > We can link from the website to the FAQ which will reside on the > > > Wiki. > > > > > > > > > > This difficult update process is probably the reason for FAQ being > > > so > > > > empty. > > > > > > > > > > We have been answering the same questions multiple times and an > > > easier > > > > > access to the FAQ will encourage everyone to help, including > > > > non-committers. > > > > > > > > > > > > > > > > > > > > On 1/19/07, Geoffrey Winn < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Venkat, > > > > > > > > > > > > Thank you for the offer. Normally I wouldn't be lazy and would > get > > > on > > > > and > > > > > > do > > > > > > the work, but it's only a small change, so I'll accept. > > > > > > > > > > > > I'd like to add the following as a third bullet point. > > > > > > > > > > > > * Does SDO for C++ provide a static interface as the Java > > > > implementation > > > > > > does? > > > > > > No. It is not clear that this is a useful feature in a > language > > > like > > > > C++ > > > > > > so we have no plans > > > > > > to implement it. > > > > > > > > > > > > Thank you for your help. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Geoff. > > > > > > > > > > > > On 19/01/07, Venkata Krishnan < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi Geoff, > > > > > > > > > > > > > > Since I have done this before I can help if you can simply > > > provide > > > > the > > > > > > > udpated faq.xml. I shall take care of building it to html and > > > then > > > > > > > updating > > > > > > > the site. Let me know. > > > > > > > > > > > > > > - Venkat > > > > > > > > > > > > > > > > > > > > > On 1/19/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > Hi Geoff, > > > > > > > > > > > > > > > > Take a look at > > > > > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/site/README.txt > > > > > > > > > > > > > > > > > > > You need to edit the xml, regenerate the HTML from the XML, > > > svn > > > > commit > > > > > > > > those changes and then log into people.apache.org and run an > > > svn > > > > > > > > update there. > > > > > > > > > > > > > > > > It's a bit of a complex process - one that we should perhaps > > > think > > > > > > > > about improving... > > > > > > > > > > > > > > > > Cheers > > > > > > > > Andy > > > > > > > > > > > > > > > > On 1/19/07, Geoffrey Winn < [EMAIL PROTECTED]> > wrote: > > > > > > > > > Apologies if this has already been covered. > > > > > > > > > > > > > > > > > > I would like to update the FAQ page of the website ( > > > > > > > > > http://incubator.apache.org/tuscany/faq.html, if that > makes > > > a > > > > > > > > difference). > > > > > > > > > How do I do that? Is it enough to edit > > > site/site-author/faq.xml > > > > or > > > > > > do > > > > > > > I > > > > > > > > have > > > > > > > > > to change anything else? > > > > > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Geoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -
Re: How to update the Tuscany website?
I've just done the svn update on the people machine. On 1/23/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, I have been able to add pages to the WIKI and have added some skeleton pages for SCA, DAS and SDO FAQs. I am also ready with the updates to our site to point to these FAQs - just that I am not able to ssh to people.apache.orgto refresh these updates. Hope to succeed in that sometime during the day. - Venkat On 1/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Right. So how do we go about this. I wanted to create a new page on > that WIKI but seems I have no permission. If somebody can help me about how > to do this, then I will create the page and post Geoffs q&a. I propose > separate FAQ pages for SCA, DAS and SDO. Once this is done then I will link > up these pages from the website. > > Thanks > > - Venkat > > > On 1/21/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > +1 to Haleh's suggestion > > > > This could be the first usage of the new wiki ? > >http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12897.html > >http://cwiki.apache.org/TUSCANY/ > > > > On 1/20/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > +1 to Haleh's suggestion > > > > > > > > > On 1/20/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > > > I propose that we move FAQ to the Wiki and make it more accessible > > for > > > > updates. > > > > We can link from the website to the FAQ which will reside on the > > Wiki. > > > > > > > > This difficult update process is probably the reason for FAQ being > > so > > > empty. > > > > > > > > We have been answering the same questions multiple times and an > > easier > > > > access to the FAQ will encourage everyone to help, including > > > non-committers. > > > > > > > > > > > > > > > > On 1/19/07, Geoffrey Winn < [EMAIL PROTECTED]> wrote: > > > > > > > > > > Venkat, > > > > > > > > > > Thank you for the offer. Normally I wouldn't be lazy and would get > > on > > > and > > > > > do > > > > > the work, but it's only a small change, so I'll accept. > > > > > > > > > > I'd like to add the following as a third bullet point. > > > > > > > > > > * Does SDO for C++ provide a static interface as the Java > > > implementation > > > > > does? > > > > > No. It is not clear that this is a useful feature in a language > > like > > > C++ > > > > > so we have no plans > > > > > to implement it. > > > > > > > > > > Thank you for your help. > > > > > > > > > > Regards, > > > > > > > > > > Geoff. > > > > > > > > > > On 19/01/07, Venkata Krishnan < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hi Geoff, > > > > > > > > > > > > Since I have done this before I can help if you can simply > > provide > > > the > > > > > > udpated faq.xml. I shall take care of building it to html and > > then > > > > > > updating > > > > > > the site. Let me know. > > > > > > > > > > > > - Venkat > > > > > > > > > > > > > > > > > > On 1/19/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi Geoff, > > > > > > > > > > > > > > Take a look at > > > > > > > http://svn.apache.org/repos/asf/incubator/tuscany/site/README.txt > > > > > > > > > > > > > > > > You need to edit the xml, regenerate the HTML from the XML, > > svn > > > commit > > > > > > > those changes and then log into people.apache.org and run an > > svn > > > > > > > update there. > > > > > > > > > > > > > > It's a bit of a complex process - one that we should perhaps > > think > > > > > > > about improving... > > > > > > > > > > > > > > Cheers > > > > > > > Andy > > > > > > > > > > > > > > On 1/19/07, Geoffrey Winn < [EMAIL PROTECTED]> wrote: > > > > > > > > Apologies if this has already been covered. > > > > > > > > > > > > > > > > I would like to update the FAQ page of the website ( > > > > > > > > http://incubator.apache.org/tuscany/faq.html, if that makes > > a > > > > > > > difference). > > > > > > > > How do I do that? Is it enough to edit > > site/site-author/faq.xml > > > or > > > > > do > > > > > > I > > > > > > > have > > > > > > > > to change anything else? > > > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Geoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > 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] > > > > > > > > > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende< http://people.apache.org/%7Elresende> > > > > > -- Luciano Resende http://people.apache.org/~lresende
Re: what's the matter with the DAS source code???
Hi Sam, I too had a similar same problem. It took me a little while, but seemed to be fixed when they are (re)generated by building DAS using maven (although I was not building from the source archive). Unfortunately eclipse does not understand maven build files without using the m3clipse plugin. There was an earlier thread about this on the dev list: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10450.html In summary most people seem to build using the command line, however it is possible to get tuscany to build in eclipse... Optionally, install Subclipse (http://subclipse.tigris.org/) if you want to download directly from the subversion repository. Install the maven2 (http://m2eclipse.codehaus.org/) plugin. Enable the M2 plugin for the DAS project Make sure that your maven repository can be located (on my linux machine I had to link '/home/murphdg/conf/settings.xml' to the real $maven/conf location and this seemed to solved it. Personally I've found that the approach of downloading and unzipping the source then running maven's eclipse plugin (mvn -Peclipse eclipse:eclipse or mvn -Pall eclipse:eclipse). Then importing this into eclipse more reliable (because it seems that the cmd line tools are less sensitive to network problems, or so it seems to me). Hope this helps, Dan On 24/01/07, Sam Su <[EMAIL PROTECTED]> wrote: I downloaded das-1.0-incubator-M2-src.zip from Apache tuscany website. when I compile it in Eclipse, there are many errors, such as following: The import org.apache.tuscany.das.rdb.config.Command cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 21 14:48:41 The import org.apache.tuscany.das.rdb.config.Config cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 22 14:48:41 The import org.apache.tuscany.das.rdb.config.ConfigFactory cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 23 14:48:41 The import org.apache.tuscany.das.rdb.config.Relationship cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 24 14:48:41 The import org.apache.tuscany.das.rdb.config.Table cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 25 14:48:41 I thought the errors show some source codes do not exist. I read some codes like org.apache.tuscany.das.rdb. ConfigHelper, this class import some other classes: import org.apache.tuscany.das.rdb.config.Command; import org.apache.tuscany.das.rdb.config.Config; import org.apache.tuscany.das.rdb.config.ConfigFactory; import org.apache.tuscany.das.rdb.config.Relationship; import org.apache.tuscany.das.rdb.config.Table; but in the org.apache.tuscany.das.rdb.config package, there are no these required files. I thought these class files may be missed in the das-1.0-incubator-M2-src.zip file, However I also cannot find source codes of these classes in Tuscany SVN repository. What's the matter with Apache Tuscany??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why not query datas?
You might be getting the IndexOutOfBounds when the query returned 0 elements
and you are trying to access an element from SDO like in your example :
("FM_TEST_CUSTOMER[1]"); I'll take a look in details on your example in the
morning.
--
Luciano Resende
http://people.apache.org/~lresende
On 1/23/07, zhuang johnyson <[EMAIL PROTECTED]> wrote:
Hello,
I have FM_TEST_CUSTOMER.xml:
http:///org.apache.tuscany.das.rdb/config.xsd"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>
And my java code:
DAS das = DAS.FACTORY.createDAS(test.getConfig("FM_TEST_CUSTOMER.xml"),
getConnection());
Command selectCommand = das.getCommand("all customers");
DataObject root = selectCommand.executeQuery();
DataObject FM_TEST_CUSTOMER = (DataObject) root.getDataObject
("FM_TEST_CUSTOMER[1]");
When I run this code,The program throws a exception:
Exception in thread "main"
org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException:index=0
,
size=0
Re: what's the matter with the DAS source code???
I'm assuming you are doing the following steps : 1.download and extract DAS M2 source distribution 2.build the source code using maven (e.g. performing mvn on the comand prompt). This should download dependencies, such as SDO, from maven repositories 3.using maven to generate proper eclipse projects (e.g mvn -Peclipse eclipse:eclipse) 4.Importing DAS project into eclipse with all necessary dependencies As for the files you mentioned, some of them are static SDOs that model our config files, and they are going to be generated by the mvn command. Please, let me know if you are still seeing all the issues after performing the steps above. -- Luciano Resende http://people.apache.org/~lresende On 1/23/07, Sam Su <[EMAIL PROTECTED]> wrote: I downloaded das-1.0-incubator-M2-src.zip from Apache tuscany website. when I compile it in Eclipse, there are many errors, such as following: The import org.apache.tuscany.das.rdb.config.Command cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 21 14:48:41 The import org.apache.tuscany.das.rdb.config.Config cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 22 14:48:41 The import org.apache.tuscany.das.rdb.config.ConfigFactory cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 23 14:48:41 The import org.apache.tuscany.das.rdb.config.Relationship cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 24 14:48:41 The import org.apache.tuscany.das.rdb.config.Table cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 25 14:48:41 I thought the errors show some source codes do not exist. I read some codes like org.apache.tuscany.das.rdb. ConfigHelper, this class import some other classes: import org.apache.tuscany.das.rdb.config.Command; import org.apache.tuscany.das.rdb.config.Config; import org.apache.tuscany.das.rdb.config.ConfigFactory; import org.apache.tuscany.das.rdb.config.Relationship; import org.apache.tuscany.das.rdb.config.Table; but in the org.apache.tuscany.das.rdb.config package, there are no these required files. I thought these class files may be missed in the das-1.0-incubator-M2-src.zip file, However I also cannot find source codes of these classes in Tuscany SVN repository. What's the matter with Apache Tuscany???
why not query datas?
Hello,
I have FM_TEST_CUSTOMER.xml:
http:///org.apache.tuscany.das.rdb/config.xsd"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>
And my java code:
DAS das = DAS.FACTORY.createDAS(test.getConfig("FM_TEST_CUSTOMER.xml"),
getConnection());
Command selectCommand = das.getCommand("all customers");
DataObject root = selectCommand.executeQuery();
DataObject FM_TEST_CUSTOMER = (DataObject) root.getDataObject
("FM_TEST_CUSTOMER[1]");
When I run this code,The program throws a exception:
Exception in thread "main"
org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException:index=0,
size=0
what's the matter with the DAS source code???
I downloaded das-1.0-incubator-M2-src.zip from Apache tuscany website. when I compile it in Eclipse, there are many errors, such as following: The import org.apache.tuscany.das.rdb.config.Command cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 21 14:48:41 The import org.apache.tuscany.das.rdb.config.Config cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 22 14:48:41 The import org.apache.tuscany.das.rdb.config.ConfigFactory cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 23 14:48:41 The import org.apache.tuscany.das.rdb.config.Relationship cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 24 14:48:41 The import org.apache.tuscany.das.rdb.config.Table cannot be resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 25 14:48:41 I thought the errors show some source codes do not exist. I read some codes like org.apache.tuscany.das.rdb. ConfigHelper, this class import some other classes: import org.apache.tuscany.das.rdb.config.Command; import org.apache.tuscany.das.rdb.config.Config; import org.apache.tuscany.das.rdb.config.ConfigFactory; import org.apache.tuscany.das.rdb.config.Relationship; import org.apache.tuscany.das.rdb.config.Table; but in the org.apache.tuscany.das.rdb.config package, there are no these required files. I thought these class files may be missed in the das-1.0-incubator-M2-src.zip file, However I also cannot find source codes of these classes in Tuscany SVN repository. What's the matter with Apache Tuscany???
