Re: Questions around Contribution Service behavior
Luciano Resende wrote: While reviewing contribution code and thinking about some test scenarios, I have the following questions and would like to get some thoughts. 1.What should be the default behavior when i re-deploy a contribution to the repository ? Should it replace the existing application, or an exception should be thrown ? To start simple, I think we could replace the existing contribution for now. 2.When you re-deploy a contribution, should it get a new contributionId ? or continue to use the same ? Not sure... I noticed this ContributionID in the code but I'm not sure what it represents and how it is used. Could you help us understand what it is? 3.When deploying a folder contribution, should we support store this contribution into the repository ? Maybe, but working off the folder passed to the contribution service seems more important to me initially. This is the typical scenario where a developer works in a folder and wants to run off the artifacts developed in that folder, without any heavy copying taking place. 4.In contributionService, do we really need to pass the InputStream for the contribution service ? would we have scenarios where we will not be able to access the contribution via it's url / uri ? I'd like to leave to the contribution to decide really when it would be necessary to open the streams to probably have a better performance and use less resources. An InputStream may be needed at some point, or may not :) I suggest to add this variation when a concrete scenario that requires it comes up. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Test case : TopDown.testUserProvidedModelDynamic: is failing
Fresh DAS build has the following test case failure: Tests run: 154, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.006 sec FAILURE! testUserProvidedModelDynamic(org.apache.tuscany.das.rdb.test.TopDown) Time elap sed: 0.06 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.fillParamet er(UpdateGenerator.java:200) at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.createParam eter(UpdateGenerator.java:221) at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.getUpdateCo mmand(UpdateGenerator.java:99) at org.apache.tuscany.das.rdb.impl.ChangeFactory.getUpdateCommand (Change Factory.java:156) at org.apache.tuscany.das.rdb.impl.ChangeFactory.createUpdateOperation(C hangeFactory.java:70) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange (ChangeS ummarizer.java:116) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges (ChangeSu mmarizer.java:81) at org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute (Apply ChangesCommandImpl.java:65) at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges(DASImpl.java :312 ) at org.apache.tuscany.das.rdb.test.TopDown.testUserProvidedModelDynamic( TopDown.java:69) at org.apache.tuscany.das.rdb.test.TopDown.testUserProvidedModelDynamic( TopDown.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:816) Results : Tests in error: testUserProvidedModelDynamic(org.apache.tuscany.das.rdb.test.TopDown) When debugged a bit around this, what I found is , case sensitivity is the issue. i.e. type Customer does have property id, and not ID and this is causing the test case to fail. Does anybody have any clue? Regards, Amita
Re: [DAS] Refactoring DAS to allow multiple implementatons
I've added a strawman in my sandbox... Factory still needs some more work to make it more efficient and use some caching. Still looking into @Annotations as well. -- Luciano Resende http://people.apache.org/~lresende On 2/23/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Jim I'll take a look at how SCA and JPA are working with the annotations to handle this scenarios. As for your comments : One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. This is exactly what we accomplish using an external DAS config file to externalize connection information, command definitions, etc. -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende On 2/21/07, Jim Marino [EMAIL PROTECTED] wrote: On Feb 21, 2007, at 3:04 PM, Luciano Resende wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? I'm more focused on JPA and SCA so my comments may be biased :-) I'd suggest moving away from the service locator pattern except in pure J2SE or legacy J2EE 1.4 environments and using dependency injection instead. EJB3/JPA does what you outline using annotations and it may be worth looking at in-depth since it is based on a lot of practical experience from integrating various O/R implementations in managed environments. For Tuscany, DAS could support annotations similar to what we have done with the JPA integration in trunk (i.e. the standard JPA annotations or Tuscany's @Resource) . For other environments such as J2EE 1.5, DAS could probably use the @Resource annotation. In Spring you can also define your own custom annotation type or resuse @Resource. For pure J2SE environments, or where an application wants to manage the DAS factory, you may want to consider just allowing the application to new up the DASFactory or pass some sort of Configuration object or InputStream to an XML source. This will allow you to avoid making assumptions about where configuration is located or provide an extensibility point for various packaging types. It will also allow you to avoid all sorts of nasty problems in environments such as OSGi. One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Test case : TopDown.testUserProvidedModelDynamic: is failing
What do you mean by fresh DAS build ? I tried : - svn update - mvn clean install Build passed successfully. What OS are you using ? On 3/1/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Fresh DAS build has the following test case failure: Tests run: 154, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.006sec FAILURE! testUserProvidedModelDynamic(org.apache.tuscany.das.rdb.test.TopDown ) Time elap sed: 0.06 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.fillParamet er(UpdateGenerator.java:200) at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.createParam eter(UpdateGenerator.java:221) at org.apache.tuscany.das.rdb.generator.impl.UpdateGenerator.getUpdateCo mmand(UpdateGenerator.java:99) at org.apache.tuscany.das.rdb.impl.ChangeFactory.getUpdateCommand (Change Factory.java:156) at org.apache.tuscany.das.rdb.impl.ChangeFactory.createUpdateOperation(C hangeFactory.java:70) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.createChange (ChangeS ummarizer.java:116) at org.apache.tuscany.das.rdb.impl.ChangeSummarizer.loadChanges (ChangeSu mmarizer.java:81) at org.apache.tuscany.das.rdb.impl.ApplyChangesCommandImpl.execute (Apply ChangesCommandImpl.java:65) at org.apache.tuscany.das.rdb.impl.DASImpl.applyChanges( DASImpl.java :312 ) at org.apache.tuscany.das.rdb.test.TopDown.testUserProvidedModelDynamic( TopDown.java:69) at org.apache.tuscany.das.rdb.test.TopDown.testUserProvidedModelDynamic( TopDown.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:816) Results : Tests in error: testUserProvidedModelDynamic(org.apache.tuscany.das.rdb.test.TopDown) When debugged a bit around this, what I found is , case sensitivity is the issue. i.e. type Customer does have property id, and not ID and this is causing the test case to fail. Does anybody have any clue? Regards, Amita -- Luciano Resende http://people.apache.org/~lresende
Re: LauncherUsage.txt, was: Running Java SCA Calculators sample?
On 2/28/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 28, 2007, at 1:02 PM, Simon Laws wrote: On 2/28/07, Jeremy Boynes [EMAIL PROTECTED] wrote: This might be a CRLF issue with the master copy for the test output as it works for me on OSX (\n type line separators). If so, then except for aborting the build, it's not significant. Is anyone else on Windows seeing this as an issue? Hi Jeremy. As you say the LauncherUsage.txt file has \n alone. I'll give it a spin tommorrow and see what it is checking against. Thanks for how to run info, now I've done it that first time it's all a bit clearer. If you are on Windows and that just has \n then we'll have problems. The test code expects the file to have the same line endings as the output from the command i.e. \n on Linux/OSX and \r\n on Windows. To do that it sets svn:eol-style to native which should me \r\n on checkout. Are you using Cygwin? That might have an impact. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apologies Jeremy. This is entirely my fault. I'm running with the svn client native settings here ( http://svn.apache.org/repos/asf/incubator/tuscany/cpp/etc/svn-config) rather than the java setting here ( http://svn.apache.org/repos/asf/incubator/tuscany/java/). I'll look to see if we can consolidate, or at least make them the same, as this gets confusing for anyone who has the desire to look at both projects. Regards Simon
Re: [SDO] Question:Support for xpath expression to get batch of DOs
Hi Kevin, Frank, Yes, Frank, thanks a lot. This is what exactly I was looking for. When this gets added to the SDO spec, I would surely like to work on the Tuscany-SDO implementation part of it. Also, Kevin, will you please provide me some pointers on the scheme front. I have so far worked on DAS and will need to know more of SDO to get a better understanding. Regards, Amita On 2/27/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Amita, I'm pretty sure when you say the current SDO you are meaning the Tuscany implementation. The SDO spec allows for extensibility here in that it includes a scheme prefix to the path syntax, which if left out is implicitly sdo:. Tuscany only has the default scheme implemented. So one way forward might be to implement an alternative scheme. However, I'm not sure that would work, since the interfaces which would permit the return of a collection (get(),getList()) have javadoc documentation which constrain them to return the value of a Property. A long while back I heard talk of an XPathHelper I think, but I don't have a notion of any current activity in that direction at the spec or implementation level. Is this something you feel you'd like to get involved with? Best Regards, Kelvin. On 27/02/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, In the current SDO, the support is provided for do.getDataObject(xpath) and rootDo.getList(property) But there is no way to get multiple DOs from evaluating xpath. i.e. expression like rootDo.getDataObject(customer[name='patrick']) returns the first matching row and not all matching rows. And expression like rootDo.getList(customer) gets all customers, but does not support xpath syntax to tailor the list for a selective (name='patrick') condition. If the user wants a convenient way to get all customers with name='patrick', he needs to get this with recursion over root DO and using detach() method. Is there any helper method available in Tuscany-SDO for this kind of operation as it will be a basic requirement for any batch select/update etc. operations on a data source? Regards, Amita - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Native] AlertAggregator problem
On 3/1/07, Pete Robbins [EMAIL PROTECTED] wrote: When running the AlertAggregator sample on Mac I start the httpd server fine but when I point the browser (Firefox or Safari) at localhost:9090 I get a not found. Pointing at localhost:9090/index.html simply displays the heml source of the document. The apache error_log contains: [Thu Mar 01 07:24:23 2007] [notice] Apache/2.2.3 (Unix) configured -- resuming normal operations [Thu Mar 01 07:24:48 2007] [error] [client 127.0.0.1] Attempt to serve directory: /Users/Pete/Documents/workspace/cpp/sca/deploy/samples/AlertAggregator/deploy/httpserver/htdocs/ [Thu Mar 01 07:25:41 2007] [error] [client ::1] Attempt to serve directory: /Users/Pete/Documents/workspace/cpp/sca/deploy/samples/AlertAggregator/deploy/httpserver/htdocs/ [Thu Mar 01 07:25:41 2007] [error] [client ::1] File does not exist: /Users/Pete/Documents/workspace/cpp/sca/deploy/samples/AlertAggregator/deploy/httpserver/htdocs/favicon.ico [Thu Mar 01 07:25:46 2007] [error] [client ::1] File does not exist: /Users/Pete/Documents/workspace/cpp/sca/deploy/samples/AlertAggregator/deploy/httpserver/htdocs/favicon.ico [Thu Mar 01 07:26:48 2007] [notice] caught SIGTERM, shutting down Any ideas? Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yep, I see this on one of my Linux boxes, but not my Windows machine.. It can be fixed by adding the mime_module to the httpd.conf file with following line: LoadModule mime_module /usr/lib/httpd/modules/mod_mime.so Then a restart will make http://localhost:9090/index.html work fine (you may need to do a 'hard' refresh on your browser - try holding down shift or ctrl when you click the reload button) To get the http://localhost:9090 address to work, I think you need to add in the dir_module: LoadModule dir_module /usr/lib/httpd/modules/mod_dir.so Both of these require us to know where the HTTPD modules are installed, which is why they're not included by default. We could add (another) env variable to set up the conf files, but it seems to work on some systems and not others. Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-952) DAS must support queries that reference tables in different schemas
[ https://issues.apache.org/jira/browse/TUSCANY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-952: Attachment: JIRA-952-Mar01-Amita.jar added more code refinement and stored procedure related note in .doc. DAS must support queries that reference tables in different schemas - Key: TUSCANY-952 URL: https://issues.apache.org/jira/browse/TUSCANY-952 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-SCA-Mx Reporter: Kevin Williams Fix For: Java-DAS-Mx Attachments: JIRA-952-Feb16-Amita.jar, JIRA-952-Mar01-Amita.jar The DAS is curently ignorant of database schema designations. This means the DAS will generate incorrect write statements when it processes the change summary from a data graph that originated from a query that uses schema names that are different from the default schema. -- 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-1148) binding.ws which does not explicitly refer to a WSDL only works when using interface.wsdl
binding.ws which does not explicitly refer to a WSDL only works when using interface.wsdl - Key: TUSCANY-1148 URL: https://issues.apache.org/jira/browse/TUSCANY-1148 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-integration Reporter: ant elder Fix For: Java-SCA-integration binding.ws which does not explicitly refer to a WSDL only works when using interface.wsdl -- 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] Assigned: (TUSCANY-1021) CopyHelper and EqualityHelper should handle ChangeSummary
[ https://issues.apache.org/jira/browse/TUSCANY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson reassigned TUSCANY-1021: --- Assignee: Kelvin Goodson CopyHelper and EqualityHelper should handle ChangeSummary - Key: TUSCANY-1021 URL: https://issues.apache.org/jira/browse/TUSCANY-1021 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Yang ZHONG Assigned To: Kelvin Goodson Fix For: Java-SDO-Mx ChangeSummary can now be any DataObject attribute, and it's stale through EMF API. Currently, CopyHelper and EqualityHelper heavily depend on EMF. That needs to be patched to support ChangeSummary at any DataObject depth and its summarization if necessary. FYI, 859 has introduced an effort to make ChangeSummary never stale through *SDO* 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]
[jira] Updated: (TUSCANY-1021) CopyHelper and EqualityHelper should handle ChangeSummary
[ https://issues.apache.org/jira/browse/TUSCANY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1021: Fix Version/s: (was: Java-SDO-Mx) Affects Version/s: (was: Java-SCA-Mx) Java-SDO-Mx CopyHelper and EqualityHelper should handle ChangeSummary - Key: TUSCANY-1021 URL: https://issues.apache.org/jira/browse/TUSCANY-1021 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Assigned To: Kelvin Goodson ChangeSummary can now be any DataObject attribute, and it's stale through EMF API. Currently, CopyHelper and EqualityHelper heavily depend on EMF. That needs to be patched to support ChangeSummary at any DataObject depth and its summarization if necessary. FYI, 859 has introduced an effort to make ChangeSummary never stale through *SDO* 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]
Trying to package a standalone application.
Hi, I try to package a standalone SCA ws-client. I follow the instructions on http://incubator.apache.org/tuscany/java_sca_overview.html But when I launcher the application an exception occured : Exception in thread main java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException at org.apache.tuscany.sdo.util.SDOUtil.createXMLStreamHelper(SDOUtil.java:338) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:43) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:37) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.transform(Output2OutputTransformer.java:176) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transform(DataBindingInteceptor.java:105) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:89) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:121) at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication(MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:88) I have read something about the XMLStreamException dependency on SDO (jira *TUSCANY*-1105) and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14302.html and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12442.html But don't know if my problem is linked to this or how I can solve it. I'm using tuscany-sca M2 binaries for windows, JDK 1.5.06. I hope you can help me. -- Guillaume Dufrene. PhD student at LIFL (France), INRIA ADAM team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476922 ] Geoff Winn commented on TUSCANY-1147: - Caroline, I applied this patch to the current source and when I run sdotest I get an access violation from b46617b at the end while all the destructors are being called. Geoff. AccessViolation in DataObjectImpl::clearReferences() Key: TUSCANY-1147 URL: https://issues.apache.org/jira/browse/TUSCANY-1147 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, PHP 5.2.1 Reporter: Caroline Maynard Priority: Critical Attachments: Tuscany-1147.patch Problem observed when SDO A refers to SDO B. The reference to SDO A is dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in the SDODataObject destructor, in DataObjectImpl::clearReferences(). I believe this is because the reference was not properly cleared at the time of A's destruction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476934 ] Caroline Maynard commented on TUSCANY-1147: --- That doesn't surprise me too much, there seems to be quite a network of these dependencies, which will all creep out one by one as we break down the previous one. Obviously I don't know what you have at 0xb46617b (!) so I can't guess what you're seeing. Would you agree with the fix by inspection? If you want to try it, the scenario is the classic company-departments-employees, where company-employeeOfTheMonth is a reference to one of the employees. So first drop the company, while still holding a reference to the employee, then drop the employee. Bang. AccessViolation in DataObjectImpl::clearReferences() Key: TUSCANY-1147 URL: https://issues.apache.org/jira/browse/TUSCANY-1147 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, PHP 5.2.1 Reporter: Caroline Maynard Priority: Critical Attachments: Tuscany-1147.patch Problem observed when SDO A refers to SDO B. The reference to SDO A is dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in the SDODataObject destructor, in DataObjectImpl::clearReferences(). I believe this is because the reference was not properly cleared at the time of A's destruction. -- 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]
ScdlContributionProcessor and Axis2 binding getting the composite name?
I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant
Re: Trying to package a standalone application.
You will need to have the StAX API and an implementation visible in the same classloader as used for SDO. If you have the SDO impl jars in WEB-INF/lib you should make sure: * stax-api-1.0.1.jar * wstx-asl-3.2.0.jar are in the same place (using the StAX impl from http:// woodstox.codehaus.org). -- Jeremy On Mar 1, 2007, at 4:39 AM, Guillaume Dufrêne wrote: Hi, I try to package a standalone SCA ws-client. I follow the instructions on http://incubator.apache.org/tuscany/ java_sca_overview.html But when I launcher the application an exception occured : Exception in thread main java.lang.NoClassDefFoundError: javax/ xml/stream/XMLStreamException at org.apache.tuscany.sdo.util.SDOUtil.createXMLStreamHelper (SDOUtil.java:338) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfor m(XMLStreamReader2DataObject.java:43) at org.apache.tuscany.databinding.sdo.XMLStreamReader2DataObject.transfor m(XMLStreamReader2DataObject.java:37) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tran sform(Output2OutputTransformer.java:176) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate (MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transfo rm(DataBindingInteceptor.java:105) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke( DataBindingInteceptor.java:89) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke (AbstractOutboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke (JDKOutboundInvocationHandler.java:121) at $Proxy19.getOperations(Unknown Source) at scabank.ClientComponent.getOperations(Unknown Source) at scabank.ClientImpl.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.launcher.MainLauncherBooter.runApplication (MainLauncherBooter.java:107) at org.apache.tuscany.launcher.MainLauncherBooter.main (MainLauncherBooter.java:88) I have read something about the XMLStreamException dependency on SDO (jira *TUSCANY*-1105) and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg14302.html and on http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg12442.html But don't know if my problem is linked to this or how I can solve it. I'm using tuscany-sca M2 binaries for windows, JDK 1.5.06. I hope you can help me. -- Guillaume Dufrene. PhD student at LIFL (France), INRIA ADAM team. - 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: ScdlContributionProcessor and Axis2 binding getting the composite name?
Yes, on closer reading that is right. Thanks! ...ant On 3/1/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Isn't it based on the parent componentId and not the composite name? -- Jeremy On Mar 1, 2007, at 6:14 AM, ant elder wrote: I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/ WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1147) AccessViolation in DataObjectImpl::clearReferences()
[ https://issues.apache.org/jira/browse/TUSCANY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476960 ] Caroline Maynard commented on TUSCANY-1147: --- My bad. It wasn't intuitive to me :-) By drop, I mean, cause the reference count to decrement to zero. In the case of the PHP impl, by setting the referring pointer to NULL. AccessViolation in DataObjectImpl::clearReferences() Key: TUSCANY-1147 URL: https://issues.apache.org/jira/browse/TUSCANY-1147 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, PHP 5.2.1 Reporter: Caroline Maynard Priority: Critical Attachments: Tuscany-1147.patch Problem observed when SDO A refers to SDO B. The reference to SDO A is dropped. Then the reference to SDO B is dropped. An AccessViolation occurs in the SDODataObject destructor, in DataObjectImpl::clearReferences(). I believe this is because the reference was not properly cleared at the time of A's destruction. -- 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: Questions around Contribution Service behavior
On Feb 28, 2007, at 9:59 PM, Luciano Resende wrote: While reviewing contribution code and thinking about some test scenarios, I have the following questions and would like to get some thoughts. 1.What should be the default behavior when i re-deploy a contribution to the repository ? Should it replace the existing application, or an exception should be thrown ? It should be duplicated - they are two separate contributions of the similar things. If the two items are identical, then you can silently drop the duplicate; if they are not identical then they are two different versions of something. 2.When you re-deploy a contribution, should it get a new contributionId ? or continue to use the same ? A different contributionId as that is how a user can tell them apart. 3.When deploying a folder contribution, should we support store this contribution into the repository ? Generally yes (including copying it) as in a production system you would not want inadvertent changes to the source disrupting service. You will also generally want to archive it up for distribution around the federation. At development time though things are different as you want changes made by the developer to be reflected quickly without them having to stop/package/redeploy/start all the time. This really requires much closer integration between the IDE and the runtime than the contribution service provides (for example, the IDE could interact with the runtime to rebuild individual components). 4.In contributionService, do we really need to pass the InputStream for the contribution service ? would we have scenarios where we will not be able to access the contribution via it's url / uri ? I'd like to leave to the contribution to decide really when it would be necessary to open the streams to probably have a better performance and use less resources. Yes - the most likely way a contribution would get to a production server is though a transport like HTTP POST. It is very unlikely that a remote server will be able to initiate a connection back to a client. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using XML- Java data bindings without WSDL
For the past couple days I've been trying to understand how one would use the databinding framework to serialize/deserialize something like JAXB/SDO to/from XML without a WSDL present. I've been doing this over a dummy binding implementation. I'm ready to ask for some help as I've run into one issue after another and haven't succeeded in my first goal which was to use a 'Node' DB for my dummy binding's binding ServiceContract which would be able to handle apps annotated with: [EMAIL PROTECTED](name= javax.xml.bind.JAXBElement) * I've mostly been looking at the Axis2 binding as a model though I've realized that it relies heavily on the presence of a WSDL definition. Whether the Composite-level ref/srvc is defined with interface.java or interface.wsdl, there is still a WSDL along with the binding.ws. The introspection performed by InterfaceWSDLIntrospector is key to loading DB-related info for the model Operation, etc. objects. Working without a WSDL... I'm basically cloning the component-level SC and adjusting the DB at the binding SC level. I still haven't suceeded and I am now realizing that as a next step I could copy and rework some of the processing currently in the WSDLOperation class. That is, I could load my XSD file into an XML Schema object and build relevant Tuscany DB objects: DataType, etc. So, (leaving aside the artifact loading question of how my Composite would point to an XSD file .. I'll have to search the list archives and specs for the latest on that). I'm just wondering who's been down this path before and if anyone has any sample code that would help me make some progress... or maybe there is somewhere in the current SVN tree that I'm missing. Thank you, Scott
Re: Native M3 release status
I'm just about at a point where I can produce a release candidate which includes everything except the PHP extension. I'm wondering if it would be best to publish this then release the PHP extension as a separate entity. We could go the whole hog and release a core package and then separate packages for cpp, Ruby, Python, WS binding etc.. Ultimately I think this is the way to go So If I just want to develop in Ruby and use REST I can download core, Ruby and Rest extensions and not worry about the others, and more impoortantly, their dependencies. Any thoughts? -- Pete
[SDO for C++] Design notes added to repository
For a while now I've been adding design notes for SDO to the Wiki ( http://wiki.apache.org/ws/Tuscany/TuscanyCpp/DesignNotes) whenever I came across something useful. I've updated that page to describe the re-write that I did a few weeks ago to eliminate a lot of C style macro code. I've also taken a copy of the page and added it to repository at sdo/doc/DesignNotes.htm as a backup copy. Geoff.
Re: Cleaning up and reorganizing samples
Hi, Its really good if we can have sampleapps out - to have another bigbank in it is quite confusing, for me. With respect to the naming conventions, yes, it would be good to have them all uniform, and I prefer something as loanAppConversation_ws as against loanappconversationws which is quite painful to make out without peering thro - this is just my opinion. Thanks. - Venkat On 3/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I took a look at the samples in the integration branch and would like to do some cleanup and a little reorganization. - Move the Web Service samples still under samples to sca/extensions/axis2/samples. - Rename samples/bigbank (this is a scaled down version of bigbank) to simplebigbank. - Move sampleapps/bigbank to samples and delete sampleapps. - Cleanup the names of the samples, we have calculator-ws, helloworldws, loanappconversationWS, echo.binding, maybe we need to make up our minds and pick a single consistent naming convention :) I'd like to propose calculatorws, helloworldws, loanappconversationws, echobinding (no dash no dot, all lowercase), or use dashes in the names if people prefer that. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleaning up and reorganizing samples
Hi, I prefer to have the following convention: calculator-ws helloworld-ws echo-binding Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, February 28, 2007 10:49 PM Subject: Cleaning up and reorganizing samples I took a look at the samples in the integration branch and would like to do some cleanup and a little reorganization. - Move the Web Service samples still under samples to sca/extensions/axis2/samples. - Rename samples/bigbank (this is a scaled down version of bigbank) to simplebigbank. - Move sampleapps/bigbank to samples and delete sampleapps. - Cleanup the names of the samples, we have calculator-ws, helloworldws, loanappconversationWS, echo.binding, maybe we need to make up our minds and pick a single consistent naming convention :) I'd like to propose calculatorws, helloworldws, loanappconversationws, echobinding (no dash no dot, all lowercase), or use dashes in the names if people prefer that. Thoughts? -- 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]
[jira] Updated: (TUSCANY-684) Generated SDO classes should be able to register the static types to a given TypeHelper
[ https://issues.apache.org/jira/browse/TUSCANY-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-684: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 Generated SDO classes should be able to register the static types to a given TypeHelper --- Key: TUSCANY-684 URL: https://issues.apache.org/jira/browse/TUSCANY-684 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Raymond Feng Assigned To: Frank Budinsky Fix For: Java-SDO-M3 In the generated SDO classes, static types are automatically registered into the EMF global registry. This behavior prevent us from keeping SDO types into different scopes defined by external schemes. It would be nice that we can do somthing like: SDOUtil.registerStaticTypes(TypeHelper scope, Class factoryClass); Thanks, Raymond -- 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-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: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 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-M3 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]
[jira] Updated: (TUSCANY-1099) fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users
[ https://issues.apache.org/jira/browse/TUSCANY-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1099: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 fix for TUSCANY-1083 used lookupPrefix method of Node not available to Java 1.4.2 users --- Key: TUSCANY-1099 URL: https://issues.apache.org/jira/browse/TUSCANY-1099 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Java 1.4.2 Reporter: Paul Golick Fix For: Java-SDO-M3 Attachments: SDOXSDEcoreBuilder.1099 mvn build ends with message: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Tuscany\java505002\sdo\impl\src\main\java\org\apache\tuscany\sdo\helper\SDOXS DEcoreBuilder.java:[71,50] cannot resolve symbol symbol : method lookupPrefix (java.lang.String) location: interface org.w3c.dom.Element -- 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-1097) DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence
[ https://issues.apache.org/jira/browse/TUSCANY-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1097: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 DataObjectXMLStreamReader shouldn't have ignored (transient Properties in) Sequence --- Key: TUSCANY-1097 URL: https://issues.apache.org/jira/browse/TUSCANY-1097 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-M3 Attachments: 1097.patch, DataObjectXMLStreamReader.1097, DataObjectXMLStreamReader.java, XMLStreamHelperTestCase.1097 DataObjectXMLStreamReader shouldn't have outputed nothing for Sequenced DataObject. -- 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-1055) DataFactory.create(abstract_type) should throw an IllegalArgumentException
[ https://issues.apache.org/jira/browse/TUSCANY-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1055: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 DataFactory.create(abstract_type) should throw an IllegalArgumentException -- Key: TUSCANY-1055 URL: https://issues.apache.org/jira/browse/TUSCANY-1055 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: You should see this error in any environment. Reporter: Ki Park Priority: Minor Fix For: Java-SDO-M3 Attachments: TUSCANY-1055.patch Use an Abstract type as a parameter of DataObject.create() and it works fine now without any exception, but it should throw an exception. According to the spec in section 3.7.2 Creating Data Objects, it reads: - Type.dataType and abstract must be both fase. - Throw an IllegalArgumentException if the instanceClass does not correspond to a Type this factory can instantiate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
[ https://issues.apache.org/jira/browse/TUSCANY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1062: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters --- Key: TUSCANY-1062 URL: https://issues.apache.org/jira/browse/TUSCANY-1062 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Paul Golick Fix For: Java-SDO-M3 Attachments: DataGraphImpl_patch.txt, DataGraphTestCase.jar When createRootObject is called and a root object has already been created, the SDO 2.1 spec calls for an IllegalStateException but the current implementation replaces the existing root. Also, when either a type is not provided or when a type cannot be determined from the URI and typeName provided, a NullPointerException is thrown from org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user who is not literate in emf utilities: an exception with a helpful error message should be provided. Attached are: a) a jar containing a new test case file for DataGraph (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) b) a patch that corrects these problems in sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- 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-718) make -noEMF code generation the default
[ https://issues.apache.org/jira/browse/TUSCANY-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-718: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 make -noEMF code generation the default --- Key: TUSCANY-718 URL: https://issues.apache.org/jira/browse/TUSCANY-718 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-Mx Reporter: Kapil Katyal Priority: Minor Fix For: Java-SDO-M3 Attachments: patch1.txt Need to make the noEMF option on the codegen tool the default immediately after M2 -- 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-930) Add new SDOUtil.createHelperContext() method
[ https://issues.apache.org/jira/browse/TUSCANY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-930: --- Fix Version/s: Java-SDO-M3 Add new SDOUtil.createHelperContext() method Key: TUSCANY-930 URL: https://issues.apache.org/jira/browse/TUSCANY-930 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Reporter: Frank Budinsky Assigned To: Kelvin Goodson Fix For: Java-SDO-M3 In SDO 2.1, helpers are accessed using a HelperContext. New method SDOUtil.createHelperContext() will replace all the existing SDOUtil.createXXXHelper() methods, which should be deprecated. -- 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-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 updated TUSCANY-521: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 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-M3 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-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:
Fix Version/s: (was: Java-SDO-Mx)
Java-SDO-M3
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-M3
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]
[jira] Updated: (TUSCANY-836) doubleValue() may be inaccurate for Long
[
https://issues.apache.org/jira/browse/TUSCANY-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-836:
---
Fix Version/s: (was: Java-SCA-Mx)
Java-SDO-M3
doubleValue() may be inaccurate for Long
Key: TUSCANY-836
URL: https://issues.apache.org/jira/browse/TUSCANY-836
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SCA-Mx
Environment: Sun JRE 1.5.0_07-b03
Reporter: Yang ZHONG
Fix For: Java-SDO-M3
Attachments: Long2BigDecimalTestCase.java
assertSame(DataObjectUtil.getBigDecimal(new
Long(Long.MAX_VALUE)).longValue(), Long.MAX_VALUE);
complains
junit.framework.AssertionFailedError: expected
same:-9223372036854775808 was not:9223372036854775807
Potential fix:
if (value instanceof Long)
{
return new BigDecimal(((Long)value).longValue());
}
before
if (value instanceof Number)
{
return new BigDecimal(((Number)value).doubleValue());
}
Thanks to Marcelo Palladino.
--
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-887) TypeHelper.define() should create an accompanying global property per type
[ https://issues.apache.org/jira/browse/TUSCANY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-887: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 TypeHelper.define() should create an accompanying global property per type -- Key: TUSCANY-887 URL: https://issues.apache.org/jira/browse/TUSCANY-887 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-M3 Whilst the spec isn't explicit about the behaviour of TypeHelper.define() in this respect, it can be inferred from the specified behaviour of SDO to XSD generation ... The global element for the type: ? lowercase(TYPE.NAME) is the type name with the first letter converted to lower case ... that the definition of a type using TypeHelper.define(), should also implicitly define a global element to be available using the same naming rules -- 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-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: Fix Version/s: (was: Java-M2) Java-SDO-M3 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-SDO-M3 Attachments: 1130.patch, 1130.patch, 1130_final.patch, 1130_new.patch, HelperContextMultiThreadedTestCase.java 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]
[jira] Updated: (TUSCANY-1102) Support EMF 2.2.2
[ https://issues.apache.org/jira/browse/TUSCANY-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1102: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Support EMF 2.2.2 - Key: TUSCANY-1102 URL: https://issues.apache.org/jira/browse/TUSCANY-1102 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-M3 Attachments: 1102 http://issues.apache.org/jira/browse/TUSCANY-1101 requires EMF 2.2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-701) Conversion to date types which do not include month can give incorrect results
[ https://issues.apache.org/jira/browse/TUSCANY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-701: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 Conversion to date types which do not include month can give incorrect results -- Key: TUSCANY-701 URL: https://issues.apache.org/jira/browse/TUSCANY-701 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: Problem exists when running Sun JVM (is not seen on IBM JVM) Reporter: Brian Murray Priority: Minor Fix For: Java-SDO-M3 Attachments: Tuscany701.patch DateConversionTestCase.java made evident an issue corrected in Tuscany-582. However, when it was introduced into the Tuscany stream an additional error was seen sporadically (repeatedly for a given individual, but for a set of individuals only a subset would see the problem). This JIRA will address the additional error. The reason the problem is seen only by a subset of people is that it is JVM specific. When it is seen (as it is with the Sun JVM), the nature of the problem is to report Day, Hour, and even Year values as X - 1, where X is the correct value. The problem occurs when the requested date format does not include a month (e.g. toYear, toDay). The truncated month is assigned a value of January, and the Sun JVM may then (depending on the TimeZone, northern versus southern hemisphere, and the month in which the test is run) change the time to reflect the change to or from daylight savings time. The reason it can have an impact on toYear is that toYear() for an input date of Wednesday September 6, 2006 03:16:20.382 would result in an interim value of Sunday January 1, 2006 00:00:00.000. In the case where an error is seen, an adjustment is made for daylight savings time to Saturday December 31, 2005 23:00:00.000. As such, toYear erroneously returns a value of 2005 for the input date (in the error case). Would a committer please assign this issue to me?. -- 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-928) Define Tuscany SDO options for XMLHelper load and save operations
[ https://issues.apache.org/jira/browse/TUSCANY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-928: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Define Tuscany SDO options for XMLHelper load and save operations - Key: TUSCANY-928 URL: https://issues.apache.org/jira/browse/TUSCANY-928 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-M3 Attachments: ChangeSummaryPropertyTestCase.928, options.928, SDOXMLResourceImpl.928, SDOXMLResourceImpl.java, XMLHelperTestCase.java, XMLHelperTestCase.java XMLHelper's load and save operations take an Object argument options, which is currently cast to a Map and forwarded to EMF. Anyone wishing to influence the behaviour of the save/load operations must understand this aspect of EMF and use EMF artifacts in their programs. We need to design and implement an SDO approach to passing options, hiding the implementation details completely. -- 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-859) ChangeSummary#isCreated cache is not updated while changes are still going on
[
https://issues.apache.org/jira/browse/TUSCANY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-859:
---
Fix Version/s: Java-SDO-M3
ChangeSummary#isCreated cache is not updated while changes are still going on
-
Key: TUSCANY-859
URL: https://issues.apache.org/jira/browse/TUSCANY-859
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SCA-Mx
Reporter: Yang ZHONG
Fix For: Java-SDO-M3
Attachments: 859.patch, ChangeSummaryImpl.859,
NeverStaleChangeSummaryTestCase.java, T859.patch
This Test Case uses simple.xsd from tuscany/java/sdo/impl/src/test/resources,
however it's a *generic* issue, not specific to simple.xsd.
child = quote.createDataObject(quotes);
assertTrue(changeSummary.isCreated(child));
child = quote.createDataObject(quotes);
assertTrue(changeSummary.isCreated(child));
The last assertion fails.
ChangeSummary#isCreated delegates to *derived* getObjectsToDetach()
caching which improves performance.
However, the cache should be updated while changes are still going on.
I have browsed the spec 2.1draft and 2.01, they don't seem forbid users from
querying ChangeSummary before endLogging().
One of the possible solutions is to invalidate cache whevever there's a new
change, such as
public void SDOChangeRecorder#notifyChanged(Notification notification)
{
cachedObjectsToDetach = null;
super.notifyChanged( notification);
}
--
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-1093) isSet returning false when boolean set to false, or int set to 0
[ https://issues.apache.org/jira/browse/TUSCANY-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1093: Fix Version/s: Java-SDO-M3 isSet returning false when boolean set to false, or int set to 0 Key: TUSCANY-1093 URL: https://issues.apache.org/jira/browse/TUSCANY-1093 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Robbie Minshall Priority: Critical Fix For: Java-SDO-M3 Attachments: patch, patch when boolean property is set to false a call to isSet returns false ( should return true ). when an int property is set to 0 a call to isSet returns false ( should return true ). This causes DataObject serialization ( our scenario involves using the sca ws binding ) to be missing values that have been set. -- 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-958) NPE generated during a property set of a static SDO
[ https://issues.apache.org/jira/browse/TUSCANY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-958: --- Fix Version/s: Java-SDO-M3 NPE generated during a property set of a static SDO --- Key: TUSCANY-958 URL: https://issues.apache.org/jira/browse/TUSCANY-958 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Environment: N/A Reporter: David T. Adcox Fix For: Java-SDO-M3 Attachments: tuscany958.diff When a property is set on a static SDO object, a Null Pointer Exception is thrown. This will only occur if the property is being set for the second time, the initial set of the property works. The problem is caused by some erroneous code in the DataObjectImpl class. In the inverseAdd(Object,int,ChangeContext) method, the local variable, changeContextImpl is retrieved from a local method initializeChangeContext(ChangeContext). Then, immediately following this line of code, the same variable is set again by way of a cast of a parameter to the method. In some instances, the value being passed is null, so when the value is used later, an NPE will occur. It seems the cast-set is possibly an old remnant of code from before the creation of the InitializeChangeContext method. This method properly handles the creation of the ChangeContext and works fine, we simply need to comment out the cast-set line of code. A similar behavior is found in inverseRemove(Object,Object,int,Class, ChangeContext), so it should be fixed, as well. -- 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-894) SDO (and indirectly DAS) may not now depend on CPL if EMF has completed migration to EPL
[ https://issues.apache.org/jira/browse/TUSCANY-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-894: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 SDO (and indirectly DAS) may not now depend on CPL if EMF has completed migration to EPL Key: TUSCANY-894 URL: https://issues.apache.org/jira/browse/TUSCANY-894 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Kelvin Goodson Assigned To: Kelvin Goodson Fix For: Java-SDO-M3 The IPMC review of the LICENSE file for SDO M2 asked for clarification of which jars in the SDO distribution depend relate to which licenses. Eclipse began a migration from the CPL to the EPL a while back (http://www.eclipse.org/legal/cpl2epl/CPL2EPLTransitionPlan.pdf) and I have checked every about.html file in every EMF jar that we redistribute, and they all reference EPL and not CPL, so I believe the migration is complete for the set of jars that we redistribute and that thererfore the CPL can be removed from our LICENSE.txt files in SDO Impl and in DAS (unless DAS has some other dependency on CPL). I would like independent confrmation of my assertion before removing the CPL from the LICENSES files. -- 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-396) Cardinality of wildcard element not respected
[
https://issues.apache.org/jira/browse/TUSCANY-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-396:
---
Fix Version/s: (was: Java-SCA-Mx)
Java-SDO-M3
Cardinality of wildcard element not respected
-
Key: TUSCANY-396
URL: https://issues.apache.org/jira/browse/TUSCANY-396
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SCA-Mx
Reporter: Kelvin Goodson
Fix For: Java-SDO-M3
I think there's a problem with the SDO Java setting of open content with
respect to cardinality.
Given a type ...
xsd:complexType name=OpenQuote
xsd:sequence
xsd:element name=symbol type=xsd:string/
xsd:any namespace=##any maxOccurs=1 /
/xsd:sequence
/xsd:complexType
and a global element
xsd:element name=note type=xsd:string/
I'd expect to be able to use generated code in this way
OpenQuote oq = OpenFactory.INSTANCE.createOpenQuote();
Property pc =
XSDHelper.INSTANCE.getGlobalProperty(http://www.example.com/open;, note,
true);
((DataObject)oq).set(pc, TBA);
but this fails with a ClassCastException in BasicFeatureMap here ..
public void set(EStructuralFeature feature, Object object)
{
if (isMany(feature))
{
List list = list(feature);
list.clear();
list.addAll((Collection)object);
this is because the feature that is being tested for isMany(feature) is that
associated with the global element note, and not the xsd:any.
The note element is marked as maxOccurs=unspecified, and so the set()
method expects the Object object to be a List. Hence in my
code above I pass in a String, and the cast of String to List unsurprisingly
fails .
--
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-1088) SDO should tolerate malformed XML
[ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1088: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 SDO should tolerate malformed XML - Key: TUSCANY-1088 URL: https://issues.apache.org/jira/browse/TUSCANY-1088 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kevin Williams Assigned To: Kelvin Goodson Fix For: Java-SDO-M3 Attachments: FormTestCase.java, patch, patch I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. XML documents are often less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: ?xml version=1.0 encoding=UTF-8? xsd:schema targetNamespace=http://QuickTest/HelloWorld; xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xsd:element name=sayHello xsd:complexType xsd:sequence xsd:element name=input1 nillable=true type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:schema If we get an xml that looks like this: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd input1input1/input1 /tns:sayHello then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: ?xml version=1.0 encoding=UTF-8? tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://QuickTest/HelloWorld HelloWorldMessage.xsd tns:input1tns:input1/tns:input1 /tns:sayHello Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault=qualified enforcement policy. What do you think? 3-1. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; input1input1/input1 /tns:sayHello The author may have forgot to qualify input1 element, although input1 may also be a global element without NameSpace. It's friendly to tolerate. 3-2. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns:onPurpose=differentNameSpace onPurpose:input1input1/onPurpose:input1 /tns:sayHello The author has qualified input1 element; I'm not confident we should tolerate. 3-3. tns:sayHello xmlns:tns=http://QuickTest/HelloWorld; xmlns=differentNameSpace !-- xmlns= declares all unqualified elements/attributes under differentNameSpace -- input1input1/input1 /tns:sayHello It's hard to tell if the author may have forgot to qualify input1 element or not. I bet on not. Should we tolerate? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-933) XSD2Java Generator still generates EMF codes with -noEMF option on
[
https://issues.apache.org/jira/browse/TUSCANY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-933:
---
Fix Version/s: Java-SDO-M3
XSD2Java Generator still generates EMF codes with -noEMF option on
--
Key: TUSCANY-933
URL: https://issues.apache.org/jira/browse/TUSCANY-933
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SCA-Mx
Reporter: Fuhwei Lwo
Fix For: Java-SDO-M3
Attachments: Tuscany933.zip
This problem only occurred when base64Binary type was defined in the XSD.
The codegen tool would generate codes using EMF to handle base64Binary type.
public void initializeMetaData()
{
if (isInitialized) return;
isInitialized = true;
// Obtain other dependent packages
ModelFactoryImpl theModelPackageImpl =
(ModelFactoryImpl)FactoryBase.getStaticFactory(ModelFactoryImpl.NAMESPACE_URI);
XMLTypeFactoryImpl theXMLTypePackage =
(XMLTypeFactoryImpl)FactoryBase.getStaticFactory(bXMLTypeFactoryImpl.NAMESPACE_URI/b);
Property property = null;
// Add supertypes to classes
// Initialize classes and features; add operations and parameters
initializeType(testTypeType, TestType.class, TestType);
property = (Property)testTypeType.getProperties().get(TestTypeImpl.NAME);
initializeProperty(property, theModelPackageImpl.getString(), Name,
null, 1, 1, TestType.class, false, false, false);
property =
(Property)testTypeType.getProperties().get(TestTypeImpl.BASE64_VALUE);
initializeProperty(property, btheXMLTypePackage.getBase64Binary()/b,
Base64Value, null, 1, 1, TestType.class, false, false, false);
property =
(Property)testTypeType.getProperties().get(TestTypeImpl.HEX_VALUE);
initializeProperty(property, theModelPackageImpl.getBytes(), HexValue,
null, 1, 1, TestType.class, false, false, false);
createXSDMetaData(theModelPackageImpl);
}
--
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-1113) Extensible namespaces and types that change
[ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1113: Fix Version/s: Java-SDO-M3 Extensible namespaces and types that change --- Key: TUSCANY-1113 URL: https://issues.apache.org/jira/browse/TUSCANY-1113 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Environment: Eclipse, EMF 2.2.1 Reporter: Christian Landbo Frederiksen Fix For: Java-SDO-M3 Attachments: SDOXSDEcoreBuilder.java, SDOXSDEcoreBuilder.java, SDOXSDEcoreBuilder.java, SDOXSDEcoreBuilder.java, TestTypeChangesAndExtensibleNamespaces.java, TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace. I would like namespaces to be extensible. Once the types of a schema is defined you cannot change them by defining an altered version of the schema. I realize the dangers of modifying already defined types but I believe i ought to be an option. Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html An xml schema is uploaded and SDO is used to generate a form for submitting data as xml-instances of the schema. New schemas in the same namespace may be added often resulting in new forms (this is the first issue where I need to extend existing namespaces). Xml instances may later be edited again. This is the most common use case and SDO seems to support this very well. BUT xml schemas may be modified, even individual types. This of course flagged some warning signs and schema versions were considered. But 'use at own risk' was chosen because of its simplicity. To support this strategy a status/mode will be introduced so xml-instances cannot be edited while schema is in 'administration'-mode. This ought to handle the case with instances at schema-modification time. With regards to serialized xml instances any data that is rendered invalid with type changes will be reset/deleted as of design. -- 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-1086) Scope defined java serialiazation/deserialization of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1086: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Scope defined java serialiazation/deserialization of SDO Key: TUSCANY-1086 URL: https://issues.apache.org/jira/browse/TUSCANY-1086 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Fix For: Java-SDO-M3 Attachments: Final_SerDeserialization.zip, JavaSerDeserialization.patch, JavaSerDeserialize_NewFiles_TestCase.zip, JavaSerializeDeserializeTestCase.java, NEW_JavaSerDeserialization.patch Need to have a scope defined java serialization/deserialization of SDO's. Currently it can be done only in the Global/default scope. Have to fix this by using helperContext as the scope for creating ObjectInputStream and ObjectOutputStream. -- 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-1101) Support mixed Sequence and any Sequence in Change Summary
[ https://issues.apache.org/jira/browse/TUSCANY-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1101: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Support mixed Sequence and any Sequence in Change Summary - Key: TUSCANY-1101 URL: https://issues.apache.org/jira/browse/TUSCANY-1101 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-M3 Attachments: mixedChangeSummary.xml, mixedChangeSummaryUndone.xml, openChangeSummary.xml, openChangeSummaryUndone.xml, patch, patch, SDOXMLResourceImpl.java, SequenceChangeSummary.xsd To support mixed Sequence and any Sequence in Change Summary, including changes recording, changes reporting, XML serializing and XML deserializing. Has requested cooperation from EMF: https://bugs.eclipse.org/bugs/show_bug.cgi?id=172738 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=173214 -- 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-885) Property DataObject.getProperty(String propertyName) should return null if the property cannot be found
[ https://issues.apache.org/jira/browse/TUSCANY-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-885: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 Property DataObject.getProperty(String propertyName) should return null if the property cannot be found --- Key: TUSCANY-885 URL: https://issues.apache.org/jira/browse/TUSCANY-885 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Fuhwei Lwo Assigned To: Kelvin Goodson Priority: Minor Fix For: Java-SDO-M3 Attachments: DAS_885.txt, tuscany-885.patch Based on SDO 2.01 specification, DataObject.getProperty(String propertyName) should return null if the property cannot be found. Unfortunately, it returns IlegalArgumentException now. -- 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-931) Sequence.add(int index, String propertyName, Object value) is not functioning correctly
[ https://issues.apache.org/jira/browse/TUSCANY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-931: --- Fix Version/s: Java-SDO-M3 Sequence.add(int index, String propertyName, Object value) is not functioning correctly --- Key: TUSCANY-931 URL: https://issues.apache.org/jira/browse/TUSCANY-931 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2, Java-SCA-Mx Environment: No specific environment Reporter: David T. Adcox Fix For: Java-SDO-M3 Attachments: DefectTestApp.java, FeatureMapValidation.java, FeatureMapValidation.xsd, SDOUtil.931 The Sequence.add(int index, String propertyName, Object value) throws a java.lang.RuntimeException. Here is a stack trace from this issue: Exception in thread main java.lang.RuntimeException: Invalid entry feature 'Customer.multi' at org.eclipse.emf.ecore.util.BasicFeatureMap.validate(BasicFeatureMap.java:87) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:661) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:384) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:368) at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:645) at org.eclipse.emf.ecore.util.BasicFeatureMap.doAdd(BasicFeatureMap.java:547) at org.eclipse.emf.ecore.util.BasicFeatureMap.add(BasicFeatureMap.java:1097) at org.apache.tuscany.sdo.util.BasicSequence.add(BasicSequence.java:100) at com.ibm.sdo.test.DefectTestApp.main(DefectTestApp.java:60) The add(String propertyName, Object value) method seems to be functioning fine using the same Sequence object. In tracing this issue through EMF, it seems a validate method in the BasicFeatureMap object is failing in the base case and throwing the exception. -- 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-935) SDO path accessors need to support names that contain .
[ https://issues.apache.org/jira/browse/TUSCANY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-935: --- Fix Version/s: Java-SDO-M3 SDO path accessors need to support names that contain . - Key: TUSCANY-935 URL: https://issues.apache.org/jira/browse/TUSCANY-935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Frank Budinsky Fix For: Java-SDO-M3 Attachments: DataObjectUtil.935, dotNames.xsd, DotNameTestCase.java, more.935 This issue keeps coming up. The . character is commonly used in industrial schemas, so we need to make it work. I propose handling it as follows: Given a property name like foo.0: 1. first simply check if there is a property with the specified name. 2. if a property with that name isn't found, then find the last . character in the name. 3. if it is followed by digits, then use the substring from 0 to the . as the property name, and the number after the dot as an index. The only case this breaks is when there is both an isMany property named foo and another property named someting like foo.0 in the same type. I think this is an unlikely corner case, that we can live with. We'll also need to propose this behavior be clarified in the spec. -- 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-1123) test case generated code and metadata access is anachronistic
[ https://issues.apache.org/jira/browse/TUSCANY-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1123: Fix Version/s: Java-SDO-M3 test case generated code and metadata access is anachronistic - Key: TUSCANY-1123 URL: https://issues.apache.org/jira/browse/TUSCANY-1123 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation, Java SDO Tools Affects Versions: Java-SDO-Mx Environment: all Reporter: Kelvin Goodson Fix For: Java-SDO-M3 There are some generated SDO java files that use an old generator pattern, and some use of helper singletons in the SDO test cases. This can lead to test case interference as in TUSCANY-1091. -- 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-713) Discover and regiester new SDO types during the time of loading the XML instance document
[ https://issues.apache.org/jira/browse/TUSCANY-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-713: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Discover and regiester new SDO types during the time of loading the XML instance document - Key: TUSCANY-713 URL: https://issues.apache.org/jira/browse/TUSCANY-713 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Wish list Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: ProcessSchemaLocations.713, SchemaLocationTestCase.java, SchemaLocationTestCase.java, SchemaLocationTestCase.xml, SDOUtil.java, SDOXMLResourceImpl.patch Current SDO implementation requires one to register the SDO types before loading their instances from XML document. The new scenario is to load the XML document before registering the types. The SDO may require the XML document to provide some information to locate its schema or metadata location. Annotation may be one way to do it. The schemaLocation attribute is not sufficient because it's only a hint not necessarily a physical location. -- 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-1085) schemaLocation attribute in the xsd:import should be only a hint
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1085: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 schemaLocation attribute in the xsd:import should be only a hint -- Key: TUSCANY-1085 URL: https://issues.apache.org/jira/browse/TUSCANY-1085 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java, tuscany-1085.patch2 Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved. The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model. I will attach a test case later. -- 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-956) SDOFactory instance lookup is using the wrong namespace URI
[ https://issues.apache.org/jira/browse/TUSCANY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-956: --- Fix Version/s: (was: Java-SCA-Mx) Java-SDO-M3 SDOFactory instance lookup is using the wrong namespace URI --- Key: TUSCANY-956 URL: https://issues.apache.org/jira/browse/TUSCANY-956 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: tuscany-956.patch String eNS_URI = http://www.apache.org/tuscany/2005/SDO;; in SDOPackage.java was defined to represent Tuscany SDO package but in the SDOFactoryImpl.java it uses http://www.eclipse.org/emf/2003/SDO; to look up the registered SDOFactory instance. -- 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-1100) Dynamic Type tests are needed to ensure that all XSD datatypes are supported
[ https://issues.apache.org/jira/browse/TUSCANY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1100: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Dynamic Type tests are needed to ensure that all XSD datatypes are supported Key: TUSCANY-1100 URL: https://issues.apache.org/jira/browse/TUSCANY-1100 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Java 1.4.2 or later Reporter: Paul Golick Fix For: Java-SDO-M3 Attachments: 1100.patch, dynamicTypesFromSchema.jar, dynamicTypesFromSchemaCTS.jar, dynamicTypesFromSchemaCTS_patch.txt Dynamic Type tests are needed. This JIRA is used to contribute test cases that use xsd and xml to define Type objects. Another JIRA will be used for test cases that use DataObjects to define the Type objects. -- 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-972) commonj.sdo/xml namespace should be supported by SDO runtime by default
[ https://issues.apache.org/jira/browse/TUSCANY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-972: --- Fix Version/s: Java-SDO-M3 commonj.sdo/xml namespace should be supported by SDO runtime by default --- Key: TUSCANY-972 URL: https://issues.apache.org/jira/browse/TUSCANY-972 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: newMainSrc.zip, TypeHelperImpl.972 Currently commonj.sdo and commonj.sdo/java namespaces are supported by SDO runtime by default. Commonj.sdo/xml should be supported as part of SDO runtime model too. Thanks. -- 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-1091) DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance
[ https://issues.apache.org/jira/browse/TUSCANY-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1091: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 DataObjectXMLStreamReader doesn't have to repeat NameSpace declaration which impacts performance Key: TUSCANY-1091 URL: https://issues.apache.org/jira/browse/TUSCANY-1091 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-M3 Attachments: bindLessNS, bindLessNS, bindLessNS.patch, org.apache.tuscany.sdo.test.XMLStreamHelperPerformanceTestCase.txt, simple3.xsd, T-1091.log, XMLStreamHelper.xsd, XMLStreamHelperPerformanceTestCase.java p0:quotes3 p1:symbol3 xmlns:p1=http://www.example.com/simple3;IBM/p1:symbol3 p1:company3 xmlns:p1=http://www.example.com/simple3;IBM Corp./p1:company3 /p0:quotes3 can be optimized as p0:quotes3 xmlns:p1=http://www.example.com/simple3; p1:symbol3IBM/p1:symbol3 p1:company3IBM Corp./p1:company3 /p0:quotes3 Thanks to Fuhwei Lwo for prototyping the Test Case. I've made small changes to make use of HelperContext so that it will neither interfere nor be interfereed by other build test(s). -- 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-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1050: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SCA-M3, Java-SCA-Mx Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-M3 Attachments: TUSCANY1050.patch, TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- 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-932) Invoking DataObject.isSet(String path) with invalid path would result in NPE
[ https://issues.apache.org/jira/browse/TUSCANY-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-932: --- Fix Version/s: Java-SDO-M3 Invoking DataObject.isSet(String path) with invalid path would result in NPE Key: TUSCANY-932 URL: https://issues.apache.org/jira/browse/TUSCANY-932 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SCA-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: DataObjectUtil.932, final.patch, RevisedPatchWithTest The 2.1 spec didn't mention what outcome should be when invoking DataObject.isSet(String path) with an invalid path so I am not sure whether NPE is acceptable. The spec did mention bold?Note that attempts to modify read-only properties (using set, unset or delete) cause an exception./bold -- 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-934) XSD2JavaGenerator -noEMF option does not work with abstract classes.
[ https://issues.apache.org/jira/browse/TUSCANY-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-934: --- Fix Version/s: Java-SDO-M3 XSD2JavaGenerator -noEMF option does not work with abstract classes. Key: TUSCANY-934 URL: https://issues.apache.org/jira/browse/TUSCANY-934 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Reporter: Brian Murray Fix For: Java-SDO-M3 SDOUtil.registerStaticTypes() fails when the statically generated classes were created from an XSD that includes an abstract Type and the -noEMF option is used. The absence of abstract=true in the XSD or not using -noEMF during the XSD2JavaGenerate will allow the registerStaticTypes() to complete. -- 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-1083) Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth
[ https://issues.apache.org/jira/browse/TUSCANY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1083: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Shorter NameSpace prefix to speed up XML processing and reduce communication bandwidth -- Key: TUSCANY-1083 URL: https://issues.apache.org/jira/browse/TUSCANY-1083 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Yang ZHONG Fix For: Java-SDO-M3 Attachments: prefix.xsd, ShortPrefix Given XSD: schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://soaassureservice.soabench.ibm.com; xmlns:as=http://soaassureservice.soabench.ibm.com; element name=requestInfo type=string/ element name=createClaim ... SDO generates NameSpace prefix too long: soaassureservice:createClaim xmlns:soaassureservice=http://soaassureservice.soabench.ibm.com; soaassureservice:requestInfo.../soaassureservice:requestInfo ... -- 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]
Apologies for the SPAM
Folks, sorry. I've been doing a fair few bulk updates on SDO jiras this afternoon, and remembering to uncheck the Send Email Notification for all of them except the last. Please ignore. They are all associated with getting the Fix Version Right in preparation for a release. Regards, Kelvin.
Re: Federating between Java and C++, was: Running Java SCA Calculators sample?
On 2/28/07, Jim Marino [EMAIL PROTECTED] wrote: do it (with all your info) it hangs together. It's just that first time when you've not seen it before it's a little confusing :-) Regards Simon I'm wondering if it would be a good time to start discussing federation between the Java and C++ runtimes. On the Java side we have been using an implementation based on JXTA which also has a C++ implementation. Would people be interested in starting to see how some of the pieces might fit together? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Jim Yes we should get back to that at some point. I'm taking some vacation at the moment so won't be that active until next week.When we discussed this last time I was going to concentrate on the C++ side. In hindsight though it's probably better to get a grounding generally in Java SCA (and it's interesting :-) hence I'm taking some time out to get up to speed. Regards Simon
Re: Cleaning up and reorganizing samples
+1 On 3/1/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I prefer to have the following convention: calculator-ws helloworld-ws echo-binding Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, February 28, 2007 10:49 PM Subject: Cleaning up and reorganizing samples I took a look at the samples in the integration branch and would like to do some cleanup and a little reorganization. - Move the Web Service samples still under samples to sca/extensions/axis2/samples. - Rename samples/bigbank (this is a scaled down version of bigbank) to simplebigbank. - Move sampleapps/bigbank to samples and delete sampleapps. - Cleanup the names of the samples, we have calculator-ws, helloworldws, loanappconversationWS, echo.binding, maybe we need to make up our minds and pick a single consistent naming convention :) I'd like to propose calculatorws, helloworldws, loanappconversationws, echobinding (no dash no dot, all lowercase), or use dashes in the names if people prefer that. Thoughts? -- 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: Cleaning up and reorganizing samples
+1 for Raymond's suggestion, it gets easier to read. On 3/1/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: +1 On 3/1/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I prefer to have the following convention: calculator-ws helloworld-ws echo-binding Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, February 28, 2007 10:49 PM Subject: Cleaning up and reorganizing samples I took a look at the samples in the integration branch and would like to do some cleanup and a little reorganization. - Move the Web Service samples still under samples to sca/extensions/axis2/samples. - Rename samples/bigbank (this is a scaled down version of bigbank) to simplebigbank. - Move sampleapps/bigbank to samples and delete sampleapps. - Cleanup the names of the samples, we have calculator-ws, helloworldws, loanappconversationWS, echo.binding, maybe we need to make up our minds and pick a single consistent naming convention :) I'd like to propose calculatorws, helloworldws, loanappconversationws, echobinding (no dash no dot, all lowercase), or use dashes in the names if people prefer that. Thoughts? -- 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] -- Luciano Resende http://people.apache.org/~lresende
Re: Cleaning up and reorganizing samples
Luciano Resende wrote: +1 for Raymond's suggestion, it gets easier to read. On 3/1/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: +1 On 3/1/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I prefer to have the following convention: calculator-ws helloworld-ws echo-binding Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, February 28, 2007 10:49 PM Subject: Cleaning up and reorganizing samples I took a look at the samples in the integration branch and would like to do some cleanup and a little reorganization. - Move the Web Service samples still under samples to sca/extensions/axis2/samples. - Rename samples/bigbank (this is a scaled down version of bigbank) to simplebigbank. - Move sampleapps/bigbank to samples and delete sampleapps. - Cleanup the names of the samples, we have calculator-ws, helloworldws, loanappconversationWS, echo.binding, maybe we need to make up our minds and pick a single consistent naming convention :) I'd like to propose calculatorws, helloworldws, loanappconversationws, echobinding (no dash no dot, all lowercase), or use dashes in the names if people prefer that. Thoughts? -- 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] Cool, +1 for Raymond's suggestion to use dashes, you're right it's much easier to read. I can take care of the core and axis2 samples. It would be great if others could help with the jms, jsonrpc and script samples as well. We are also using a mix of various different naming conventions in itests. What about applying Raymond's naming convention there as well? plus remove the Test at the end of some of these names? something like that: callBackBasicTest - callback-basic -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS C++] Necessary classes for a initial simple read application
This might also be interesting read for you guys... http://wiki.apache.org/ws/Tuscany/TuscanyCpp/DesignNotes On 2/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: Sorry guys, the sdo article url I gave is wrong, the correctly url is: http://www-128.ibm.com/developerworks/webservices/library/ws-sdo-api/ Adriano Crestani On 2/27/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks for the clarification. Makes sense now. On 2/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: I gave this name just cause it doesn't have all the classes and fuctionality of a real DAS library. But it will later become a complete DAS library, I expect ; ). You may call also DAS initial phase, I don't know. Adriano Crestani On 2/27/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Adriano What's the difference between DAS C++ and DAS C++ lite ? Why we would need two ? I thought one DAS was already too much work :) -- Luciano Resende http://people.apache.org/~lresende On 2/26/07, Adriano Crestani [EMAIL PROTECTED] wrote: 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/~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
Re: Native M3 release status
Andrew Borley wrote: On 3/1/07, Pete Robbins [EMAIL PROTECTED] wrote: I'm just about at a point where I can produce a release candidate which includes everything except the PHP extension. I'm wondering if it would be best to publish this then release the PHP extension as a separate entity. We could go the whole hog and release a core package and then separate packages for cpp, Ruby, Python, WS binding etc.. Ultimately I think this is the way to go So If I just want to develop in Ruby and use REST I can download core, Ruby and Rest extensions and not worry about the others, and more impoortantly, their dependencies. Any thoughts? +1 from me. I've had some experience of building the PHP extension and it's quite a process - you need to build PHP with the right flags, then download and build a particular branch of the PECL SCA_SDO package and then you can build the Tuscany PHP extension! (see [1]) It may be worth waiting until the AVOCET branch of the SCA_SDO package becomes the main downloadable package from the PECL site - I believe this is the plan for the next SCA_SDO release. This (I think) will remove (or at least vastly simplify) the first 2 steps in the above process. Cheers Andy [1] http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/php/README - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me. If I understand correctly then the Tuscany PHP extension will work with an actual release of the PECL SCA_SDO package. Correct? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ScdlContributionProcessor and Axis2 binding getting the composite name?
Could you please take a look and see if the fix I committed solves your issue ? On 3/1/07, ant elder [EMAIL PROTECTED] wrote: Yes, on closer reading that is right. Thanks! ...ant On 3/1/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Isn't it based on the parent componentId and not the composite name? -- Jeremy On Mar 1, 2007, at 6:14 AM, ant elder wrote: I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/ WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
Re: Native M3 release status
On 3/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: On 3/1/07, Pete Robbins [EMAIL PROTECTED] wrote: I'm just about at a point where I can produce a release candidate which includes everything except the PHP extension. I'm wondering if it would be best to publish this then release the PHP extension as a separate entity. We could go the whole hog and release a core package and then separate packages for cpp, Ruby, Python, WS binding etc.. Ultimately I think this is the way to go So If I just want to develop in Ruby and use REST I can download core, Ruby and Rest extensions and not worry about the others, and more impoortantly, their dependencies. Any thoughts? +1 from me. I've had some experience of building the PHP extension and it's quite a process - you need to build PHP with the right flags, then download and build a particular branch of the PECL SCA_SDO package and then you can build the Tuscany PHP extension! (see [1]) It may be worth waiting until the AVOCET branch of the SCA_SDO package becomes the main downloadable package from the PECL site - I believe this is the plan for the next SCA_SDO release. This (I think) will remove (or at least vastly simplify) the first 2 steps in the above process. Cheers Andy [1] http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/php/README - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me. If I understand correctly then the Tuscany PHP extension will work with an actual release of the PECL SCA_SDO package. Correct? Not with the current release of the PECL SCA_SDO package (1.1.2), but it will with the next release, which will be based on the AVOCET branch that the Tuscany PHP extension depends on. Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving modules to contrib for this release
There are a few modules in the runtime that I don't think should be included in this release: * jxta due to the Bouncy Castle issue * osgi (not ready) * equinox (not ready) For now I am going to move them to a contrib directory under sca as this makes it easier to package runtime as a source distribution. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1120) Static code generator template bugs
[
https://issues.apache.org/jira/browse/TUSCANY-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David T. Adcox updated TUSCANY-1120:
Attachment: 1120a.patch
The 1120a.patch provides the code needed to resolve all list constructor
issues. A new method has been added to the SDOGenUtil class to handle
processing of the genFeature during code gen time. This new method determines
which list type should be used for this feature. The javajet template then
uses the ordinal returned to identify the list type to create. The javajet has
been updated as well to properly set up the call using this mechanism.
Static code generator template bugs
---
Key: TUSCANY-1120
URL: https://issues.apache.org/jira/browse/TUSCANY-1120
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-M3
Reporter: Frank Budinsky
Fix For: Java-SDO-M3
Attachments: 1120a.patch
There are some serious problems with the new SDO (noEMF) codegen templates:
Problem 1
SDOClass.javajet uses containment-type lists (EObjectContainmentEList) for
all List-type properties. List property generation seems to be completely
broken in general. The template isn't handling bi-directional (e.g.,
EObjectWithInverseEList), proxy resolving, unsettable, etc. Every flavor of
list other than basic containment is broken with the new template.
This part of the template should not always be calling createPropertyList
with the containment list kind:
%=genFeature.getSafeName()% = createPropertyList(ListKind.CONTAINMENT,
%=genFeature.getListItemType()%.class, ...
It needs to pass a correct kind indicator, which createPropertyList() would
use to create the correct kind of EMF List. It used to just new up the right
kind of EList, but createPropertyList() was added as the indirect way to do
it without having an EMF dependency in the generated code. The new noEMF
template should have all the same logic as before, but just using
createPropertyList(some kind, ...) instead of new Esome
kindList(...). Note that the implementation of createPropertyList() in
class FactoryBase, also needs to be completed.
Note: that the built-in model, sdoModel.xsd, need to be regenerated when this
is fixed - see TUSCANY-1095.
Problem 2
SDOFactoryClass.javajet is not adding the correct xsdMapping annotations for
open or mixed properties (and maybe others).
The following changes were made manually to fix the generated
SequencesFactoryImpl.java test model. They illustrate the changes that are
needed in the generator.
---
java/sdo/tools/src/test/java/com/example/sequences/impl/SequencesFactoryImpl.java
(revision 505122)
+++
java/sdo/tools/src/test/java/com/example/sequences/impl/SequencesFactoryImpl.java
(working copy)
@@ -346,13 +346,13 @@
new String[]
{
name, MixedQuote,
-kind, elementOnly
+kind, mixed
});
addXSDMapping
((Property)mixedQuoteType.getProperties().get(MixedQuoteImpl.MIXED),
new String[]
{
-kind, element,
+kind, elementWildcard,
name, mixed
});
@@ -434,13 +434,13 @@
new String[]
{
name, MixedRepeatingChoice,
-kind, elementOnly
+kind, mixed
});
addXSDMapping
((Property)mixedRepeatingChoiceType.getProperties().get(MixedRepeatingChoiceImpl.MIXED),
new String[]
{
-kind, element,
+kind, elementWildcard,
name, mixed
});
@@ -448,8 +448,8 @@
((Property)mixedRepeatingChoiceType.getProperties().get(MixedRepeatingChoiceImpl.GROUP),
new String[]
{
-kind, element,
-name, group
+kind, group,
+name, group:1
});
addXSDMapping
@@ -457,7 +457,8 @@
new String[]
{
kind, element,
-name, a
+name, a,
+group, #group:1
});
addXSDMapping
@@ -465,7 +466,8 @@
new String[]
{
kind, element,
-name, b
+name, b,
+group, #group:1
});
// TODO - kdk - is the order right? should kind, elementOnly be first
@@ -480,8 +482,8 @@
((Property)repeatingChoiceType.getProperties().get(RepeatingChoiceImpl.GROUP),
new String[]
{
-kind, element,
-name, group
+kind, group,
+name, group:0
});
addXSDMapping
@@ -489,7 +491,8 @@
new String[]
{
kind, element,
-name, a
+name, a,
+group, #group:0
});
addXSDMapping
@@ -497,7 +500,8 @@
new String[]
{
kind, element,
-name, b
+name, b,
+group, #group:0
});
// TODO - kdk - is the order right? should kind, elementOnly be first
@@ -512,8 +516,8 @@
[jira] Commented: (TUSCANY-1120) Static code generator template bugs
[
https://issues.apache.org/jira/browse/TUSCANY-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477111
]
David T. Adcox commented on TUSCANY-1120:
-
With regards problem #2. I've run codegen using no command line options
against sequences.xsd and found that it produces the desired results, without
any code modifications. Could more information be provided on how this problem
can be reproduced?
Static code generator template bugs
---
Key: TUSCANY-1120
URL: https://issues.apache.org/jira/browse/TUSCANY-1120
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-M3
Reporter: Frank Budinsky
Fix For: Java-SDO-M3
Attachments: 1120a.patch
There are some serious problems with the new SDO (noEMF) codegen templates:
Problem 1
SDOClass.javajet uses containment-type lists (EObjectContainmentEList) for
all List-type properties. List property generation seems to be completely
broken in general. The template isn't handling bi-directional (e.g.,
EObjectWithInverseEList), proxy resolving, unsettable, etc. Every flavor of
list other than basic containment is broken with the new template.
This part of the template should not always be calling createPropertyList
with the containment list kind:
%=genFeature.getSafeName()% = createPropertyList(ListKind.CONTAINMENT,
%=genFeature.getListItemType()%.class, ...
It needs to pass a correct kind indicator, which createPropertyList() would
use to create the correct kind of EMF List. It used to just new up the right
kind of EList, but createPropertyList() was added as the indirect way to do
it without having an EMF dependency in the generated code. The new noEMF
template should have all the same logic as before, but just using
createPropertyList(some kind, ...) instead of new Esome
kindList(...). Note that the implementation of createPropertyList() in
class FactoryBase, also needs to be completed.
Note: that the built-in model, sdoModel.xsd, need to be regenerated when this
is fixed - see TUSCANY-1095.
Problem 2
SDOFactoryClass.javajet is not adding the correct xsdMapping annotations for
open or mixed properties (and maybe others).
The following changes were made manually to fix the generated
SequencesFactoryImpl.java test model. They illustrate the changes that are
needed in the generator.
---
java/sdo/tools/src/test/java/com/example/sequences/impl/SequencesFactoryImpl.java
(revision 505122)
+++
java/sdo/tools/src/test/java/com/example/sequences/impl/SequencesFactoryImpl.java
(working copy)
@@ -346,13 +346,13 @@
new String[]
{
name, MixedQuote,
-kind, elementOnly
+kind, mixed
});
addXSDMapping
((Property)mixedQuoteType.getProperties().get(MixedQuoteImpl.MIXED),
new String[]
{
-kind, element,
+kind, elementWildcard,
name, mixed
});
@@ -434,13 +434,13 @@
new String[]
{
name, MixedRepeatingChoice,
-kind, elementOnly
+kind, mixed
});
addXSDMapping
((Property)mixedRepeatingChoiceType.getProperties().get(MixedRepeatingChoiceImpl.MIXED),
new String[]
{
-kind, element,
+kind, elementWildcard,
name, mixed
});
@@ -448,8 +448,8 @@
((Property)mixedRepeatingChoiceType.getProperties().get(MixedRepeatingChoiceImpl.GROUP),
new String[]
{
-kind, element,
-name, group
+kind, group,
+name, group:1
});
addXSDMapping
@@ -457,7 +457,8 @@
new String[]
{
kind, element,
-name, a
+name, a,
+group, #group:1
});
addXSDMapping
@@ -465,7 +466,8 @@
new String[]
{
kind, element,
-name, b
+name, b,
+group, #group:1
});
// TODO - kdk - is the order right? should kind, elementOnly be first
@@ -480,8 +482,8 @@
((Property)repeatingChoiceType.getProperties().get(RepeatingChoiceImpl.GROUP),
new String[]
{
-kind, element,
-name, group
+kind, group,
+name, group:0
});
addXSDMapping
@@ -489,7 +491,8 @@
new String[]
{
kind, element,
-name, a
+name, a,
+group, #group:0
});
addXSDMapping
@@ -497,7 +500,8 @@
new String[]
{
kind, element,
-name, b
+name, b,
+group, #group:0
});
// TODO - kdk - is the order right? should kind, elementOnly be first
@@ -512,8 +516,8 @@
((Property)twoRCsType.getProperties().get(TwoRCsImpl.GROUP),
new String[]
{
-kind, element,
-name, group
+kind, group,
+name, group:0
});
addXSDMapping
@@ -521,7 +525,8 @@
new
Re: Cleaning up and reorganizing samples
Comments inline. Venkata Krishnan wrote: Hi, Its really good if we can have sampleapps out - to have another bigbank in it is quite confusing, for me. Working on it :) With respect to the naming conventions, yes, it would be good to have them all uniform, and I prefer something as loanAppConversation_ws as against loanappconversationws which is quite painful to make out without peering thro - this is just my opinion. Thanks. Ok, it looks like there is consensus against names like loanappconversationws, but most people seem to prefer - instead of _ as a separator. Loanappconversationws is really long anyway so in the first pass I'm going to try to use simpler/shorter names. I suggest to take a look bagain after I finish a first renaming pass, and if some of the names are still difficult to read, I'm open to do another pass using mixed case if others prefer that too. - Venkat -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving modules to contrib for this release
+1 From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Moving modules to contrib for this release Date: Thu, 1 Mar 2007 13:47:10 -0800 There are a few modules in the runtime that I don't think should be included in this release: * jxta due to the Bouncy Castle issue * osgi (not ready) * equinox (not ready) For now I am going to move them to a contrib directory under sca as this makes it easier to package runtime as a source distribution. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Solve the Conspiracy and win fantastic prizes! http://www.theconspiracygame.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1065) Coexistence problem between EMF and Tuscany SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1065. - Resolution: Fixed Fixed in revision 513560. Coexistence problem between EMF and Tuscany SDO --- Key: TUSCANY-1065 URL: https://issues.apache.org/jira/browse/TUSCANY-1065 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx When EMF and Tuscany SDO are running in the same JVM, Tuscany SDO is completely not working when EMF was run and initialized before SDO. -- 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]
IP CLEARANCE needed, was: svn commit: r513560 [1/2] - in /incubator/tuscany/java/sdo/impl/src: main/java/org/apache/tuscany/sdo/helper/ main/java/org/apache/tuscany/sdo/impl/ main/java/org/apache/tusc
We need to follow the IP Clearance process for all code developed outside Apache ... -- Jeremy Begin forwarded message: From: [EMAIL PROTECTED] Date: March 1, 2007 4:14:07 PM PST To: tuscany-commits@ws.apache.org Subject: svn commit: r513560 [1/2] - in /incubator/tuscany/java/sdo/ impl/src: main/java/org/apache/tuscany/sdo/helper/ main/java/org/ apache/tuscany/sdo/impl/ main/java/org/apache/tuscany/sdo/util/ test/java/com/example/simple/ ... Added: incubator/tuscany/java/sdo/impl/src/main/java/org/apache/ tuscany/sdo/helper/BaseSDOExtendedMetaDataImpl.java URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/impl/ src/main/java/org/apache/tuscany/sdo/helper/ BaseSDOExtendedMetaDataImpl.java?view=autorev=513560 == --- incubator/tuscany/java/sdo/impl/src/main/java/org/apache/ tuscany/sdo/helper/BaseSDOExtendedMetaDataImpl.java (added) +++ incubator/tuscany/java/sdo/impl/src/main/java/org/apache/ tuscany/sdo/helper/BaseSDOExtendedMetaDataImpl.java Thu Mar 1 16:14:06 2007 @@ -0,0 +1,163 @@ +/** + * copyright + * + * Copyright (c) 2003-2004 IBM Corporation and others. + * All rights reserved. This program and the accompanying materials + * are made available under the terms of the Eclipse Public License v1.0 + * which accompanies this distribution, and is available at + * http://www.eclipse.org/legal/epl-v10.html + * + * Contributors: + * IBM - Initial API and implementation + * + * /copyright + * + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks Exp $ + */ + and more ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1065) Coexistence problem between EMF and Tuscany SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1065: Attachment: DeserializationNoSchemaTestCase.java Hi Frank, I just tested your fixes and found they break AnyTypeDataObject. Below is the exception by running the attached test case. Also, the execution time takes much longer. It seems there is some endless loop somewhere. java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EClassImpl incompatible with commonj.sdo.Type at org.apache.tuscany.sdo.impl.DataObjectImpl.getType(DataObjectImpl.java:193) at org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:743) at org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:216) at org.apache.tuscany.sdo.impl.DataObjectImpl.getList(DataObjectImpl.java:376) at org.apache.tuscany.sdo.test.DeserializationNoSchemaTestCase.testLoadQuoteXMLDoc(DeserializationNoSchemaTestCase.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Coexistence problem between EMF and Tuscany SDO --- Key: TUSCANY-1065 URL: https://issues.apache.org/jira/browse/TUSCANY-1065 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Fuhwei Lwo Fix For: Java-SDO-Mx Attachments: DeserializationNoSchemaTestCase.java When EMF and Tuscany SDO are running in the same JVM, Tuscany SDO is completely not working when EMF was run and initialized before SDO. -- 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: Native M3 release status
On 01/03/07, Andrew Borley [EMAIL PROTECTED] wrote: On 3/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: On 3/1/07, Pete Robbins [EMAIL PROTECTED] wrote: I'm just about at a point where I can produce a release candidate which includes everything except the PHP extension. I'm wondering if it would be best to publish this then release the PHP extension as a separate entity. We could go the whole hog and release a core package and then separate packages for cpp, Ruby, Python, WS binding etc.. Ultimately I think this is the way to go So If I just want to develop in Ruby and use REST I can download core, Ruby and Rest extensions and not worry about the others, and more impoortantly, their dependencies. Any thoughts? +1 from me. I've had some experience of building the PHP extension and it's quite a process - you need to build PHP with the right flags, then download and build a particular branch of the PECL SCA_SDO package and then you can build the Tuscany PHP extension! (see [1]) It may be worth waiting until the AVOCET branch of the SCA_SDO package becomes the main downloadable package from the PECL site - I believe this is the plan for the next SCA_SDO release. This (I think) will remove (or at least vastly simplify) the first 2 steps in the above process. Cheers Andy [1] http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/php/README - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me. If I understand correctly then the Tuscany PHP extension will work with an actual release of the PECL SCA_SDO package. Correct? Not with the current release of the PECL SCA_SDO package (1.1.2), but it will with the next release, which will be based on the AVOCET branch that the Tuscany PHP extension depends on. Cheers Andy I can now build the PHP extension and a distro of it's source/binaries separate from the rest of the release (at leat on Linux for now). I have some other questions on how we should package the release. 1) Should we produce a source and binary download for core and each extension? This would produce many download files but would improve the modularity and flexibility of future releases. e.g. if the Ruby extension gets a major update there is no need to package, release and test the other extensions. 2) If we do 1) where should the samples go? I think the samples should belong to the extension that they are demonstrating. This means the language samples xxxCalculator would be packaged with their extension. THe REST samples would be in the REST extension (though they would pre-req a language binding e.g. Python). etc.. An alternative would be to package the samples separately. 3) Does anyone ever download the Linux binary release? In my experience the download source/build/install model is used for the vast majority of Linux projects. We only produce a binary for a single Linux anyway so unless you are using RHEL3 you need to go via the source. It may make sense to have a Mac binary download but again this would be for Mac OS X Intel so of no use o the PPC Macs. I would like to implement 1) and have a 3 downloads per extension: Linux/Mac source, Windows source, Windows binary. Samples would be included with the relevant extensions. The extensions would be: tuscany_sca - the core tuscany_sca_cpp - C++ language binding tuscany_sca_ruby - Ruby language binding tuscany_sca_python - Python language binding tuscany_sca_ws - Axis2c webservices binding tuscany_sca_binding - sca binding (based on ws binding) tuscany_sca_rest - rest binding 3 download artifacts for each. Cheers, -- Pete
