Re: DAS Relationship Reference
Is this C++ specific issue? I see the below output for DAS Java - RelationshipTests.testRelationshipModification2() - which is correct behavior. Before move of order from cust2 to cust1 ?xml version=1.0 encoding=ASCII? cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust1=cust1 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID1/ID LASTNAMEWilliams/LASTNAME ADDRESS1212 foobar lane/ADDRESS ordersroot.xml#//@ANORDER.0/orders ordersroot.xml#//@ANORDER.1/orders /cust1:cust1 ?xml version=1.0 encoding=ASCII? cust2:cust2 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust2=cust2 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID2/ID LASTNAMEDaniel/LASTNAME ADDRESS156 Brentfield Loop/ADDRESS ordersroot.xml#//@ANORDER.2/orders ordersroot.xml#//@ANORDER.3/orders /cust2:cust2 After move of order from cust2 to cust1 ?xml version=1.0 encoding=ASCII? cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust1=cust1 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID1/ID LASTNAMEWilliams/LASTNAME ADDRESS1212 foobar lane/ADDRESS ordersroot.xml#//@ANORDER.0/orders ordersroot.xml#//@ANORDER.1/orders ordersroot.xml#//@ANORDER.2/orders /cust1:cust1 ?xml version=1.0 encoding=ASCII? cust2:cust2 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust2=cust2 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID2/ID LASTNAMEDaniel/LASTNAME ADDRESS156 Brentfield Loop/ADDRESS ordersroot.xml#//@ANORDER.3/orders /cust2:cust2 After applyChanges() and re-query ?xml version=1.0 encoding=ASCII? cust1:cust1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust1=cust1 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID1/ID LASTNAMEWilliams/LASTNAME ADDRESS1212 foobar lane/ADDRESS ordersroot.xml#//@ANORDER.0/orders ordersroot.xml#//@ANORDER.1/orders ordersroot.xml#//@ANORDER.2/orders /cust1:cust1 ?xml version=1.0 encoding=ASCII? cust2:cust2 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:cust2=cust2 xmlns:das=http:///org.apache.tuscany.das.rdb/das; xsi:type=das:CUSTOMER ID2/ID LASTNAMEDaniel/LASTNAME ADDRESS156 Brentfield Loop/ADDRESS ordersroot.xml#//@ANORDER.0/orders /cust2:cust2 Regards, Amita On 10/6/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi again Kelvin, I created this thread a long time ago and you answered me that SDO does not support MxN relatioships between objects. The code above removes the first department from the first company and adds it to the second company. I expected that the reference the first company had to that department would be removed automatically, but it's not being: ... commonj::sdo::DataObjectPtr company1 = root-getDataObject(company[1]); commonj::sdo::DataObjectPtr company2 = root-getDataObject(company[2]); company1-printSelf(cout); company2-printSelf(cout); commonj::sdo::DataObjectPtr department = company1-getDataObject(department[1]); company2-getList(department).append(department); company1-printSelf(cout); company2-printSelf(cout); ... Output: start of DO DataObject type: apache.das#company Property: id Property Type: commonj.sdo#Int Property Value: 1 Property: name Property Type: commonj.sdo#String Property Value: apache Property: department Property Type: apache.das#department Value 0 Reference Value: #/department.0 Value 1 Reference Value: #/department.1 end of do start of DO DataObject type: apache.das#company Property: id Property Type: commonj.sdo#Int Property Value: 2 Property: name Property Type: commonj.sdo#String Property Value: acme Property: department Property Type: apache.das#department Value 0 Reference Value: #/department.2 Value 1 Reference Value: #/department.3 end of do start of DO DataObject type: apache.das#company Property: id Property Type: commonj.sdo#Int Property Value: 1 Property: name Property Type: commonj.sdo#String Property Value: apache Property: department Property Type: apache.das#department Value 0 Reference Value: #/department.0 Value 1 Reference Value: #/department.1 end of do start of DO DataObject type: apache.das#company Property: id Property Type: commonj.sdo#Int Property Value: 2 Property: name Property Type: commonj.sdo#String Property Value: acme Property: department Property Type: apache.das#department Value 0 Reference Value: #/department.2 Value 1 Reference Value: #/department.3 Value 2 Reference Value: #/department.0 end of do So, as the output shows, the department.0 is added on the company2, but the reference to department.0 that company1 has is not removed. Should it work like this? Regards, Adriano
[jira] Resolved: (TUSCANY-1827) SDO Types based PK map needed in GraphMerger
[ https://issues.apache.org/jira/browse/TUSCANY-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1827. --- Resolution: Fixed SDO Types based PK map needed in GraphMerger Key: TUSCANY-1827 URL: https://issues.apache.org/jira/browse/TUSCANY-1827 Project: Tuscany Issue Type: Bug Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1827.patch DAS GraphMerger code has getPrimaryKeyName() based on SDO Type and addPrimaryKey() based on database Column name. So when these 2 are different GraphMerges fails to detect PKs. This is very similar bug to JIRA-1807. -- 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: SDO C++ doubts about change summary
Sorry, item 2 was my fault, not a sdo c++ problem. But the item 1 question remains. Adriano Crestani On 10/8/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I'm getting upset about how change summary logs a isMany property. 1- What does Setting ChangeSummary::getOldValue( DataObjectPtr dataobject, const Property property) returns if the property is many=true? 2- How can I retrieve info from the ChangeSummary, about a DO A that was removed from DO B where the Property C that relates these 2 DOs is many=true and reference=true? Because the there is no Setting on DO B SettingList that Setting::getProperty()=Property C and Setting::getDataObjectValue()=DO A. Adriano Crestani
Re: SDO C++ doubts about change summary
Not sure about C++ , but below is what happens in java impls. Giving example
xsd, test case and result (and 1 question)
-
test case
public class ChangeSummaryMyTestCase extends TestCase {
HelperContext hc;
XSDHelper xh;
TypeHelper th;
public void testCustomerDG() {
Type idt = th.getType(commonj.sdo, Int);
Type custt = SDOUtil.createType(hc, testcases.changesummary,
Customer, false);
Type ordert = SDOUtil.createType(hc, testcases.changesummary,
AnOrder, false);
Type cst = th.getType(commonj.sdo,ChangeSummaryType);
Property idProp = SDOUtil.createProperty(custt, ID, idt);
Property ordProp = SDOUtil.createProperty(custt, orders, ordert);
SDOUtil.setMany(ordProp, true);
Property idordProp= SDOUtil.createProperty(ordert, ID, idt);
SDOUtil.createProperty(ordert, changeSummary, cst);
DataGraph graph = SDOUtil.createDataGraph();
DataObject cust = graph.createRootObject(custt);
final DataObject order1 = hc.getDataFactory().create(ordert);
final DataObject order2 = hc.getDataFactory().create(ordert);
order1.setInt(ID, 1);
order2.setInt(ID, 2);
final ArrayList list = new ArrayList();
list.add(order1);
list.add(order2);
cust.setList(ordProp, list);
cust.set(ID, new Integer(1));
testCustomerBody(ordProp, cust, ordert);
}
private void testCustomerBody(Property orderProp, DataObject cust, Type
ordert) {
ChangeSummary csCust = cust.getChangeSummary();
csCust.beginLogging();
if(cust.getList(orderProp) == null)
System.out.println(orderProp is null);
else
System.out.println(orderProp is not null, orders in customer
size +cust.getList(orderProp).size());
if( ((DataObject)cust.getList(orderProp).get(0)).getChangeSummary()
== null ||
((DataObject)cust.getList(orderProp).get(1)).getChangeSummary()
== null )
System.out.println(orders change summary is null);
else
System.out.println(orders change summary is not null);
ChangeSummary csOrd1 =
((DataObject)cust.getList(orderProp).get(0)).getChangeSummary();
csOrd1.beginLogging();
ChangeSummary csOrd2 =
((DataObject)cust.getList(orderProp).get(1)).getChangeSummary();
csOrd2.beginLogging();
List coCust = csCust.getChangedDataObjects();
assertEquals(0, coCust.size());
((DataObject)cust.getList(orderProp).get(0)).setInt(ID, 10);
((DataObject)cust.getList(orderProp).get(1)).setInt(ID, 11);
((DataObject)cust.getList(orderProp).get(1)).delete();
final DataObject order3 = hc.getDataFactory().create(ordert);
ChangeSummary csOrd3 = order3.getChangeSummary();
csOrd3.beginLogging();
order3.setInt(ID, 12);
cust.getList(orderProp).add(order3);
cust.setInt(ID, 2);
assertEquals(0, coCust.size());
coCust = csCust.getChangedDataObjects();
assertEquals(1, coCust.size()); //TODO? why 1 why not 3 changes - 1
add order, 1 delete order, 1 change cust id
List custOldValues = csCust.getOldValues((DataObject)coCust.get(0));
System.out.println(customer change history OldValues size
+custOldValues.size());
ChangeSummary.Setting ovCust1 =
(ChangeSummary.Setting)custOldValues.get(0);
Property povCust1 = ovCust1.getProperty();
System.out.println(povCust1 + povCust1.getName());
Object custv = ovCust1.getValue();
System.out.println(changes in first change +
((List)custv).size());
System.out.println(1st change is in order1 ID:
+((DataObject)((List)custv).get(0)).getInt(ID));
System.out.println(2nd change is in order2 ID:
+((DataObject)((List)custv).get(1)).getInt(ID));
System.out.println(new num of orders in customer
+cust.getList(orderProp).size());
ChangeSummary.Setting ovCust2 = (ChangeSummary.Setting
)custOldValues.get(1);
Property povCust2 = ovCust2.getProperty();
System.out.println(povCust2 +povCust2.getName());
assertEquals(ID, povCust2.getName());
System.out.println(old value customer ID: + ovCust2.getValue());
System.out.println(new value customer ID
:+((DataObject)coCust.get(0)).get(ID));
System.out.println(csOrd1 co size
+((List)csOrd1.getChangedDataObjects()).size());
System.out.println(csOrd1 co size
+((List)csOrd1.getChangedDataObjects()).size());
ChangeSummary.Setting ovOrd1 = (ChangeSummary.Setting
)((List)csOrd1.getOldValues((DataObject)((List)csOrd1.getChangedDataObjects()).get(0))).get(0);
Property pOrd1 = ovOrd1.getProperty();
assertEquals(ID, pOrd1.getName());
Object vOrd1 = ovOrd1.getValue();
System.out.println(order1 old value ID:+vOrd1);
helloworld-ws-reference-secure sample failing to build?
I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703 sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:130) ... 36 more ...ant
Re: helloworld-ws-reference-secure sample failing to build?
Yes, I am seeing this from a mvn clean ; mvn on r582825 On 10/8/07, ant elder [EMAIL PROTECTED] wrote: I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703 sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:130) ... 36 more ...ant
[jira] Created: (TUSCANY-1836) JMS Binding does not conform to the specification when creating JMS queues
JMS Binding does not conform to the specification when creating JMS queues -- Key: TUSCANY-1836 URL: https://issues.apache.org/jira/browse/TUSCANY-1836 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-1.0 Environment: SVN Revision #582742 Linux Reporter: Mark Combellack Priority: Minor Fix For: Java-SCA-Next Currently, the way that the JMS Binding creates JMS queues is not compliant with the SCA JMS Binding specification. Currently it looks for the JMS Queue. If it does not exist, it will attempt to create it if the create mode is CREATE_ALLWAYS. The JMS Binding specification says: 137• /binding.jms/destination/@create - indicates whether the destination should be created 138when the containing composite is deployed. Valid values are always, never and 139ifnotexist. The default value is ifnotexist. If always is specified and the corresponding 140resource already exists, then this should be considered an error. The current implementation does not handle the following scenarios correctly: * Queue existing and always specified * No support for ifnotexist Also, throughout the code CREATE_ALLWAYS is spelt wrongly. -- 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-1836) JMS Binding does not conform to the specification when creating JMS queues
[ https://issues.apache.org/jira/browse/TUSCANY-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Combellack updated TUSCANY-1836: - Attachment: JMSQueueCreateModes_Tests.patch JMSQueueCreateModes.patch The patch JMSQueueCreateModes.patch updates the JMS binding to make it specification compliant in the way it creates it's JMS queues The patch JMSQueueCreateModes_Tests.patch adds unit tests for the various queue creation scenarios. JMS Binding does not conform to the specification when creating JMS queues -- Key: TUSCANY-1836 URL: https://issues.apache.org/jira/browse/TUSCANY-1836 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-1.0 Environment: SVN Revision #582742 Linux Reporter: Mark Combellack Priority: Minor Fix For: Java-SCA-Next Attachments: JMSQueueCreateModes.patch, JMSQueueCreateModes_Tests.patch Currently, the way that the JMS Binding creates JMS queues is not compliant with the SCA JMS Binding specification. Currently it looks for the JMS Queue. If it does not exist, it will attempt to create it if the create mode is CREATE_ALLWAYS. The JMS Binding specification says: 137• /binding.jms/destination/@create - indicates whether the destination should be created 138when the containing composite is deployed. Valid values are always, never and 139ifnotexist. The default value is ifnotexist. If always is specified and the corresponding 140resource already exists, then this should be considered an error. The current implementation does not handle the following scenarios correctly: * Queue existing and always specified * No support for ifnotexist Also, throughout the code CREATE_ALLWAYS is spelt wrongly. -- 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: JMS Binding for Tuscany Java
On 9/24/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/22/07, Joseph, Roshan IN BLR SISL [EMAIL PROTECTED] wrote: Hi all, I believe the JMS binding is not included in the latest release and if it is due to bugs, I would like to contribute in making it work. Can someone point to the issues in JMS binding or let me know the current status of it. Any help in this regard will be really helpful, as I would like to utilize the binding for my prototype which I am making Thanks Roshan Important notice:This e-mail and any attachment thereto contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You. Hi Roshan You are right, the JMS binding is not included in the latest release. Someone else has just asked about it's status (https://issues.apache.org/jira/browse/TUSCANY-1789). Basically the JMS binding got to a stage where it supported request/response type message patterns but not the full asynchronous model you might expect (see the unit tests included with the binding). It does run currently and it's included in the build so if you check the latest Java SCA code out of trunk you can play with it. I note, looking at SVN, that there have been a few changes over the last month or so, including a new implementation of the jms binding model. Your help would be very much appreciate in improving the JMS binding. Shall we start making a list here of the things that need to be done? Something that springs to mind just having had a brief refresh of the code is 1/ move the model information from o.a.t.s.binding.jms.impl.JMSBinding to the new model classes under o.a.t.s.binding.jms Regards Simon Hi Joseph Did you make and progress with your prototype. Do you need any more help/info. One of our other users has provided some patches to the JMS binding recently you might want to take a look at. Regards Simon
Re: helloworld-ws-reference-secure sample failing to build?
Yes. I too see this and am right now fixing it. Regret the inconvenience. - Venkat On 10/8/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Yes, I am seeing this from a mvn clean ; mvn on r582825 On 10/8/07, ant elder [EMAIL PROTECTED] wrote: I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:130) ... 36 more ...ant
Re: helloworld-ws-reference-secure sample failing to build?
Fixed under r582882. The sample is now going ok for me. Could you also try, please ? Thanks - Venkat On 10/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. I too see this and am right now fixing it. Regret the inconvenience. - Venkat On 10/8/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Yes, I am seeing this from a mvn clean ; mvn on r582825 On 10/8/07, ant elder [EMAIL PROTECTED] wrote: I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:130) ... 36 more ...ant
Re: helloworld-ws-reference-secure sample failing to build?
Works for me now, thanks! ...ant On 10/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Fixed under r582882. The sample is now going ok for me. Could you also try, please ? Thanks - Venkat On 10/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. I too see this and am right now fixing it. Regret the inconvenience. - Venkat On 10/8/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Yes, I am seeing this from a mvn clean ; mvn on r582825 On 10/8/07, ant elder [EMAIL PROTECTED] wrote: I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase ) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:130) ... 36 more ...ant
[NOTICE] Amita Vadhavkar voted as Tuscany committer
The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. -- 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]
Re: [NOTICE] Amita Vadhavkar voted as Tuscany committer
Congrats Amita :D Adriano Crestani On 10/8/07, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. -- 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]
Re: helloworld-ws-reference-secure sample failing to build?
Same here. On 10/8/07, ant elder [EMAIL PROTECTED] wrote: Works for me now, thanks! ...ant On 10/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Fixed under r582882. The sample is now going ok for me. Could you also try, please ? Thanks - Venkat On 10/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. I too see this and am right now fixing it. Regret the inconvenience. - Venkat On 10/8/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Yes, I am seeing this from a mvn clean ; mvn on r582825 On 10/8/07, ant elder [EMAIL PROTECTED] wrote: I've been getting a build fail in helloworld-ws-reference-secure for a while now with the error below, does anyone else see this? Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.703sec FAILURE! testEmbeddedReferenceClient(helloworld.HelloWorldClientTestCase ) Time elapsed: 2.859 sec ERROR! java.lang.reflect.UndeclaredThrowableException Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException : WSDoAllReceiver: Incoming message does not contain required Security header at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke ( Axis2BindingInvoker.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:73) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:130) ... 36 more ...ant
Re: [NOTICE] Amita Vadhavkar voted as Tuscany committer
On 10/8/07, Adriano Crestani [EMAIL PROTECTED] wrote: Congrats Amita :D Adriano Crestani On 10/8/07, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. -- 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] Congratulations and welcome on board Amita. Simon
Re: [NOTICE] Amita Vadhavkar voted as Tuscany committer
A big welcome from me Amita, you really deserve this. ...ant On 10/8/07, Luciano Resende [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. -- 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]
Re: Policy support for implementation elements
Venkata Krishnan wrote: Hi, I've been trying to figure out if there is a common pattern in how implementations and bindings could be interpretting and applying policies so that we could include this in the SPI. But haven't been successful with this. Maybe with getting policies to work with a few implementation types will give a better idea. So, to start with I have extended the java implementaion type a bit to support policies. I have picked on the 'Logging' intent for now and have implemented a rudimentary logging mechanism that simply uses System.out.println. I am going to soon replace this with a formal Logging system. I've been looking a SLF4J so that we could facilitate switching of various logging implementations thro policy specifications. But seems like there is no programmatic way of binding the logging options (such as log4j or JDK Logging) into SLF4J. The logging implementation jar in the classpath is the one that would get picked up it seems. So for now I plan to go on with using the JDK Logger and having policies to specify the logging levels, logging handlers and so on. +1 to use the JDK logger as this is what we're using for logging inside the Tuscany runtime as well. Is the Logging policy a sample policy? or are you planning to make it available in Tuscany for people to use in their applications? Can you show what the XML to turn logging on looks like? While I am working on completing this, I'd like to explore another implementation type for including policy support for a QoS - maybe transactions. Good idea! There's a public draft of a Transaction spec at OSOA and several people on the dev and user list have expressed an interest in the transaction policy. I'd appreciate a lot if people could give me some feedback on the approach I have taken for the java implementation type and also suggestions on a implementation type that we could pickup for supporting transactions. How about changing the Online Store sample to update a database from the ShoppingCart Java component as a starting point? Thanks. - Venkat -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A demo application to showcase our XML integration story
Raymond Feng wrote: I'd quite like to see some transformation going on , i.e. something like an implementation.xslt. Isn't Saxon also an XSLT processor so can we already do this? The XSLT is already in the JDK (javax.xml.transform or TrAX). Apache Xalan is one of the implementations. It would be nice to support implementation.xslt. There could be something mappings between XSLT and SCA. The implementation.xslt could have a fixed operation to transform the XML inforset such as: Node transform(Node ...); We can also map XSLT functions to be SCA services. Top-level xsl:param might be used as SCA properties. Injecting of SCA references will be interesting too. We already have XQuery support. Can't we do the same kind of transformation (and more readable) with XQuery? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A demo application to showcase our XML integration story
Raymond Feng wrote: Hi, I put together a demo application to showcase our XML integration story. The business scenario is derived from the bigbank demo and the main function is to calculate the total value (using a selected currency) of a customer who has checking/saving/stock accounts. At this moment, I add three different sources to provide XML data. 1) A live feed to retrieve the exchange rate (binding.feed) and use XPath to exact the rate for a given currency. I have to use Rome API to convert the feed as our feed binding produces Feed objects. 2) The account data for a customer is loaded from a XML file. (We can use implementation.data once Sebastien's proposal is implemented). 3) A live Web Service invocation to get the quotes for a list of symbols. Only XMLStreamReader is used as the input and output. (binding.ws) 4) The calculation of the total value is implemented using XQuery to join the XML data from 2 and 3. (implementation.xquery) The demo application is checked in under r581755. I hope we can use it as a test-bed to further drive our XML integration story. Please feel free to chime in with your ideas, for example, add implementation.data or implementation.das, or implementation.bpel. Thanks, Raymond A few comments: - This looks pretty good! - CustomerAsset looks like the AccountService from the Java Bigbank demo, if it's the same thing then it should be named AccountService to avoid any confusion and make the comparison easier. - I think we should try to remove all Java code from the demo and try to implement CustomerAsset (or AccountService) as a BPEL process or an XQuery function. and a question: - What would it take to return Account summary complex documents from the AccountService instead of just a number? Can we do this without having to generate any code? (I'd like to do change the Java Bigbank demo to return account summaries as well, like the original Bigbank scenario described in the original spec docs) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
To copy or not to copy, that is the question, was: Pass-by-value interceptor
Raymond Feng wrote:
More comments inline.
Thanks,
Raymond
- Original Message - From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, October 05, 2007 1:57 PM
Subject: Re: Pass-by-value interceptor
Maybe it would help for me to point out that I'd opened 1678,79,80
before
the refactoring for
TUSCANY-1559 was performed.
As I have the time I'll try to understand to what degree if any 1559 may
have addressed the issues I mentioned.
But Raymond, on the surface it seems like you're suggesting going
back to
how it was pre-1559, though with
a per-implementation-type extension instead of just the old
PassByValueInvoker associated with the Java implementation.
Yes.
To me it seemed like one not-too-hard change to address 1678 would
be to
have a flag in the Message SPI
that says, there's no need to do a copy. This would be off by
default but
a binding impl or databinding transform could switch it on.
We're trying hard to avoid additional fields on the Message unless
it's absolutely necessary.
I'm not sure if it's a good idea to rely on the pass-by-value
interceptor to deal with object marshaling/unmarshaling accross
classloaders. To handle the optimization for co-located components
(different classloader) in the same VM, we probably should add an
marshaling interceptor on the client side and unmarshling
interceptor on the service side.
On 10/5/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I'm looking into JIRA TUSCANY-1678, TUSCANY-1679, TUCANY-1680. At this
moment, the pass-by-value interceptor is added by the
DataBindingRuntimeWireProcessor. I start to wonder if it's the right
approach. The pass-by-value semantics is somehow
implementation-specific
and
it also requires some metadata from the Implementation (for example,
@AllowsPassByReference in java components). It seems that the
implementation
type extension will have more knowledge to enforce the pass-by-value.
Does it make better sense to have implementation type extension be
responsible to set up the pass-by-value interceptor?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
A few thoughts... If I understand correctly, we're trying to guarantee
that business data flowing through a remote interface is guaranteed to
not be changed.
Looking at a number of scenarios, I'm making the following observations:
- Some bindings can guarantee it because they're just writing the data
to a network connection.
- Other bindings can't guarantee it because they're passing a pointer to
the data in memory to somebody else.
- Some component implementations can guarantee that, for example if I
remember correctly a BPEL process will not modify its input data, a
mediation component if we had one would probably not change its input
data either.
- Other component implementations will pass a pointer to the data in
memory to user code, and can't guarantee that the user code won't change it.
- Some component implementations (e.g. Java) have defined a way for the
application developer to declare that he'll be nice and won't modify the
data (see @AllowsPassByReference).
- In some cases, whatever the binding or component implementation say,
the Tuscany databinding machinery must convert the data from one
representation to another, indirectly protecting the original data
against any changes.
- The same extends to other types of interceptors, for example an
encryption or compression interceptor naturally protects the data
against changes as it passes an encrypted or compressed representation
of the data in place of the original data.
- Finally, all the above conditions must be evaluated on a business
operation basis.
Considering all this, I think bindings, implementations, and all
interceptors in an invocation chain should state if they are going to
protect data against changes or not, and we need that information on an
operation basis. I'd suggest to add a method to oat.sca.invocation.Invoker {
// I'm not sure about the best name for this method.
boolean allowsPassByReference();
or
boolean doesNotChangeInputData();
or
boolean protectsInputData();
}
The wire algorithm will have to call that method on the Invokers in an
invocation chain to decide if it's safe to pass the original data or if
a copy of the data should be passed instead. If an invoker claims to
protect the data then we can pass the original data, if no invoker in
the invocation chain claims to protect the data then we need to copy it.
Now the next question is: Who should perform the copy?
I don't think it's fair to require bindings and implementations to know
how to copy all the different data representations supported in Tuscany
:) I think it's better to have a generic CopyInterceptor to do that,
leveraging the databinding framework.
On the other hand, if
Re: [NOTICE] Amita Vadhavkar voted as Tuscany committer
Amita, Congratulations and welcome. Well deserved. Yours, Mike. Luciano Resende wrote: The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SDO C++] DO having no container after removed from a reference list
Hi,
The code above is from DataObjectListImpl.cpp. As far as I know, when a DO
is removed from a non-containment Property, it should not loose its
container. Although, when it's removed from a list it's not checking if the
property is containment or not, it always set the removed DO container as
NULL.
DataObjectPtr DataObjectListImpl::remove(unsigned int index)
{
validateIndex(index);
if (container != 0)
{
container-logChange(pindex);
}
DataObjectPtr d = (*this)[index];
// log deletion only if the list is of data objects.
if (theFactory != 0)
{
const Type t = theFactory-getType(typeURI,typeName);
const Property p = container-getPropertyFromIndex(pindex);
if (!t.isDataType() !p.isReference())
{
(getVec()[index])-logDeletion();
}
}
plist.erase(plist.begin()+index);
DataObject* dob = getRawPointer(d);
((DataObjectImpl*)dob)-setContainer(0); // should check if is
a contaiment property before execute this operation
return d;
}
If everything is ok, I will create a jira for that.
Adriano Crestani
Re: could databinding-axiom Object2OMElement construct a default elem?
Raymond Feng wrote: Hi, In a short answer, yes. We should try to create a dummy element in such case. I believe we already do that for DOM. Do you want to provide a patch :-)? Thanks, Raymond Could you help a me understand why a dummy element is needed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding intents and policy sets to JavaImplementation instances
Venkata Krishnan wrote: Hi, As I am extending policy support for implementations I realize that we have trouble with aggregating intents and policysets in an JavaImplementation instance. The reason for this is that JavaImplementation instances could be reused in cases where two or more components provide services thro the same implementation. There is also a JIRA - https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this problem with a nice example. The JIRA has a patch that solves the issue to some extent and not entirely. If JavaImplementaition instances are going to be reused when the same implemenation is used by two or more components, then we need an alternative to store the intents / policy sets so that they are unique for each component. Take for example composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CompositeX component name=ComponentA requires=managedTransaction.none implementation.java class=test.DataServiceImpl / /component component name=ComponentB requires=managedTransaction.global implementation.java class=test.DataServiceImpl r/ /component /composite Are you sure that this is what you meant in the example? or did you mean: component name=ComponentA implementation.java class=test.DataServiceImpl requires=managedTransaction.none/ /component component name=ComponentB implementation.java class=test.DataServiceImpl requires=managedTransaction.global/ /component Here there is going to be a single instance of JavaImplementation that will be used for both components. But it happens that both these components have different intents defined and these intents will be inherited by the implementations. At the present moment I can only think of storing this info in the Component but I am absolutely uncomfortable with this pollutes the assembly model design for 'Component'. Any other ideas that folks can suggest for this ? Thanks - Venkat Intents and policySets specified in component/implementation should not be stored in the Implementation model as they actually configure the Component and not the Implementation (as reported in JIRA 1765). Storing them in the Component model makes more sense to me, what wrong with doing that? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] SCA Domain
ant elder wrote: On 10/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 9/29/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Here's sample code to illustrate that use case: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/domain-and-node/samples/ SampleTuscanyDomainImplementation.java Why does that sample need to add and start composites with: // Add the Calculator deployable composite to the domain composite domain.addComposite(new QName(http://calc;, Calculator)); // Start the Calculator composite domain.startComposite(new QName(http://calc;, Calculator)); The contribution jar is going to have the sca-contribution.xml (or the composites in the deployables folder we once talked of supporting), No, sca-contribution.xml is optional. so can't the simplest case just be adding the contribution and the deployable composites get started automatically? I don't think that having to write a sca-contribution.xml file is the simplest case. contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://calc; xmlns:sample=http://calc; deployable composite=calc:Calculator/ /contribution vs domain.addComposite(new QName(http://calc;, Calculator)); Placing the composite file under META-INF/deployables will appear simple to some people, but will not necessarily play well with other people using IDEs for example which often hide META-INF, or people who are not used to place their development artifacts, .wsdl, .xsd, .componentType, or .composite... under META-INF. Agree about sca-contribution.xml not being simplest nor META-INF/deployables, but we've had this discussion before and couldn't get much agreement on anything else. Take the Tuscany/Geronimo integration as an example, deploying an sca contribution jar on that and the code can only tell which composites to add based on somethng like sca-contribution.xml or doing some default behaviour like add all composites or add no composites. Does the spec say anywhere that when there is no sca-contribution.xml then composites in a contribution must not be added by default? ...ant Assembly specification V1.0 2867 The contribution optionally contains a document that declares runnable composites, exported 2868 definitions and imported definitions. ... 2887 deployable element: Identifies a composite which is a composite within the contribution that is 2888 a composite intended for potential inclusion into the virtual domain-level composite. Other 2889 composites in the contribution are not intended for inclusion but only for use by other 2890 composites. New composites can be created for a contribution after it is installed, by using the 2891 add Deployment Composite capability and the add To Domain Level Composite capability. This tells me that: - sca-contribution.xml is optional - composites not listed as deployables are not intended for inclusion - composites can be included in the domain after contribution, manually using the addDeploymentComposite and addToDomainLevel operations - the spec says potential inclusion and does not even imply that deployable composites should be included in the domain by default Including all composites in the domain by default when there's no sca-contribution.xml is going to be pretty inconvenient and confusing as it'll force people to ship an empty sca-contribution.xml file in all contributions containing only composites intended for use by other composites (aka implementations). I don't think that this was the intent of the spec. If it's not clear, we should send an issue to the assembly spec OASIS TC. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: could databinding-axiom Object2OMElement construct a default elem?
Hi, When we introspect the simple types on a java method, we map it to a xsd type, such as java.lang.String to xsd:string. When it's converted to some databindings which requires an element (such as DOM or AXIOM), we need to have an xsd element. The element information can be derived from either the source or target data type. In case that none of them have the element information, we will create a dummy element. It's similar to convert a SDO data object into a DOM Node (Customer -- dummy xsi:type=Customer.../dummy). Ideally, the remotable java interface could be normalized as WSDL by applying the java2wsdl rules. Then the element names for the parameters can be ns:param0, ns:param1, etc. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 3:16 PM Subject: Re: could databinding-axiom Object2OMElement construct a default elem? Raymond Feng wrote: Hi, In a short answer, yes. We should try to create a dummy element in such case. I believe we already do that for DOM. Do you want to provide a patch :-)? Thanks, Raymond Could you help a me understand why a dummy element is needed? -- 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: [DISCUSS] SCA Domain
ant elder wrote: On 10/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 9/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Why all the static and abstract methods? Is there a reason SCADomain couldn't just be an interface with a separate SCADomainFactory for creating instances? I don't know. A factory works for me. +1 for making SCADomain an interface +1 for having a factory So instead of: SCADomain domain = SCADomain.newInstance(...) We'll have: SCADomainFactory domainFactory; SCADomain domain = domainFactory.createSCADomain(domainURI) Now how do people would like to the get factory? a pretty common pattern is: SCADomainFactory domainFactory = SCADomainFactory.newInstance(...) Is there a better pattern? Does that answer the question about why the static and abstract methods? :) The question wasn't so much about why use static and abstract methods but why they were all munged into the one SCADomain class, now that its accepted that is better to have a separate SCADomain interface i think its fine to keep the static and abstract methods on the SCADomainFactory as that keeps the API simple to use. So this code: SCADomainFactory domainFactory = SCADomainFactory.newInstance(); SCADomain domain = domainFactory.createSCADomain( http://mydomain:7890/asmalldomain;); could be simplified to: SCADomain domain = SCADomainFactory.createSCADomain( http://mydomain:7890/asmalldomain;); ...ant Can you help me understand: - how people will be able to plug-in different factories? - how to pass the factory to use? I'm not sure I understand how it'll be possible with createSCADomain() being a static method. Thanks -- Jean-Sebastien Um, it would just work similarly to the current SCADomain class, the impl of any other static methods can still call newInstance so can still plug in different factories. ...ant Sorry I still don't understand how SCADomain domain = SCADomainFactory.createSCADomain(http://mydomain:7890/asmalldomain;); will allow to plug-in different factories. I'm guessing how it'll allow to plug-in different Domain implementations (like SCADomain did) but I'm confused by the factory proposal. What will the factory look like to allow for pluggability? and once a factory has been selected how will it be passed around? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Evolving Implementation-data
Luciano Resende wrote: Hey Douglas Thanks for volunteering, maybe you could start by prototyping the JDBC version of implementation-data that would return a XMLStreamReader. Once we flush out the design details, then we could think about the other CUD operations. Sebastien, and others... Thoughts ? It might be even better to start from a sample, without even using implementation-data at the beginning. I'd suggest the Online Store sample under samples/store, try to change CatalogImpl.java component to get the Catalog from a database using JDBC (instead of a hardcoded table in memory), and return either an XMLStreamReader or the current Item objects. Then try the same thing with the ShoppingCartImpl component, this will help us understand what to do for updates, deletes etc. Then once we've been through that sample we'll probably have a clearer idea of what implementation-data needs to do... basically automate what we wrote by hand in the sample. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: could databinding-axiom Object2OMElement construct a default elem?
Raymond Feng wrote: Hi, When we introspect the simple types on a java method, we map it to a xsd type, such as java.lang.String to xsd:string. This may be a dumb question :) why don't we convert a method parameter (I guess that's what you meant) to an element in the first place? Isn't that what happens anyway with a doc / wrapped Java - XSD mapping? Isn't an XSD element converted into a parameter in the other direction? How could a parameter be represented by a type? maybe I'm really confused and this is a really dumb question :) When it's converted to some databindings which requires an element (such as DOM or AXIOM), we need to have an xsd element. The element information can be derived from either the source or target data type. In case that none of them have the element information, we will create a dummy element. It's similar to convert a SDO data object into a DOM Node (Customer -- dummy xsi:type=Customer.../dummy). Ideally, the remotable java interface could be normalized as WSDL by applying the java2wsdl rules. Then the element names for the parameters can be ns:param0, ns:param1, etc. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 3:16 PM Subject: Re: could databinding-axiom Object2OMElement construct a default elem? Raymond Feng wrote: Hi, In a short answer, yes. We should try to create a dummy element in such case. I believe we already do that for DOM. Do you want to provide a patch :-)? Thanks, Raymond Could you help a me understand why a dummy element is needed? -- 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] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Policies associated with an operation, was Re: Policy support for implementation elements
Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi, I've been trying to figure out if there is a common pattern in how implementations and bindings could be interpretting and applying policies so that we could include this in the SPI. But haven't been successful with this. Maybe with getting policies to work with a few implementation types will give a better idea. Looking at this I noticed that Policy.getOperations() is still commented out. Are you going to put the operation support back? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Further enhancements for implementation.xquery
Comments inline.
Raymond Feng wrote:
Hi,
I spent more time reviewing the XQuery implementation type. I think
it's a great addition to our XML story. Let me share some of the
questions and suggestions I have so far.
1) The implementation.xquery model
The current code only supports: implementation.xquery
location=location_of_the_xquery_script/. It requires that we locate
and load a file which is not very consistent with other extensions (we
use QNames to identify artifacts).
I suggest that we use the QName of the XQuery function instead of the
location.
+1 to make it more consistent with the other XML patterns in SCA. This
will also allow people to package their XQueries in other SCA
contributions and import them with SCA import statements.
For the following XQuery function,
declare namespace quoteJoin=scaservice:java/xquery.quote.QuoteJoin;
declare function quoteJoin:joinPriceAndAvailQuotes($priceQuoteDoc,
$availQuoteDoc, $taxRate)
I assume the QName will be:
{scaservice:java/xquery.quote.QuoteJoin}joinPriceAndAvailQuotes
implementation.xquery xmlns:f=function_ns_uri
function=f:function_name/
Do we also want to support the inline XQuery such as
implementation.xquery script=the_text_of_xquery_script?
Not sure about the value of this, as:
- It won't allow you to edit the XQuery using any kind of XQuery tool,
as it won't like the SCA composite elements around the XQuery
- It will start to pollute the composite, which is mostly about
assembly, with implementation details
- it will force the application developer to duplicate the whole text of
the XQuery into each component/implementation element.
2) How to map the SCA services/references/properties to XQuery?
We currently use the namespace in XQuery to define SCA
services/references/properties as follows:
declare namespace
quoteJoin=scaservice:java/xquery.quote.PropertiesQuoteJoin;
declare namespace
quoteCalculator=scareference:java/xquery.quote.QuoteCalculator;
declare namespace
priceQuoteDoc=scaproperty:xml/http://www.example.org/price:priceQuote;;
declare namespace taxRate=scaproperty:java/java.lang.Float;
declare variable $quoteCalculator external;
declare variable $priceQuoteDoc external;
declare variable $availQuoteDoc external;
declare variable $taxRate external;
I suggest that we refine the naming convention of the namespaces.
What would people like to propose. It would nice if we could leave
namespaces out of this and just use simple names...
The e-mail is getting lengthy. I'll post more questions/suggestions as
we go.
Thanks,
Raymond
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: could databinding-axiom Object2OMElement construct a default elem?
We have been talking about deriving/populating the element information for parameters and return value of a java method following the java2wsdl rules. I agree with you that should be the right direction. There are a few cases: 1) If the java interface is generated from WSDL, we can try to get the element/type information from the WSDL. For example, we can check the JAX-WS annotations for the metadata. 2) If no hint is provided, we can use dummy names such as param0, param1 and return. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 4:14 PM Subject: Re: could databinding-axiom Object2OMElement construct a default elem? Raymond Feng wrote: Hi, When we introspect the simple types on a java method, we map it to a xsd type, such as java.lang.String to xsd:string. This may be a dumb question :) why don't we convert a method parameter (I guess that's what you meant) to an element in the first place? Isn't that what happens anyway with a doc / wrapped Java - XSD mapping? Isn't an XSD element converted into a parameter in the other direction? How could a parameter be represented by a type? maybe I'm really confused and this is a really dumb question :) When it's converted to some databindings which requires an element (such as DOM or AXIOM), we need to have an xsd element. The element information can be derived from either the source or target data type. In case that none of them have the element information, we will create a dummy element. It's similar to convert a SDO data object into a DOM Node (Customer -- dummy xsi:type=Customer.../dummy). Ideally, the remotable java interface could be normalized as WSDL by applying the java2wsdl rules. Then the element names for the parameters can be ns:param0, ns:param1, etc. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 3:16 PM Subject: Re: could databinding-axiom Object2OMElement construct a default elem? Raymond Feng wrote: Hi, In a short answer, yes. We should try to create a dummy element in such case. I believe we already do that for DOM. Do you want to provide a patch :-)? Thanks, Raymond Could you help a me understand why a dummy element is needed? -- 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] -- 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: SCA JAVA - Checkstyle and PMD
ant elder wrote: On 10/2/07, Douglas Leite [EMAIL PROTECTED] wrote: After reading the SCA developer guide I had some doubts about the checkstyle and pmd. I have installed those like plug-ins in the Eclipse IDE. However, what I would like to know is if there is some specific configuration file, which was defined by Tuscany community, for those code formatters. I am a novice in the Tuscany project, and I hope to help the project as soon as I get more familiar with it. Sorry for my probable English mistakes. Thanks, Douglas Leite. Hey thanks for your interest in Tuscany. Thats actually old information in the developer guide which we need to clean up, most code doesn't use the checkstyle and pmd stuff and you can safely ignore that part of the guide. ..ant Since we're not using these .pmd and .checkstyle files, how about removing them to avoid any confusion? If there's no objection I can take care of it later this week. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SDO C++] DO having no container after removed from a reference list
Adriano,
This indeed seems to be a bug. Go ahead and write a JIRA please.
Thanks
Best regards,
Brady
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adriano Crestani
Sent: Monday, October 08, 2007 3:43 PM
To: tuscany-dev@ws.apache.org
Subject: [SDO C++] DO having no container after removed from a reference
list
Hi,
The code above is from DataObjectListImpl.cpp. As far as I know, when a
DO is removed from a non-containment Property, it should not loose its
container. Although, when it's removed from a list it's not checking if
the property is containment or not, it always set the removed DO
container as NULL.
DataObjectPtr DataObjectListImpl::remove(unsigned int index) {
validateIndex(index);
if (container != 0)
{
container-logChange(pindex);
}
DataObjectPtr d = (*this)[index];
// log deletion only if the list is of data objects.
if (theFactory != 0)
{
const Type t = theFactory-getType(typeURI,typeName);
const Property p = container-getPropertyFromIndex(pindex);
if (!t.isDataType() !p.isReference())
{
(getVec()[index])-logDeletion();
}
}
plist.erase(plist.begin()+index);
DataObject* dob = getRawPointer(d);
((DataObjectImpl*)dob)-setContainer(0); // should check if
is a contaiment property before execute this operation
return d;
}
If everything is ok, I will create a jira for that.
Adriano Crestani
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] SCA Domain
I think the pluggability of the factory is still there, same as SCADomainFactory.newInstance(). SCADomainFactory.newInstance() can follow the typical factory pattern to search for the sub class of SCADomainFactory. 1) The META-INF/services/org.apache.tuscany.sca.SCADomainFactory 2) The system property named as org.apache.tuscany.sca.SCADomainFactory 3) The default implementation class (hard-coded) If I understand correctly, Ant was proposing to have a shortcut 1) to replace 2). 1) SCADomain domain = SCADomainFactory.createSCADomain(http://mydomain:7890/asmalldomain;); 2) SCADomainFactory domainFactory = SCADomainFactory.newInstance(); SCADomain domain = domainFactory.createSCADomain(http://mydomain:7890/asmalldomain;); Personally, I prefer the style 2). It's cleaner and it will be more flexible if we have than one methods on the SCADomainFactory. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 3:55 PM Subject: Re: [DISCUSS] SCA Domain ant elder wrote: On 10/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 9/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Why all the static and abstract methods? Is there a reason SCADomain couldn't just be an interface with a separate for creating instances? I don't know. A factory works for me. +1 for making SCADomain an interface +1 for having a factory So instead of: SCADomain domain = SCADomain.newInstance(...) We'll have: SCADomainFactory domainFactory; SCADomain domain = domainFactory.createSCADomain(domainURI) Now how do people would like to the get factory? a pretty common pattern is: SCADomainFactory domainFactory = SCADomainFactory.newInstance(...) Is there a better pattern? Does that answer the question about why the static and abstract methods? :) The question wasn't so much about why use static and abstract methods but why they were all munged into the one SCADomain class, now that its accepted that is better to have a separate SCADomain interface i think its fine to keep the static and abstract methods on the SCADomainFactory as that keeps the API simple to use. So this code: SCADomainFactory domainFactory = SCADomainFactory.newInstance(); SCADomain domain = domainFactory.createSCADomain( http://mydomain:7890/asmalldomain;); could be simplified to: SCADomain domain = SCADomainFactory.createSCADomain( http://mydomain:7890/asmalldomain;); ...ant Can you help me understand: - how people will be able to plug-in different factories? - how to pass the factory to use? I'm not sure I understand how it'll be possible with createSCADomain() being a static method. Thanks -- Jean-Sebastien Um, it would just work similarly to the current SCADomain class, the impl of any other static methods can still call newInstance so can still plug in different factories. ...ant Sorry I still don't understand how SCADomain domain = SCADomainFactory.createSCADomain(http://mydomain:7890/asmalldomain;); will allow to plug-in different factories. I'm guessing how it'll allow to plug-in different Domain implementations (like SCADomain did) but I'm confused by the factory proposal. What will the factory look like to allow for pluggability? and once a factory has been selected how will it be passed around? -- 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: A demo application to showcase our XML integration story
Thank all of you for the feedback. More comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, October 08, 2007 12:28 PM Subject: Re: A demo application to showcase our XML integration story Raymond Feng wrote: Hi, I put together a demo application to showcase our XML integration story. The business scenario is derived from the bigbank demo and the main function is to calculate the total value (using a selected currency) of a customer who has checking/saving/stock accounts. At this moment, I add three different sources to provide XML data. 1) A live feed to retrieve the exchange rate (binding.feed) and use XPath to exact the rate for a given currency. I have to use Rome API to convert the feed as our feed binding produces Feed objects. 2) The account data for a customer is loaded from a XML file. (We can use implementation.data once Sebastien's proposal is implemented). 3) A live Web Service invocation to get the quotes for a list of symbols. Only XMLStreamReader is used as the input and output. (binding.ws) 4) The calculation of the total value is implemented using XQuery to join the XML data from 2 and 3. (implementation.xquery) The demo application is checked in under r581755. I hope we can use it as a test-bed to further drive our XML integration story. Please feel free to chime in with your ideas, for example, add implementation.data or implementation.das, or implementation.bpel. Thanks, Raymond A few comments: - This looks pretty good! - CustomerAsset looks like the AccountService from the Java Bigbank demo, if it's the same thing then it should be named AccountService to avoid any confusion and make the comparison easier. +1. I renamed it to AccountService. - I think we should try to remove all Java code from the demo and try to implement CustomerAsset (or AccountService) as a BPEL process or an XQuery function. Ant was proposing to have a java script component :-). I'm open. and a question: - What would it take to return Account summary complex documents from the AccountService instead of just a number? Can we do this without having to generate any code? We could try to return the AccountReport (w/ a list account summaries). If we don't want to code-gen, then we could use DOM, AXIOM or even XMLStreamReader. Or we could use XQuery or XSLT to produce HTML. I'm wondering if code-gen is always a bad thing. On one hand, it complicates the story a bit, but on the other hand, it demonstrates that application developers have the freedom of choices if they prefer strong-typed representation of XML infoset. (I'd like to do change the Java Bigbank demo to return account summaries as well, like the original Bigbank scenario described in the original spec docs) -- 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: A demo application to showcase our XML integration story
Raymond Feng wrote: - I think we should try to remove all Java code from the demo and try to implement CustomerAsset (or AccountService) as a BPEL process or an XQuery function. Ant was proposing to have a java script component :-). I'm open. I am proposing BPEL and/or XQuery here was the focus of XML-Bigbank is XML programming models, but It would be nice to have a variation of that demo with a Web 2.0 + scripting focus, with Javascript in the browser, a popular server-side scripting language - note that I didn't say Javascript again :) - and data/script integration in the various scripts. and a question: - What would it take to return Account summary complex documents from the AccountService instead of just a number? Can we do this without having to generate any code? We could try to return the AccountReport (w/ a list account summaries). +1 this is what the original Bigbank app was doing. If we don't want to code-gen, then we could use DOM, AXIOM or even XMLStreamReader. Or we could use XQuery or XSLT to produce HTML. I'm wondering if code-gen is always a bad thing. On one hand, it complicates the story a bit, If it complicates the story it's a bad thing, and why would I need a Java compiler to compile my XML app? but on the other hand, it demonstrates that application developers have the freedom of choices if they prefer strong-typed representation of XML infoset. Yes application developers have the freedom to pick their poison :) but we can use the Java version of Bigbank to show strongly (Java) type representation of XML. Once we change that demo back to return Account summary objects we can show SDO, JaxB etc. (I'd like to do change the Java Bigbank demo to return account summaries as well, like the original Bigbank scenario described in the original spec docs) -- Jean-Sebastien -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: could databinding-axiom Object2OMElement construct a default elem?
Raymond Feng wrote: We have been talking about deriving/populating the element information for parameters and return value of a java method following the java2wsdl rules. I agree with you that should be the right direction. There are a few cases: 1) If the java interface is generated from WSDL, we can try to get the element/type information from the WSDL. For example, we can check the JAX-WS annotations for the metadata. 2) If no hint is provided, we can use dummy names such as param0, param1 and return. Thanks, Raymond +2 :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1837) DataObject having its container set as NULL when removed from a non-containment property
DataObject having its container set as NULL when removed from a non-containment property Key: TUSCANY-1837 URL: https://issues.apache.org/jira/browse/TUSCANY-1837 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Reporter: Adriano Crestani Fix For: Cpp-Next http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24644.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]
Re: Transaction scenarios and test cases, was Re: I keep processing local transaction support
Hi Amita, the link below is unavailable. I will be waiting for your new words here. Thank you. Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have gathered some comments about work going on in JIRA-1816, JIRA-1700 and the draft Tx Policy Spec below. Also tried to list some scenarios. http://cwiki.apache.org/confluence/display/TUSCANY/Transaction+Intents+and+Transaction+Manager+support Please share your comments. Regards, Amita On 9/26/07, Luciano Resende wrote: What if we start be defining some scenarios and concrete test cases before we start making changes on the runtime ? This would probably make things much easier and would help on the integration with existing parts of the runtime. Thoughts ? Let me also think little more overnight and send a more elaborated e-mail tomorrow... On 9/25/07, shaoguang geng wrote: Hi, every one, Suggestion expected. I keep processing some try on local transaction support. I want to find a place to hold a only instance of a TransactionManager in Tuscany. Tuscany uses ExtensionPointRegistries to hold those global instances, so it seems TM instance should be held the same way. TM is going to be used by JavaImplementationInvoker, but its current structure has no relation to any EPRs. Thanks. - Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. -- 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] - Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
[jira] Resolved: (TUSCANY-1837) DataObject having its container set as NULL when removed from a non-containment property
[ https://issues.apache.org/jira/browse/TUSCANY-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1837. --- Resolution: Fixed bug fixed on revision 583039 DataObject having its container set as NULL when removed from a non-containment property Key: TUSCANY-1837 URL: https://issues.apache.org/jira/browse/TUSCANY-1837 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Reporter: Adriano Crestani Fix For: Cpp-Next http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24644.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]
Re: Transaction scenarios and test cases, was Re: I keep processing local transaction support
Hi, Please see the one http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Design+Discussion the page was moved, as TUSCANYWIKI is the correct place for discussions etc. By mistake I first created under TUSCANY Please give your comments there. Regards, Amita - Show quoted text - On 10/9/07, shaoguang geng [EMAIL PROTECTED] wrote: Hi Amita, the link below is unavailable. I will be waiting for your new words here. Thank you. Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have gathered some comments about work going on in JIRA-1816, JIRA-1700 and the draft Tx Policy Spec below. Also tried to list some scenarios. http://cwiki.apache.org/confluence/display/TUSCANY/Transaction+Intents+and+Transaction+Manager+support Please share your comments. Regards, Amita On 9/26/07, Luciano Resende wrote: What if we start be defining some scenarios and concrete test cases before we start making changes on the runtime ? This would probably make things much easier and would help on the integration with existing parts of the runtime. Thoughts ? Let me also think little more overnight and send a more elaborated e-mail tomorrow... On 9/25/07, shaoguang geng wrote: Hi, every one, Suggestion expected. I keep processing some try on local transaction support. I want to find a place to hold a only instance of a TransactionManager in Tuscany. Tuscany uses ExtensionPointRegistries to hold those global instances, so it seems TM instance should be held the same way. TM is going to be used by JavaImplementationInvoker, but its current structure has no relation to any EPRs. Thanks. - Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. -- 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] - Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
Re: [NOTICE] Amita Vadhavkar voted as Tuscany committer
Thanks everyone for the congratulations and welcome. It is a great experience working with you all. I am looking forward to the next exciting progress in Tuscany community and will try my best. Regards, Amita On 10/9/07, Mike Edwards [EMAIL PROTECTED] wrote: Amita, Congratulations and welcome. Well deserved. Yours, Mike. Luciano Resende wrote: The Tuscany PPMC and Incubator PMC have voted for Amita Vadhavkar to become a Tuscany committer. Congratulations and welcome Amita! I look forward to your continued excellent contributions to Tuscany. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
