RE: [SDO CTS] M1 Release Plan
I would prefer the first option of having Core, Optional and UnderReview test suites. Thanks, Andy. -Original Message- From: Dan Murphy [mailto:[EMAIL PROTECTED] Sent: 23 February 2007 12:03 To: Tuscany Developers Subject: [SDO CTS] M1 Release Plan Hi, The SDO Community Test Suite has amassed a good number of test cases since we started only a couple of months ago. In view of this, it seems we should think about a milestone 1 release. There are a couple of areas we could improve on so I'd appreciate comments and additional views/insights from the community. There are a couple of pages in the wiki ( http://cwiki.apache.org/confluence/display/TUSCANY/Index) about the SDO CTS, we could do with adding more pages - but I don't think this should gate an M1 release. I was wondering if we should have a number of main suites in the cts/sdo2.1 project. Currently we have the CTSGeneralSuite which includes the DateConversionTest XSDSerialisationTest DataObjectTest and DynamicTypesFromSchemaTestCase test cases classes. This is a subset of the test cases in the cts/sdo2.1 project. I guess there are a couple options. 1. Use a similar approach to the cts/sdo2.1-tuscany project and have Core, Optional and UnderReview suites 2. Group test cases into areas according to the part of the specification they cover. Whilst 2 seems like it could be interesting, I tend to prefer the first approach as I have a feeling that we may just end up with as many suites as test case classes . Alternatively we could just leave the decision to those using the CTS, although this may make it harder for a user (as opposed to an SDO implementer) to run and understand the tests - WDYT ? Comments greatly appreciated - what do you think needs to happen before we cut a M1 release ? Many thanks to Robbie and friends for their contributions to date. All the best, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Marshalling WireDefinitions for federated deployment
Hi, Just wanted to confirm a few things before I hack on .. 1. The unit of transmission between the master and slave is always going to be a PCS. 2. The PCS will contain collections of PWDs and PCDs 3. I am assuming we will use different namespaces for different types of PCDs (Java PCD for example) and have corersponding strong-typed sub-classes for PCD. 4. A PCD will have a collection of RD (Reference Definitions) and SD (Srevice Definiions), which will again use namespaces and concrete sub-types for supporting extensions. 5. WDs will contains a set of Ods (Operation Definitions), which will in turn contain a set of Ids (Interceptor Definitions). Ids will use namespaces and concrete sub-types for supporting extensions. 6. PhysicalChangeSet, PhysicalWireDefinition and OperationDefinition will be generic, whereas PhysicalComponentDefinition, ReferenceDefinition, ServiceDefinition and InterceptorDefinition will support extensions using namespaces and strong typed sub-classes for the extensions. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 1:30 AM To: tuscany-dev@ws.apache.org Subject: Re: Marshalling WireDefinitions for federated deployment For all of these: cns:component bns:reference and service ins:interceptorName the element is an extension-specific, unique, versioned identifier for the component implementation type, binding, or interceptor builder. Meeraj's unmarshalling framework is able to dispatch the to the appropriate unmarshaller in order to read the element in builder- specific manner. The content of that is completely under the control of the marshaller/unmarshaller for that extension so there is no need for xml extension hooks. This data is not intended for use by end-users so we can be very precise with the XML definitions (read really ugly XML, lots of namespaces etc.). We need that in order to maintain portability between different implementation and different versions of the same implementation. Hope that makes sense. -- Jeremy On Feb 25, 2007, at 3:00 PM, Jim Marino wrote: On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote: I'm little confused by this one. AIUI we have two configurations in the physical world: 1) two co-located components connected by a wire the PCS would contain two PCDs and a PWD for the connection 2) a component connected to the network via a binding the PCD would contain a PCD with binding configuration for the remote service/reference These could actually be mixed (a PCD may have one service/ reference bound to the network and another wired to a different co- located component). With that in mind, I don't see why we would have 'bindingType' on a PWD. In the optimal case, the controller would have reduced that to: wire source=foo#ref target=bar#srv/ In the non-optimal case, we would need to define interceptor chains for each of the source/callback operations, something like: wire source=foo#ref target=bar#srv interface operation name=method1* paramType type=type1/ !-- deals with overloading ins:interceptorName ...* !-- unique QName for each interceptor type callback operation name=cb1* ins:interceptorName ...* For the second configuration above, we would just specify binding configuration in the PCD for each physically bound service/ reference. Something like: cns:component name=foo ... bns:reference name=ref* !-- unique QName for reference binding ... binding config elements ... interface operation name=method1* paramType type=type1/ !-- do we need to deal with overloading? ins:interceptorName ...* !-- outbound interceptors callback operation name=method1* paramType type=type1/ ins:interceptorName ...* !-- inbound interceptors bns:service name=srv* !-- unique QName for service binding ... binding config elements ... interface ... callback ... I'm cool with the format above provided we allow for extensibility info in the interceptor (I think it needs to be more than a name). Having the param types as elements rather than attributes is better as is the separation of forward and callback ops. Also, you are right, we don't need binding type. 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This
SOAP 1.1 Spec Vs. SOAP 1.1 Schema inconsistencies
Hello there everyone, during my playing about with Tuscany SDO2 I have run into a problem using Tuscany to read in some of my existing SOAP test messages. I believe that the problem lies in an inconsistency between the SOAP 1.1 specification, and the SOAP 1.1 Schema. My test SOAP messages follow the Specification, and Tuscany sticks rigidly to the Schema. Below is my (inexpert) analysis of the inconsistency. The basic inconsistency is that the Specification allows the SOAP Envelope to have an encodingStyle attribute (and shows it in examples), but the Schema specifically forbids it. 4.1.1 SOAP encodingStyle Attribute The SOAP encodingStyle global attribute can be used to indicate the serialization rules used in a SOAP message. This attribute MAY appear on any element, and is scoped to that element's contents and all child elements not themselves containing such an attribute, much as an XML namespace declaration is scoped. There is no default encoding defined for a SOAP message. There is an example SOAP message in the prose of the specification that has encodingStyle on the Envelope SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:Body m:GetLastTradePrice xmlns:m=Some-URI symbolDIS/symbol /m:GetLastTradePrice /SOAP-ENV:Body /SOAP-ENV:Envelope Yet the SOAP 1.1 Schema says: xs:element name=Envelope type=tns:Envelope / - xs:complexType name=Envelope - xs:sequence xs:element ref=tns:Header minOccurs=0 / xs:element ref=tns:Body minOccurs=1 / xs:any namespace=##other minOccurs=0 maxOccurs=unbounded processContents=lax / /xs:sequence xs:anyAttribute namespace=##other processContents=lax / /xs:complexType xs:attribute name=encodingStyle type=tns:encodingStyle / - xs:attributeGroup name=encodingStyle xs:attribute ref=tns:encodingStyle / /xs:attributeGroup So the Schema says that Envelope only allows any attributes not in the same namespace (##other), yet encodingStyle is in the same namespace, and therfor is not allowed on Envelope. I may be making a mountain out of a molehill here, but the Spec and Schema don't seem to match up (assuming my interpretation is correct). This means that SDO2/Tuscany needs to realise this and decide whether to be as strict as they currently are (not allowing encodingStyle on Envelope) which may lead to incompatible-ness with old SOAP out there, or to specifically relax a bit and allow the attribute, even though it breaks the Schema. Just thought I should throw this out there for discussion and debate. I do not know how much existing SOAP there is with the encodingStyle attribute on the Envelope, or how much of it will/could be sent to Tuscany code for parsing, but I thought it would be better that an informed decision is made as to how Tuscany will behave. So - what do people think? Martin. ___ WebSphere ESB Foundation Technologies Mail Point 211 IBM United Kingdom Limited HursleySO21 2JN Phone: 01962 817395 (247395) Notes ID : Martin Phillips1/UK/[EMAIL PROTECTED] INTERNET : [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Marshalling WireDefinitions for federated deployment
+1 I'll add that ODs apply to PCDs as well as interceptors may be required between the component implementation and the binding's transport. -- Jeremy On Feb 26, 2007, at 4:23 AM, Meeraj Kunnumpurath wrote: Hi, Just wanted to confirm a few things before I hack on .. 1. The unit of transmission between the master and slave is always going to be a PCS. 2. The PCS will contain collections of PWDs and PCDs 3. I am assuming we will use different namespaces for different types of PCDs (Java PCD for example) and have corersponding strong-typed sub-classes for PCD. 4. A PCD will have a collection of RD (Reference Definitions) and SD (Srevice Definiions), which will again use namespaces and concrete sub-types for supporting extensions. 5. WDs will contains a set of Ods (Operation Definitions), which will in turn contain a set of Ids (Interceptor Definitions). Ids will use namespaces and concrete sub-types for supporting extensions. 6. PhysicalChangeSet, PhysicalWireDefinition and OperationDefinition will be generic, whereas PhysicalComponentDefinition, ReferenceDefinition, ServiceDefinition and InterceptorDefinition will support extensions using namespaces and strong typed sub-classes for the extensions. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 1:30 AM To: tuscany-dev@ws.apache.org Subject: Re: Marshalling WireDefinitions for federated deployment For all of these: cns:component bns:reference and service ins:interceptorName the element is an extension-specific, unique, versioned identifier for the component implementation type, binding, or interceptor builder. Meeraj's unmarshalling framework is able to dispatch the to the appropriate unmarshaller in order to read the element in builder- specific manner. The content of that is completely under the control of the marshaller/unmarshaller for that extension so there is no need for xml extension hooks. This data is not intended for use by end-users so we can be very precise with the XML definitions (read really ugly XML, lots of namespaces etc.). We need that in order to maintain portability between different implementation and different versions of the same implementation. Hope that makes sense. -- Jeremy On Feb 25, 2007, at 3:00 PM, Jim Marino wrote: On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote: I'm little confused by this one. AIUI we have two configurations in the physical world: 1) two co-located components connected by a wire the PCS would contain two PCDs and a PWD for the connection 2) a component connected to the network via a binding the PCD would contain a PCD with binding configuration for the remote service/reference These could actually be mixed (a PCD may have one service/ reference bound to the network and another wired to a different co- located component). With that in mind, I don't see why we would have 'bindingType' on a PWD. In the optimal case, the controller would have reduced that to: wire source=foo#ref target=bar#srv/ In the non-optimal case, we would need to define interceptor chains for each of the source/callback operations, something like: wire source=foo#ref target=bar#srv interface operation name=method1* paramType type=type1/ !-- deals with overloading ins:interceptorName ...* !-- unique QName for each interceptor type callback operation name=cb1* ins:interceptorName ...* For the second configuration above, we would just specify binding configuration in the PCD for each physically bound service/ reference. Something like: cns:component name=foo ... bns:reference name=ref* !-- unique QName for reference binding ... binding config elements ... interface operation name=method1* paramType type=type1/ !-- do we need to deal with overloading? ins:interceptorName ...* !-- outbound interceptors callback operation name=method1* paramType type=type1/ ins:interceptorName ...* !-- inbound interceptors bns:service name=srv* !-- unique QName for service binding ... binding config elements ... interface ... callback ... I'm cool with the format above provided we allow for extensibility info in the interceptor (I think it needs to be more than a name). Having the param types as elements rather than attributes is better as is the separation of forward and callback ops. Also, you are right, we don't need binding type. 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] This message has been checked for all email viruses
Re: databinding.TransformationTestCase failing? was: Making changes to the bindingsTest integration tests
Hi Sebastien, Yes, it was failing for me and ant (I believe). It seems to be caused by a change in behaviour resulting from the update of the SDO Snapshot. I'll open a jira On 24/02/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Dan Murphy wrote: Sorry Sebastien, I was meaning databindings not bindings... ignore my was going to write some... comment - although still interested in your thoughts on databinding-test On 22/02/07, Dan Murphy [EMAIL PROTECTED] wrote: Actually, looking at the recent changes to the pom files... it seems like the unit tests aren't of any concern, so I'll stop looking at these unless anyone thinks otherwise On 22/02/07, Dan Murphy [EMAIL PROTECTED] wrote: HI Sebastien, Although not working on the bindingsTest currently, I was planning to add some more test cases once I figured out why (and hopefully fixed) org.apache.tuscany.databinding.TransformationTestCase.testTransformation1which is failing since the SDO Implementation snapshot got updated... Maybe this isn't that important since it is an XMLBeans - SDO transform that fails... http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/testing/sca/itest/databinding/src/test/java/org/apache/tuscany/databinding/TransformationTestCase.java works for me. Does it still fail for you? If it still fails could you report the exception in a JIRA? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XMLBeans databinding
The XMLBeans databinding builds OK again this morning so I put it back as well as the databinding integration tests in the default profile. I was having problems building it on Friday because the xmlbeans Jars couldn't be downloaded from http://www.ibiblio.net/. Is there an alternate Maven repository for XMLBeans that we can use? The other thing is that our databinding integration tests currently depend on SDO, JAXB and XMLBeans, would it be possible to split this in two or three different test suites? SDO - JAXB SDO - XMLBeans JAXB - XMLBeans -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-709) Loads DataGraph in designated scope(TypeHelper)
[ https://issues.apache.org/jira/browse/TUSCANY-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-709: --- Patch Info: [Patch Available] Loads DataGraph in designated scope(TypeHelper) --- Key: TUSCANY-709 URL: https://issues.apache.org/jira/browse/TUSCANY-709 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Yang ZHONG Priority: Minor Fix For: Java-SDO-Mx Attachments: patch.709 SDOUtil.loadDataGraph doesn't support scope, this improvement tries to address that. TypeHelper#define registers Types with the corresponding TypeHelper instance (scope) and XMLHelper#load utilizes the registered Types from the corresponding scope to instantiate DataObject instances. Unfortunately yet, current SDOUtil.loadDataGraph 2-1. can't designate scope to register serialized Types, 2-2. and can't designate scope to utilize already registered Types in order to instantiate user expected DataObject instances. An example of 2-1 is SerializeTypesTestCase had to // The following is a kludge to force deserialization of metadata into a different TypeHelper (scope) // TBD figure out a proper non-EMF way to do this. Map options = new HashMap(); Object differentFromSerializing = ((TypeHelperImpl) deserializingTypeHelper).getExtendedMetaData(); options.put(XMLResource.OPTION_EXTENDED_META_DATA, differentFromSerializing); This proposal tries to adress scope by 2-1. add new SDOUtil.loadDataGraph(InputStream inputStream,Map options,TypeHelper scope)throws IOException 2-2. deprecate old SDOUtil.loadDataGraph(InputStream inputStream,Map options)throws IOException Any comment is welcomed. -- 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: Marshalling WireDefinitions for federated deployment
+1 Jim On Feb 26, 2007, at 4:23 AM, Meeraj Kunnumpurath wrote: Hi, Just wanted to confirm a few things before I hack on .. 1. The unit of transmission between the master and slave is always going to be a PCS. 2. The PCS will contain collections of PWDs and PCDs 3. I am assuming we will use different namespaces for different types of PCDs (Java PCD for example) and have corersponding strong-typed sub-classes for PCD. 4. A PCD will have a collection of RD (Reference Definitions) and SD (Srevice Definiions), which will again use namespaces and concrete sub-types for supporting extensions. 5. WDs will contains a set of Ods (Operation Definitions), which will in turn contain a set of Ids (Interceptor Definitions). Ids will use namespaces and concrete sub-types for supporting extensions. 6. PhysicalChangeSet, PhysicalWireDefinition and OperationDefinition will be generic, whereas PhysicalComponentDefinition, ReferenceDefinition, ServiceDefinition and InterceptorDefinition will support extensions using namespaces and strong typed sub-classes for the extensions. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Monday, February 26, 2007 1:30 AM To: tuscany-dev@ws.apache.org Subject: Re: Marshalling WireDefinitions for federated deployment For all of these: cns:component bns:reference and service ins:interceptorName the element is an extension-specific, unique, versioned identifier for the component implementation type, binding, or interceptor builder. Meeraj's unmarshalling framework is able to dispatch the to the appropriate unmarshaller in order to read the element in builder- specific manner. The content of that is completely under the control of the marshaller/unmarshaller for that extension so there is no need for xml extension hooks. This data is not intended for use by end-users so we can be very precise with the XML definitions (read really ugly XML, lots of namespaces etc.). We need that in order to maintain portability between different implementation and different versions of the same implementation. Hope that makes sense. -- Jeremy On Feb 25, 2007, at 3:00 PM, Jim Marino wrote: On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote: I'm little confused by this one. AIUI we have two configurations in the physical world: 1) two co-located components connected by a wire the PCS would contain two PCDs and a PWD for the connection 2) a component connected to the network via a binding the PCD would contain a PCD with binding configuration for the remote service/reference These could actually be mixed (a PCD may have one service/ reference bound to the network and another wired to a different co- located component). With that in mind, I don't see why we would have 'bindingType' on a PWD. In the optimal case, the controller would have reduced that to: wire source=foo#ref target=bar#srv/ In the non-optimal case, we would need to define interceptor chains for each of the source/callback operations, something like: wire source=foo#ref target=bar#srv interface operation name=method1* paramType type=type1/ !-- deals with overloading ins:interceptorName ...* !-- unique QName for each interceptor type callback operation name=cb1* ins:interceptorName ...* For the second configuration above, we would just specify binding configuration in the PCD for each physically bound service/ reference. Something like: cns:component name=foo ... bns:reference name=ref* !-- unique QName for reference binding ... binding config elements ... interface operation name=method1* paramType type=type1/ !-- do we need to deal with overloading? ins:interceptorName ...* !-- outbound interceptors callback operation name=method1* paramType type=type1/ ins:interceptorName ...* !-- inbound interceptors bns:service name=srv* !-- unique QName for service binding ... binding config elements ... interface ... callback ... I'm cool with the format above provided we allow for extensibility info in the interceptor (I think it needs to be more than a name). Having the param types as elements rather than attributes is better as is the separation of forward and callback ops. Also, you are right, we don't need binding type. 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] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com
Re: XMLBeans databinding
Hi, The XMLBeans is available at the default maven2 repo (http://repo1.maven.org/maven2/xmlbeans/xbean/2.2.0/). You can also add mirrors in settings.xml. Please see http://maven.apache.org/guides/mini/guide-mirror-settings.html for more details. +1 on the proposal to split. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 26, 2007 8:19 AM Subject: XMLBeans databinding The XMLBeans databinding builds OK again this morning so I put it back as well as the databinding integration tests in the default profile. I was having problems building it on Friday because the xmlbeans Jars couldn't be downloaded from http://www.ibiblio.net/. Is there an alternate Maven repository for XMLBeans that we can use? The other thing is that our databinding integration tests currently depend on SDO, JAXB and XMLBeans, would it be possible to split this in two or three different test suites? SDO - JAXB SDO - XMLBeans JAXB - XMLBeans -- 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: Databinding integration tests
Was about to replying on the other thread but this one seems better ... this proposal sounds good to me. Over the weekend i added a JavaScript E4X databinding [1], and plan in the future to also add ones for Ruby ReXML, Python ElementTree, and perhaps something for Groovy as well. That could make itesting all the databinding combinations a little onerous, so testing specific combinations sounds good, eg e4x uses axiom so just e4x-axiom itests are probably enough if axiom is tested with all the others. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/databinding.e4x/ On 2/26/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Althought the databinding-test project has been moved into the testing/sca project, the tests themselves could do with some improvements. If people agree, I'd like to seperate them into a number of sub projects that test individual databindings (ie. a sperate project for each SDO, JAXB etc) and one or more to test interoperbillity between them (eg SDO-JAXB) using default and WS bindings. Initially these tests would focus on client and inter composite transformations rather than inter component. I should be able to submitt them later this week, assuming it is felt better tests are approprite, and would be willing to try interlanguage later if needed (eg. Java SDO - Javascript or other composite/components). Cheers, Dan
[jira] Updated: (TUSCANY-1132) SDO Java serialization/deserialization throws an exception when the serialized data object is not the root and its container is of AnyTypeDataObject
[ https://issues.apache.org/jira/browse/TUSCANY-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1132: Patch Info: [Patch Available] SDO Java serialization/deserialization throws an exception when the serialized data object is not the root and its container is of AnyTypeDataObject Key: TUSCANY-1132 URL: https://issues.apache.org/jira/browse/TUSCANY-1132 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: tuscany-1132-testcase.patch With or without the patch of TUSCANY-1131 to fix the problem in XMLDocumentImpl.java, this problem always exists. With the fix from TUSCANY-1131, now I got this exception. I believe there are still some problem in the SDO Java serialization/deserialization code. org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value '[EMAIL PROTECTED] (eClass: [EMAIL PROTECTED] (name: DataObject) (instanceClassName: null) (abstract: true, interface: false))' is not legal. (http:///temp.xml, 3, 50) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:80) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:275) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:463) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:246) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:224) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:78) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:72) at org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readDataObject(HelperProviderImpl.java:210) at org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readExternal(HelperProviderImpl.java:150) at commonj.sdo.impl.ExternalizableDelegator.readExternal(ExternalizableDelegator.java:83) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1774) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1324) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:362) at org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readDataObject(HelperProviderImpl.java:219) at org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readExternal(HelperProviderImpl.java:150) at commonj.sdo.impl.ExternalizableDelegator.readExternal(ExternalizableDelegator.java:83) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1774) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1736) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1324) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:362) at org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase.testAnyTypeContainer(JavaSerializeDeserializeTestCase.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at
Re: Review of spec classes wanted
Thanks Ignacio On Feb 26, 2007, at 8:35 AM, Jim Marino wrote: On Feb 26, 2007, at 8:26 AM, Ignacio Silva-Lepe wrote: I took a quick pass. I saw a couple of inconsistencies with respect to the spec doc: - @EndsConversation is defined in the spec doc (small typo) Oops that is a bug in our jar - I'll fix it Done ... -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script components and script container in integration branch
This looks pretty good to me. I have a few comments and questions inline. ant elder wrote: I've spent the weekend getting the script container going again, see the code in [1], its looking pretty good now. I think we should eventually be able to use this one container to support all the script language components instead of having separate containers for each language. With a single container, will there still be a way to customize the support for each language? For example in one language we may want to map references to instance variables in classes, while in another less object-oriented language we'll want to map them to global variables. Another example, one language may support interfaces, while another does have this concept at all. How will you provide different SCA programming models to these different scripting languages? Ideally script components will be interchangeable between the C++ and Java runtimes, so with that in mind i've started trying to use the various script samples from the C++ runtime, so far thats the Python and Ruby calculator samples, now copied into the script itests module. Currently there are some changes required to get these running in the Java runtime and they are: - Need a java Interface to invoke the sample from a test client Is it a limitation of the runtime? Or is it a natural requirement anyway because your test client is written in Java? Can you write the test client as a script as well? - Need to specify the full path of the script file - calculator/ on script file resource - Need to use a .componentType side file - Ruby script @divideService variable needs to be changed to $divideService. Whats the difference between the @ and $ characters in Ruby? @variable is an instance variable $variable is a global variable - Python components use a module attribute to define script file and the attribute value doesn't include the .py suffix - Python divide doesn't work with rounding as the line result = round(result) fails as result is a string which seems a bit odd Requiring the componentType side file seems the main problem, i'm going to spend a bit of time now seeing if the java runtime can be made a bit more dynamic like the C++ runtime to avoid needing these. You'll probably need to change the Java runtime a little to make interfaces optional. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1130) Concurrent access to SDOUtil.createHelperContext() results in exception
[ https://issues.apache.org/jira/browse/TUSCANY-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1130: Patch Info: [Patch Available] Concurrent access to SDOUtil.createHelperContext() results in exception --- Key: TUSCANY-1130 URL: https://issues.apache.org/jira/browse/TUSCANY-1130 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-M2 Attachments: 1130.patch, 1130_final.patch, 1130_new.patch In tuscany runtime, when multiple apps are started simultaneously, we get an exception as below: This is a problem with acessing SDOUtil.createHelperContext(0 concurrently. Exception = java.util.ConcurrentModificationException Source = com.ibm.ws.soa.sca.admin.config.loader.SDOLoader.INIT probeid = 80 Stack Dump = java.util.ConcurrentModificationException: concurrent access to HashMap attempted by Thread[server.startup : 2,5,main] at java.util.HashMap.onExit(HashMap.java:217) at java.util.HashMap.transfer(HashMap.java:514) at java.util.HashMap.resize(HashMap.java:500) at java.util.HashMap.addEntry(HashMap.java:800) at java.util.HashMap.put(HashMap.java:441) at com.ibm.sdo.internal.ecore.util.BasicExtendedMetaData$EPackageExtendedMetaDataImpl.getType(BasicExtendedMetaData.java:2064) at com.ibm.sdo.internal.ecore.util.BasicExtendedMetaData.getType(BasicExtendedMetaData.java:115) at com.ibm.sdo.internal.xsd.ecore.XSDEcoreBuilder.populateTypeToTypeObjectMap(XSDEcoreBuilder.java:108) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.init(SDOXSDEcoreBuilder.java:61) at org.apache.tuscany.sdo.helper.XSDHelperImpl.init(XSDHelperImpl.java:79) at org.apache.tuscany.sdo.helper.XSDHelperImpl.init(XSDHelperImpl.java:94) at org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:48) at org.apache.tuscany.sdo.helper.HelperContextImpl.init(HelperContextImpl.java:52) at org.apache.tuscany.sdo.util.SDOUtil.createHelperContext(SDOUtil.java:299) -- 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: Review of spec classes wanted
I took a quick pass. I saw a couple of inconsistencies with respect to the spec doc: - @EndsConversation is defined in the spec doc (small typo) - @Conversation is defined only in the spec doc (not sure what for) I am assuming that both of these are spec doc bugs (I am looking at SCA_JavaAnnotationsAndAPIs_V100.doc, dated 15 February 2007) to be fixed. If that's the case, here's my +1 On 2/25/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Databinding integration tests
Hi, Althought the databinding-test project has been moved into the testing/sca project, the tests themselves could do with some improvements. If people agree, I'd like to seperate them into a number of sub projects that test individual databindings (ie. a sperate project for each SDO, JAXB etc) and one or more to test interoperbillity between them (eg SDO-JAXB) using default and WS bindings. Initially these tests would focus on client and inter composite transformations rather than inter component. I should be able to submitt them later this week, assuming it is felt better tests are approprite, and would be willing to try interlanguage later if needed (eg. Java SDO - Javascript or other composite/components). Cheers, Dan
[jira] Updated: (TUSCANY-1128) Support attribute and element with same name
[ https://issues.apache.org/jira/browse/TUSCANY-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1128: Patch Info: [Patch Available] Support attribute and element with same name Key: TUSCANY-1128 URL: https://issues.apache.org/jira/browse/TUSCANY-1128 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-Mx Attachments: 1128.patch, 1128.patch, DifferAttrFromElementTestCase.java To support attribute and element with same name within one Type such as complexType sequence element name=property type=int/ /sequence attribute name=property type=string/ /complexType and using @property to access attribute and property to access element. This is to support OTA standard schema used in the travel industry. @property notation comes from XPath: http://www.w3.org/TR/xpath#path-abbrev -- 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: Databinding integration tests
Hi Ant, I was working on the basis that, for example, an SDO client - JAXB Composite using WS bindings would go though the AXIOM layer. If not it wouldn't be too difficult to ad a specifc AXIOM set of tests (similar to e4x-axiom) for the others if necessary... Is this sufficent, or do you think we need sdo-axiom, jaxb-axiom) are explicitly needed ? Cheers On 26/02/07, ant elder [EMAIL PROTECTED] wrote: Was about to replying on the other thread but this one seems better ... this proposal sounds good to me. Over the weekend i added a JavaScript E4X databinding [1], and plan in the future to also add ones for Ruby ReXML, Python ElementTree, and perhaps something for Groovy as well. That could make itesting all the databinding combinations a little onerous, so testing specific combinations sounds good, eg e4x uses axiom so just e4x-axiom itests are probably enough if axiom is tested with all the others. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/databinding.e4x/ On 2/26/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, Althought the databinding-test project has been moved into the testing/sca project, the tests themselves could do with some improvements. If people agree, I'd like to seperate them into a number of sub projects that test individual databindings (ie. a sperate project for each SDO, JAXB etc) and one or more to test interoperbillity between them (eg SDO-JAXB) using default and WS bindings. Initially these tests would focus on client and inter composite transformations rather than inter component. I should be able to submitt them later this week, assuming it is felt better tests are approprite, and would be willing to try interlanguage later if needed (eg. Java SDO - Javascript or other composite/components). Cheers, Dan
Re: XMLBeans databinding
As per message just posted (sorry should have read this one first) - I was thinking about this, could have something later this week... On 26/02/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: The XMLBeans databinding builds OK again this morning so I put it back as well as the databinding integration tests in the default profile. I was having problems building it on Friday because the xmlbeans Jars couldn't be downloaded from http://www.ibiblio.net/. Is there an alternate Maven repository for XMLBeans that we can use? The other thing is that our databinding integration tests currently depend on SDO, JAXB and XMLBeans, would it be possible to split this in two or three different test suites? SDO - JAXB SDO - XMLBeans JAXB - XMLBeans -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1098) Add get() and getInstanceProperties() methods in Type and Property
[ https://issues.apache.org/jira/browse/TUSCANY-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1098: Patch Info: [Patch Available] Add get() and getInstanceProperties() methods in Type and Property -- Key: TUSCANY-1098 URL: https://issues.apache.org/jira/browse/TUSCANY-1098 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Attachments: TestRetrieveMetadataInfo.java, TestRetrieveMetadataInfo.java, tuscany-1098.patch1, tuscany-1098.patch1, TypePropertyMetadataInfo.xsd, TypePropertyMetadataInfo.xsd The 2.1 spec introduced these new methods on Type and Property -- 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-1044) DataHelperImpl.toDateTime() is not compliant with spec.
[
https://issues.apache.org/jira/browse/TUSCANY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1044:
Patch Info: [Patch Available]
DataHelperImpl.toDateTime() is not compliant with spec.
---
Key: TUSCANY-1044
URL: https://issues.apache.org/jira/browse/TUSCANY-1044
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Mx
Reporter: Ron Gavlin
Fix For: Java-SDO-Mx
Attachments: DateTime.patch, DateTimeTest.zip
Ron,
I think you are correct. The spec says ...
The String representation of DateTime, Duration, Time, Day, Month, MonthDay,
Year, YearMonth, and YearMonthDay follows the lexical representation defined
in XML Schema for the corresponding data types: dateTime, duration, time,
gDay, gMonth, gMonthDay, gYear, gYearMonth, and Date respectively.
and the XML schema definition at
http://www.w3.org/TR/xmlschema-2/#dateTime-timezones seems to be overriden
by the errata at http://www.w3.org/2001/05/xmlschema-errata#e2-45 which
gives ...
The lexical representation of a timezone is a string of the form: (('+' |
'-') hh ':' mm) | 'Z', where *hh* is a two-digit numeral (with leading zeros
as required) that represents the hours, *mm* is a two-digit numeral that
represents the minutes, '+' indicates a nonnegative duration, and '-'
indicates a nonpositive duration. The mapping so defined is one-to-one,
except that '+00:00', '00:00', and 'Z' all represent the same zero-length
duration timezone, UTC; 'Z' is its canonical representation.
so please raise a JIRA, and of course I have to say it ... a fix would be
great too ;-)
Cheers, Kelvin.
On 09/01/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
Based on my reading of the spec, DataHelperImpl.toDateTime(Calendar)
should return a String compatible with the XML Schema dateTime. Consider the
code snippet below:
import commonj.sdo.helper.DataHelper;
System.out.println(DataHelper.INSTANCE.toDateTime(
DataHelper.INSTANCE.toCalendar(2007-01-01T00:00:00.200Z))
This snippet prints the result:
(java.lang.String) 2007-01-01T00:00:00.200 GMT
instead of
(java.lang.String) 2007-01-01T00:00:00.200Z
The GMT suffix seems incorrect to me. The following code supports this
assertion by throwing an IllegalArgumentException when it encounters the
GMT suffix generated by the DataHelper.toDateTime() method.
import javax.xml.datatype.DatatypeFactory;
DatatypeFactory.newInstance().newXMLGregorianCalendar(2007-01-01T00:00:
00.200 GMT);
Do you agree this is a bug? If so, I'll be glad to open a JIRA.
- Ron
--
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: Review of spec classes wanted
On Feb 26, 2007, at 8:26 AM, Ignacio Silva-Lepe wrote: I took a quick pass. I saw a couple of inconsistencies with respect to the spec doc: - @EndsConversation is defined in the spec doc (small typo) Oops that is a bug in our jar - I'll fix it - @Conversation is defined only in the spec doc (not sure what for) Conversation is an error - it should be removed from the spec. I am assuming that both of these are spec doc bugs (I am looking at SCA_JavaAnnotationsAndAPIs_V100.doc, dated 15 February 2007) to be fixed. If that's the case, here's my +1 Thanks for reviewing. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-521) Hide special Sequence-type properties from SDO Types
[ https://issues.apache.org/jira/browse/TUSCANY-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-521. Resolution: Fixed The core of this change lies in a) for the runtime, the fact that ClassImpl now maintains lists of user visible properties, rather than relying on the state of the EMF implementation objects b) for the generated classes, the creation of 2 sets of Property indices, one for the user and one for referencing internal EMF objects' features. Each generated class has a generated method for mapping between the external and internal indices. All other changes relate to the use or testing of the above changes. Hide special Sequence-type properties from SDO Types Key: TUSCANY-521 URL: https://issues.apache.org/jira/browse/TUSCANY-521 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Frank Budinsky Fix For: Java-SDO-Mx Attachments: hideprops_rt.patch, hideprops_tools.patch, T-521-hideprops_rt_update.patch Type,getProperties() often includes several Sequence-type properites (e.g., mixed, group, any, etc.). These properties are used by the underlying EMF implementation to provide full XSD support, but they aren't described in the SDO spec and therefore should not be exposed to clients. They should be hidden from the getProperties() list and instead be accessable via new SDOUtil methods, similar to the way substitution groups are handled in TUSCANY-503. -- 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-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-826: --- Patch Info: [Patch Available] Containment cycle should result in Exception Key: TUSCANY-826 URL: https://issues.apache.org/jira/browse/TUSCANY-826 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Windows XP, both Sun and IBM JVMs Reporter: Brian Murray Fix For: Java-SDO-Mx Attachments: ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip Near the bottom of page 19 in the 2.0.1 specification it is stated that Containment cannot have cycles. If a set or add would create a containment cycle an exception is thrown. However, I have found that no such exception is thrown. I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1139) [SDO for C++] Use x.push_back(y) rather than x.insert(x.end(), y)
[SDO for C++] Use x.push_back(y) rather than x.insert(x.end(), y) - Key: TUSCANY-1139 URL: https://issues.apache.org/jira/browse/TUSCANY-1139 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: All Reporter: Geoff Winn Assigned To: Geoff Winn Fix For: Cpp-current There are numerous places in the code where an item is appended to the end of a list or vector using code similar to vector.insert(vector.end(), new_item); This is less efficient than the preferred form which is vector.push_back(new_item); The performance impact of this is visible on Linux platforms using callgrind. -- 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: @Property attributes
The xml type for a property can be from the introspection of the java class or @DataType annotation if the java class doesn't provide such metadata. +1 to remove the xmlType attribute from @Property. We need to fix the property handling pieces accordingly. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, February 25, 2007 1:20 PM Subject: Re: @Property attributes On Feb 25, 2007, at 12:21 PM, Jim Marino wrote: On Feb 25, 2007, at 12:14 PM, Jeremy Boynes wrote: The @Property annotation currently has two non-standard attributes: public String override() default may; public String xmlType() default ; I have marked these as @Deprecated but have not removed them as there are references in our implementation. I think it should be fairly easy to replace override() with the standard required() attribute but it looked like it would be more complex to remove the xmlType() one given its use in the databinding framework. What do we need to do to remove these? -- Jeremy I think we need to remove them as they aren't spec compliant. I can do that today if it makes sense or unless there is another option (e.g. perhaps a different annotation?). We need to remove them, but that means the code we have that uses them needs to be fixed. I don't see ATM where override fits in - what's the purpose of a property that can't be overridden (what in Java would be known as a constant)? I think all of its usages can be replaced with required(). xmlType seems to be used in the databinding framework to help in the conversion from the property value. As a Java programmer I don't really want to have to deal with all this pointy-bracket stuff so the Java type of the property should be enough. I don't know yet what the impact on the databinding would be if we removed this. Is this something you're planning on tackling? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-257: --- Patch Info: [Patch Available] recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 --- Key: TUSCANY-257 URL: https://issues.apache.org/jira/browse/TUSCANY-257 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-Mx Environment: all Reporter: Paul Golick Fix For: Java-SDO-Mx Attachments: newFiles.jar, patchInterface2JavaGenerator.txt, patchUpdated.txt Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and java.lang.reflect.Type that were added in Java 5 for generics. It appears that the portion of Interface2JavaGenerator that uses ParameterizedType and Type is not needed for Java 1.4 classes. -- 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-193) Fix eclipse warnings for sdo/tools
[ https://issues.apache.org/jira/browse/TUSCANY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-193: --- Patch Info: [Patch Available] Fix eclipse warnings for sdo/tools -- Key: TUSCANY-193 URL: https://issues.apache.org/jira/browse/TUSCANY-193 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SCA-Mx Reporter: Daniel Kulp Assigned To: Frank Budinsky Priority: Minor Fix For: Java-SDO-Mx Attachments: sdo.patch Very small and minor patch to the sdo/tools section to remove the last eclipse warning in there. Also patches one file in sdo/impl. The only eclipse warning left in there is use of a deprecated API. -- 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: Review of spec classes wanted
On Feb 25, 2007, at 9:24 PM, Jim Marino wrote: On Feb 25, 2007, at 2:12 PM, Jim Marino wrote: On Feb 25, 2007, at 1:29 PM, Jim Marino wrote: On Feb 25, 2007, at 1:23 PM, Jeremy Boynes wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? I'll volunteer although I'm not the best person to do it in terms of being a fresh set of eyes. Also, I'm a bit concerned about the extensions related to DataTypes being in there. I think it is critical we have this information but not at the expense of violating the spec. If people agree, I will volunteer to go in and provide an alternative today that uses a Tuscany API. Jim Provisional +1 assuming the @Property#override and @Property#xmlType are fixed. Jim In r511727 I removed the @Property#override and replaced it with the use of @Property#required where appropriate. Jim I changed the kernel to support @EndConversation and I see Jeremy has removed @Property#xmlType so +1 for the release. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1139) [SDO for C++] Use x.push_back(y) rather than x.insert(x.end(), y)
[ https://issues.apache.org/jira/browse/TUSCANY-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoff Winn resolved TUSCANY-1139. - Resolution: Fixed All cases changed as described [SDO for C++] Use x.push_back(y) rather than x.insert(x.end(), y) - Key: TUSCANY-1139 URL: https://issues.apache.org/jira/browse/TUSCANY-1139 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: All Reporter: Geoff Winn Assigned To: Geoff Winn Fix For: Cpp-current There are numerous places in the code where an item is appended to the end of a list or vector using code similar to vector.insert(vector.end(), new_item); This is less efficient than the preferred form which is vector.push_back(new_item); The performance impact of this is visible on Linux platforms using callgrind. -- 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] Resolved: (TUSCANY-709) Loads DataGraph in designated scope(TypeHelper)
[ https://issues.apache.org/jira/browse/TUSCANY-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-709. Resolution: Fixed loadDataGraph(InputStream inputStream, Map options, TypeHelper scope) ensure the extended metadata from the scope is used for the period of the datagraph load, and ensures the supplied options map is unchanged on exit from the method Loads DataGraph in designated scope(TypeHelper) --- Key: TUSCANY-709 URL: https://issues.apache.org/jira/browse/TUSCANY-709 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Yang ZHONG Priority: Minor Fix For: Java-SDO-Mx Attachments: patch.709 SDOUtil.loadDataGraph doesn't support scope, this improvement tries to address that. TypeHelper#define registers Types with the corresponding TypeHelper instance (scope) and XMLHelper#load utilizes the registered Types from the corresponding scope to instantiate DataObject instances. Unfortunately yet, current SDOUtil.loadDataGraph 2-1. can't designate scope to register serialized Types, 2-2. and can't designate scope to utilize already registered Types in order to instantiate user expected DataObject instances. An example of 2-1 is SerializeTypesTestCase had to // The following is a kludge to force deserialization of metadata into a different TypeHelper (scope) // TBD figure out a proper non-EMF way to do this. Map options = new HashMap(); Object differentFromSerializing = ((TypeHelperImpl) deserializingTypeHelper).getExtendedMetaData(); options.put(XMLResource.OPTION_EXTENDED_META_DATA, differentFromSerializing); This proposal tries to adress scope by 2-1. add new SDOUtil.loadDataGraph(InputStream inputStream,Map options,TypeHelper scope)throws IOException 2-2. deprecate old SDOUtil.loadDataGraph(InputStream inputStream,Map options)throws IOException Any comment is welcomed. -- 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: @Property attributes
On Feb 26, 2007, at 9:12 AM, Raymond Feng wrote: The xml type for a property can be from the introspection of the java class or @DataType annotation if the java class doesn't provide such metadata. +1 to remove the xmlType attribute from @Property. We need to fix the property handling pieces accordingly. I removed the attribute and updated core to just use the SimpleTypePropertyMapper. I'm guessing that this may have an impact on complex property support. Raymond, Venkat is this something you can look at or should I dig into it? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tossing @Autowire
FYI, Now that we have the AutowireResolver in place, I'm going to look into adding support for full SCA 1.0 autowire semantics in trunk. This will mean we can get rid of the @Autowire tag (using @Reference instead). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO CTS: Update to Make Use of HelperContext
I plan to update the CTS so that it makes use of HelperContexts. After the update, a HelperContext parameter will be injected into the Paramatized tests. (The existing injected parameters are a DataObject whose Type was defined in a particular way, and a String which describes the method of Type definition.) I plan to remove the get___Helper methods from TuscanyTestHelper. The various helpers will instead be obtained from the HelperContext API. Please let me know of any thoughts or concerns. -Brian
Re: Tossing @Autowire
Resending a previous reply as my ISP's MTA seems to be acting up... On 2/26/07, Jim Marino [EMAIL PROTECTED] wrote: FYI, Now that we have the AutowireResolver in place, I'm going to look into adding support for full SCA 1.0 autowire semantics in trunk. This will mean we can get rid of the @Autowire tag (using @Reference instead). It might be an idea to deprecate that now so that users know that it will be going away. Will they need to use @Reference or is default introspection typically going to ensure that there is no need for any annotation (which would even better)? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review of spec classes wanted
Is anyone else going to be reviewing these or should I start to prep for a release? -- Jeremy On 2/26/07, Jim Marino [EMAIL PROTECTED] wrote: On Feb 25, 2007, at 9:24 PM, Jim Marino wrote: On Feb 25, 2007, at 2:12 PM, Jim Marino wrote: On Feb 25, 2007, at 1:29 PM, Jim Marino wrote: On Feb 25, 2007, at 1:23 PM, Jeremy Boynes wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? I'll volunteer although I'm not the best person to do it in terms of being a fresh set of eyes. Also, I'm a bit concerned about the extensions related to DataTypes being in there. I think it is critical we have this information but not at the expense of violating the spec. If people agree, I will volunteer to go in and provide an alternative today that uses a Tuscany API. Jim Provisional +1 assuming the @Property#override and @Property#xmlType are fixed. Jim In r511727 I removed the @Property#override and replaced it with the use of @Property#required where appropriate. Jim I changed the kernel to support @EndConversation and I see Jeremy has removed @Property#xmlType so +1 for the release. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review of spec classes wanted
Hi, I'm still in the middle of reviewing it and will get back to the ML by the end of the day. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 26, 2007 2:48 PM Subject: Re: Review of spec classes wanted Is anyone else going to be reviewing these or should I start to prep for a release? -- Jeremy On 2/26/07, Jim Marino [EMAIL PROTECTED] wrote: On Feb 25, 2007, at 9:24 PM, Jim Marino wrote: On Feb 25, 2007, at 2:12 PM, Jim Marino wrote: On Feb 25, 2007, at 1:29 PM, Jim Marino wrote: On Feb 25, 2007, at 1:23 PM, Jeremy Boynes wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? I'll volunteer although I'm not the best person to do it in terms of being a fresh set of eyes. Also, I'm a bit concerned about the extensions related to DataTypes being in there. I think it is critical we have this information but not at the expense of violating the spec. If people agree, I will volunteer to go in and provide an alternative today that uses a Tuscany API. Jim Provisional +1 assuming the @Property#override and @Property#xmlType are fixed. Jim In r511727 I removed the @Property#override and replaced it with the use of @Property#required where appropriate. Jim I changed the kernel to support @EndConversation and I see Jeremy has removed @Property#xmlType so +1 for the release. 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]
Spec schemata, was: Review of spec classes wanted
The sca-api module contains old versions of the schemas from 0.9 days. I think we should remove these from the jar as they are orthogonal from the Java APIs. We could package them separately, on our website, or just leave them to the spec to publish (as the URIs point back to their website). -- Jeremy On 2/25/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? Thanks -- Jeremy - 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: Spec schemata, was: Review of spec classes wanted
[snip] Jeremy Boynes wrote: The sca-api module contains old versions of the schemas from 0.9 days. I think we should remove these from the jar as they are orthogonal from the Java APIs. We could package them separately, on our website, or just leave them to the spec to publish (as the URIs point back to their website). -- Jeremy I think that they should be published on the web site and also packaged in Tuscany distributions. Does anybody know if there will be any license issue if we want to package them in Tuscany? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review of spec classes wanted
Hi,
The SCA 1.0 spec api looks good to me. I have two minor comments.
1) The JavaDoc for @AllowsPassByRerence is a bit misleading.
The Java spec says: Either a whole class implementing a remotable service
or an individual remotable service method implementation can be annotated
using the @AllowsPassByReference annotation.
2) In the spec, it uses null as the default value for annotation
attributes. It's not allowed by java. The APIs we have the project fix the
problem.
3) Java Common Annotations and APIs spec should use ClassB instead of
Class between 250 and 255.
250 interface ComponentContext{
251 .
252 B ServiceReferenceB createSelfReference (Class businessInterface);
253 B ServiceReferenceB createSelfReference (Class businessInterface,
254 String serviceName);
255 }
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 26, 2007 2:48 PM
Subject: Re: Review of spec classes wanted
Is anyone else going to be reviewing these or should I start to prep
for a release?
--
Jeremy
On 2/26/07, Jim Marino [EMAIL PROTECTED] wrote:
On Feb 25, 2007, at 9:24 PM, Jim Marino wrote:
On Feb 25, 2007, at 2:12 PM, Jim Marino wrote:
On Feb 25, 2007, at 1:29 PM, Jim Marino wrote:
On Feb 25, 2007, at 1:23 PM, Jeremy Boynes wrote:
I've been through the sca-api-r1.0 classes and tried to bring
them in line with the specification, including applicable
errata :-) Apart from one issue with @Property I think they are
now in alignment.
It would be good if a couple of other people could review these
so we can release them.
Any volunteers?
I'll volunteer although I'm not the best person to do it in terms
of being a fresh set of eyes. Also, I'm a bit concerned about the
extensions related to DataTypes being in there. I think it is
critical we have this information but not at the expense of
violating the spec. If people agree, I will volunteer to go in
and provide an alternative today that uses a Tuscany API.
Jim
Provisional +1 assuming the @Property#override and
@Property#xmlType are fixed.
Jim
In r511727 I removed the @Property#override and replaced it with
the use of @Property#required where appropriate.
Jim
I changed the kernel to support @EndConversation and I see Jeremy has
removed @Property#xmlType so +1 for the release.
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]
Re: Databinding integration tests
[snip] ant elder wrote: Was about to replying on the other thread but this one seems better ... this proposal sounds good to me. Over the weekend i added a JavaScript E4X databinding [1], and plan in the future to also add ones for Ruby ReXML, Python ElementTree, and perhaps something for Groovy as well. That could make itesting all the databinding combinations a little onerous, so testing specific combinations sounds good, eg e4x uses axiom so just e4x-axiom itests are probably enough if axiom is tested with all the others. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/databinding.e4x/ I thought that E4X depended on XMLBeans, has this changed? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tossing @Autowire
On Feb 26, 2007, at 10:56 AM, Jim Marino wrote: FYI, Now that we have the AutowireResolver in place, I'm going to look into adding support for full SCA 1.0 autowire semantics in trunk. This will mean we can get rid of the @Autowire tag (using @Reference instead). It might be an idea to deprecate that now so that users know that it will be going away. Will they need to use @Reference or is default introspection typically going to ensure that there is no need for any annotation (which would even better)? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Property attributes
Hi Jeremy, I'll take care of this, when I sync up the trunk for complex and multivalued properties later down this week. Thanks - Venkat On 2/26/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 26, 2007, at 9:12 AM, Raymond Feng wrote: The xml type for a property can be from the introspection of the java class or @DataType annotation if the java class doesn't provide such metadata. +1 to remove the xmlType attribute from @Property. We need to fix the property handling pieces accordingly. I removed the attribute and updated core to just use the SimpleTypePropertyMapper. I'm guessing that this may have an impact on complex property support. Raymond, Venkat is this something you can look at or should I dig into it? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA 1.0 autowire support, r512108
I've check in support for SCA 1.0 autowire semantics. I need to refactor the implementation a bit (actually the entire type loading needs a good refactor) and improve test coverage. As I do that I plan to migrate the kernel SCDLs to using the new syntax and removing all uses of @Autowire. I will also probably throw in a core sample as well. I'd then like to remove @Autowire since it won't be needed. I'm happy to leave it as deprecated but removing it will allow us to get rid of a lot of unneeded and brittle code (autowire needs to be checked on types as will as instances, which is bad). Let me know if people feel strongly otherwise and we should retain it as a deprecated annotation. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating Contribution services with DefaultSCAContainer
Luciano Resende wrote: I want to start getting the Contribution service integrated to the process of running components, and I was thinking to give it a try by integrating the service with the new DeafultSCAContatiner that some sample apps in the integration branch is using. I think the idea is to stop using the launcher to consume the application SCDL, and ask the Contribution service to process the application as a contribution. from: component = launcher.bootApplication(application, applicationSCDL); to maybe: URI appURI = this.contributionService.contribute(contributionLocation, false); ... Today, when you ask the contribution service to consume an application, you will get back an URI, that is an ID for that contribution. So, my question is, how the external world would get access to the model objects created during the loading phase from the contribution service ? Is the contribution service responsible to register these model objects ( e.g componentDefinition) into some specific model repository (e.g the domain) ? and If so, how do I got about doing this ? Could someone please share some ideas, or more concrete example on how I'd go about integrating the Contribution service into the big picture ? -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende I have one question and a few comments: - I was expecting to see that ContributionService in the spi module, with the Contribution model. Why is it defined in the host-api module? - I don't think that bootApplication and contribute() are really equivalent. Starting a component requires the following to happen: 1. An SCA contribution containing the component implementation and a composite containing the component declaration is installed. 2. The composite declaring the component is included in the SCA domain logical composite. 3. An SCA runtime starts, instantiates and starts the component. ContributionService.contribute() should only do step 1. Launcher.bootApplication used to do the equivalent of 1+2+3. Then I imagine that you'll need to get your hands on the actual Contribution model and point to the DeployedArtifact representing the Composite. Next you'll need to add this Composite to the SCA Domain. By the way, do we have an SCA Domain service yet? If we don't then maybe we can just skip that step for now... Then you'll probably want to turn the DeployedArtifact into a Component model object and add it to the correct node in the Component model tree described at http://cwiki.apache.org/TUSCANY/tuscany-architecture-guide.data/tuscany_composite_hierarchy.jpg. And finally start that Component. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble building the Tuscany Trunk
Hi, I'm not promoting something against the modular build :-), but for my own convenience, I use the following script to build the current trunk from source: --- setlocal set TUSCANY_HOME=%cd% pushd %TUSCANY_HOME% svn update cd %TUSCANY_HOME%\pom\parent call mvn clean install cd %TUSCANY_HOME%\buildtools call mvn clean install cd %TUSCANY_HOME%\spec\sca-api-r1.0 call mvn clean install -Peclipse eclipse:eclipse cd %TUSCANY_HOME%\sca\kernel call mvn clean install -Peclipse eclipse:eclipse cd %TUSCANY_HOME%\sca\runtime call mvn clean install -Peclipse eclipse:eclipse cd %TUSCANY_HOME%\sca\core-samples call mvn clean install -Peclipse eclipse:eclipse cd %TUSCANY_HOME%\sca\integration-test call mvn clean install -Peclipse eclipse:eclipse popd endlocal --- SDO can be built by its own. You can run mvn clean install under folder spec\sdo-api and then sdo. BTW, with the SNAPSHOT versions of the individual modules published to maven, it should be possible to build them independently. Thanks, Raymond - Original Message - From: Snehit Prabhu [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 26, 2007 9:49 PM Subject: Trouble building the Tuscany Trunk Hi, I am trying to setup the Tuscany Trunk Distribution on my machine for a while now, with little success. Any help on the matter would be appreciated. I should mention that the complete M2 distribution has been downloaded, built and used quite easily. I'm using the same svn, maven, java5 environment for the trunk. Im working on a WinXP system. I am trying to setup the Trunk environment, while M2 is already present on the system. I assume there should be no trouble with the 2 sharing the same local Maven repository. I followed the instructions on this page : http://incubator.apache.org/tuscany/building_source.html Step 1 : *svn co http://svn.apache.org/repos/asf/incubator/tuscany/java/ . * Works just fine. The complete following folder structure is setup: Directory of E:\TuscanyTrunk 26/02/2007 16:06DIR . 26/02/2007 16:06DIR .. 26/02/2007 16:03 686 BUILDING.txt 26/02/2007 16:03 7,722 GettingStarted.htm 26/02/2007 16:0375,767 LICENSE.txt 26/02/2007 16:03 873 NOTICE 26/02/2007 16:03 2,833 pom.xml 26/02/2007 16:03 974 README.txt 16/02/2007 11:05 764 setenv.bat 26/02/2007 16:06DIR testing 26/02/2007 16:08DIR spec 26/02/2007 16:08DIR sdo 26/02/2007 16:08DIR sca 26/02/2007 16:15DIR samples 26/02/2007 16:15DIR sampleapps 26/02/2007 16:16DIR pom 26/02/2007 16:16DIR javadoc 26/02/2007 16:16DIR etc 26/02/2007 16:16DIR distribution 26/02/2007 16:16DIR das 26/02/2007 16:16DIR cts 26/02/2007 16:16DIR buildtools 27/02/2007 11:01 0 contents.txt 8 File(s) 89,619 bytes 15 Dir(s) 50,448,465,920 bytes free Step 2 : run mvn at the root directory (in my case E:\TuscanyTrunk), as intructed in the Building.txt file. This step fails - throwing the following output. [INFO] Scanning for projects... [INFO] [INFO] Building Tuscany Project [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing E:\TuscanyTrunk\pom.xml to C:\Documents and Settings\Administrator\.m2\repository\org\apache\tuscany\tuscany-project\1.0-incubator-SNAPSHOT\tuscany- project-1.0-incubator-SNAPSHOT.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Feb 27 11:06:56 IST 2007 [INFO] Final Memory: 4M/19M [INFO] This happens in a second. No target directories formed anywhere. Nothing builds. Step 3 : I tried building individual components. Running mvn at E:\TuscanyTrunk\sdo runs fine - all dependencies are resolved, downloaded and the build runs successfully. Running mvn at E:\TuscanyTrunk\sca, however, does not work. Here is the output : [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [INFO] For more information, run Maven with
Re: [DAS C++] Necessary classes for a initial simple read application
I looked at the maven for netbeans page and it seems interesting, but I didn't have time to test it yet. Sorry Luciano, but what is a webApp skeleton? Could you give an example? On 2/17/07, Luciano Resende [EMAIL PROTECTED] wrote: Except for the instructions related to NetBeans, most of these steps are defined on the following two links: http://incubator.apache.org/tuscany/java-projects.html or http://incubator.apache.org/tuscany/java_das_overview.html Probably would be better for you to review these links and suggest enhancements, as most new users will probably have the same issues as you guys are having. The netBeans steps could probably also be appended to the java-projects.htmllink, together with the instructions on how to use Eclipse or IDEA. BTW, have you seen this : http://maven.apache.org/guides/mini/guide-ide-netbeans/guide-ide-netbeans.html Looks like there is a plugin that does the creation of the netBeans project files from the pom mvn netbeans-freeform:generate-netbeans-project Then, for the webAPP, maybe it's easy if you provide a webApp skeleton, then people could only import the war file. Toughts ? Does the link help ? -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende On 2/16/07, Adriano Crestani [EMAIL PROTECTED] wrote: As me and Dannyel had some trouble on building and debugging this simple read app using das java, I created this short howTo to help anyone else that is also having difficult to create a project on netbeans IDE to debbug the code. 1 - download subversion(http://subversion.tigris.org/project_packages.html ) and unpack it 2 - download maven 2.0.4 (http://maven.apache.org/download.html) and unpack it 3 - set maven/bin and subversion/bin in your SO path 4 - create a folder called, i. e. Tuscany, and download the java source executing the following commands: cd tuscany svn co https://svn.apache.org/repos/asf/incubator/tuscany/java It will probably ask you if you accept the secure connection, than allow it. 5 - Now, download the dependencies: cd java/das mvn The dependencies should be downloaded. Let us know if you get any build error on this part. 6 - Run Netbeans and select File New Project Select General on categories and then Java Project with Existing Sources then click on next 7 - Give a name to your project, i.e. DAS, select its folder and click on next. 8 - Click on the first button Add Folder... and select the following folders: Tuscany\java\das\rdb\src\main\java Tuscany\java\das\rdb\target\sdo-source Click on Finish 9 - Unpack the file Tuscany\java\das\distribution\binary\target\das- 1.0-incubator-SNAPSHOT-bin.zip in a folder, i.e. Lib. 10 - Right click on DAS project and select properties. Then select libraries and click on Add JAR/Folder. Select all the files the folder Lib\tuscany- das-1.0-incubator-SNAPSHOT\lib contains and click on Open. 11 - Again select File New Project... select Web on categories and Web Application then click on next. 12 - Give a name to your project, i.e. SimpleReadApp, select its folder and click on finish. 13 - Right click on you SimpleReadApp project and select New Servlet. Give a name to your servlet, i.e. CommandServlet and click on finish. A new .java file will be created in SimpleReadApp's Source Packages, open it and copy the CommandServlet class code in it. 14 - Right click on you SimpleReadApp project and select properties. Then select libraries and click on Add JAR/Folder. Select the file sdo-api-r2.1-1.0-incubator-20061220.211548-2.jar that resides inside the Libs\tuscany-das-1.0-incubator-SNAPSHOT\lib folder and click on Open. 15 - On the same window click on Add Project..., select the DAS project folder and click on open. Now you already have what is necessary to run and debug the code. Don't forget to do the adjustments for your dbms: - set the jdbc jar file - modify the sql statement according to your dbms pl/sql - modify the in getConnection method the jdbc driver class path, the database path, user and password - create in your database having an table called ITEM that has an integer attribute called ID. You must also insert at least an row in this table. I expect you to debug this simple read app and see for yourselves which classes and methods are needed to implement the simple read app. Then pick the classes you want to implement and create a JIRA for it ; ) Adriano Crestani On 2/9/07, Douglas Leite [EMAIL PROTECTED] wrote: Good ideia I´ll do it. On 2/9/07, Adriano Crestani [EMAIL PROTECTED] wrote: I have an idea to make it more independent. Each one that wants to help to implement this simple app, evaluate which class is intended to implement and create a new JIRA for it. In this new JIRA should be described the classes and their methods that will be implemented. This way if someone finish to
[jira] Created: (TUSCANY-1140) Implementation of DAS Lite Command classes
Implementation of DAS Lite Command classes -- Key: TUSCANY-1140 URL: https://issues.apache.org/jira/browse/TUSCANY-1140 Project: Tuscany Issue Type: Sub-task Components: C++ DAS Affects Versions: Wish list Reporter: Adriano Crestani Assigned To: Adriano Crestani Fix For: Wish list Implementation of BaseCommandImpl, Command, CommandImpl and ReadCommandImpl classes as described on the DAS Lite class diagram: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093 -- 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: [DAS C++] Necessary classes for a initial simple read application
I created a JIRA(https://issues.apache.org/jira/browse/TUSCANY-1140) to implement the DAS Lite Command classes that I described here: http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=45093 Hey guys, I read this article https://issues.apache.org/jira/browse/TUSCANY-1140 and I think you will like that, it tells a lot about how c++ sdo works ; ) Adriano Crestani On 2/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: I looked at the maven for netbeans page and it seems interesting, but I didn't have time to test it yet. Sorry Luciano, but what is a webApp skeleton? Could you give an example? On 2/17/07, Luciano Resende [EMAIL PROTECTED] wrote: Except for the instructions related to NetBeans, most of these steps are defined on the following two links: http://incubator.apache.org/tuscany/java-projects.html or http://incubator.apache.org/tuscany/java_das_overview.html Probably would be better for you to review these links and suggest enhancements, as most new users will probably have the same issues as you guys are having. The netBeans steps could probably also be appended to the java-projects.htmllink, together with the instructions on how to use Eclipse or IDEA. BTW, have you seen this : http://maven.apache.org/guides/mini/guide-ide-netbeans/guide-ide-netbeans.html Looks like there is a plugin that does the creation of the netBeans project files from the pom mvn netbeans-freeform:generate-netbeans-project Then, for the webAPP, maybe it's easy if you provide a webApp skeleton, then people could only import the war file. Toughts ? Does the link help ? -- Luciano Resende http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende On 2/16/07, Adriano Crestani [EMAIL PROTECTED] wrote: As me and Dannyel had some trouble on building and debugging this simple read app using das java, I created this short howTo to help anyone else that is also having difficult to create a project on netbeans IDE to debbug the code. 1 - download subversion(http://subversion.tigris.org/project_packages.html ) and unpack it 2 - download maven 2.0.4 (http://maven.apache.org/download.html ) and unpack it 3 - set maven/bin and subversion/bin in your SO path 4 - create a folder called, i. e. Tuscany, and download the java source executing the following commands: cd tuscany svn co https://svn.apache.org/repos/asf/incubator/tuscany/java It will probably ask you if you accept the secure connection, than allow it. 5 - Now, download the dependencies: cd java/das mvn The dependencies should be downloaded. Let us know if you get any build error on this part. 6 - Run Netbeans and select File New Project Select General on categories and then Java Project with Existing Sources then click on next 7 - Give a name to your project, i.e. DAS, select its folder and click on next. 8 - Click on the first button Add Folder... and select the following folders: Tuscany\java\das\rdb\src\main\java Tuscany\java\das\rdb\target\sdo-source Click on Finish 9 - Unpack the file Tuscany\java\das\distribution\binary\target\das- 1.0-incubator-SNAPSHOT-bin.zip in a folder, i.e. Lib. 10 - Right click on DAS project and select properties. Then select libraries and click on Add JAR/Folder. Select all the files the folder Lib\tuscany- das-1.0-incubator-SNAPSHOT\lib contains and click on Open. 11 - Again select File New Project... select Web on categories and Web Application then click on next. 12 - Give a name to your project, i.e. SimpleReadApp, select its folder and click on finish. 13 - Right click on you SimpleReadApp project and select New Servlet. Give a name to your servlet, i.e. CommandServlet and click on finish. A new .java file will be created in SimpleReadApp's Source Packages, open it and copy the CommandServlet class code in it. 14 - Right click on you SimpleReadApp project and select properties. Then select libraries and click on Add JAR/Folder. Select the file sdo-api-r2.1-1.0-incubator-20061220.211548-2.jar that resides inside the Libs\tuscany-das-1.0-incubator-SNAPSHOT\lib folder and click on Open. 15 - On the same window click on Add Project..., select the DAS project folder and click on open. Now you already have what is necessary to run and debug the code. Don't forget to do the adjustments for your dbms: - set the jdbc jar file - modify the sql statement according to your dbms pl/sql - modify the in getConnection method the jdbc driver class path, the database path, user and password - create in your database having an table called ITEM that has an integer attribute called ID. You must also insert at least an row in this table. I expect you to debug this simple read app and see for yourselves which classes and methods are needed to implement the
