Re: Contribution URLs
On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Simon, Could you please send the exact URL you are passing to the contribution service ? I have added a test case for what I understood your problem is, and that is working fine, but note that in the test case, I'm calling getClass().getResource(/deployables), and that gives me a url like : file://deployables, and that would pass the logic to correct identify a folder. On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano This was the piece of code that was causing me problems... contributionURL = new URL(file:/ + currentDirectory.getCanonicalPath() + /src/main/resources/ + nodeName + /); // Contribute the SCA application Contribution contribution = contributionService.contribute( http://calculator;, contributionURL, resolver, false); Composite composite = contribution.getDeployables().get(0); // Add the deployable composite to the domain domain.getDomainComposite().getIncludes().add(composite); domain.getCompositeBuilder().build(composite); Where the directory structure is. src/ main/ resources/ nodeA/ META-INF/ sca-contribution.xml wsdl mutiply.wsdl calculator.composite And I want to read the contribution from the nodeA directory. Maybe you can spot something from this. But if nothing comes to mind immediately don't worry. I'll check this test in over the next few days and we can look at it directly. Regards Simon
Re: Release management for next release, was: SCA 0.92 release?
+1 for the 21st. Simon ant elder wrote: I guess early the following week still leaves time for an August release. It will be real tight though so we'll all need to be quick and thorough with our RC reviews as one problem once we get to the IPMC voting and it could easily slip it into September. So does taking the branch on the 21st sound ok to everyone? ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Ant talked about cutting the branch very early next week. I'd prefer that to doing it on August 18th. I will be away for a few days, returning home late on the 18th, and I could take advantage of the extra couple of days to help with last-minute things. Simon Venkata Krishnan wrote: Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...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] Updated: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
[ https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1528: Patch Info: (was: [Patch Available]) ClassCastException thrown when trying to deserializing an XML with undefined global element --- Key: TUSCANY-1528 URL: https://issues.apache.org/jira/browse/TUSCANY-1528 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-Next Attachments: 1528-testcase.patch Using simple.xsd, I can serialize and deserialize an XML with a undefined global element. If I removed the global element definition from the simple.xsd, a ClassCastException will be thrown. It seems without the global element definition's presence some required step was not done. Here is the stack trace and test case. junit.framework.AssertionFailedError: java.lang.ClassCastException: org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with commonj.sdo.DataObject at junit.framework.Assert.fail(Assert.java:47) at org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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] Created: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
ClassCastException thrown when trying to deserializing an XML with undefined global element --- Key: TUSCANY-1528 URL: https://issues.apache.org/jira/browse/TUSCANY-1528 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-Next Attachments: 1528-testcase.patch Using simple.xsd, I can serialize and deserialize an XML with a undefined global element. If I removed the global element definition from the simple.xsd, a ClassCastException will be thrown. It seems without the global element definition's presence some required step was not done. Here is the stack trace and test case. junit.framework.AssertionFailedError: java.lang.ClassCastException: org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with commonj.sdo.DataObject at junit.framework.Assert.fail(Assert.java:47) at org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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]
Policy intents and policySets on bindings and implementations
I noticed that bindings and implementations now have: - intents - policySets and - computedIntents - computedPolicySets How about simplifying this a bit and doing what we've done in CompositeBuilder with all other similar cases like bindings, property configuration etc. - we read intents - we compute/combine/override intents declared at different levels - eventually the intents field contains the effective (computed) intents With bindings on references for example we don't have bindings and computedBindings... This will make the model simpler, and will also avoid confusion when people use the model, like: hmm I'm looking at Binding, which intent field should I use? intents or computedIntents? should I add to both? which one should I get the intents from? if I add to one does the other reflect my changes? etc. :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r564429 - in /incubator/tuscany/java/sca: modules/binding-ajax/src/main/java/org/apache/tuscany/sca/binding/ajax/ modules/binding-jsonrpc/src/main/java/org/apache/tuscany/sca/binding/j
On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: How about instead of extension having to do new ExtensibleServletHost(servletHosts) that code is moved into the ExtensionUtils DiscoveryUtils class as a special case so that extensions can still just use the simple constructor taking a ServletHost and ExtensionHelper creates the ExtensibleServletHost for them? Sure, but won't that create a new dependency from extension-helper on host-http? Thats true, and thats no good. Guess it could just use reflection, bit messy but are there any alternatives? Its just the whole point of it is to avoid extensions having to know and do stuff like this so it would be really good to find a way to avoid it. ...ant
[SDO Native] Tuscany SDO Native for Windows is not msvc backwards compatible
Hello all, I created a JIRA for this compilation issue and have already uploaded a patch. Can someone submit it please. https://issues.apache.org/jira/browse/TUSCANY-1529 Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
Is there value in keeping download links for old releases?
Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh
Re: mvn eclipse:eclipse fails on java
I also tried looking for this manually: org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Here's what I find in the repository under: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/ [DIR] tuscany-binding-notification/27-Jul-2007 22:06- [DIR] tuscany-binding-rmi/ 23-May-2007 15:32- [DIR] tuscany-binding-sca/ 27-Jul-2007 17:17- [DIR] tuscany-binding-ws-axis2/23-May-2007 15:35- [DIR] tuscany-binding-ws-xml/ Should there be a directory corresponding to the groupid: tuscany-binding-sca-xml Here? Thanks, - Ole Luciano Resende wrote: What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - 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: mvn eclipse:eclipse fails on java
I tried it with 2.0.5: [EMAIL PROTECTED] java]$ /home/ole/Desktop/maven-2.0.5/bin/mvn eclipse:eclipse I still get the same error... Missing: -- 1) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Luciano Resende wrote: What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - 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]
Rename itest artifacts to not include the tuscany- suffix?
Anyone mind if i change all the itest artifacts to not include the tuscany- suffix? Its a minor thing i know but it would mean then they don't get mixed up with the tuscany runtime modules in the IDE panel views. ...ant
Re: Is there value in keeping download links for old releases?
On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi, The latest release for each subproject is the preferred release to download. Does it make sense to keep links to download for old releases on the download page? This can give a wrong impression that these are also OK to download. For example, for Java SCA there are still links to M1 and M2 from last year. Architecture has changed since then. Does it make sense to have the latest release and the previous release as an option for download and leave everything else under history or remove them? Haleh I think yes we should keep them. One of the first things I look at when coming across an open source project is the release history as it gives you a good indication of how much life there is in the project. Maybe from that we don't need actual links to the download artifacts, but something clearly showing we do regular releases and have been doing so for years is a Good Thing IMHO. Another reason is if someone is debugging some old system with a back level release they may need access to the source distro to debug the code. ...ant
[jira] Updated: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible
[ https://issues.apache.org/jira/browse/TUSCANY-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1529: --- Attachment: tuscany_patch_jira1529 Uploading patch. Tuscany SDO native for windows is not msvc backwards compatible Key: TUSCANY-1529 URL: https://issues.apache.org/jira/browse/TUSCANY-1529 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: MSVC 8.0 and 7.1 Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: tuscany_patch_jira1529 I've been trying to compile Tuscany on platforms other than VSExpress (which is msvc 8.0) and Linux. I came across something that doesn't compile on msvc7.1 in SDODate.cpp. The problem is the definition of localtime for windows. Its #define'd as localtime_s for windows. A simple check for compiler version would allow it to be defined for msvc 8.0 and anything previous, as follows: #ifndef tuscany_localtime_r #if defined(WIN32) || defined (_WINDOWS) #if _MSC_VER 1400 // _MSC_VER: 1400 is msvc 8.0, so anything less is pre 8.0 #define tuscany_localtime_r(value, ignore) localtime(value); #else #define tuscany_localtime_r(value, tmp_tm) localtime_s(tmp_tm, value); #endif #else #define tuscany_localtime_r(value, tmp_tm) localtime_r(value, tmp_tm); #endif #endif // tuscany_localtime_r Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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: Rename itest artifacts to not include the tuscany- suffix?
Are these tests specific to Tuscany SCA or can they be viewed as a community test suite for SCA Java? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: Anyone mind if i change all the itest artifacts to not include the tuscany- suffix? Its a minor thing i know but it would mean then they don't get mixed up with the tuscany runtime modules in the IDE panel views. ...ant
[jira] Updated: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
[ https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1528: Attachment: 1528-testcase.patch ClassCastException thrown when trying to deserializing an XML with undefined global element --- Key: TUSCANY-1528 URL: https://issues.apache.org/jira/browse/TUSCANY-1528 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Fix For: Java-SDO-Next Attachments: 1528-testcase.patch Using simple.xsd, I can serialize and deserialize an XML with a undefined global element. If I removed the global element definition from the simple.xsd, a ClassCastException will be thrown. It seems without the global element definition's presence some required step was not done. Here is the stack trace and test case. junit.framework.AssertionFailedError: java.lang.ClassCastException: org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with commonj.sdo.DataObject at junit.framework.Assert.fail(Assert.java:47) at org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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: SCA schema files, where can I download them
Thanks for that Simon and Jean-Sebastien. I checked the sca-core.xsd versus the errata listed and the schema has not been updated. Its easy enough for me to change it locally, but maybe another version should be uploaded. To avoid confusion, maybe it could be called sca-core.xsd-with-errata-fix. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 9:29 AM To: tuscany-dev@ws.apache.org Subject: Re: SCA schema files, where can I download them On 8/10/07, Brady Johnson [EMAIL PROTECTED] wrote: Does anyone know where I can download the SCA schema files referenced in the SCA_AssemblyModel_v100? Specifically: * sca-core.xsd * sca-binding-sca.xsd * sca-interface-wsdl.xsd * sca-implementation-composite.xsd * sca-definitions.xsd The schemas are presented in that spec, but they have the 4 digit line numbers present, and its very error-prone to copy paste them and then have to remove the line numbers. Then, there's the issue of the errata listed here: http://www.osoa.org/display/Main/Service+Component+Architecture+Specif ic ations It would be nice if the osoa website had them available for download. I tried looking through the TuscanyJava code, but didn't see that they are using the schemas, maybe I missed them. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Hi Brady I've got them from here in the past http://www.osoa.org/xmlns/sca/1.0/. There seem to have been recent updates judging by the dates. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SCA Native] java implementation and interface schema files loaded but not used
That's a good point I hadn't considered. I think we should definitely keep these schemas in then, since without them it will probably fail to load. There should be no problem at all to load but ignore. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 9:33 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] java implementation and interface schema files loaded but not used Brady Johnson wrote: Does anyone have any insight into why these files are loaded but never used in TuscanySCA Native: TuscanySCA Root dir/xsd/ sca-implementation-java.xsd sca-interface-java.xsd I created a JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1513 Their existence in the project is misleading and implies that TuscanySCA Native supports Java services. Perhaps these should be removed in M4. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Will you be able to load (and ignore without breaking) a composite containing implementation.java and interface.java elements? I'm thinking about scenarios where people share a composite between the two runtimes, with part of it running on the Native runtime and part running on the Java runtime. I guess I'll have the same question for the Java project, we should be able to ignore (or just handle with a warning) implementation.cpp and interface.cpp in the Java runtime. -- Jean-Sebastien - 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: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Jean-Sebastien Delfino wrote: Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. Thanks, this helps me to understand the scenarios. I was thinking in terms of service and reference names, which would not be exposed (like the current $self$. and $promoted$. names that the runtime uses). The issue is when the service or reference name is used to form the externally visible URI for the callback endpoint. If we want to do something in the spec group to address this, I think the best thing to do would be to add a rule to the spec for how a URI should be constructed for the endpoint that represents a callback reference. This needs to be done in a way that won't collide with URIs for SCDL services on the same component. One way to ensure that the endpoint names don't collide is to say (as you have proposed): 1. The name of the callback endpoint is derived from the SCDL reference name using the same algorithm that is currently used for services. 2. Reference and service names must never be the same. Another way to ensure that the endpoint names don't collide is to say: 1. The name of the callback endpoint is derived from the SCDL reference name using a different algorithm than the one that is currently used for services. For example, it could be something like componentname/referencename-callback My preference would be for something like this because it makes it very easy to see which URIs are for callbacks and which are for real services. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] java implementation and interface schema files loaded but not used
Brady Johnson wrote: Does anyone have any insight into why these files are loaded but never used in TuscanySCA Native: TuscanySCA Root dir/xsd/ sca-implementation-java.xsd sca-interface-java.xsd I created a JIRA for this: https://issues.apache.org/jira/browse/TUSCANY-1513 Their existence in the project is misleading and implies that TuscanySCA Native supports Java services. Perhaps these should be removed in M4. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Will you be able to load (and ignore without breaking) a composite containing implementation.java and interface.java elements? I'm thinking about scenarios where people share a composite between the two runtimes, with part of it running on the Native runtime and part running on the Java runtime. I guess I'll have the same question for the Java project, we should be able to ignore (or just handle with a warning) implementation.cpp and interface.cpp in the Java runtime. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
ant elder wrote: I guess early the following week still leaves time for an August release. It will be real tight though so we'll all need to be quick and thorough with our RC reviews as one problem once we get to the IPMC voting and it could easily slip it into September. So does taking the branch on the 21st sound ok to everyone? ...ant +1 as of today, assuming that I get everything I want in before the 21. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intent and Policy attachments on Operations
Venkata Krishnan wrote: Sebastien, thanks for responding. I am still not convinced about Intent instances having links to things in the assembly model. I perceive the Policy module to be independent of any other SCA module (assembly, or interface, ... ). I just responded to some of these in a response to Ant's email in the same thread. I think I covered your questions there. All of this can probably be summarized as: If you're not convinced that Intent should point to interface/operation, try to draw a parallel with how service/reference point to interface. or An intent configures a particular use of an interface/operation (so it should point to that operation...) Also when we are resovling or building the composites, it seems a bit odd to me to go after a PolicyRegistry and get the bunch of all Intents defined for a domain and then run thro each to find the operations that use it. Also I see that there are other decorations as well to the Operation that exists today - one of which is the databinding. So, why wouldn't intents and policy sets simply add on. Because Databindings should not be doing this in the first place :) However if you say that we share instances of Operations across interface definitions, then we probably need to store this map in the InterfaceDef.. or if the InterfaceDef instances are shared then we have look at the next higher level thing that is not shared to manage this information. Am I missing some point here ? - Venkat The models are currently using lists and I'd suggest to continue on the same path. If you really wanted to switch the relationship around, I think you'd have to come up with a new model object containing pointers to interface, operation, and the list of intents that apply to it. Then try to give a meaningful name to that object, if you can't find a good name for it, maybe that's because it's just too artificial and does not represent a real entity in the model but instead a disguised relationship? ... which is simply represented at the moment as an Intent - Operation pointer I'll let you think about it :) On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat The Intent - operations relationship was modeled like this intentionally. Here's why: If you're talking about o.a.t.interfacedef.Operation, then I don't think it can hold intents. Operation represents a business method/operation on a business interface, potentially used in multiple Services or References... with different sets of intents. The operation element in SCA assembly XML does not represent the actual operation on the business interface, it is just the syntax used to group the intents that apply to a given operation, within the context of a particular service or reference. So basically we need to represent the association: a set of intents - a set of operations in the context of a particular service/reference There's basically two ways to represent this: a) In an intent, list the business operations that the intent applies to or b) Invent a new object representing an operation used within the context of a reference/service, pointing to the actual operation + listing the intents The assembly model being a logical model it does not have to follow the convolutions of the particular XML syntax, and it seems to me that (a) is more logical than (b). At least it'll allow us to easily find which operations a particular intent (and the corresponding interceptors) applies to. Hope this helps. -- Jean-Sebastien -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intent and Policy attachments on Operations
ant elder wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat The Intent - operations relationship was modeled like this intentionally. Here's why: If you're talking about o.a.t.interfacedef.Operation, then I don't think it can hold intents. Operation represents a business method/operation on a business interface, potentially used in multiple Services or References... with different sets of intents. The operation element in SCA assembly XML does not represent the actual operation on the business interface, it is just the syntax used to group the intents that apply to a given operation, within the context of a particular service or reference. So basically we need to represent the association: a set of intents - a set of operations in the context of a particular service/reference There's basically two ways to represent this: a) In an intent, list the business operations that the intent applies to or b) Invent a new object representing an operation used within the context of a reference/service, pointing to the actual operation + listing the intents The assembly model being a logical model it does not have to follow the convolutions of the particular XML syntax, and it seems to me that (a) is more logical than (b). At least it'll allow us to easily find which operations a particular intent (and the corresponding interceptors) applies to. Hope this helps. -- Jean-Sebastien I'm not sure i follow this (though i've barely skimmed over the policy specs so thats no surprise) From those (a) and (b) above why is (a) more logical? I'd have thought you'd be more likely to be processing a particular Operation instance and be interested in what intents apply to it, and less interested in finding all the operations in a system that use a particular intent. The bit about an Operation instance potentially being used in multiple Services or References with different intents is interesting. Are Operations really shared like this? I've not checked all the code but don't we copy/clone Operations specifically so that doesn't happen? The data binding is also attached to the Operation and that can be different for each Service / Reference so that would also be be a problem if the Operations are shared. ...ant Here's a few more thoughts. First with respect to interface/operation sharing: - Interfaces are shared by multiple services/references (i.e. two services can share the same Java interface and therefore the same JavaInterface model object) - Operations belong to interfaces so they are shared as well - Similarly (to help illustrate my point), implementations are shared by multiple components The code which has recently been checked in, which starts to tie intents to an interface will break as soon as two services use the same interface with different polices. Now what's the most logical way to represent policies? - My understanding is that policies are used to express configuration of services, references and implementations. They are similar to service/reference bindings (which configure protocols used to talk to an interface), or component declarations (which configure properties of an implementation). They configure the QOS to use when to talk through an interface or to a component implementation. How are we representing service/reference bindings and components today? - Services/references (+ the binding they contain) logically point to interfaces, the service/reference effectively do, the binding does not need to do it explicitly and duplicate that relationship because it's contained in a service/reference - Component declarations point to implementations Following the same pattern... - Intents and policysets should point to interfaces, like a binding an intent does not need to point explicitly point to the interface because it's known from the service/reference that contains it, but it needs to distinguish which operation it applies to. If you're still not convinced or have a better way to represent the intent - operation relationship, maybe you should try for yourself and come up with a set of model interfaces that
Re: [jira] Commented: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/10/07, Simon Nash [EMAIL PROTECTED] wrote: What happens if you change the example a little bit to: component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.port(MultiplySoapPort)/ /service /component I believe this is valid according to the spec. Does it work? Simon gengshaoguang (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518963 ] gengshaoguang commented on TUSCANY-1526: I read SCA_WebServiceBinding_V100 again, I think there might miss some restrictions againse cross reference like you mentioned here. I agree with you. For the time being, we need to document it as a poor practise. Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Having looked back at the spec I think both of these exampled should be valid. I.e that the tuscany runtime should be able to workout what the endpoint uri is based on the SCDL wiring. Does anyone have examples of bindings that are explicitly not wireable in which case an error would be validly produced? Simon Sorry I'm having trouble understanding this. What's a non-wireable binding? My understanding of the spec is: - references can be wired - they can use whatever binding they want - bindings on both ends of a wire must match I'm probably missing something but the initial snippet in TUSCANY-1526 looks valid to me and should work. If it doesn't it's a bug, which needs to be fixed. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The wireable binding is something that appears in the code. I don't know what it's for but the sca binding implements the interface and the web service binding doesn't. Looking at the spec we are agreeing that these cases should work so I'll close this JIRA and open a new one against the fault (once I've got my build back to the
Re: [jira] Commented: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
Simon Laws wrote: On 8/10/07, Simon Nash [EMAIL PROTECTED] wrote: What happens if you change the example a little bit to: component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.port(MultiplySoapPort)/ /service /component I believe this is valid according to the spec. Does it work? Simon gengshaoguang (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518963] gengshaoguang commented on TUSCANY-1526: I read SCA_WebServiceBinding_V100 again, I think there might miss some restrictions againse cross reference like you mentioned here. I agree with you. For the time being, we need to document it as a poor practise. Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Having looked back at the spec I think both of these exampled should be valid. I.e that the tuscany runtime should be able to workout what the endpoint uri is based on the SCDL wiring. Does anyone have examples of bindings that are explicitly not wireable in which case an error would be validly produced? Simon Sorry I'm having trouble understanding this. What's a non-wireable binding? My understanding of the spec is: - references can be wired - they can use whatever binding they want - bindings on both ends of a wire must match I'm probably missing something but the initial snippet in TUSCANY-1526 looks valid to me and should work. If it doesn't it's a bug, which needs to be fixed. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
Hi Pete, Yes I agree, SDO.h should only have public APIs. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 2:04 AM To: tuscany-dev@ws.apache.org Subject: Re: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API Another great patch! Thanks! Should SDO.h only include headers for the public (i.e. spec) APIs? I think it should so things like DASValue.h should be removed. Anyone who wants to utilize the internal APIs should have to know they are doing it! What do you think? Cheers, On 10/08/07, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I have uploaded a patch for TUSCANY-1375. If it could be reviewed and applied that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 9:16 PM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API [ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian. ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: TUSCANY-1375.txt This patch privatizes the internal helper classes used in SDO for processing XML Schema, and removes their use from SCA. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec C++ classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] -- Pete - 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: Accessing global domain information
Simon Laws wrote:
On 8/10/07, Raymond Feng [EMAIL PROTECTED] wrote:
Comments inline.
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, August 09, 2007 3:46 PM
Subject: Re: Accessing global domain information
On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote:
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
I need some advice on the way the code is structures. In various
places in
the code I need to get at some information that logically belongs
to
the sca
domain. For example,
CompositeWireBuilderImpl.connectComponentReferences()
Tries to resolve services. In the distributed case this resolution
may
validly fail and I need to ask the domain whether the service is
available
elsewhere. So I need access to some domain management services.
Ideally I
would like to have access to a domain interface but am unsure how
to
plumb
it in as this kind of thing isn't generally available now. Anyone
care
to
offer some advice how I get at such an interface without breaking
the
SPIs?
Thanks
Simon
WireCompositeBuilderImpl is not an SPI, so you can pass whatever you
want to its constructor without breaking any SPI.
But I have a preliminary question: Why do you need to ask the domain
(management service) about remote services at that specific point in
WireCompositeBuilderImpl?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
I was thinking about this on the drive home. Just looking back at the
code
I had missed the important point that a reference target remains
unresolved
if the target component cannot be found. I could use this instead of
the
actual service lookup at this point. The issue I have though is that
the
CompositeWireBuilder dumps the bindings from the reference if it can't
find
a matching service/binding. This will be the case if the model for the
references service/binding is not read into the model for the current
node,
i.e. if the target component is not included in the current nodes
contributions.
Is it valid to only replace the current bindings with
selectedBindings
if some selected bindings have actually be found?
Simon
Have been looking into this a little more and it seems that the list of
matched bindings takes into account the reference multiplicities and
then
is
used during activation to create the runtime wires so we do have to be a
little cleverer in terms of creating a dummy resolved target to keep the
bindings in play.
Let's assume the reference is wired to a remote SCA service for this
discussion. For non-SCA services, it's simpler as we just have to pick a
binding locally for the reference and the binding URI will be good enough
for the routing.
There are two factors here:
1) What information is required from the service side for the reference
side
to choose the right binding?
service: {service uri in the domain, a list of bindings} (I intentionally
skip the intent/policy stuff here). The key is that should be able to
build
a call routing to this service endpoint.
2) When should we try to do the matching between the reference and the
service?
In some cases, the remote service information is not available when the
runtime wires are constructed. It means we have to defer the process when
the reference is used.
Anyone out there intimately familiar with the resolution process? What I
want to be able to do is have an sca binding (or any other binding for
that
matter) remain in place even in the case where the referenced target is
not
available in the local domain composite. Come runtime wire generation
time
the binding itself can take responsibility for creating the correct
providers and invokers so that, assuming the referenced service is
remoteable, the request can be routed to the correct node.
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks Raymond, I'm with you there. I'm not sure whether you are agreeing
or disagreeing that maintaining the list of unresolved targets will be
problematic. I'm going ahead on the basis that we need to maintain the list,
i.e. I'll change
if (!targets.isEmpty() ) {
// Add all the effective bindings
to
if (!targets.isEmpty()
!selectedBindings.isEmpty()) {
// Add all the effective bindings
at the bottom of
Re: [jira] Commented: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
See below. Simon Simon Laws wrote: On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/10/07, Simon Nash [EMAIL PROTECTED] wrote: What happens if you change the example a little bit to: component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.port(MultiplySoapPort)/ /service /component I believe this is valid according to the spec. Does it work? Simon gengshaoguang (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518963 ] gengshaoguang commented on TUSCANY-1526: I read SCA_WebServiceBinding_V100 again, I think there might miss some restrictions againse cross reference like you mentioned here. I agree with you. For the time being, we need to document it as a poor practise. Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class= calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement= http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Having looked back at the spec I think both of these exampled should be valid. I.e that the tuscany runtime should be able to workout what the endpoint uri is based on the SCDL wiring. Does anyone have examples of bindings that are explicitly not wireable in which case an error would be validly produced? Simon Sorry I'm having trouble understanding this. What's a non-wireable binding? My understanding of the spec is: - references can be wired - they can use whatever binding they want - bindings on both ends of a wire must match I'm probably missing something but the initial snippet in TUSCANY-1526 looks valid to me and should work. If it doesn't it's a bug, which needs to be fixed. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The wireable binding is something that appears in the code. I don't know what it's for but the sca binding implements the interface and the web service binding doesn't. Looking at the spec we are agreeing that these cases should work so I'll close this JIRA and open a new one against the fault (once I've got my build back to the stage where I can try it again). But It would be useful to get an explanation of what the org.apache.tuscany.sca.assembly.WireableBindingis and under what
[jira] Created: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible
Tuscany SDO native for windows is not msvc backwards compatible Key: TUSCANY-1529 URL: https://issues.apache.org/jira/browse/TUSCANY-1529 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Environment: MSVC 8.0 and 7.1 Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next I've been trying to compile Tuscany on platforms other than VSExpress (which is msvc 8.0) and Linux. I came across something that doesn't compile on msvc7.1 in SDODate.cpp. The problem is the definition of localtime for windows. Its #define'd as localtime_s for windows. A simple check for compiler version would allow it to be defined for msvc 8.0 and anything previous, as follows: #ifndef tuscany_localtime_r #if defined(WIN32) || defined (_WINDOWS) #if _MSC_VER 1400 // _MSC_VER: 1400 is msvc 8.0, so anything less is pre 8.0 #define tuscany_localtime_r(value, ignore) localtime(value); #else #define tuscany_localtime_r(value, tmp_tm) localtime_s(tmp_tm, value); #endif #else #define tuscany_localtime_r(value, tmp_tm) localtime_r(value, tmp_tm); #endif #endif // tuscany_localtime_r Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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: Cross-jvm locate service
Kevin Williams wrote: Sebastien and Simon, Thanks for this conversation. Its been very helpful. I would like to recap a little and ask a couple of questions. At the highest level the steps to locate a service are: 1. Look locally and if found proceed as Tuscany does today, otherwise 2. Dynamically create a reference for the target service using binding and end-point URI info 3. Create a CallableReference for that self-reference 4. Get a ServiceReference proxy to the service from the CallableReference 5. Return the ServiceReference Yes For an example of how to dynamically create a reference(2) you mentioned: CompositeConfigurationBuilderImpl.createSelfReference() and I assume you meant CompositeBuilderImpl.createSelfReference(Component, ComponentService), right? I meant CompositeConfigurationBuilderImpl, as I have refactored CompositeBuilderImpl in trunk earlier this week :) Since I won't have a ComponentService available I will need to somehow provide the required binding and InterfaceContract information. I think there are factories for these. Can you point me to code that creates a CallableReference from a ComponentReference (3) ? org.apache.tuscany.sca.implementation.java.invocation.JavaComponentInfo.getServiceReference() does that. the interesting part is: ObjectFactoryB factory = createWireFactory(type, wire); return new ServiceReferenceImplB(type, factory); type is a business interface I'm afraid that ObjectFactory will always remain a mistery to me, starting with the class name... this looks like a Factory for Objects, what does that tell me exactly? :) so I hope that someone else on the list mastering the art of ObjectFactory can jump in and help here :) Thanks! --Kevin On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. [snip] Simon Laws wrote: Currently getServiceReference() expects a service name so we can rely on the implication that all contributed composites are notionally included into the domain level composite to reference a component and extend Sebastien's process to say. Just to make sure it's clear, as I'm not sure I completely follow the above sentence, components deployed to other nodes will not be present in the in-memory composite model kept in an SCAdomain object. I was just pointing out that regardless of where a component is actually running one of it's services can be identified in the domain composite using the component/service name by virtue of the implicit inclusion of contributed composites into the domain composite. This is an important assumption as it means that people can arbitrarily locate services deployed into the domain. I was making no statement about what is in the model inside each JVM. I assume that the model in each JVM will contain whatever artifacts that have been contributed to that JVM. So if you have different contributions for each JVM in the domain then you get whatever is contributed to the JVM in your model. If you want to reference a component that is not part of the contributions loaded by the JVM then you are forced to look elsewhere in the distributed domain. If you want the components in a single contribution/composite to be distributed across JVMs then this is a different scenario. We have done this before with the distributed runtime by recording the component/JVM mapping in a topology file. This still doesn't imply that the components will make it into the model (although they do in the current distributed implementation). 1. look for the target component model object in the in-memory domain composite kept in SCADomain if found 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference else 2. look for the named component/serivce in other nodes of the distributed (cross JVM) domain I am working up some interfaces to allow this to happen in the distributed domain case, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java Not implemented just yet as I'm currently looking at the sca domain implementation but you get the idea. The implementation could use some simple repository implementation or could derive the information from file. 3. Create a local reference for the remote service Your if/else proposal looks good to me. Not sure of the details here but you both seem happy that this is straightforward. The thing that does look problematic
[jira] Updated: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
[
https://issues.apache.org/jira/browse/TUSCANY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bert.robben updated TUSCANY-1527:
-
Attachment: com.zip
These is the source of the important classes of our sdo extension dealing with
UI binding.
Allow for custom data binding of DataObjects in a Swing UI
--
Key: TUSCANY-1527
URL: https://issues.apache.org/jira/browse/TUSCANY-1527
Project: Tuscany
Issue Type: New Feature
Reporter: bert.robben
Attachments: com.zip
We're developing 3-tier applications with a swing client, JBoss app server
and a couple of databases in the back-end. On the client side we use sdo
objects as model objects for our UI. As such, we need a mechanism for binding
our objects to the UI controls such that changes in the objects are reflected
in the UI and vice versa.
At the moment, there is no real standard for data binding and many different
implementations exist. As such, it would not be a good idea to build support
for this directly into the sdo core. Ideally, the sdo core would allow
implementations supporting data binding to be added as extensions [an
extension as in jar, module, bundle, component, ...]. This is a request for
supporting this in Tuscany SDO.
-
For our applications, we developed our own implementation of the sdo
specification. This implementation is designed to support that kind of
extensions. In the rest of this description, I'd like to show more details on
our implementation to make this more clear and to serve as food for a
possible discussion.
Our sdo core module defines the abstract class AbstractPartialDataObject
implementing DataObject. This class (together with its superclasses)
implements the majority of the bevahiour of DataObject. This includes
bi-directional property updates, type-safe properties, containment, ... It
doesn't implement however the basic access to property values.
Here's a code fragment.
public abstract class AbstractPartialDataObject extends AbstractDataObject
implements PartialDataObject {
protected abstract Object basicGet(Property property);
protected abstract void basicSet(Property property, Object value);
public Object get(Property property) { ... }
public void set(Property property, Object value) { ... }
...
}
The sdo core module also provides a non-abstract class
DataObjectImplementation that provides a simple implementation of this
abstract behaviour where the property values are stored in an ArrayList.
On top of that we defined an extension that deals with our UI requirements.
Our UI is based on a proprietary UI framework. This framework has the
following requirements:
- single valued properties should be exposed as XObservables. An XObservable
is a kind of ValueModel that provides access to a value (get/set) and also
allows for registration of change listeners
- multi valued properties should be exposed as ListModel instances. A
ListModel is a proprietary class (a bit similar to the javax.swing.ListModel)
that provides List functionality and also allows for change listeners
- the data object itself should allow registration of attribute change
listeners that are notified each time a property changes
The extension implements these requirements by providing an appropriate
subclass ObservableDataObject of AbstractPartialDataObject. The only other
pieces of code needed in the extension is an appropriate implementation of
DataFactory and a wrapper to deal with the differences between ListModel and
List.
Here's the class with the most important code snippets.
public class ObservableDataObject extends CompositePartialDataObject
implements {
private XObservable[] properties;
protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
super(type);
this.properties = new XObservable[type.getProperties().size()];
for (int i = 0; i properties.length; i++) {
initializeProperty(type.getProperty(i));
}
}
private XObservableObject initializeProperty(Property prop) {
XObservableObject observable =
XObservableFactory.create(prop.getType().getInstanceClass(), this);
if (prop.isMany()) {
observable.init(new DataObjectListModel(this, prop));
}
properties[prop.getIndex()] = observable;
return observable;
}
public XObservable getObservable(commonj.sdo.Property property) {
XObservable result = properties[property.getIndex()];
return result;
}
public ListModel getListModel(Property property) {
return (ListModel) getObservable(property).get();
}
public ListModel getListModel(String
[jira] Created: (TUSCANY-1527) Allow for custom data binding of DataObjects in a Swing UI
Allow for custom data binding of DataObjects in a Swing UI
--
Key: TUSCANY-1527
URL: https://issues.apache.org/jira/browse/TUSCANY-1527
Project: Tuscany
Issue Type: New Feature
Reporter: bert.robben
We're developing 3-tier applications with a swing client, JBoss app server and
a couple of databases in the back-end. On the client side we use sdo objects as
model objects for our UI. As such, we need a mechanism for binding our objects
to the UI controls such that changes in the objects are reflected in the UI and
vice versa.
At the moment, there is no real standard for data binding and many different
implementations exist. As such, it would not be a good idea to build support
for this directly into the sdo core. Ideally, the sdo core would allow
implementations supporting data binding to be added as extensions [an extension
as in jar, module, bundle, component, ...]. This is a request for supporting
this in Tuscany SDO.
-
For our applications, we developed our own implementation of the sdo
specification. This implementation is designed to support that kind of
extensions. In the rest of this description, I'd like to show more details on
our implementation to make this more clear and to serve as food for a possible
discussion.
Our sdo core module defines the abstract class AbstractPartialDataObject
implementing DataObject. This class (together with its superclasses) implements
the majority of the bevahiour of DataObject. This includes bi-directional
property updates, type-safe properties, containment, ... It doesn't implement
however the basic access to property values.
Here's a code fragment.
public abstract class AbstractPartialDataObject extends AbstractDataObject
implements PartialDataObject {
protected abstract Object basicGet(Property property);
protected abstract void basicSet(Property property, Object value);
public Object get(Property property) { ... }
public void set(Property property, Object value) { ... }
...
}
The sdo core module also provides a non-abstract class DataObjectImplementation
that provides a simple implementation of this abstract behaviour where the
property values are stored in an ArrayList.
On top of that we defined an extension that deals with our UI requirements. Our
UI is based on a proprietary UI framework. This framework has the following
requirements:
- single valued properties should be exposed as XObservables. An XObservable is
a kind of ValueModel that provides access to a value (get/set) and also allows
for registration of change listeners
- multi valued properties should be exposed as ListModel instances. A ListModel
is a proprietary class (a bit similar to the javax.swing.ListModel) that
provides List functionality and also allows for change listeners
- the data object itself should allow registration of attribute change
listeners that are notified each time a property changes
The extension implements these requirements by providing an appropriate
subclass ObservableDataObject of AbstractPartialDataObject. The only other
pieces of code needed in the extension is an appropriate implementation of
DataFactory and a wrapper to deal with the differences between ListModel and
List.
Here's the class with the most important code snippets.
public class ObservableDataObject extends CompositePartialDataObject implements
{
private XObservable[] properties;
protected ObservableDataObject(com.agfa.hap.sdo.Type type) {
super(type);
this.properties = new XObservable[type.getProperties().size()];
for (int i = 0; i properties.length; i++) {
initializeProperty(type.getProperty(i));
}
}
private XObservableObject initializeProperty(Property prop) {
XObservableObject observable =
XObservableFactory.create(prop.getType().getInstanceClass(), this);
if (prop.isMany()) {
observable.init(new DataObjectListModel(this, prop));
}
properties[prop.getIndex()] = observable;
return observable;
}
public XObservable getObservable(commonj.sdo.Property property) {
XObservable result = properties[property.getIndex()];
return result;
}
public ListModel getListModel(Property property) {
return (ListModel) getObservable(property).get();
}
public ListModel getListModel(String property) {
return (ListModel) getObservable(type.getProperty(property)).get();
}
@Override
public List getList(Property property) {
return ((DataObjectListModel) getObservable(property).get()).asList();
}
@Override
protected Object basicGet(Property property) {
Object result = properties[property.getIndex()].get();
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
See inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. Thanks, this helps me to understand the scenarios. I was thinking in terms of service and reference names, which would not be exposed (like the current $self$. and $promoted$. names that the runtime uses). The issue is when the service or reference name is used to form the externally visible URI for the callback endpoint. If we want to do something in the spec group to address this, I think the best thing to do would be to add a rule to the spec for how a URI should be constructed for the endpoint that represents a callback reference. This needs to be done in a way that won't collide with URIs for SCDL services on the same component. One way to ensure that the endpoint names don't collide is to say (as you have proposed): 1. The name of the callback endpoint is derived from the SCDL reference name using the same algorithm that is currently used for services. 2. Reference and service names must never be the same. Another way to ensure that the endpoint names don't collide is to say: 1. The name of the callback endpoint is derived from the SCDL reference name using a different algorithm than the one that is currently used for services. For example, it could be something like componentname/referencename-callback My preference would be for something like this because it makes it very easy to see which URIs are for callbacks and which are for real services. Simon Will that work? component name=foo service name=bar/ -- this one has a callback reference name=bar-callback /component On the service side there is no problem, as no external endpoint URI is created for the pseudo-reference, and I am not proposing that we change the internal Tuscany model names from the $callback$. scheme. The case that would have a problem is on the reference side: component name=foo service name=bar-callback/ reference name=bar -- this one has a callback /component I was only using the -callback suffix is as an example to get the discussion started. If we are trying to ensure guaranteed uniqueness in all cases, then we need a different separator from - that isn't legal for service names but is legal for URIs. What about using /? The above example would then translate to: base-uri/foo/bar-callback -- the real SCDL service base-uri/foo/bar/callback -- the callback pseudo-service As long as there is no possibility of having a SCDL service named bar/callback then this will not break. If I understood what you proposed correctly, the service's callback and the reference will end up with the same URI. I really don't know what kind of convention we could use here. Can anyone think of an automatic naming convention that won't break and will still be obvious to the app developer? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1514) DataHelperImpl.toDate will report a NullPointerException
[ https://issues.apache.org/jira/browse/TUSCANY-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519022 ] Fuhwei Lwo commented on TUSCANY-1514: - I have made a minor fix on DataHelperImpl.toDate(String dateString) to check on the null dateString but this fix only prevents you from getting a NPE from SDO. DataHelperImpl.toDate will report a NullPointerException - Key: TUSCANY-1514 URL: https://issues.apache.org/jira/browse/TUSCANY-1514 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-SDO-beta1 Reporter: Leo Li Fix For: Java-DAS-beta1 Hi All , when I read the data from a table , there is a Datetime field in the table , if the datetime field'value is null , the SDO will produce a NullPointException , Maybe this is a bug , and How to fixed it ? Exception content as follow : 12:02:21,015 [main] ERROR [DasService] java.lang.NullPointerException at org.apache.tuscany.sdo.helper.DataHelperImpl.toDate(DataHelperImpl.java:48) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createDateFromString(Mode lFactoryImpl.java:1931) at org.apache.tuscany.sdo.model.impl.ModelFactoryImpl.createFromString(ModelFac toryImpl.java:224) at org.apache.tuscany.sdo.impl.FactoryBase$SDOEFactoryImpl.createFromString(Fac toryBase.java:270) at org.eclipse.emf.ecore.util.EcoreUtil.createFromString(EcoreUtil.java:2982) at org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.getValue(FeatureChangeIm pl.java:428) at org.apache.tuscany.sdo.impl.ChangeSummarySettingImpl.getValue(ChangeSummaryS ettingImpl.java:89) at org.apache.tuscany.das.rdb.util.DataObjectUtil.restoreAttributeValues(DataOb jectUtil.java:74) at org.apache.tuscany.das.rdb.util.DataObjectUtil.getRestoredCopy(DataObjectUti l.java:41) at org.apache.tuscany.das.rdb.impl.DeleteOperation.init(DeleteOperation.java: 34) at org.apache.tuscany.das.rdb.impl.ChangeFactory.createDeleteOperation(ChangeFa ctory.java:77) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange(ChangeSummariz er.java:103) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges(ChangeSummarize r.java:80) at org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute(ApplyChanges CommandImpl.java:64) at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java:310) -- 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: mvn eclipse:eclipse fails on java
On 8/10/07, Ole Ersoy [EMAIL PROTECTED] wrote:
I also tried looking for this manually:
org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT
Here's what I find in the repository under:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/
[DIR] tuscany-binding-notification/27-Jul-2007
22:06-
[DIR] tuscany-binding-rmi/ 23-May-2007
15:32-
[DIR] tuscany-binding-sca/ 27-Jul-2007
17:17-
[DIR] tuscany-binding-ws-axis2/23-May-2007
15:35-
[DIR] tuscany-binding-ws-xml/
Should there be a directory corresponding to the groupid:
tuscany-binding-sca-xml
Here?
Thanks,
- Ole
Luciano Resende wrote:
What version of maven are you using ? Does it work with maven 2.0.5 ?
See more info here [1]
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html
On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote:
Hi,
I tried checking out java and eclipseefying the build, but I get this
error:
1 required artifact is missing.
for artifact:
org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT
Thoughts?
Thanks,
- Ole
-
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]
Hi Ole
The one you see missing is a relatively new module. Went in Wednesday
morning and hasn't made it out as a snapshot yet. From what you say I'm
assuming you have the source tree checked out of svn. Can you try building
that module before you run the eclipse generation?
Having said that I just knocked it out of my local repo and the eclipse
generation ran fine. This is what I see for the project in question.
[INFO]
-
---
[INFO] Building Apache Tuscany Dojo Sample WebApp
[INFO]task-segment: [eclipse:eclipse]
[INFO]
-
---
[INFO] Preparing eclipse:eclipse
Downloading:
http://people.apache.org/repo/m2-incubating-repository/wsdl4j/wsdl4
j/1.6.2/wsdl4j-1.6.2.pom
[WARNING] Unable to get resource 'wsdl4j:wsdl4j:pom:1.6.2' from repository
apach
e.incubator (http://people.apache.org/repo/m2-incubating-repository)
Downloading:
http://repo1.maven.org/maven2/wsdl4j/wsdl4j/1.6.2/wsdl4j-1.6.2.pom
[WARNING] Unable to get resource 'wsdl4j:wsdl4j:pom:1.6.2' from repository
centr
al (http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: install-dojo}]
[INFO] Executing tasks
check-dojo-installed:
install-dojo:
[INFO] Executed tasks
[INFO] [antrun:run {execution: copy-dojo-files}]
[INFO] Executing tasks
check-dojo-installed:
check-dojo-unpacked:
unpack-dojo-files:
[mkdir] Created dir:
C:\simon\tuscany\java-head\sca\samples\helloworld-dojo\
target\dojo-unpack-temp
[unzip] Expanding: C:\Documents and
Settings\slaws\.m2\repository\dojo\dojo-
ajax\0.4.0\dojo-ajax-0.4.0.zip into
C:\simon\tuscany\java-head\sca\samples\hello
world-dojo\target\dojo-unpack-temp
[move] Attempting to rename dir:
C:\simon\tuscany\java-head\sca\samples\hel
loworld-dojo\target\dojo-unpack-temp\dojo-0.4.0-ajax to
C:\simon\tuscany\java-he
ad\sca\samples\helloworld-dojo\src\main\webapp\dojo
[delete] Deleting directory
C:\simon\tuscany\java-head\sca\samples\helloworld
-dojo\target\dojo-unpack-temp
[INFO] Executed tasks
[INFO] [eclipse:eclipse]
[INFO] Using source status cache:
C:\simon\tuscany\java-head\sca\samples\hellowo
rld-dojo\target\mvn-eclipse-cache.properties
[INFO] Not writing settings - defaults suffice
[INFO] Creating maven-eclipse.xml Ant file to handle resources
[INFO] Creating external launcher file
[INFO] File C:\simon\tuscany\java-head\sca\samples\helloworld-dojo\.project
alre
ady exists.
Additional settings will be preserved, run mvn eclipse:clean if you
want
old settings to be removed.
[INFO] Wrote Eclipse project for sample-helloworld-dojo to
C:\simon\tuscany\ja
va-head\sca\samples\helloworld-dojo.
[INFO]
Sources for some artifacts are not available.
Please run the same goal with the -DdownloadSources=true parameter in
ord
er to check remote repositories for sources.
List of artifacts without a source archive:
o org.codehaus.woodstox:wstx-asl:3.2.1
o
org.apache.tuscany.sca:tuscany-assembly-xml:1.0-incubating-SNAPSHOT
o
org.apache.tuscany.sca:tuscany-interface-java:1.0-incubating-SNAPSHOT
o wsdl4j:wsdl4j:1.6.2
o org.apache.tuscany.sca:tuscany-core:1.0-incubating-SNAPSHOT
o
org.apache.tuscany.sca:tuscany-host-webapp:1.0-incubating-SNAPSHOT
o junit:junit:4.2
o
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. Thanks, this helps me to understand the scenarios. I was thinking in terms of service and reference names, which would not be exposed (like the current $self$. and $promoted$. names that the runtime uses). The issue is when the service or reference name is used to form the externally visible URI for the callback endpoint. If we want to do something in the spec group to address this, I think the best thing to do would be to add a rule to the spec for how a URI should be constructed for the endpoint that represents a callback reference. This needs to be done in a way that won't collide with URIs for SCDL services on the same component. One way to ensure that the endpoint names don't collide is to say (as you have proposed): 1. The name of the callback endpoint is derived from the SCDL reference name using the same algorithm that is currently used for services. 2. Reference and service names must never be the same. Another way to ensure that the endpoint names don't collide is to say: 1. The name of the callback endpoint is derived from the SCDL reference name using a different algorithm than the one that is currently used for services. For example, it could be something like componentname/referencename-callback My preference would be for something like this because it makes it very easy to see which URIs are for callbacks and which are for real services. Simon Will that work? component name=foo service name=bar/ -- this one has a callback reference name=bar-callback /component On the service side there is no problem, as no external endpoint URI is created for the pseudo-reference, and I am not proposing that we change the internal Tuscany model names from the $callback$. scheme. The case that would have a problem is on the reference side: component name=foo service name=bar-callback/ reference name=bar -- this one has a callback /component I was only using the -callback suffix is as an example to get the discussion started. If we are trying to ensure guaranteed uniqueness in all cases, then we need a different separator from - that isn't legal for service names but is legal for URIs. What about using /? The above example would then translate to: base-uri/foo/bar-callback -- the real SCDL service base-uri/foo/bar/callback -- the callback pseudo-service As long as there is no possibility of having a SCDL service named bar/callback then this will not break. Sure it was an example, and I just gave an example of why it wouldn't work :) But remember, the main reason why I don't like that approach is that I think that make it work we'll need to come up with an ugly naming convention, and place that ugly naming convention in the face of all application developers. foo/bar/callback doesn't work either, if you have a component bar inside a (composite) component foo (as with nested composition you can't really use the component name, you have to use the component URI instead). All interested in this little challenge, please bring your proposals, prove me wrong, come up with a nice convention that works... and I'll be happy to change my position on this :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
What happens if you change the example a little bit to: component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.port(MultiplySoapPort)/ /service /component I believe this is valid according to the spec. Does it work? Simon gengshaoguang (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518963 ] gengshaoguang commented on TUSCANY-1526: I read SCA_WebServiceBinding_V100 again, I think there might miss some restrictions againse cross reference like you mentioned here. I agree with you. For the time being, we need to document it as a poor practise. Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribution URLs
On 8/10/07, Luciano Resende [EMAIL PROTECTED] wrote: I think your current directory, during the execution of the code, will not be mapped to the root of you project, but probably to target/classes or target/test-classes. Could you check that please ? On 8/10/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Simon, Could you please send the exact URL you are passing to the contribution service ? I have added a test case for what I understood your problem is, and that is working fine, but note that in the test case, I'm calling getClass().getResource(/deployables), and that gives me a url like : file://deployables, and that would pass the logic to correct identify a folder. On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano This was the piece of code that was causing me problems... contributionURL = new URL(file:/ + currentDirectory.getCanonicalPath() + /src/main/resources/ + nodeName + /); // Contribute the SCA application Contribution contribution = contributionService.contribute( http://calculator;, contributionURL, resolver, false); Composite composite = contribution.getDeployables().get(0); // Add the deployable composite to the domain domain.getDomainComposite().getIncludes().add(composite); domain.getCompositeBuilder().build(composite); Where the directory structure is. src/ main/ resources/ nodeA/ META-INF/ sca-contribution.xml wsdl mutiply.wsdl calculator.composite And I want to read the contribution from the nodeA directory. Maybe you can spot something from this. But if nothing comes to mind immediately don't worry. I'll check this test in over the next few days and we can look at it directly. Regards Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] currently I'm mapping it to root directory of my project, i.e the directory that holds src. I could map it to test/classes as, of course, maven copies the resources there also. Would that make a difference? Simon
Re: Contribution URLs
I think your current directory, during the execution of the code, will not be mapped to the root of you project, but probably to target/classes or target/test-classes. Could you check that please ? On 8/10/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Simon, Could you please send the exact URL you are passing to the contribution service ? I have added a test case for what I understood your problem is, and that is working fine, but note that in the test case, I'm calling getClass().getResource(/deployables), and that gives me a url like : file://deployables, and that would pass the logic to correct identify a folder. On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano This was the piece of code that was causing me problems... contributionURL = new URL(file:/ + currentDirectory.getCanonicalPath() + /src/main/resources/ + nodeName + /); // Contribute the SCA application Contribution contribution = contributionService.contribute( http://calculator;, contributionURL, resolver, false); Composite composite = contribution.getDeployables().get(0); // Add the deployable composite to the domain domain.getDomainComposite().getIncludes().add(composite); domain.getCompositeBuilder().build(composite); Where the directory structure is. src/ main/ resources/ nodeA/ META-INF/ sca-contribution.xml wsdl mutiply.wsdl calculator.composite And I want to read the contribution from the nodeA directory. Maybe you can spot something from this. But if nothing comes to mind immediately don't worry. I'll check this test in over the next few days and we can look at it directly. Regards Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. -- 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]
XQuery Implementation type for SCA
Hi all, I have provided a prototype for XQuery impelementation type extension for Tuscany. I did this as part of my master thesis and I would like to contribute the sources and the idea to Tuscany if you think this would be useful. Of course it is currently only a prototype and it is not production ready, but if you think that such contribution will be useful for the future of Tuscany I will be glad to help. Some notes about the prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file. Bye, Vasil Vasilev - С бензин в кръвта! http://auto-motor-und-sport.bg/ - Познай победителя във Формула 1 и спечели награда! http://www.clubf1.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support
Hi Amita, I think it can be useful to bunch commands, but I didn't get how you are planning to do it : ( What would be the parameter of method getTransaction? Regards, Adriano Crestani On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below is a simple matrix based on current RDB DAS Config, showing what it does/does not do today managedtx(default-true) - config attribute in ConnectionInfo element to control transactions managedtx database conn. supplied effect on transaction -- 1)true from caller each DAS command undergoes commit/rollback 2)false from within DAS this is not handled in any way 3)true from within DAS each DAS command undergoes commit/rollback 4)false from caller DAS does not issue commit/rollback, external caller manages Case 2) - when database Connection is created in RDB DAS, it does not expose it to caller today. So, in case 2) neither RDB DAS nor caller can manage transactions. From above, it seems that, RDB DAS in general does not provide support to handle a group of Commands under one database transactions. Only case 4) is the place when multiple DAS Commands can undergo as one transaction. To help serve the transaction control better, I would like to propose the following requirements:- [1]RDB DAS should have a way to issue commit/rollback for single/group of Commands [2]When there is exception, the ongoing transaction should be immediately aborted by RDB DAS irrespective of whether it was for single/group of Commands [3]Optional Timeout feature - to have an escape route to end the transaction controlled by RDB DAS, when it seems to linger for time Timeout (to take care of situations like deadlocks). For this, I am thinking of introducing 2 new attributes in RDB DAS Config A) TRANSACTION_DEMARCATION_PER_COMMAND - true/false (mandatory when managedtx=true) B) TRANSACTION_TIMEOUT - millis (always optional) These 2 attributes can be specified at Config level. When case 1) or 3) - both these attributes will take effect. When 2) or 4), these will be ignored. To handle case 2) - here user is required to be given handle to the database Connection, created by RDB DAS (in 1) and 3), this should be prohibited, and in 4) user already has handle of the Connection.) This way, the responsibility of transaction management can be taken by user for 4)(as it is today) and 2)(as now user will get handle) For 1) and 3) - TRANSACTION_DEMARCATION_PER_COMMAND=true is already working in RDB DAS today. For handling TRANSACTION_DEMARCATION_PER_COMMAND=false, new APIs can be given to user like DAS.getTransaction().commit() /rollback() , so in a controlled way, user will be able to bunch group of Commands based on business logic and issue commits/rollbacks. Also, internally, RDB DAS will be responsible to rollback in case of exceptions and in case of Timeouts. Please share your thoughts. Regards, Amita On 6/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I just want to clarify if the below is something missing in DAS or just that I have not understood it clearly. Appreciate your response. At present, DAS has managedtx attribute at ConnectionInfo level(default true). So when true or not specificed, each Command does a database commit. When false, external caller is responsible for managing transaction. There is no way to bunch a set of Commands in one transaction under control of DAS, it is at the mercy of external caller (when managedtx is false). Is it not useful to introduce this in DAS, wherein, when DAS manages transaction, it can have today's behavior (similar to autocommit) or can have a public API which allows client to commit using the connection associated with current DAS instance. This way, when the connection is not passed from client (but created in DAS, using ConnectionInfo and thus not exposed to client), client will have a way to support real transaction (multiple logical bunch of Commands) using DAS? Regards, Amita
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[
https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518948
]
Adriano Crestani commented on TUSCANY-1465:
---
Hi Amita,
1)
Lets exemplify:
{ //user code
List userResultDescriptors = new ArrayList();
userResultDescriptors.add(resultDescriptor1);
userResultDescriptors.add(resultDescriptor2);
readCommand.setResultDescriptor(userResultDescriptors);
userResultDescriptors.add(resultDescriptor3); // [3]
} //user code
On ReadCommandImpl:
public void setResultDescriptor(List resultDescriptor){
//for null/0 list or -1 columnIndex, throw RuntimeException
if(resultDescriptor == null || resultDescriptor.size()==0){
throw new RuntimeException(Can not accept null or empty
ResultDescriptor);
}
for(int i=0; iresultDescriptor.size(); i++){
if(
((ResultDescriptor)resultDescriptor.get(i)).getColumnIndex() = -1 ){
throw new RuntimeException(Need =0 columnIndex
sequencing in ResultDescriptor);
}
}
this.resultDescriptor = resultDescriptor; // [1]
this.resultSetShape = new ResultSetShape(resultDescriptor,
configWrapper.getConfig()); // [2]
}
[1] here the user ResultDescriptor List object is being set as Command
ResultDescriptor List, so when the user add the resultDescriptor3 on [3] the
Command ResultDescriptor List will also be modified.
[2] here the user ResultDescriptor List is being copied on ResultSetShape
constructor when ResultDescriptorSorter.sortList() method is invoked, as
defined on item 2). So, as it is a new copy, when user add the
resultDescriptor3 on the list it will not be updated on ResultSetShape, that
will continue storing info only about the resultDescriptor1 and 2. So, the
readCommandImpl.resultDescriptors and readCommandImpl.resultSetShape will have
different information.
I suggest to copy the user ResultDescriptor List and also its
ResultDescriptors, once the user can externaly alter the ResultDescriptor
object using its setters and it will not be updated on ResultSetShape.
It's just all about the ResultSetShape not being updated when ResultDescriptors
info are modified externaly. If you want to, you may find a way to keep the
ResultSetShape updated, but it all depends on the logic you want to define: if
the user can modify the ResultDescriptor externaly after have set the
ResultDescriptor on a Command or not.
4) Sorry for bothering you with names and patterns issues, but as these methods
will be used by the user, I think we should be cautiously when defining them.
Agreed?
Allow passing ResultDescriptor for dynamic Commands
---
Key: TUSCANY-1465
URL: https://issues.apache.org/jira/browse/TUSCANY-1465
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Fix For: Java-DAS-Next
Attachments: 1465.patch
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html
Action for the issue discussed in above mail.
--
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: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
Another great patch! Thanks! Should SDO.h only include headers for the public (i.e. spec) APIs? I think it should so things like DASValue.h should be removed. Anyone who wants to utilize the internal APIs should have to know they are doing it! What do you think? Cheers, On 10/08/07, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I have uploaded a patch for TUSCANY-1375. If it could be reviewed and applied that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 9:16 PM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API [ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: TUSCANY-1375.txt This patch privatizes the internal helper classes used in SDO for processing XML Schema, and removes their use from SCA. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intent and Policy attachments on Operations
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat The Intent - operations relationship was modeled like this intentionally. Here's why: If you're talking about o.a.t.interfacedef.Operation, then I don't think it can hold intents. Operation represents a business method/operation on a business interface, potentially used in multiple Services or References... with different sets of intents. The operation element in SCA assembly XML does not represent the actual operation on the business interface, it is just the syntax used to group the intents that apply to a given operation, within the context of a particular service or reference. So basically we need to represent the association: a set of intents - a set of operations in the context of a particular service/reference There's basically two ways to represent this: a) In an intent, list the business operations that the intent applies to or b) Invent a new object representing an operation used within the context of a reference/service, pointing to the actual operation + listing the intents The assembly model being a logical model it does not have to follow the convolutions of the particular XML syntax, and it seems to me that (a) is more logical than (b). At least it'll allow us to easily find which operations a particular intent (and the corresponding interceptors) applies to. Hope this helps. -- Jean-Sebastien I'm not sure i follow this (though i've barely skimmed over the policy specs so thats no surprise) From those (a) and (b) above why is (a) more logical? I'd have thought you'd be more likely to be processing a particular Operation instance and be interested in what intents apply to it, and less interested in finding all the operations in a system that use a particular intent. The bit about an Operation instance potentially being used in multiple Services or References with different intents is interesting. Are Operations really shared like this? I've not checked all the code but don't we copy/clone Operations specifically so that doesn't happen? The data binding is also attached to the Operation and that can be different for each Service / Reference so that would also be be a problem if the Operations are shared. ...ant
[jira] Commented: (TUSCANY-1526) Trying to wire a non-wireable binding should fal gracefully
[ https://issues.apache.org/jira/browse/TUSCANY-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518963 ] gengshaoguang commented on TUSCANY-1526: I read SCA_WebServiceBinding_V100 again, I think there might miss some restrictions againse cross reference like you mentioned here. I agree with you. For the time being, we need to document it as a poor practise. Trying to wire a non-wireable binding should fal gracefully --- Key: TUSCANY-1526 URL: https://issues.apache.org/jira/browse/TUSCANY-1526 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Priority: Minor If I do something like component name=CalculatorServiceComponent implementation.java class=calculator.CalculatorServiceImpl/ reference name=addService target=AddServiceComponent / reference name=subtractService target=SubtractServiceComponent / reference name=multiplyService target=MultiplyServiceComponent interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /reference reference name=divideService target=DivideServiceComponent / /component component name=MultiplyServiceComponent implementation.java class=calculator.MultiplyServiceImpl / service interface.java interface=calculator.MultiplyService / binding.ws wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/ /service /component I belive it should tell me that I'm trying to wire the mutiplyService reference up with a binding that is not wireable. Currently it fails in the axis2 binding URL handling code with an NPE. The runtime should just not load the contribution. I guess we could get smarter and introduce a wireable binding but we would be trying to second guess the deployers orignal intention which I don't think is a good idea. -- 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: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845 ] Jean-Sebastien Delfino commented on TUSCANY-1499: - I'd suggest the following to further simplify this: State that a reference with a callback cannot be named like a service State that a service with a callback cannot be named like a reference Take these statements as proposals to the SCA spec workgroup. This will save us from having to implement a complicated naming convention for the derived callback services and callback references, and will save the application developer to have to understand it. I think that this is a reasonable approach for now, as Java components for example will typically name a reference foo and a service Foo, and as another example BPEL components already have this naming limitation as well if I understand BPEL and WSDL correctly. I don't think convenience of the runtime (one particular runtime) should be made visible at the spec level. We should take the spec as is and do what we need to support it. This won't be very difficult. The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. On the other hand, I'm observing that: - 99% of Java components name their services and references differently (actually 100% of the ones I've seen implemented so far) - (unless i'm mistaken about BPEL) 100% of BPEL components will name them differently - and IIRC earlier versions of the SCA assembly spec had this rule as well, at least in composite implementations (before the service/reference promotion mechanism was introduced). So instead of implementing an ugly naming convention (necessarily ugly to avoid naming collisions), and exposing it to application developers... I'd rather go with an acceptable limitation, which may actually make it back to the spec. I'll raise this as as an issue to the SCA assembly spec work group. Define marker interfaces ComponentCallbackService extends ComponentService and ComponentCallbackReference extends Reference to allow code like domain.locateService to filter out these callback services/references and not allow them to be located explicitly. I'd be more inclined to do this using a method isCallback() on the Contract interface from which services and references inherit. +1 Instead of trying to establish callback wires all over the place, which will not fly anyway as soon as 2 references with callback are wired to a single service, flow the endpoint reference of the callback service representing the client in the SCA request message and use it to direct the callback in context as suggested by Raymond in thread [1]. These callback wires are already being established and AFAIK this does work in the case you describe. The callback wire is selected based on the forward wire that was used. I'll write an itest to verify that this is working correctly. Already covered in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
For those struggling to build due to this problem you can use the mvn parameter -Dmaven.test.skip=true so the tests don't get run and the jar still gets built and added to your local repos. ...ant On 8/10/07, ant elder [EMAIL PROTECTED] wrote: Doesn't seem to make any difference. I guess it must be differences between the local repositories as everything else seems to be the same. ...ant On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Build problem in binding-ws-axis2
Thanks for the workaround tip. I'm on maven 2.0.4 as well. Perhaps this is the vital clue as to why some setups fail and others don't. Did you try upgrading from 2.0.4 to 2.0.6 on the machine that failing? Simon ant elder wrote: For those struggling to build due to this problem you can use the mvn parameter -Dmaven.test.skip=true so the tests don't get run and the jar still gets built and added to your local repos. ...ant On 8/10/07, ant elder [EMAIL PROTECTED] wrote: Doesn't seem to make any difference. I guess it must be differences between the local repositories as everything else seems to be the same. ...ant On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XQuery Implementation type for SCA
Hi, Vasil. Welcome to Tuscany and thank you for contributing the XQuery implemention type to Tuscany! Would you please go ahead to create a JIRA and attach the prototype (https://issues.apache.org/jira/browse/TUSCANY) ? We can start from there. Thanks, Raymond - Original Message - From: Vasil Vasilev [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 10, 2007 1:06 PM Subject: XQuery Implementation type for SCA Hi all, I have provided a prototype for XQuery impelementation type extension for Tuscany. I did this as part of my master thesis and I would like to contribute the sources and the idea to Tuscany if you think this would be useful. Of course it is currently only a prototype and it is not production ready, but if you think that such contribution will be useful for the future of Tuscany I will be glad to help. Some notes about the prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file. Bye, Vasil Vasilev - С бензин в кръвта! http://auto-motor-und-sport.bg/ - Познай победителя във Формула 1 и спечели награда! http://www.clubf1.net/ - 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: XQuery Implementation type for SCA
Hi Vasil, This sounds like a really good idea, very promising! I imagine that XQuery components will be very useful to transform/extract/mediate the data flowing through most SCA integration applications! Welcome to Tuscany :) -- Jean-Sebastien Raymond Feng wrote: Hi, Vasil. Welcome to Tuscany and thank you for contributing the XQuery implemention type to Tuscany! Would you please go ahead to create a JIRA and attach the prototype (https://issues.apache.org/jira/browse/TUSCANY) ? We can start from there. Thanks, Raymond - Original Message - From: Vasil Vasilev [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 10, 2007 1:06 PM Subject: XQuery Implementation type for SCA Hi all, I have provided a prototype for XQuery impelementation type extension for Tuscany. I did this as part of my master thesis and I would like to contribute the sources and the idea to Tuscany if you think this would be useful. Of course it is currently only a prototype and it is not production ready, but if you think that such contribution will be useful for the future of Tuscany I will be glad to help. Some notes about the prototype: 1. I see XQuery as a mighty data integration technology, that's why, in my opinion, the SCA specification should be enhanced with XQuery-related implementation type. 2. In order to prove this concept I created simple extension to Tuscany, which interprets implementation type implementation.xquery. Generally the following contributions were done: - xquery artifact resolver - xquery implementation provider - Saxon data binding and transormes for DOM Nodes and SDO DataObjects 3. As underlying implementation Saxon B is used. This has its limitations - it is not schema aware, but it is free (MPL - licensed). 4. I created test cases for the following scenarios: - Sending data from one SCA component to XQuery component - Feeding data to XQuery component by using properties - Binding XQuery component as a web service - referencing other SCA components from the XQuery component 5. In order to allow integration of XQuery in SCA I have also provided some specification of how references, services and properties can be defined in the XQuery file. Bye, Vasil Vasilev - С бензин в кръвта! http://auto-motor-und-sport.bg/ - Познай победителя във Формула 1 и спечели награда! http://www.clubf1.net/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
ant elder wrote: On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Thats an interesting proposal :) Its pretty aggressive but actually sounds ok to me, what do others think about a 1.0 in this sort of time frame? It'll make a for a busy next few weeks to make 1.0 good...don't get a 2nd chance for a first impression... If we do go for this then would naming the August release 0.99 instead of 0.95 be more favourable to those who've been preferring the 1.0-beta name over 0.95? ...ant Here's my preference, in decreasing preference order: - 1.0 beta1 - 0.99 - 0.95 So to answer your question, 0.99 is more favourable than 0.95. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA schema files, where can I download them
Does anyone know where I can download the SCA schema files referenced in the SCA_AssemblyModel_v100? Specifically: * sca-core.xsd * sca-binding-sca.xsd * sca-interface-wsdl.xsd * sca-implementation-composite.xsd * sca-definitions.xsd The schemas are presented in that spec, but they have the 4 digit line numbers present, and its very error-prone to copy paste them and then have to remove the line numbers. Then, there's the issue of the errata listed here: http://www.osoa.org/display/Main/Service+Component+Architecture+Specific ations It would be nice if the osoa website had them available for download. I tried looking through the TuscanyJava code, but didn't see that they are using the schemas, maybe I missed them. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845 ] Jean-Sebastien Delfino commented on TUSCANY-1499: - I'd suggest the following to further simplify this: State that a reference with a callback cannot be named like a service State that a service with a callback cannot be named like a reference Take these statements as proposals to the SCA spec workgroup. This will save us from having to implement a complicated naming convention for the derived callback services and callback references, and will save the application developer to have to understand it. I think that this is a reasonable approach for now, as Java components for example will typically name a reference foo and a service Foo, and as another example BPEL components already have this naming limitation as well if I understand BPEL and WSDL correctly. I don't think convenience of the runtime (one particular runtime) should be made visible at the spec level. We should take the spec as is and do what we need to support it. This won't be very difficult. The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. On the other hand, I'm observing that: - 99% of Java components name their services and references differently (actually 100% of the ones I've seen implemented so far) - (unless i'm mistaken about BPEL) 100% of BPEL components will name them differently - and IIRC earlier versions of the SCA assembly spec had this rule as well, at least in composite implementations (before the service/reference promotion mechanism was introduced). So instead of implementing an ugly naming convention (necessarily ugly to avoid naming collisions), and exposing it to application developers... I'd rather go with an acceptable limitation, which may actually make it back to the spec. I'll raise this as as an issue to the SCA assembly spec work group. Define marker interfaces ComponentCallbackService extends ComponentService and ComponentCallbackReference extends Reference to allow code like domain.locateService to filter out these callback services/references and not allow them to be located explicitly. I'd be more inclined to do this using a method isCallback() on the Contract interface from which services and references inherit. +1 Instead of trying to establish callback wires all over the place, which will not fly anyway as soon as 2 references with callback are wired to a single service, flow the endpoint reference of the callback service representing the client in the SCA request message and use it to direct the callback in context as suggested by Raymond in thread [1]. These callback wires are already being established and AFAIK this does work in the case you describe. The callback wire is selected based on the forward wire that was used. I'll write an itest to verify that this is working correctly. Already covered in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1530) Tuscany SCA native for windows is not msvc backwards compatible
Tuscany SCA native for windows is not msvc backwards compatible --- Key: TUSCANY-1530 URL: https://issues.apache.org/jira/browse/TUSCANY-1530 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: MSVC 8.0 and 7.1 Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next I've been trying to compile TuscanySCA on platforms other than VSExpress (which is msvc 8.0) and Linux. I came across something that doesn't compile with msvc7.1 in Logger.cpp. The problem is the use of vsnprintf, which is only available for msvc8.0. Changing it to _vsnprintf will work for both msvc 7.1 and 8.0. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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-1530) Tuscany SCA native for windows is not msvc backwards compatible
[ https://issues.apache.org/jira/browse/TUSCANY-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1530: --- Attachment: tuscany_jira1530 Uploading patch. Tuscany SCA native for windows is not msvc backwards compatible --- Key: TUSCANY-1530 URL: https://issues.apache.org/jira/browse/TUSCANY-1530 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: MSVC 8.0 and 7.1 Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: tuscany_jira1530 I've been trying to compile TuscanySCA on platforms other than VSExpress (which is msvc 8.0) and Linux. I came across something that doesn't compile with msvc7.1 in Logger.cpp. The problem is the use of vsnprintf, which is only available for msvc8.0. Changing it to _vsnprintf will work for both msvc 7.1 and 8.0. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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]
[SCA Native] Tuscany SCA Native for Windows is not msvc backwards compatible
Hello all, I created a JIRA for this compilation issue and have already uploaded a patch. Can someone submit it please. https://issues.apache.org/jira/browse/TUSCANY-1530 Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1530) Tuscany SCA native for windows is not msvc backwards compatible
[ https://issues.apache.org/jira/browse/TUSCANY-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1530: --- Attachment: tuscany_jira1530_patch1 When I did the svn diff for the first patch, I forgot to remove my changes to the platform.properties file. Either disregard those changes from the first patch, or submit only this patch. Tuscany SCA native for windows is not msvc backwards compatible --- Key: TUSCANY-1530 URL: https://issues.apache.org/jira/browse/TUSCANY-1530 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M3 Environment: MSVC 8.0 and 7.1 Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: tuscany_jira1530, tuscany_jira1530_patch1 I've been trying to compile TuscanySCA on platforms other than VSExpress (which is msvc 8.0) and Linux. I came across something that doesn't compile with msvc7.1 in Logger.cpp. The problem is the use of vsnprintf, which is only available for msvc8.0. Changing it to _vsnprintf will work for both msvc 7.1 and 8.0. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- 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: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Simon Nash wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. Thanks, this helps me to understand the scenarios. I was thinking in terms of service and reference names, which would not be exposed (like the current $self$. and $promoted$. names that the runtime uses). The issue is when the service or reference name is used to form the externally visible URI for the callback endpoint. If we want to do something in the spec group to address this, I think the best thing to do would be to add a rule to the spec for how a URI should be constructed for the endpoint that represents a callback reference. This needs to be done in a way that won't collide with URIs for SCDL services on the same component. One way to ensure that the endpoint names don't collide is to say (as you have proposed): 1. The name of the callback endpoint is derived from the SCDL reference name using the same algorithm that is currently used for services. 2. Reference and service names must never be the same. Another way to ensure that the endpoint names don't collide is to say: 1. The name of the callback endpoint is derived from the SCDL reference name using a different algorithm than the one that is currently used for services. For example, it could be something like componentname/referencename-callback My preference would be for something like this because it makes it very easy to see which URIs are for callbacks and which are for real services. Simon Will that work? component name=foo service name=bar/ -- this one has a callback reference name=bar-callback /component If I understood what you proposed correctly, the service's callback and the reference will end up with the same URI. I really don't know what kind of convention we could use here. Can anyone think of an automatic naming convention that won't break and will still be obvious to the app developer? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA schema files, where can I download them
On 8/10/07, Brady Johnson [EMAIL PROTECTED] wrote: Does anyone know where I can download the SCA schema files referenced in the SCA_AssemblyModel_v100? Specifically: * sca-core.xsd * sca-binding-sca.xsd * sca-interface-wsdl.xsd * sca-implementation-composite.xsd * sca-definitions.xsd The schemas are presented in that spec, but they have the 4 digit line numbers present, and its very error-prone to copy paste them and then have to remove the line numbers. Then, there's the issue of the errata listed here: http://www.osoa.org/display/Main/Service+Component+Architecture+Specific ations It would be nice if the osoa website had them available for download. I tried looking through the TuscanyJava code, but didn't see that they are using the schemas, maybe I missed them. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Hi Brady I've got them from here in the past http://www.osoa.org/xmlns/sca/1.0/. There seem to have been recent updates judging by the dates. Simon
Re: [SCA Native] next release content [was: Tuscany roadmap]
How about enhancing the documentation (architecture, get started and user doc) to help new people come on board faster? Another thought might be to have an integration story between Native and Java. Some of this work started for OSCon, for example a sample of a composite which include C++ and Java components. On 7/26/07, Pete Robbins [EMAIL PROTECTED] wrote: That looks good. I think there is more than enough in that list to justify a release. My priorities would be: 1) upgrade to the sca 1.0 spec levels (assembly and cpp). 2) build system move to ant (enough there for a release) We should discuss your ideas for the rearchitecture of the data model. It sounds like a good idea so maybe we can flesh out a proposal for that. Cheers, On 26/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Hello all, I created a wiki page detailing the TuscanySCA Native Next Release Contents, which will probably be called M4. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R elease+Contents Can I get some feedback on the items listed there. Also, what's the Apache procedure to start planning and implementing the changes? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 11:00 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I forgot to mention another one in my previous post: - get the test suite up to date and working. I don't like making changes to code without running a good unit/basic test suite. We do not have ANY test suite. I run through the samples to test changes. The code under tuscany/cpp/sca/test is not maintained and should probably be discarded. I think we need to build up a unit test suite and would welcome suggestions on how to start this (use cppunit?) I can start a separate thread for the ant vs make discussion. Basically, I think it would be easier to simplify the build process using make. I've looked through some of the makefiles and they're horrendous. :) Let's discuss it here then. We need to be able to build from source on windows, linux and Mac. On Windows we settled on MSVC 8 so it can build with the free studio express. For linux we settled on automake as it seemed to be fairly standard for C/C++ open source projects. In doing this I had to learn automake and learnt to hate it ;-) ... and as you say some of the makefiles are ugly. If you believe an ant based build would be better then I'll happily go along with that. Perhaps you could start this off by showing us what the build would look like for, say, cpp/sca/runtime/core ?? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 9:53 AM To: tuscany-dev@ws.apache.org Subject: [SCA Native] next release content [was: Tuscany roadmap] We should definitely start planning some content for the next SCA Native release. On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Is there some sort of TuscanySCA roadmap? I've looked around a bit and haven't found one. I was curious what the future plans for TuscanySCA CPP were in particular. I have a few ideas and I was curious if they had been contemplated yet. - Move from Assembly Model 0.96 to 1.0 Definitely. We also need to move the CPP extension to the 1.0 C++ CI spec version - Move to ant instead of make I need to understand this proposal a little better. Can you elaborate? Probably worth starting a separate thread to discuss this. I'm all for simplifying the build though! - Remove runtime dependancy on model data structure (slight changes to data/model shouldnt affect runtime usage) ok - Support additional WSDL bindings: RPC, DOC encoded... sounds good. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Cheers, -- Pete - 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] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intent and Policy attachments on Operations
Sebastien, thanks for responding. I am still not convinced about Intent instances having links to things in the assembly model. I perceive the Policy module to be independent of any other SCA module (assembly, or interface, ... ). Also when we are resovling or building the composites, it seems a bit odd to me to go after a PolicyRegistry and get the bunch of all Intents defined for a domain and then run thro each to find the operations that use it. Also I see that there are other decorations as well to the Operation that exists today - one of which is the databinding. So, why wouldn't intents and policy sets simply add on. However if you say that we share instances of Operations across interface definitions, then we probably need to store this map in the InterfaceDef.. or if the InterfaceDef instances are shared then we have look at the next higher level thing that is not shared to manage this information. Am I missing some point here ? - Venkat On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat The Intent - operations relationship was modeled like this intentionally. Here's why: If you're talking about o.a.t.interfacedef.Operation, then I don't think it can hold intents. Operation represents a business method/operation on a business interface, potentially used in multiple Services or References... with different sets of intents. The operation element in SCA assembly XML does not represent the actual operation on the business interface, it is just the syntax used to group the intents that apply to a given operation, within the context of a particular service or reference. So basically we need to represent the association: a set of intents - a set of operations in the context of a particular service/reference There's basically two ways to represent this: a) In an intent, list the business operations that the intent applies to or b) Invent a new object representing an operation used within the context of a reference/service, pointing to the actual operation + listing the intents The assembly model being a logical model it does not have to follow the convolutions of the particular XML syntax, and it seems to me that (a) is more logical than (b). At least it'll allow us to easily find which operations a particular intent (and the corresponding interceptors) applies to. Hope this helps. -- Jean-Sebastien - 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]
Tuscany/Geronimo Integration Demo
Hi, We put together a demo [1] on Tuscany/Geronimo integration for the LinuxWorld 2007. You are welcome to play with it and give us feedback. Please follow the instructions at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/README.TXT. The demo scenario is captured at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/scenario.png. The demo is built on top of the sandbox code in Geronimo [2] which is discussed on [3]. Please note this is just the starting of effort and there are still quite a lot to do. Please join us on this effort. In the near term, I believe that we need to do the following: 1) Move the code out of sandbox and have them in the build with test cases. 2) The tuscany-geronimo-plugin uses mixed versions of Tuscany Java SCA 0.91-incubating and 1.0-incubating-SNAPSHOT. Let's try to switch to 1.0-incubating-SNAPSHOT so that we have consistent modules. 3) The Geronimo 2.0 RC1 is not being voted on. We should be prepared to move this level. Vamsi, do you have the JIRA GERONIMO-3351 [4] fixed in the RC1? [1] http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/geronimo-demo/ [2] http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/ [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integration [4] https://issues.apache.org/jira/browse/GERONIMO-3351 Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Simon Laws wrote: On 8/8/07, ant elder [EMAIL PROTECTED] wrote: On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote: We talked about this before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html) but didn't come to any conclusions. So, 1/ What is the requirement? 2/ What is the technical solution? 3/ When should we try and get it done? To get things going again here are some thoughts drawn from what was said in the referenced thread. 1/ An API in line with accepted logging/management practices to support arbitrary debugging and runtime info, warning and error logging A common approach to exception/error handling specifically around the detail recorded in the error messages Internationalization/localization Execution Tracing 2/ Keeping it simple was a popular sentiment A number of java logging solutions have been proposed Log4J, SLF4J etc. I believe DAS is using Log4J. We have dependencies that also use logging tools. We can take a look at how others approach this, e.g, quick glance at the last CxF release shows they include SLF4J jars Aspects were investigated to show how they can be used for tracing, seems like an interesting optional facility but adds extra complexity/dependencies There was also a suggestion that we could implement some higher level tracing, e.g. runtime starts, stops, application loading, component instance creation etc. We need to move error message out of the code and into resource files 3/ I think we can reasonably expect to agree what approach we are going to take fairly quickly and provide some examples, i.e. before the next release? People suggested before that we take time out to go through the code based and bring it into line. This will take a lot of time but can we get it into 1.0? Please add your thoughts to the list and we can then draw them together, try some of it out and come to some conclusions. Simon +1 for going with SLF4J. If we can decide on this soon then we can all just start adding it in to the code we're working on and debugging, and then maybe have a focused sweep before 1.0 to make sure its in everywhere useful. ...ant Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon We had a similar discussion in April [1]. Here's what I suggest for logging: - Separate the trace calls from the runtime code. Insert them automatically at build time or run time using Aspectj. Raymond on SCA and Kelvin on SDO already showed how to do it. - Use SLF4J in these generated trace calls. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA schema files, where can I download them
Brady Johnson wrote: Does anyone know where I can download the SCA schema files referenced in the SCA_AssemblyModel_v100? Specifically: * sca-core.xsd * sca-binding-sca.xsd * sca-interface-wsdl.xsd * sca-implementation-composite.xsd * sca-definitions.xsd The schemas are presented in that spec, but they have the 4 digit line numbers present, and its very error-prone to copy paste them and then have to remove the line numbers. Then, there's the issue of the errata listed here: http://www.osoa.org/display/Main/Service+Component+Architecture+Specific ations It would be nice if the osoa website had them available for download. I tried looking through the TuscanyJava code, but didn't see that they are using the schemas, maybe I missed them. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] http://www.osoa.org/xmlns/sca/1.0/ The Tuscany Java project does not ship the schemas at the moment. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1528) ClassCastException thrown when trying to deserializing an XML with undefined global element
[
https://issues.apache.org/jira/browse/TUSCANY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519131
]
Fuhwei Lwo commented on TUSCANY-1528:
-
Here is what I found out so far.
Without defining a global element in the XSD, a DocumentRoot object won't be
created and a different demand create path was taken. In this case,
org.eclipse.emf.ecore.xmi.impl.validateCreateObjectFromFactory() will be
invoked to demand creating a new package, type and data object. I think the
problem lies on the demand creating type was not set up correctly. (See
BaseSDOExtendedMetaDataImpl.demandType(String namespace, String name))
I tried to add the line below after demandPackage to set up the right
eFactoryInstance for the package but it's no use.
ePackage.setEFactoryInstance(new DynamicDataObjectImpl.FactoryImpl());
because later on
eClass.getESuperTypes().add(demandMetaData.getAnyType());
will set the new type's super type to be XMLTypePackage.eINSTANCE.getAnyType()
which will be used to create EMF's AnyTypeImpl instead of SDO's any type impl.
I found the following method in SDOExtendedMetaDataImpl.java doesn't define the
type for SDO's any type. Does anyone know what it should be mapped to? Am I on
the right track?
public static class SDODemandMetaData extends DemandMetaData {
EClassifier getEObject() { return
(EClassifier)((ModelFactoryImpl)ModelFactory.INSTANCE).getDataObject(); }
EClassifier getAnySimpleType() { return
(EClassifier)((ModelFactoryImpl)ModelFactory.INSTANCE).getObject(); }
}
ClassCastException thrown when trying to deserializing an XML with undefined
global element
---
Key: TUSCANY-1528
URL: https://issues.apache.org/jira/browse/TUSCANY-1528
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: WinXP
Reporter: Fuhwei Lwo
Fix For: Java-SDO-Next
Attachments: 1528-testcase.patch
Using simple.xsd, I can serialize and deserialize an XML with a undefined
global element. If I removed the global element definition from the
simple.xsd, a ClassCastException will be thrown. It seems without the global
element definition's presence some required step was not done. Here is the
stack trace and test case.
junit.framework.AssertionFailedError: java.lang.ClassCastException:
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl incompatible with
commonj.sdo.DataObject
at junit.framework.Assert.fail(Assert.java:47)
at
org.apache.tuscany.sdo.test.XMLHelperTestCase.testDemandCreateRootObject(XMLHelperTestCase.java:248)
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 junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
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
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
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: [SCA Native] next release content [was: Tuscany roadmap]
Good idea, I always prefer to see plenty of documentation. I updated the wiki with a documentation feature. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R elease+Contents What sort of help do you think I'll have with these features? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: haleh mahbod [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 3:36 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] How about enhancing the documentation (architecture, get started and user doc) to help new people come on board faster? Another thought might be to have an integration story between Native and Java. Some of this work started for OSCon, for example a sample of a composite which include C++ and Java components. On 7/26/07, Pete Robbins [EMAIL PROTECTED] wrote: That looks good. I think there is more than enough in that list to justify a release. My priorities would be: 1) upgrade to the sca 1.0 spec levels (assembly and cpp). 2) build system move to ant (enough there for a release) We should discuss your ideas for the rearchitecture of the data model. It sounds like a good idea so maybe we can flesh out a proposal for that. Cheers, On 26/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Hello all, I created a wiki page detailing the TuscanySCA Native Next Release Contents, which will probably be called M4. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Ne xt+R elease+Contents Can I get some feedback on the items listed there. Also, what's the Apache procedure to start planning and implementing the changes? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 11:00 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] next release content [was: Tuscany roadmap] On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I forgot to mention another one in my previous post: - get the test suite up to date and working. I don't like making changes to code without running a good unit/basic test suite. We do not have ANY test suite. I run through the samples to test changes. The code under tuscany/cpp/sca/test is not maintained and should probably be discarded. I think we need to build up a unit test suite and would welcome suggestions on how to start this (use cppunit?) I can start a separate thread for the ant vs make discussion. Basically, I think it would be easier to simplify the build process using make. I've looked through some of the makefiles and they're horrendous. :) Let's discuss it here then. We need to be able to build from source on windows, linux and Mac. On Windows we settled on MSVC 8 so it can build with the free studio express. For linux we settled on automake as it seemed to be fairly standard for C/C++ open source projects. In doing this I had to learn automake and learnt to hate it ;-) ... and as you say some of the makefiles are ugly. If you believe an ant based build would be better then I'll happily go along with that. Perhaps you could start this off by showing us what the build would look like for, say, cpp/sca/runtime/core ?? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 9:53 AM To: tuscany-dev@ws.apache.org Subject: [SCA Native] next release content [was: Tuscany roadmap] We should definitely start planning some content for the next SCA Native release. On 12/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Is there some sort of TuscanySCA roadmap? I've looked around a bit and haven't found one. I was curious what the future plans for TuscanySCA CPP were in particular. I have a few ideas and I was curious if they had been contemplated yet. - Move from Assembly Model 0.96 to 1.0 Definitely. We also need to move the CPP extension to the 1.0 C++ CI spec version - Move to ant instead of make I need to understand this proposal a little better. Can you elaborate? Probably worth starting a separate thread to discuss this. I'm all for simplifying the build though! - Remove runtime dependancy on model data structure (slight changes to data/model shouldnt affect runtime usage) ok - Support additional WSDL bindings: RPC, DOC encoded... sounds good. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1531) Java SDO Documentation page should be updated to default website stype/design
Java SDO Documentation page should be updated to default website stype/design - Key: TUSCANY-1531 URL: https://issues.apache.org/jira/browse/TUSCANY-1531 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-SDO-Next Reporter: Luciano Resende Fix For: Java-SDO-Next The default left side menus are missing or wrong Some pages are only available on the left menu on this page : http://incubator.apache.org/tuscany/developing-sdo-java.html It should probably be listed/visible from : http://incubator.apache.org/tuscany/sdo-java-documentation-menu.html as it's one of the pages with more contents on it. User guide has wrong styles : http://incubator.apache.org/tuscany/sdo-java-user-guide.html -- 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-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
[ https://issues.apache.org/jira/browse/TUSCANY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1523: - Component/s: Java SCA Core Runtime Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- 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-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1496: Attachment: patch2 This second patch completes the changes for this JIRA. It adds further support for some more advanced callback use cases (most notably the ability to make callbacks through a CallableReference), and it cleans up the Web Service binding and the SCA binding to remove the code for callback wires, which are no longer being created by the core. It also removes redundant callback code from CompositeActivatorImpl. The Web Service binding model no longer depends on CallbackBinding. (This class and the Axis2CallbackInvocationHandler class are now unused but I haven't rebuilt the code without them to make sure there are no lurking dependencies.) Other changes not specifically mentioned above were needed to make the above things work. Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Attachments: patch1, patch2 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- 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]
Build Failure on java trunk
Hi, I just tried building the entire java trunk, and I get the following build failure: --- T E S T S --- Running org.apache.tuscany.sca.contribution.services.ContributionMetadataDocumentProcessorTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.146 sec Running org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec Running org.apache.tuscany.sca.contribution.services.PackageTypeDescriberImplTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec Running org.apache.tuscany.sca.contribution.resolver.ExtensibleArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec Running org.apache.tuscany.sca.contribution.resolver.ArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.095 sec Running org.apache.tuscany.sca.contribution.processor.JarContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec Running org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.107 sec FAILURE! testStore(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.094 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) testRemove(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.001 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at
Re: mvn eclipse:eclipse fails on java
Hi Simon, SNIP assuming you have the source tree checked out of svn. Yes Can you try building that module before you run the eclipse generation? Sure - I'll give it a shot. If I'm in ./java how do I find the module? Having said that I just knocked it out of my local repo and the eclipse generation ran fine. This is what I see for the project in question. SNIP Can you post the output block you get? Here's a partial block (The entire out is pretty long - I can post the rest if we need it though): [INFO] Building Apache Tuscany Dojo Sample WebApp [INFO]task-segment: [eclipse:eclipse] [INFO] [INFO] Preparing eclipse:eclipse Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/sca/tuscany-binding-sca-xml/1.0-incubating-SNAPSHOT/tuscany-binding-sca-xml-1.0-incubating-SNAPSHOT.jar Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sca/tuscany-binding-sca-xml/1.0-incubating-SNAPSHOT/tuscany-binding-sca-xml-1.0-incubating-SNAPSHOT.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-sca-xml \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-sca-xml \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-host-webapp:jar:1.0-incubating-SNAPSHOT 3) org.apache.tuscany.sca:tuscany-host-embedded:jar:1.0-incub ating-SNAPSHOT 4) org.apache.tuscany.sca:tuscany-binding-sca-xml:jar:1.0-incubating-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Fri Aug 10 18:48:57 CDT 2007 [INFO] Final Memory: 36M/63M [INFO] Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1532) Add sdo-tools dependency to tuscany-sca distribution
Add sdo-tools dependency to tuscany-sca distribution Key: TUSCANY-1532 URL: https://issues.apache.org/jira/browse/TUSCANY-1532 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next We need to add sdo-tools dependency to tuscany-sca distribution in order to be able to generate static SDO for the sample applications. -- 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]
