Re: DAS C++ - Design documents and Overall Documentation
Great! It´s better implement with UML diagrams than debug the code. = ) On 2/10/07, Adriano Crestani [EMAIL PROTECTED] wrote: Cool, I think after we have the first classes of das c++ being used by the proposed simple read app we may produce some documentation like this ; ) Adriano Crestani On 2/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Guys It looks like couple people now working on the C++ implementation of DAS, I have created a page on the Wiki for us to share design documents, overall documentation and user guide : http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093 Below are good examples of design documents and user documents that we can take as example: Design documentation: http://cwiki.apache.org/confluence/display/TUSCANY/Deployment Users guide : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_Java_User_Guide -- Luciano Resende http://people.apache.org/~lresende
Re: Suggestions for Tuscany SCA documenation?
On 2/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Ah. You add a good point that we need to think about extension documents as well :) On 2/9/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote: Extension developer would generally not work off the latest code (I generally discourage people from doing this as the state of trunk may be in flux). They would tend to go off a published release. OK. Although it seems like all discussions are typically centered around the latest code on mailing list. Maybe this is what we should encourage. When you munge everything together it can be hard to tell. Most of the technical discussion recently has been around changes to the kernel rather than extensions and so naturally relates to the latest kernel code. If we did have discussion around an extension, it would be about the latest code /of that extension/. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So, from this thread, a number of things that partition our documentation. Underlying technology: Java, C++ Project: SCA, SDO, DAS Module(?): Kernel, Runtimes, Extensions... Release: M1, M2, M3 (are the next releases going to be at the module level now?) Reader: User, Extension Developer, Developer It seems that the Cwiki is shaping up as follows: SCA Java User pages Intro Installing Samples Building an app What extension are available Etc… Developer pages Intro Architecture Dev env Module docs Etc… C++ FAQ - not sure why this is at this level? SDO Java C++ FAQ DAS Java C++ FAQ It's difficult to comment on whether developer docs should be separate from extension developer docs but if feels like it's a low priority at the moment. We should make space to describe the separate modules that are available both from user and developer perspectives. Is there still going to be a full milestone release at some point where documentation is built or are the separate modules going to advance independently? This will flavor how we keep track of what we are writing docs for. As we are still in incubation can we continue just to worry about the latest code? I like the idea of using new spaces to represent documentation for major releases but that doesn't work for finer grained releases. We need a way of marking which details relate to which version. Confluence themselves label pages, e.g, ( http://confluence.atlassian.com/display/DOC/Administrators+Guide), but I don't know how they use the labels exactly yet. As Dan pointed out page names must be unique within a space but this doesn't cause particular pain in our PHP site as we just prefix page names. We do have a very small number of pages though. We also use the Left Navigation theme. This provides a left hand menu like they have on CFX ( http://cwiki.apache.org/CXF/) as Shelita noted. Changing the theme is a space admin task. If we want this is Ted Husted the man to talk to? Does anyone from Tuscany have space admin privileges? Simon
Re: fractal module, was: sca-extensions which code to checkout
thanks Jeremy, just checked out, I'll work on it later today and tomorrow, to see how it goes. Thanks! On 2/9/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 9, 2007, at 9:10 AM, Jeremy Boynes wrote: I'll add a module in the sandbox for fractal. https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal -- http://valerioschiavoni.blogspot.com http://jroller.com/page/vschiavoni
Re: Building the integration branch
Jean-Sebastien Delfino wrote: Rick Rineholt wrote: Hello, I don't think I'm having the same success as you in the sca-java-integration below is my reactor summary also attached is the full build. My source has no mods and started from a clean local repo. I'll look at it some but just like to know if it just local to my environment. Any others build ok or see issues ? Thanks [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany Project Parent . SUCCESS [1:28.297s] [INFO] Apache Tuscany Build Tools SUCCESS [42.766s] [INFO] Commonj API for Timer and Work Manager SUCCESS [10.562s] [INFO] SCA API Version 1.0 ... SUCCESS [34.985s] [INFO] OSOA Specification API jars ... SUCCESS [0.015s] [INFO] Apache Tuscany SCA Implementation Project . SUCCESS [0.000s] [INFO] Apache Tuscany SCA Kernel Sub-Project . SUCCESS [0.047s] [INFO] Apache Tuscany SCA API SUCCESS [15.484s] [INFO] Apache Tuscany Host API ... SUCCESS [2.875s] [INFO] Apache Tuscany SCA SPI SUCCESS [13.235s] [INFO] Apache Tuscany SCA Core ... SUCCESS [31.719s] [INFO] Apache Tuscany SCA Services ... SUCCESS [0.000s] [INFO] Apache Tuscany SCA Interface Definition Languages . SUCCESS [0.046s] [INFO] Apache Tuscany WSDL ... SUCCESS [9.313s] [INFO] Apache Tuscany SCA Data Bindings .. SUCCESS [0.016s] [INFO] Apache Tuscany Data Binding for JAXB .. SUCCESS [1:22.890s] [INFO] Apache Tuscany Data Binding for SDO ... SUCCESS [38.578s] [INFO] Apache Tuscany Jetty HTTP Service . SUCCESS [15.578s] [INFO] Apache Tuscany Test Framework . FAILED [2.813s] [INFO] Apache Tuscany SCA Maven Plugins .. SUCCESS [0.062s] [INFO] Apache Tuscany Integration Test Plugin FAILED [43.360s] [INFO] Apache Tuscany SCA Extensions . SUCCESS [0.015s] [INFO] Apache Tuscany SCA Extensions for Axis2 ... SUCCESS [0.016s] [INFO] Apache Tuscany Data Binding for Axiom . SUCCESS [38.891s] [INFO] Apache Tuscany Binding for Axis2 .. FAILED [33.250s] [INFO] Apache Tuscany Axis2 Tools SUCCESS [0.000s] [INFO] Apache Tuscany Axis2 Java2WSDL Tool ... SUCCESS [13.234s] [INFO] Apache Tuscany Axis2 WSDL2Java Tool ... SUCCESS [3.969s] [INFO] Apache Tuscany Axis2 Maven Plugins SUCCESS [0.015s] [INFO] Apache Tuscany Maven Plugin for Java2WSDL . SUCCESS [1.485s] [INFO] Apache Tuscany Maven Plugin for WSDL2Java . SUCCESS [0.312s] [INFO] Tuscany Samples for the Axis2 extension ... SUCCESS [5.125s] [INFO] Tuscany HelloWorld Web Service Client Sample .. FAILED [0.750s] [INFO] Tuscany HelloWorld Web Service Client Sample OM ... FAILED [4.750s] [INFO] Apache Tuscany SCA tests .. SUCCESS [0.031s] [INFO] Apache Tuscany SCA Integration Test Suite . SUCCESS [0.000s] [INFO] Test Suite for SCA Spec APIs .. FAILED [1.031s] [INFO] Test Suite for SCA properties . FAILED [0.532s] [INFO] SCA FVT Bindings Test Tool Service Composite .. FAILED [5.328s] [INFO] SCA FVT Bindings Test Tool Utility Composite .. FAILED [0.890s] [INFO] SCA FVT Test Tool Suite ... SUCCESS [0.016s] [INFO] Test Suite for SCA Callback Basic . FAILED [0.500s] [INFO] Test Suite for SCA Callback CType . FAILED [0.516s] [INFO] Test Suite for SCA Callback ID FAILED [0.640s] [INFO] Test Suite for SCA Callback SetCallback ... FAILED [1.063s] [INFO] Test Suite for SCA Callback SetCallback Conversation .. FAILED [0.500s] [INFO] Tuscany Samples ... SUCCESS [0.031s] [INFO] Apache Tuscany SCA Samples SUCCESS [0.000s] [INFO] Tuscany Calculator Sample . FAILED [0.484s] [INFO] Tuscany Supply Chain Sample ... FAILED [0.469s] [INFO] Tuscany BigBank Sample FAILED [0.531s] [INFO] Echo Binding .. FAILED [0.500s] [INFO] Tuscany Inner Composite Sample FAILED [0.500s] [INFO] Tuscany Loan App Conversation Sample .. FAILED [0.438s] [INFO] Tuscany Scenario Samples
Re: Status of the databinding-test module?
Also... seems like the dependcies are set to be the pre-spec-change branch should these be updated to the SCA 1.0 specification ? On 10/02/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Dan Murphy wrote: I was also wondering if there was a better place for this project since it's an integration test (testing/sca/itest ?) Yes, what you're proposing makes sense to me. Raymond, what do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of the databinding-test module?
Dan Murphy wrote: Also... seems like the dependcies are set to be the pre-spec-change branch should these be updated to the SCA 1.0 specification ? Yes -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML
[ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-1088: Attachment: FormTestCase.java patch The attached patch has passed all build tests. SDO should tolerate malformed XML - Key: TUSCANY-1088 URL: https://issues.apache.org/jira/browse/TUSCANY-1088 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kevin Williams Fix For: Java-SDO-Mx Attachments: FormTestCase.java, patch I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. XML documents are often less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: ?xml version=1.0 encoding=UTF-8? xsd:schema targetNamespace=http://QuickTest/HelloWorld; xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xsd:element name=sayHello xsd:complexType xsd:sequence xsd:element name=input1 nillable=true type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:schema If we get an xml that looks like this: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd input1input1/input1 /tns:sayHello then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd tns:input1tns:input1/tns:input1 /tns:sayHello Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault=qualified enforcement policy. What do you think? 3-1. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; input1input1/input1 /tns:sayHello The author may have forgot to qualify input1 element, although input1 may also be a global element without NameSpace. It's friendly to tolerate. 3-2. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:onPurpose=differentNameSpace onPurpose:input1input1/onPurpose:input1 /tns:sayHello The author has qualified input1 element; I'm not confident we should tolerate. 3-3. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns=differentNameSpace !-- xmlns= declares all unqualified elements/attributes under differentNameSpace -- input1input1/input1 /tns:sayHello It's hard to tell if the author may have forgot to qualify input1 element or not. I bet on not. Should we tolerate? -- 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: Getting Developer Jira access to Adriano Crestani
Sorry Jeremy, but I'm not being able to access the developer options. Have you granted developer access for the user adriano_crestani? I don't remember if I've registered more than once. Adriano Crestani On 2/7/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks ! On 2/7/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Done. -- Jeremy On Feb 7, 2007, at 10:34 AM, Luciano Resende wrote: Adriano Crestani has been helping DAS for couple months now, he had contributed on a DAS tutorial initiative, and recently he has been discussing and contributing on a C++ implementation of a DAS. I'd like to give him developer access to JIRA so he can manage JIRAs with more flexibility, etc. -- Luciano Resende http://people.apache.org/~lresende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: Getting Developer Jira access to Adriano Crestani
That was the account I added (and the email associated with it is the one you sent this from). You might try logging out/in. What is not working for you? -- Jeremy On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote: Sorry Jeremy, but I'm not being able to access the developer options. Have you granted developer access for the user adriano_crestani? I don't remember if I've registered more than once. Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting Developer Jira access to Adriano Crestani
I tried to log in/out, but didn't work. There is no option to assign the task to me. Adriano Crestani On 2/11/07, Jeremy Boynes [EMAIL PROTECTED] wrote: That was the account I added (and the email associated with it is the one you sent this from). You might try logging out/in. What is not working for you? -- Jeremy On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote: Sorry Jeremy, but I'm not being able to access the developer options. Have you granted developer access for the user adriano_crestani? I don't remember if I've registered more than once. Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA's : Trunk versus java-sca-integration branch
I understand that a java-sca-integration category was created for JIRAs, but I wanted to know what's the right way to handle JIRAs that are being fixed in one place (e.g java-sca-integration branch) but are still valid on other place (e.g trunk), or vice versa. Should we clone the JIRA, and close it on the place it's being fixed and leave it opened where it still valid ? Or there is a way to resolve the JIRA against one category and leave it open in another ? -- Luciano Resende http://people.apache.org/~lresende
Re: Getting Developer Jira access to Adriano Crestani
I think I fixed it - there was a JIRA upgrade recently and I think the permission mechanism changed. I can assign you an issue which I couldn't before - please let me know if it is working for you. -- Jeremy On Feb 11, 2007, at 5:22 PM, Adriano Crestani wrote: I tried to log in/out, but didn't work. There is no option to assign the task to me. Adriano Crestani On 2/11/07, Jeremy Boynes [EMAIL PROTECTED] wrote: That was the account I added (and the email associated with it is the one you sent this from). You might try logging out/in. What is not working for you? -- Jeremy On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote: Sorry Jeremy, but I'm not being able to access the developer options. Have you granted developer access for the user adriano_crestani? I don't remember if I've registered more than once. Adriano Crestani - 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] Assigned: (TUSCANY-1040) DAS C++
[ https://issues.apache.org/jira/browse/TUSCANY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani reassigned TUSCANY-1040: - Assignee: Adriano Crestani DAS C++ --- Key: TUSCANY-1040 URL: https://issues.apache.org/jira/browse/TUSCANY-1040 Project: Tuscany Issue Type: New Feature Components: C++ DAS Affects Versions: Wish list Reporter: Luciano Resende Assigned To: Adriano Crestani Fix For: Wish list Attachments: DAS_CPP.zip, DAS_CPP_01_11_2007.zip, DAS_CPP_01_11_2007.zip, tuscany1040.crestani.20070117.txt, tuscany1040.crestani.20070207.patch, tuscany1040.crestani.20070208.patch Create a version of DAS in C++ integrating with SDO C++ -- 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: Getting Developer Jira access to Adriano Crestani
It's working now, thanks Jeremy ; ) Adriano Crestani On 2/11/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I think I fixed it - there was a JIRA upgrade recently and I think the permission mechanism changed. I can assign you an issue which I couldn't before - please let me know if it is working for you. -- Jeremy On Feb 11, 2007, at 5:22 PM, Adriano Crestani wrote: I tried to log in/out, but didn't work. There is no option to assign the task to me. Adriano Crestani On 2/11/07, Jeremy Boynes [EMAIL PROTECTED] wrote: That was the account I added (and the email associated with it is the one you sent this from). You might try logging out/in. What is not working for you? -- Jeremy On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote: Sorry Jeremy, but I'm not being able to access the developer options. Have you granted developer access for the user adriano_crestani? I don't remember if I've registered more than once. Adriano Crestani - 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: DataBindingInterceptor and PassByValueInterceptor question
Thanks Raymond. Yes, I am aware of the fact that this should be picked up from the Implementation and hence was guessing the ImplementationProcessor to be the place for picking this up. Anyways, I guess I can figure that out :) - Venkat On 2/8/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I guess I need to correct my previous response. The @AllowsPassByReference should be used to annotate the implementation class/method instead of the interface. Then the flag should goes to the Java implementation. The following is quoted from the Java CI spec: = The @AllowsPassByReference annotation is used on implementations of remotable interfaces to indicate that interactions with the service within the same address space are allowed to use pass by reference data exchange semantics. The implementation promises that its by-value semantics will be maintained even if the parameters and return values are actually passed by-reference. This means that the service will not modify any operation input parameter or return value, even after returning from the operation. Either a whole class implementing a remotable service or the individual remotable service method implementation can be annotated using the @AllowsPassByReference annotation. == Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, February 08, 2007 8:23 AM Subject: Re: DataBindingInterceptor and PassByValueInterceptor question Hi, Venkat. I think it's reasonable to add an attribute allowsPassByReference to the Operation model. We already have remotable in the ServiceContract. The java introspection can set the attribute. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, February 08, 2007 4:37 AM Subject: Re: DataBindingInterceptor and PassByValueInterceptor question Hi Jim, The PassByValueWirePostProcessor sure needs an update in the sense that it only looks for allowsPassByReference at the interface level. It needs to do this at the operation level as well. My imagination is to have this information as part of 'Operation' which presently has things like isNonBlocking, isCallBack and so on. So something like 'isAllowsPassByReference'. If this is right, then is this something that we must do in the ImplementationProcessor i.e. looking for the allowsPassByReference annotation and setting this to the Operation instance. Let me know if I can go ahead and do this. Thanks. - Venkat On 2/8/07, Raymond Feng [EMAIL PROTECTED] wrote: Yes, I agree. And that should be part of the efforts to support the load/resolve/build for SCDL extensibility elements so that they can be handled in a pluggable way. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, February 07, 2007 10:37 AM Subject: Re: DataBindingInterceptor and PassByValueInterceptor question On Feb 7, 2007, at 10:21 AM, Raymond Feng wrote: Hi, Jim. Let me explain the DataBindingInterceptor part. In this case, I pass the CompositeComponent as a metadata in the transformation context so that the transformers can access the extensions (SCAObject.getExtensions) of the CompositeComponent. The extensions contain some information (such as the TypeHelper for the composite) built from SCDL extensibility elements such as import.sdo . This is a workaround to support the load/build for SCDL extensibility elements. Thanks Raymond for the response... This seems problematic, particularly since we are passing CompositeComponent just to use extensibility elements in an untyped way. Wouldn't it be better to do this through some type of typed context ( e.g. for extensibility elements, which themselves may need to be untyped) for the post processor? I generally prefer APIs to be explicit about what they are passing around. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Native] Changes to the SCA default binding
I changed the SCA default binding a little to delegate to the WS binding instead of inheriting from it. This will allow us to select the best concrete binding (WS, REST, or AMQP for example) depending on what's installed and the QOS intents/requirements declared on a service/reference. The new code contains logic to select either the WS or REST binding but I have hardcoded the selection to the WS binding for now as I've been running into an SDO complextype serialization/deserialization issues using the REST binding with the HttpdBigBank scenario. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
