[jira] Assigned: (TUSCANY-1054) Enhancement about ComponentType sidefile for JavaScript conatiner
[ https://issues.apache.org/jira/browse/TUSCANY-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1054: -- Assignee: ant elder Enhancement about ComponentType sidefile for JavaScript conatiner -- Key: TUSCANY-1054 URL: https://issues.apache.org/jira/browse/TUSCANY-1054 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-Mx Environment: IDE:Eclipse3.2.1+SVN plugin OS:win2k JDK:JDK1.5_09 Reporter: Zhenghui Lee Assigned To: ant elder Priority: Minor Fix For: Java-Mx Attachments: javascript.patch.jar ant elder did make a change to the way the ComponentType sidefile, We should sync it with JavaScript container.. I am attaching the patch here, anyone have time, pls help me to review it. thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java/C++
On 15/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: What is the class equivalent to DataObjectBase.java in SDO C++? Adriano Crestani I'll talk to someone who is familiar with the Java implementation and get back to you tomorrow. Regards, Geoff.
[jira] Closed: (TUSCANY-1054) Enhancement about ComponentType sidefile for JavaScript conatiner
[ https://issues.apache.org/jira/browse/TUSCANY-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1054. -- Resolution: Fixed Applied. Thanks for the fix Lee Zhenghui! Enhancement about ComponentType sidefile for JavaScript conatiner -- Key: TUSCANY-1054 URL: https://issues.apache.org/jira/browse/TUSCANY-1054 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-Mx Environment: IDE:Eclipse3.2.1+SVN plugin OS:win2k JDK:JDK1.5_09 Reporter: Zhenghui Lee Assigned To: ant elder Priority: Minor Fix For: Java-Mx Attachments: javascript.patch.jar ant elder did make a change to the way the ComponentType sidefile, We should sync it with JavaScript container.. I am attaching the patch here, anyone have time, pls help me to review it. thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1029) Update Axis2 to 1.1.1 release and its associated dependencies
[ https://issues.apache.org/jira/browse/TUSCANY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1029. -- Resolution: Fixed Done. (pom issues aside which can be another JIRA if required) Update Axis2 to 1.1.1 release and its associated dependencies - Key: TUSCANY-1029 URL: https://issues.apache.org/jira/browse/TUSCANY-1029 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Affects Versions: Java-M3 Reporter: ant elder Fix For: Java-M3 Axis2 1.1.1 is coming out soon so we should move up to it and its associated dependency release updates like axiom and wsdl4j. This will fix things like the axiom snaphot jar problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-871) Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed.
[ https://issues.apache.org/jira/browse/TUSCANY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-871: -- Fix Version/s: Java-M3 Affects Version/s: Java-M3 Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed. -- Key: TUSCANY-871 URL: https://issues.apache.org/jira/browse/TUSCANY-871 Project: Tuscany Issue Type: Bug Affects Versions: Java-M3 Reporter: Rick Rineholt Assigned To: Raymond Feng Priority: Critical Fix For: Java-M3 The current model tries to isolate each extension and the application to their own classloader. This works ok until there is a need to share objects between them. At this point these object's classs are each loaded by seperate classloaders. Classes loaded this way don't work well. For example, a class creating an instance by one classloader in an extension and then passed to an application that has the same class loaded by another class loader will see a classcast exception when an attempt is made to set a reference to the passed in object. Currently an example of this happens with databinding framework when using SDOs. The application creates SDOs loaded by its classloader. When the SDO object is sent on the wire the databinding framework intercepts to attempt to convert SDO to axiom for a webservice interface. But SDO classes in the SDO databinding framework are loaded via another classloader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-795) Aviod switching of TCCL
[ https://issues.apache.org/jira/browse/TUSCANY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-795: -- Fix Version/s: Java-M3 Affects Version/s: Java-M3 Aviod switching of TCCL --- Key: TUSCANY-795 URL: https://issues.apache.org/jira/browse/TUSCANY-795 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M3 Reporter: Rick Rineholt Fix For: Java-M3 Both org.apache.tuscany.binding.axis2.Axis2BindingBuilder.initAxis and org.apache.tuscany.binding.axis2.Axis2Service.invokeTarget need to avoid swithing ContextClassLoader -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-271) Sort out what Tuscany does/requires for the axis2.xml
[ https://issues.apache.org/jira/browse/TUSCANY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-271: -- Fix Version/s: (was: Java-M2) Java-M3 Sort out what Tuscany does/requires for the axis2.xml - Key: TUSCANY-271 URL: https://issues.apache.org/jira/browse/TUSCANY-271 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M3 How the axis2.xml config worked changed a bit since 0.95 so I've commentted out that bit of code and it now just uses the default config provided wih Axis2. Should look at this and see if we need our own defaults and also if we need a way to pick up app specific config with an axis2.xml bundled with the web app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-526) warnings in devstudio7
[ https://issues.apache.org/jira/browse/TUSCANY-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Borley closed TUSCANY-526. - Resolution: Won't Fix We've now moved to VSExpress (devstudio8) and this jira is a tad unspecific so I'm closing it. warnings in devstudio7 -- Key: TUSCANY-526 URL: https://issues.apache.org/jira/browse/TUSCANY-526 Project: Tuscany Issue Type: Bug Components: C++ Build Affects Versions: Cpp-current Environment: windows Reporter: Ed Slattery Priority: Minor Fix For: Cpp-current Not really a build problem, but in both sca and sdo. These warnings are not important, but the build would look nicer without them, and it would be easier to see if real problems happen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SOA Scenarios
Hi, There have been a number of postings about scenarios. For example: - In July http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html about JSF using Tuscany - In Nov http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas part of the what next for C++ - More recently http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html Would it be useful to document and maintain a set of scenarios that Tuscany does/will support? These could be used to validate and help guide what get developed, rather than relying what next ? postings (more permentant record). It could also be used to help identify complexity and completeness. Lastley it might also make it clearer to differenticate Tuscany from similar projects. Perhaps a way to kick off would be to start gathering some user stories (rather than more abstract scenarios) WDYT ? Cheers, Dan
Re: [SDO CTS] addition of paramatized tests, application server harness
Dan, Kelvin have you had a chance to look at some of the changes to the organization and the use of use of junit 4.1 features. Any more thoughts on vendor specific initialization and staitc SDO testing ? If you like the general format of hte paramatized tests then I will spend some time needed to clean it up and create a 'patch' for what is currently in the java/cts branch. If there are suggestions, or especially reorganization issues then lets discuss them. cheers, Robbie On 1/11/07, Robbie Minshall [EMAIL PROTECTED] wrote: I have opened *TUSCANY-1048https://issues.apache.org/jira/browse/TUSCANY-1048 * to track this topic. The initial drop of the cts code had some contributions from Brian Murray and myself. I have made some significant modifications to these which I hope will better fit into the framework. The work is not complete but is complete enough to get some feedback on what features etc would be desirable in the CTS. - Paramatized test suite. Tests API calls and scenarios using Junit 4.1paramatized test runner to use DataObjects created and populated using different mechanisms - Application Server Test harness and application. Application UI using DOJO to categorize and present errors within a jsp for tests that have been executed within the application server environement rather than within a simple standalone java env. - Use TestHelper which in turn used HelperProvider to get instance of commonj.sdo.helper.* classes. I will attach source to the JIRA and continue this discussion there where appropiate. Robbie On 1/11/07, Robbie Minshall [EMAIL PROTECTED] wrote: I would lean towards providing an exucutable jar file and a structure that allows for vendors to have their own branch/pom.xml for vendor specific implementations ( static code, TestHelperImpl etc ) and a dependancy on the cts ( java/cts/sdo21 java/cts/vendorImpl/tuscany or something). However, I am not sure off the top of my head if that would work well with the surefire plugin for maven. I personally prefer and use ant so will ultmately just be pulling in the cts jar into my own build env. Robbie On 1/9/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I would like to get people's thoughts on how we want to launch the SDO test suite. As you may have seen, an initial set of tests have been committed via jira 987 http://issues.apache.org/jira/browse/TUSCANY-987. Since the tests are the product of the CTS suite, they are in the /src/main/ folder. As I'm sure you know this means that they will be built into a jar when the default mvn build is run. Currently the pom does not actually attempt to run the CTS against any implementation. Personally I think this is the right default behaviour, if it was to run the CTS against Tuscany by default it would add a dependency to tuscany and download it - which kind of goes against the idea of being implementation agnostic. However, people obviously do need to execute the CTS against an implementation. We can do this a number of ways: 1. Provide commented out sections in the pom.xml that when uncommented would run against a given implementation (with Tuscany as an example) 2. Provide seperate, alternative pom's that run against given implementations; for example mvn -f tuscany.xml to run against Tuscany 3. Provide an executable jar that contains a launcher such that a java -jar sdo2.1-cts-1.0-SNAPSHOT.jar would execute the test suites (and leave it to the user to put an implementation on their classpath) 4. Provide a set of shell script to launch the tests (for Windows and unix/linux) My personal preference is 2 (and is seems easier than 3 4) but not sure if this approach would be acceptable for other implementations. Anyone got an opinion of how they would like to launch/execute the tests ? Cheers, Dan -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Commented: (TUSCANY-1038) SDO databinding for Axis2
[ https://issues.apache.org/jira/browse/TUSCANY-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464803 ] Kelvin Goodson commented on TUSCANY-1038: - For ref: There have been some discussions on this on the dev list including those at ... http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12548.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12753.html SDO databinding for Axis2 - Key: TUSCANY-1038 URL: https://issues.apache.org/jira/browse/TUSCANY-1038 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: ant elder Fix For: Java-SDO-Mx Implement a native Axis2 databinding for SDO. Axis2 supports pluggable databindings and currently has support for things like xmlbeans, jibx, and Axis2s own ADB. It would help promote SDO if we implemented an Axis2 databinding for SDO. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-948) Consider DAS config connection info for J2SE environment
[ https://issues.apache.org/jira/browse/TUSCANY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-948: Attachment: rdb-das-jan15-jira-948-amita.txt rdb-das-jan15-jira-948-amita.jar sample-customer-j2se-das-jan15-jira-948-amita.zip Consider DAS config connection info for J2SE environment Key: TUSCANY-948 URL: https://issues.apache.org/jira/browse/TUSCANY-948 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: rdb-das-jan15-jira-948-amita.jar, rdb-das-jan15-jira-948-amita.txt, rdb-das-jan5-jira-948-amita.txt, rdb-das-jan5-jira-948-amita.zip, sample-customer-j2se-das-jan15-jira-948-amita.zip, sample-customer-j2se-das-jan5-jira-948-amita.zip Currently the DAS allow users to specfify a JDBC Connection for the DAS to utilize by either providing a JDBC Connection explicitly or provifing a JNDI name in the config file. We should reconsider allowing DriverManager info to be provided to allow similar, config-based set up, in a J2SE enviroinment. I know this was debated in the past but I cannot recall if this was deferred or rejected. The issues may have been around the need to include user/password info in the DriverManager info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-948) Consider DAS config connection info for J2SE environment
[ https://issues.apache.org/jira/browse/TUSCANY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464805 ] Amita Vadhavkar commented on TUSCANY-948: - Jan15--rdb-das-jan15-jira-948-amita.jar, sample-customer-j2se-das-jan15-jira-948-amita.zip, rdb-das-jan15-jira-948-amita.txt In this the change is making JNDI provider and Encryption Util pluggable through a factory. So, we can support any available JNDI provider as well as allow for custom Encryption /Decryption of database password. --in rdb-das-- Changed: org.apache.tuscany.das.rdb.impl.DASImpl config.xsd New classes added: org.apache.tuscany.das.rdb.util.JNDIContextProviderFactory org.apache.tuscany.das.rdb.util.JNDIContextProviderInterface org.apache.tuscany.das.rdb.util.SimpleSymmEncryption org.apache.tuscany.das.rdb.util.SunJNDIProvider org.apache.tuscany.das.rdb.util.SymmetricEncryptionUtilFactory org.apache.tuscany.das.rdb.util.SymmetricEncryptionUtilInterface --in sample-customer-j2se-das - to use the above changes Changed: Customers.xml CustomerClient.java Consider DAS config connection info for J2SE environment Key: TUSCANY-948 URL: https://issues.apache.org/jira/browse/TUSCANY-948 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Affects Versions: Java-Mx Reporter: Kevin Williams Fix For: Java-Mx Attachments: rdb-das-jan15-jira-948-amita.jar, rdb-das-jan15-jira-948-amita.txt, rdb-das-jan5-jira-948-amita.txt, rdb-das-jan5-jira-948-amita.zip, sample-customer-j2se-das-jan15-jira-948-amita.zip, sample-customer-j2se-das-jan5-jira-948-amita.zip Currently the DAS allow users to specfify a JDBC Connection for the DAS to utilize by either providing a JDBC Connection explicitly or provifing a JNDI name in the config file. We should reconsider allowing DriverManager info to be provided to allow similar, config-based set up, in a J2SE enviroinment. I know this was debated in the past but I cannot recall if this was deferred or rejected. The issues may have been around the need to include user/password info in the DriverManager info. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
As part of this are you considering only multiple Java runtimes or can this proposal embrace a C++/Python/Ruby component implementation deployed on the C++ runtime? Cheers, On 13/01/07, Jim Marino [EMAIL PROTECTED] wrote: On Jan 13, 2007, at 1:26 PM, Meeraj Kunnumpurath wrote: Jeremy, Based on the discussion we had earlier I have started putting the basic shell around the domain physical model and discovery service. 1. Both physical model discovery and service interfaces are hosted in SPI. 2. Under services I have started on couple of implementations for the discovery service. 3. I guess the physical model realisation would go into core. 3. In standalone assembly, I have created the home for the admin rutnime SCDL, that will host the client facing assembly service and also manage the domain wide singleton assembly model. Once we get this working we can look into moving this from a cerntalized model to a more federated peer-to-peer model. The admin runtime uses the discovery service to listen for federated runtimes, participating in the domain managed by the admin runtime, coming alive. The runtimes publish their presence using the discovery service when they come alive. The admin runtime will use the current topology of the domain to send artifacts that are deployed in the domain using the assembly service to participating runtimes. I am still unclear on how the admin runtime would make a decision on deploy component X in runtime X and component Y in runtime Y. Anyway, I will keep the discovery and the domain physical model service going. Cool. I've been looking at the discover service in some detail (both zeroconf and JXTA) and when I have some more time, I'll post some thoughts as well. Jim Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Distributed assemblies Date: Sat, 13 Jan 2007 12:26:12 -0800 Meeraj and I were chatting this morning about an approach for supporting an SCA Domain that is broader than a single runtime. So far we have been focusing on the wiring and component models within a single address space (runtime) allowing us to hook up user and system components according to the principles of SCA assembly. This has provided us a foundation for expanding functionality to the more interesting distributed case where we are managing an assembly that spans multiple runtimes. To do that, we identified a set of system services that would support this: 1) a global assembly model which represents the logical assembly of application components in the domain 2) a global physical model which represents the online physical structure of the domain (primarily which runtimes are participating) 3) a discovery service which would abstract the protocols used to discover/track the physical structure (a layering over protocols such as UPNP, Bonjour or JXTA) 4) a user-facing assembly service that allows them to manipulate the logical assembly 5) a run this (need a better name) service that allows the assembly service to control which logical components are actually running on a physical runtime (this may include bindings to support inter-runtime connections) The first use-case we want to support is one that allows a user to add a component to the assembly that is implemented by a composite that contains two components (X and Y) that are wired to each other but which need to be executed on two different physical runtimes (A and B). The assembly service will direct runtime A to run component X and runtime B to run component Y. It will also direct runtime A to bind the reference and runtime B to bind the service for the connecting wire so that X is able to invoke Y. This will take quite a bit of work so is probably best tackled in stages. The first priorities will be to get implementations of the user-facing assembly service and internal run this services running in a manner that supports distribution. We can do this locally by running two runtimes in a single server. At the same time we can be implementing a version of the discovery service that uses one of the standard protocols (which one is TBD) to build up the physical model. With this in place we can add the algorithms that determine how components get allocated to runtimes, starting with a basic form where the user provides the information and advancing to forms where it is configured by the global controller. The second phase will probably work in a master-slave mode where the controller runs on a single runtime (possibly with failover). A third phase will tackle the more complex problem of distributing the assembly model in a multi-master or pure-peer mode. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
Ultimately I think some of us would like to support federated runtimes. In the Java runtime, we will be using a pluggable mechanism for service discovery and some of the implementations have both Java and C++ variants. For example, Bonjour and JXTA. Jim On Jan 15, 2007, at 6:44 AM, Pete Robbins wrote: As part of this are you considering only multiple Java runtimes or can this proposal embrace a C++/Python/Ruby component implementation deployed on the C++ runtime? Cheers, On 13/01/07, Jim Marino [EMAIL PROTECTED] wrote: On Jan 13, 2007, at 1:26 PM, Meeraj Kunnumpurath wrote: Jeremy, Based on the discussion we had earlier I have started putting the basic shell around the domain physical model and discovery service. 1. Both physical model discovery and service interfaces are hosted in SPI. 2. Under services I have started on couple of implementations for the discovery service. 3. I guess the physical model realisation would go into core. 3. In standalone assembly, I have created the home for the admin rutnime SCDL, that will host the client facing assembly service and also manage the domain wide singleton assembly model. Once we get this working we can look into moving this from a cerntalized model to a more federated peer-to-peer model. The admin runtime uses the discovery service to listen for federated runtimes, participating in the domain managed by the admin runtime, coming alive. The runtimes publish their presence using the discovery service when they come alive. The admin runtime will use the current topology of the domain to send artifacts that are deployed in the domain using the assembly service to participating runtimes. I am still unclear on how the admin runtime would make a decision on deploy component X in runtime X and component Y in runtime Y. Anyway, I will keep the discovery and the domain physical model service going. Cool. I've been looking at the discover service in some detail (both zeroconf and JXTA) and when I have some more time, I'll post some thoughts as well. Jim Ta Meeraj From: Jeremy Boynes [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Distributed assemblies Date: Sat, 13 Jan 2007 12:26:12 -0800 Meeraj and I were chatting this morning about an approach for supporting an SCA Domain that is broader than a single runtime. So far we have been focusing on the wiring and component models within a single address space (runtime) allowing us to hook up user and system components according to the principles of SCA assembly. This has provided us a foundation for expanding functionality to the more interesting distributed case where we are managing an assembly that spans multiple runtimes. To do that, we identified a set of system services that would support this: 1) a global assembly model which represents the logical assembly of application components in the domain 2) a global physical model which represents the online physical structure of the domain (primarily which runtimes are participating) 3) a discovery service which would abstract the protocols used to discover/track the physical structure (a layering over protocols such as UPNP, Bonjour or JXTA) 4) a user-facing assembly service that allows them to manipulate the logical assembly 5) a run this (need a better name) service that allows the assembly service to control which logical components are actually running on a physical runtime (this may include bindings to support inter-runtime connections) The first use-case we want to support is one that allows a user to add a component to the assembly that is implemented by a composite that contains two components (X and Y) that are wired to each other but which need to be executed on two different physical runtimes (A and B). The assembly service will direct runtime A to run component X and runtime B to run component Y. It will also direct runtime A to bind the reference and runtime B to bind the service for the connecting wire so that X is able to invoke Y. This will take quite a bit of work so is probably best tackled in stages. The first priorities will be to get implementations of the user-facing assembly service and internal run this services running in a manner that supports distribution. We can do this locally by running two runtimes in a single server. At the same time we can be implementing a version of the discovery service that uses one of the standard protocols (which one is TBD) to build up the physical model. With this in place we can add the algorithms that determine how components get allocated to runtimes, starting with a basic form where the user provides the information and advancing to forms where it is configured by the global controller. The second phase will probably work in a master-slave mode where the controller runs on a single runtime (possibly with failover). A third
[jira] Updated: (TUSCANY-829) Investigate integration of RogueWave tests
[ https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Murphy updated TUSCANY-829: --- Attachment: Patch-jira-829 Investigate integration of RogueWave tests -- Key: TUSCANY-829 URL: https://issues.apache.org/jira/browse/TUSCANY-829 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: Patch-jira-829, sdo.zip, testdata.zip Investigation of bringing RogueWave tests into the SDO Compliance Test Suite environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java/C++
DataObjectBase.java is the base class for static (generated) SDOs. I don't believe there is C++ static SDO support, so there is no equivalent in SDO C++. Frank Adriano Crestani [EMAIL PROTECTED] wrote on 01/15/2007 12:49:23 AM: What is the class equivalent to DataObjectBase.java in SDO C++? Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-829) Investigate integration of RogueWave tests
[ https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464822 ] Dan Murphy commented on TUSCANY-829: Hi, Just attached a patch (https://issues.apache.org/jira/secure/attachment/12348960/Patch-jira-829) for the DataObjectListTests to fit into the current cts structure (should be applied to the cts root, not sdo2.1 directory). Do we want to try convert XMLDataObjectTest (given Bryan's comments about heavy use of RW specific apis) ? In the meantime, can someone try applying my patch... thanks Investigate integration of RogueWave tests -- Key: TUSCANY-829 URL: https://issues.apache.org/jira/browse/TUSCANY-829 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: Patch-jira-829, sdo.zip, testdata.zip Investigation of bringing RogueWave tests into the SDO Compliance Test Suite environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-882) Async samples fail in stanalone launcher
[ https://issues.apache.org/jira/browse/TUSCANY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Silva-Lepe reassigned TUSCANY-882: -- Assignee: Ignacio Silva-Lepe Async samples fail in stanalone launcher Key: TUSCANY-882 URL: https://issues.apache.org/jira/browse/TUSCANY-882 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: ant elder Assigned To: Ignacio Silva-Lepe Fix For: Java-M2 Simplecallback sample fails in stanalone launcher with the following exception: C:\SCA\SVN\TRUNK\samples\sca\simplecallbackjava -jar ..\..\..\..\..\StandaloneT\bin\launcher.jar target\sample-simplecallback-1.0-incubator-M2-SNAPSHOT.jar Main thread Thread[main,5,main] java.lang.IllegalStateException: Scope not running [6] at org.apache.tuscany.core.component.scope.AbstractScopeContainer.checkInit(AbstractScopeContainer.java:124) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.getInstanceWrapper(ModuleScopeContainer.java:118) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getInstance(AbstractScopeContainer.java:105) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:117) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:94) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:59) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:60) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(NonBlockingBridgingInterceptor.java:70) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr237Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Callback methods w/ non-void return types
Based on Dave's comments and the current behavior, I've opened http://issues.apache.org/jira/browse/TUSCANY-1052 so we don't lose this discussion. scabooz wrote: I don't understand why we'd force the client to handle responses asyncly if it doesn't want to. It is by choice as you said. In this use case, the client wants a sync response. I think the use case is going to be common, that's why it's in the spec. Dave -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist
[ https://issues.apache.org/jira/browse/TUSCANY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-936: - Assignee: ant elder HttpSessionScopeContainer requires a session to exist - Key: TUSCANY-936 URL: https://issues.apache.org/jira/browse/TUSCANY-936 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Greg Dritschler Assigned To: ant elder Priority: Minor Fix For: Java-M3 In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP session. (Look at the class LazyHTTPSessionId to see how it worked.) Now the HttpSessionScopeContainer requires a preexisting session. If a session does not exist, a NullPointerException occurs when it tries to look up the instance using a null key. InstanceWrapper ctx = wrappers.get(key); The problem can be circumvented by creating a session in the web app client. JSPs have sessions by default. Servlets can call getSession(true) to ensure a session exists before invoking an SCA component that requires session scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist
[ https://issues.apache.org/jira/browse/TUSCANY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-936: -- Fix Version/s: Java-Mx Affects Version/s: (was: Java-Mx) Java-M3 HttpSessionScopeContainer requires a session to exist - Key: TUSCANY-936 URL: https://issues.apache.org/jira/browse/TUSCANY-936 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Greg Dritschler Assigned To: ant elder Priority: Minor Fix For: Java-M3 In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP session. (Look at the class LazyHTTPSessionId to see how it worked.) Now the HttpSessionScopeContainer requires a preexisting session. If a session does not exist, a NullPointerException occurs when it tries to look up the instance using a null key. InstanceWrapper ctx = wrappers.get(key); The problem can be circumvented by creating a session in the web app client. JSPs have sessions by default. Servlets can call getSession(true) to ensure a session exists before invoking an SCA component that requires session scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist
[ https://issues.apache.org/jira/browse/TUSCANY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-936: -- Fix Version/s: (was: Java-Mx) Java-M3 Affects Version/s: (was: Java-M3) Java-M2 HttpSessionScopeContainer requires a session to exist - Key: TUSCANY-936 URL: https://issues.apache.org/jira/browse/TUSCANY-936 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Greg Dritschler Assigned To: ant elder Priority: Minor Fix For: Java-M3 In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP session. (Look at the class LazyHTTPSessionId to see how it worked.) Now the HttpSessionScopeContainer requires a preexisting session. If a session does not exist, a NullPointerException occurs when it tries to look up the instance using a null key. InstanceWrapper ctx = wrappers.get(key); The problem can be circumvented by creating a session in the web app client. JSPs have sessions by default. Servlets can call getSession(true) to ensure a session exists before invoking an SCA component that requires session scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standalone Smoketest failure
After a full update, mvn clean of sca and mvn in sca I see the following failure: Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyCon tent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.081 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.42 sec FAI LURE! testLauncherUsage( org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL auncher) Time elapsed: 0.27 sec FAILURE! junit.framework.ComparisonFailure: expected:usage: java [jvm-options] -jar laun cher.jar jar [args...] but was:java.lang.NoClassDefFoundError: org/osoa/sca/SCA Exception in thread main at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c ompareOutput(CommandTestCase.java:37) at org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher .testLauncherUsage(SmokeTestLauncher.java:40) testLauncherWithNoArgs( org.apache.tuscany.sca.runtime.standalone.smoketest.Smoke TestLauncher) Time elapsed: 0.13 sec FAILURE! junit.framework.ComparisonFailure: expected:No Args but was: at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c ompareOutput(CommandTestCase.java:37) at org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher .testLauncherWithNoArgs(SmokeTestLauncher.java:53) Does anybody else see it?
[jira] Commented: (TUSCANY-829) Investigate integration of RogueWave tests
[ https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464834 ] Dan Murphy commented on TUSCANY-829: I think XMLDataObjectTests will take a while longer since there is a also a fair use of datagraphs, which the current spec discourages and when I tried using getDataGraph() on DataObjects that I build on the fly, null was returned... so there are a lot of tests that will probably just NPE if we simple removed RW specific classes Investigate integration of RogueWave tests -- Key: TUSCANY-829 URL: https://issues.apache.org/jira/browse/TUSCANY-829 Project: Tuscany Issue Type: Test Components: Java SDO Community Test Suite Affects Versions: Java-Mx Reporter: Kelvin Goodson Attachments: Patch-jira-829, sdo.zip, testdata.zip Investigation of bringing RogueWave tests into the SDO Compliance Test Suite environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Smoketest failure
I also just did a fresh checkout with a an empty local repo and I'm getting a test failure for the echo binding: --- Test set: echo.BootstrapTestCase --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.688 sec FAILURE! testDemoBoot(echo.BootstrapTestCase) Time elapsed: 1.64 sec ERROR! java.lang.NullPointerException at echo.ClientImpl.call(ClientImpl.java:37) 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.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:93) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy20.call(Unknown Source) at echo.BootstrapTestCase.testDemoBoot(BootstrapTestCase.java:35) at echo.BootstrapTestCase.testDemoBoot(BootstrapTestCase.java:35) 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 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 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.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:816) Any ideas? Are they related? -Bert On 1/15/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: After a full update, mvn clean of sca and mvn in sca I see the following failure: Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyCon tent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.081 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.42 sec FAI LURE! testLauncherUsage( org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL auncher) Time elapsed: 0.27 sec FAILURE! junit.framework.ComparisonFailure: expected:usage: java [jvm-options] -jar laun cher.jar jar [args...] but was:java.lang.NoClassDefFoundError: org/osoa/sca/SCA Exception in thread main at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c ompareOutput(CommandTestCase.java:37) at org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher .testLauncherUsage(SmokeTestLauncher.java:40) testLauncherWithNoArgs( org.apache.tuscany.sca.runtime.standalone.smoketest.Smoke TestLauncher) Time elapsed: 0.13 sec FAILURE!
Re: SDO Java: ChangeSummary doubt
If a DataObject is contained in a DataGraph then DataObject.getDataGraph().getChangeSummary() and DataObject.getChangeSummary() will return the same value. It's not possible (allowed) to nest a DataObject with its own ChangeSummary inside a DataGraph or other DataObject with a ChangeSummary. Frank. Adriano Crestani [EMAIL PROTECTED] wrote on 01/14/2007 11:12:25 PM: Is the command DataObject.getDataGraph().getChangeSummary() equal to DataObject.getChangeSummary() or the second one returns only the ChangeSummary of the DataObject and the first one returns the ChangeSummary of the whole graph? Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1048: - Attachment: tuscanyHelper.zip SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Attachments: tuscany-1048-paramatizedTests1.zip, tuscanyHelper.zip An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOA Scenarios
I think that sounds really good Dan. I'd love to know more about what's driving our users or potential users. This could be seen as a nitpick, but I think also there's the potential for some confusion, since you talk about 'abstract scenarios'. I don't see scenarios as particularly abstract, since they are instances of the more abstract 'use case', i.e. a scenario is a single given path through the use case, documenting only one path wherever the use case gives choices. I guess what we would really like to capture are the use cases, but getting some scenarios together is probably not a bad way to begin. So I think your stories are really the scenarios, and your scenarios are the use cases. Cheers, Kelvin. On 15/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, There have been a number of postings about scenarios. For example: - In July http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html about JSF using Tuscany - In Nov http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas part of the what next for C++ - More recently http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html Would it be useful to document and maintain a set of scenarios that Tuscany does/will support? These could be used to validate and help guide what get developed, rather than relying what next ? postings (more permentant record). It could also be used to help identify complexity and completeness. Lastley it might also make it clearer to differenticate Tuscany from similar projects. Perhaps a way to kick off would be to start gathering some user stories (rather than more abstract scenarios) WDYT ? Cheers, Dan
Re: Standalone Smoketest failure
Did you try to rebuild the SCA spec module? It seems to be working for me now. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: Tuscany Dev List tuscany-dev@ws.apache.org Sent: Monday, January 15, 2007 7:38 AM Subject: Standalone Smoketest failure After a full update, mvn clean of sca and mvn in sca I see the following failure: Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyCon tent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.081 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.42 sec FAI LURE! testLauncherUsage( org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL auncher) Time elapsed: 0.27 sec FAILURE! junit.framework.ComparisonFailure: expected:usage: java [jvm-options] -jar laun cher.jar jar [args...] but was:java.lang.NoClassDefFoundError: org/osoa/sca/SCA Exception in thread main at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c ompareOutput(CommandTestCase.java:37) at org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher .testLauncherUsage(SmokeTestLauncher.java:40) testLauncherWithNoArgs( org.apache.tuscany.sca.runtime.standalone.smoketest.Smoke TestLauncher) Time elapsed: 0.13 sec FAILURE! junit.framework.ComparisonFailure: expected:No Args but was: at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.tuscany.sca.runtime.standalone.smoketest.CommandTestCase.c ompareOutput(CommandTestCase.java:37) at org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher .testLauncherWithNoArgs(SmokeTestLauncher.java:53) Does anybody else see it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1046) NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION)
[ https://issues.apache.org/jira/browse/TUSCANY-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464871 ] Lou Amodeo commented on TUSCANY-1046: - I do not think that I am exactly past this problem. It makes sense to me to annotate with @Scope(CONVERSATION') on the implemmentation class to designate a specific services instances should be managed as conversational by the container. I am unclear what is required on the client interface to indicate to the client runtime that a conversation needs to be started. Are we saying that for now @Scope(CONVERSATION) is required on the interface as well and that a new annotation will be defined to the spec in the future? Is it valid to have a conversational client interface but not the service impl and vice- versa? It also appears that there is no validation of the annotations by the runtime and when annotations are misplaced or not synchronized inappropriate exceptions may be thrown as in this instance. NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION) -- Key: TUSCANY-1046 URL: https://issues.apache.org/jira/browse/TUSCANY-1046 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Reporter: Lou Amodeo Assigned To: Ignacio Silva-Lepe Fix For: Java-Mx Attachments: test-CallBackSetCallbackConv.zip r494421 test-CallBackSetCallbackConv - This test attempts to use @Scope(CONVERSATION). Upon launch of test case using integration test environment the following NPE occurs. --- Test set: org.apache.tuscany.sca.test.CallBackSetCallbackConvITest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec FAILURE! testCallBackSetCallback(org.apache.tuscany.sca.test.CallBackSetCallbackConvITest) Time elapsed: 0.01 sec ERROR! java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:172) at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:760) at org.apache.tuscany.core.services.store.memory.MemoryStore.insertRecord(MemoryStore.java:110) at org.apache.tuscany.core.component.scope.ConversationalScopeContainer.getInstance(ConversationalScopeContainer.java:92) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:122) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:127) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:75) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy22.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvITest.testCallBackSetCallback(CallBackSetCallbackConvITest.java:12) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Smoketest failure
I'm seeing it as well. It's probably caused by some changes in the core. I did a bit debugging, and here's the stacktrace where the code goes wrong: (OutboundWireImpl.targetWire == null for the EchoReference's outbound wire). Jim, can you check? Thanks, Raymond Thread [main] (Suspended) OutboundWireImpl.getTargetService() line: 78 InboundWireImpl.getTargetService() line: 81 OutboundWireImpl.getTargetService() line: 82 WireObjectFactoryT.getInstance() line: 70 PojoObjectFactoryT.getInstance() line: 100 JavaAtomicComponent(PojoAtomicComponent).createInstance() line: 137 StatelessScopeContainer.getInstanceWrapper(AtomicComponent, boolean) line: 70 StatelessScopeContainer(AbstractScopeContainer).getInstance(AtomicComponent)line: 99 JavaAtomicComponent(PojoAtomicComponent).getTargetInstance() line: 129 JavaTargetInvoker.getInstance(short) line: 127 JavaTargetInvoker.invokeTarget(Object, short) line: 75 JavaTargetInvoker(TargetInvokerExtension).invoke(Message) line: 67 InvokerInterceptor.invoke(Message) line: 44 JDKInboundInvocationHandler(AbstractInboundInvocationHandler).invoke(InboundInvocationChain, TargetInvoker, Object[]) line: 45 JDKInboundInvocationHandler.invoke(Object, Method, Object[]) line: 122 $Proxy18.call(String) line: not available BootstrapTestCase.testDemoBoot() line: 35 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: notavailable [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 615 BootstrapTestCase(TestCase).runTest() line: 154 BootstrapTestCase(TestCase).run Bare() line: 127 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run(TestCase) line: 109 BootstrapTestCase(TestCase).run(TestResult) line: 118 TestSuite.runTest(Test, TestResult) line: 208 TestSuite.run(TestResult) line: 203 JUnit3TestReference.run(TestExecution) line: 128 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 460 RemoteTestRunner.runTests(TestExecution) line: 673 RemoteTestRunner.run() line: 386 RemoteTestRunner.main(String[]) line: 196- Original Message -From: Bert Lamb [EMAIL PROTECTED]To: tuscany-dev@ws.apache.orgSent: Monday, January 15, 2007 7:48 AMSubject: Re: Standalone Smoketest failureI also just did a fresh checkout with a an empty local repo and I'm getting a test failure for the echo binding: --- Test set: echo.BootstrapTestCase -- - Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.688 sec FAILURE! testDemoBoot(echo.BootstrapTestCase) Time elapsed: 1.64 sec ERROR! java.lang.NullPointerException at echo.ClientImpl.call(ClientImpl.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) atorg.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:93) atorg.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) atorg.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) atorg.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) a torg.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy20.call(Unknown Source) at echo.BootstrapTestCase.testDemoBoot(BootstrapTestCase.java:35) at echo.BootstrapTestCase.testDemoBoot(BootstrapTestCase.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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.Te stSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
Re: Callback methods w/ non-void return types
Jim, I agree that bi-directional interfaces with _mostly_ @oneway operations would be considered the _80% use case_. That's not to say that sync operations won't be used. The point was that the spec currently allows sync operations in the interface, so this is something that Tuscany will need to implement. I would oppose a change in the spec that disallowed sync operations in a bi-directional interface. Dis-allowing it seems arbitrary, as sync/async seems orthogonal to the concept of bi-directional interfaces, which could be characterized more as a peer-to-peer component relationship (as oppose the usual client-server relationship between components). Dave - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, January 12, 2007 6:51 PM Subject: Re: Callback methods w/ non-void return types On Jan 12, 2007, at 1:50 PM, scabooz wrote: I don't understand why we'd force the client to handle responses asyncly if it doesn't want to. It is by choice as you said. In this use case, the client wants a sync response. I think the use case is going to be common, that's why it's in the spec. Dave, Can you outline the use case you think is going to be common (I'm assuming it is a sync forward invoke with response and a callback)? My opinion is that complicating the programming model in this respect is not worth it as this is not an 80% case but I am open to being convinced. Also, this is one of the areas we need to clarify in the spec as the section on callbacks is under asynchronous programming. Also, as a comment on Ignacio's comment, in the spec group we did entertain the idea of adding support for futures but decided against in to limit complexity in the first version. Jim Dave - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, January 12, 2007 4:20 PM Subject: Re: Callback methods w/ non-void return types Yeah, to me though, the orthogonality in this case is by choice, not by necessity. I mean, the client would behave asynchronously anyway to handle the callbacks, so it could also handle the response that way. And, orthogonal dimensions imply combinations. So my question is, is the use-case at hand common enough to justify handling the combinations, both at the spec level and at the impl level. On 1/12/07, scabooz [EMAIL PROTECTED] wrote: Ignacio, It's true that non-void returns are mux with non-blocking, but that's not the point being made. The point is that non-blocking and bidirectional are orthogonal. Dave - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, January 12, 2007 1:09 PM Subject: Re: Callback methods w/ non-void return types I agree with you, the spec does not explcitly rule this out. Although I have not participated in spec discussions about this, it seems to me that, unless a special type is returned (something like java.lang.concurrent.Future), non- void return values and non-blocking are mutually exclusive. Adding j.l.c.Future as an option would have to be explicitly specified, so it seems reasonable to me to assume that in its absence void should be assumed for non-blocking. On 1/12/07, Scott Kurz [EMAIL PROTECTED] wrote: So Jim and Ignacio are both assuming that each of the forward half and the backward half return void. But I don't see where in any spec this is stated. Where does it say that in SCA a bidirectional interface can't have one or both halves returning non-void data? On 1/12/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: FWIW, I'll try to respond to both Scott and Matt. Say we have a bi- directional interface consisting of FI.cf and BI.cb, where FI is the forward half and BI is the backward half. We agree that both the call forward method cf and the callback method cb return void. If the call to FI.cf blocked, the question then would be until when and what for? Since the result to cf will be coming in the invocation to cb, there seems to be no purpose in blocking cf, and unblocking it would require some coordination, e.g. with the call to cb, by the system. As for the call to cb (by the service that implements cf) the local implementation is actually blocking, it does not seem to be necessary to spawn another thread for this. Does this address what you were trying to get at? Given the above, the connector assumes that a bi-directional interface is non-blocking an inserts a NonBlockingBridgingInterceptor, which in turn assumes that the return type of the forward call is void and thus returns a message with a null body, which is probably the cause of your NPE. On 1/12/07, Matthew Sykes [EMAIL PROTECTED] wrote: Jim, I'm interested in the answer to this as well. I think we all understand that non-blocking operations
[jira] Created: (TUSCANY-1055) DataFactory.create(abstract_type) should throw an IllegalArgumentException
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-Mx 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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-688. Resolution: Fixed The feature is in for M2. WAR Maven Plugin for Tuscany Key: TUSCANY-688 URL: https://issues.apache.org/jira/browse/TUSCANY-688 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Meeraj Kunnumpurath Assigned To: Jeremy Boynes Priority: Minor Fix For: Java-M2 Attachments: tuscany-war-patch-20060906.txt, tuscany-war-plugin-patch-20060906-2.txt, tuscany-war-plugin-patch-20060907.txt, tuscany-war-plugin-src.jar, tuscany-webapp-sample-patch-20060906.txt Hi, This is the first cut for the Maven plugin for the Tuscany war plugin. The plugin is attached to the packaged phase and works on the WAR file produced by the Maven WAR plugin. It accepts the boot and extension libraries as configuration parameteres and adds them to the original WAR at relavant locations. Outstanding stuff, liVerify the presence of the required context listeners in web XML and add them if not present./li liDefaults handling, don't know what the defaults are :-)/li Here is a usage pattern, code project modelVersion4.0.0/modelVersion artifactIdMyWar/artifactId packagingwar/packaging groupIdMyCompany/groupId descriptionMy War/description version1.0/version build plugins plugin groupIdorg.apache.tuscany/groupId artifactIdtuscany-war-plugin/artifactId extensionstrue/extensions executions execution idtuscany-war/id goals goaltuscany-war/goal /goals /execution /executions configuration bootLibs dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version1.2/version /dependency /bootLibs extensions dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2/version /dependency /extensions /configuration /plugin /plugins /build /project /code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-770) Support to set Host specific (provided) RuntimeInfo object, in LauncherImpl
[
https://issues.apache.org/jira/browse/TUSCANY-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng updated TUSCANY-770:
-
Fix Version/s: (was: Java-M2)
Java-M3
Support to set Host specific (provided) RuntimeInfo object, in LauncherImpl
---
Key: TUSCANY-770
URL: https://issues.apache.org/jira/browse/TUSCANY-770
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Rashmi Hunt
Fix For: Java-M3
Currently there is no API or any way in LauncherImpl to set Host specific
(provided) RuntimeInfo object, while bootstrapping the runtime.
This support is needed for the host to supply its own implementation of
RuntimeInfo so that it can be later accessed in binding extensions
by autowiring in the builder. Such support will provide a way for binding
extensions to access any host specific information.
LauncherImpl needs an API like,
public void setHostRuntimeInfo(Class runtimeInfoClass, Object
runtimeInfo) {
systemCompositeComponent.registerJavaObject(runtimeInfoClass.getName(),
runtimeInfoClass,
runtimeInfo);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-733) Version information should not be in war plugin source code
[ https://issues.apache.org/jira/browse/TUSCANY-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-733. Resolution: Fixed Version information should not be in war plugin source code --- Key: TUSCANY-733 URL: https://issues.apache.org/jira/browse/TUSCANY-733 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-M2 Attachments: tuscany-773.patch The version of the runtime to use should be a configuration property of the war plugin and not hard coded in Dependency. Ideally, the default value for runtime version should come from a POM property, perhaps the version of the POM plugin itself. A user of the plugin should be able to override this in their own project with a configuration property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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 ] Ki Park updated TUSCANY-1055: - Attachment: TUSCANY-1055.patch 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-Mx 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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-538) Refactor Celtix binding
[ https://issues.apache.org/jira/browse/TUSCANY-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-538. Resolution: Fixed Refactor Celtix binding --- Key: TUSCANY-538 URL: https://issues.apache.org/jira/browse/TUSCANY-538 Project: Tuscany Issue Type: Improvement Components: Java SCA Celtix Binding Affects Versions: Java-M2 Reporter: Jervis Liu Priority: Minor Fix For: Java-M2 Attachments: jira538.patch We need to refactor the Celtix binding in sandbox to reflect changes in the new recursive framework. Also more tests need to be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-775) Web deployment broken
[ https://issues.apache.org/jira/browse/TUSCANY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-775. Resolution: Fixed Web deployment broken - Key: TUSCANY-775 URL: https://issues.apache.org/jira/browse/TUSCANY-775 Project: Tuscany Issue Type: Bug Components: Java SCA Core, Java SCA Samples Affects Versions: Java-M2 Reporter: Andy Piper Assigned To: Kenneth Tam Fix For: Java-M2 Attachments: web.patch Web deployment is broken -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-437) StAX loader framework cannot handle xsi:type
[
https://issues.apache.org/jira/browse/TUSCANY-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng updated TUSCANY-437:
-
Fix Version/s: (was: Java-M2)
Java-Mx
StAX loader framework cannot handle xsi:type
--
Key: TUSCANY-437
URL: https://issues.apache.org/jira/browse/TUSCANY-437
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2, Java-Mx
Reporter: Raymond Feng
Assigned To: Raymond Feng
Fix For: Java-Mx
The current StAX loader registration is against the QName of the element. It
cannot handle the xsi:type variant.
For example, if I change the sca.module for Helloworld to use the
xsi:type (which is legal against the SCA xsd).
module xmlns=http://www.osoa.org/xmlns/sca/0.9;
xmlns:v=http://www.osoa.org/xmlns/sca/values/0.9;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
name=helloworld
component name=HelloWorldServiceComponent
!--
implementation.java class=helloworld.HelloWorldImpl/
--
implementation xsi:type=JavaImplementation
class=helloworld.HelloWorldImpl/
/component
/module
I'm getting the following exception:
Exception in thread main
org.apache.tuscany.core.config.ConfigurationLoadException: Unrecognized
element [{http://www.osoa.org/xmlns/sca/0.9}implementation]
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:62)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:76)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.loader.assembly.CompositeLoader.loadComposite(CompositeLoader.java:43)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:41)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoaderImpl.loadModule(StAXModuleComponentConfigurationLoaderImpl.java:51)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:142)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67)
at helloworld.HelloWorldClient.main(HelloWorldClient.java:32)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-687) Add tuscany- as the prefix for our artifact ids
[ https://issues.apache.org/jira/browse/TUSCANY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng updated TUSCANY-687: - Fix Version/s: (was: Java-M2) Java-M3 Add tuscany- as the prefix for our artifact ids - Key: TUSCANY-687 URL: https://issues.apache.org/jira/browse/TUSCANY-687 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Fix For: Java-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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 ] Ki Park updated TUSCANY-1055: - Fix Version/s: (was: Java-SDO-Mx) Affects Version/s: (was: Java-SDO-Mx) I've attached a patch which resolves this problem by updating DataFactoryImpl.java and added an extra !type.isAbstract() check before creating a DataObject. 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 Environment: You should see this error in any environment. Reporter: Ki Park Priority: Minor 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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-687) Add tuscany- as the prefix for our artifact ids
[ https://issues.apache.org/jira/browse/TUSCANY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-687: Assignee: Raymond Feng Add tuscany- as the prefix for our artifact ids - Key: TUSCANY-687 URL: https://issues.apache.org/jira/browse/TUSCANY-687 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Fix For: Java-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-751) Update SDO overview of Tuscany site
[ https://issues.apache.org/jira/browse/TUSCANY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-751: Assignee: Kelvin Goodson Update SDO overview of Tuscany site --- Key: TUSCANY-751 URL: https://issues.apache.org/jira/browse/TUSCANY-751 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-M2 Reporter: Yang ZHONG Assigned To: Kelvin Goodson Fix For: Java-M2 Attachments: ChangeSummary.gif, DataObject.gif, NewSdoOverview.zip, NewSdoOverview2.zip, NewSdoOverview3.zip, overview.gif, property.gif, sdouml.zip, type.gif The overview says SDO simplify and unify ... SDO is language neutral. SDO is being implemented ... SDO PHP ... SDO can be used ... SDO is a natural format for representing data on the wire in an SOA environment. With new comer hat on, I still don't know what SDO is briefly. How about a brief description right after SDO is a natural format ... with a structural diagram clickable towards brief DataObject, Type, Property and ChangeSummary description? SCA overview has demonstrated such a good example. Thank Andrew for the support and thank Kelvin and Geoff for the text contribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
non mvn artifacts
Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: non mvn artifacts
I do something similar to this in the helloworldjsonrpc sample, the sample uses the dojo toolkit and downloads it and installs it into the local maven repo if it isn't there already. Have a look at samples/sca/helloworldjsonrpc/pom.xml and build.xml to see how it works. -Bert On 1/15/07, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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: non mvn artifacts
Thanks Bert, I will take a look. From: Bert Lamb [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: non mvn artifacts Date: Mon, 15 Jan 2007 13:50:21 -0500 I do something similar to this in the helloworldjsonrpc sample, the sample uses the dojo toolkit and downloads it and installs it into the local maven repo if it isn't there already. Have a look at samples/sca/helloworldjsonrpc/pom.xml and build.xml to see how it works. -Bert On 1/15/07, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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] _ MSN Hotmail is evolving – check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Echo binding failure, was: Re: Standalone Smoketest failure
Yes, It's related to wire optimizations. I'll take a look. Jim On Jan 15, 2007, at 9:38 AM, Raymond Feng wrote: I'm seeing it as well. It's probably caused by some changes in the core. I did a bit debugging, and here's the stacktrace where the code goes wrong: (OutboundWireImpl.targetWire == null for the EchoReference's outbound wire). Jim, can you check? Thanks, Raymond Thread [main] (Suspended) OutboundWireImpl.getTargetService() line: 78 InboundWireImpl.getTargetService() line: 81 OutboundWireImpl.getTargetService() line: 82 WireObjectFactoryT.getInstance() line: 70 PojoObjectFactoryT.getInstance() line: 100 JavaAtomicComponent(PojoAtomicComponent).createInstance() line: 137 StatelessScopeContainer.getInstanceWrapper(AtomicComponent, boolean) line: 70 StatelessScopeContainer(AbstractScopeContainer).getInstance (AtomicComponent)line: 99 JavaAtomicComponent (PojoAtomicComponent).getTargetInstance() line: 129 JavaTargetInvoker.getInstance(short) line: 127 JavaTargetInvoker.invokeTarget(Object, short) line: 75 JavaTargetInvoker(TargetInvokerExtension).invoke(Message) line: 67 InvokerInterceptor.invoke(Message) line: 44 JDKInboundInvocationHandler(AbstractInboundInvocationHandler).invoke (InboundInvocationChain, TargetInvoker, Object[]) line: 45 JDKInboundInvocationHandler.invoke(Object, Method, Object[]) line: 122 $Proxy18.call(String) line: not available BootstrapTestCase.testDemoBoot() line: 35 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: notavailable [native method] NativeMethodAccessorImpl.invoke (Object, Object[]) line: 64 DelegatingMethodAccessorImpl.invoke (Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 615 BootstrapTestCase(TestCase).runTest() line: 154 BootstrapTestCase(TestCase).run Bare() line: 127 TestResult$1.protect() line: 106 TestResult.runProtected(Test, Protectable) line: 124 TestResult.run (TestCase) line: 109 BootstrapTestCase(TestCase).run(TestResult) line: 118 TestSuite.runTest(Test, TestResult) line: 208 TestSuite.run(TestResult) line: 203 JUnit3TestReference.run (TestExecution) line: 128 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 460 RemoteTestRunner.runTests(TestExecution) line: 673 RemoteTestRunner.run() line: 386 RemoteTestRunner.main(String[]) line: 196- Original Message -From: Bert Lamb [EMAIL PROTECTED]To: tuscany-dev@ws.apache.orgSent: Monday, January 15, 2007 7:48 AMSubject: Re: Standalone Smoketest failureI also just did a fresh checkout with a an empty local repo and I'm getting a test failure for the echo binding: -- - Test set: echo.BootstrapTestCase -- - Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.688 sec FAILURE! testDemoBoot(echo.BootstrapTestCase) Time elapsed: 1.64 sec ERROR! java.lang.NullPointerException at echo.ClientImpl.call(ClientImpl.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) atorg.apache.tuscany.core.implementation.java.JavaTargetInvoker.invoke Target(JavaTargetInvoker.java:93) atorg.apache.tuscany.spi.extension.TargetInvokerExtension.invoke (TargetInvokerExtension.java:67) atorg.apache.tuscany.core.wire.InvokerInterceptor.invoke (InvokerInterceptor.java:44) atorg.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke( AbstractInboundInvocationHandler.java:45) a torg.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke (JDKInboundInvocationHandler.java:122) at $Proxy20.call(Unknown Source) at echo.BootstrapTestCase.testDemoBoot (BootstrapTestCase.java:35) at echo.BootstrapTestCase.testDemoBoot (BootstrapTestCase.java:35) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.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.Te stSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke
Re: non mvn artifacts
Why don't we ask the JXTA folks to publish the latest versions into maven2 repo if possible :-)? Thanks, Raymond - Original Message - From: Meeraj Kunnumpurath [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, January 15, 2007 10:45 AM Subject: non mvn artifacts Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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: non mvn artifacts
I have done that as well, in fact, I am thinkining about volunteering to do the mavenisation. Meeraj From: Raymond Feng [EMAIL PROTECTED] Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: non mvn artifacts Date: Mon, 15 Jan 2007 11:01:26 -0800 Why don't we ask the JXTA folks to publish the latest versions into maven2 repo if possible :-)? Thanks, Raymond - Original Message - From: Meeraj Kunnumpurath [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, January 15, 2007 10:45 AM Subject: non mvn artifacts Hi, How do we handle dependencies on artifacts that are not maintaiend in mvn repos. I have a requirement to use the 2.4.1 release for jxta, however, they don't maintain the artifacts in any repos. One option I thought was to download it as part of the build and install it to the local repo. I think we do something similar with sun jars for celtix. Ta Meeraj _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters - 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] _ MSN Hotmail is evolving – check out the new Windows Live Mail http://ideas.live.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: [jira] Resolved: (INFRA-1107) Request to create a space for Tuscany project on the CWIKI site
Hi, The Tuscany space is now created on Apche CWIKI. Please see more details below. Thanks, Raymond - Original Message - From: Ted Husted (JIRA) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 14, 2007 12:19 PM Subject: [jira] Resolved: (INFRA-1107) Request to create a space for Tuscany project on the CWIKI site [ https://issues.apache.org/jira/browse/INFRA-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Husted resolved INFRA-1107. --- Resolution: Fixed Assignee: Ted Husted Confluence Group: tuscany-committers Confluence-Administrator for Group: rfeng Public site: http://cwiki.apache.org/TUSCANY/ Remember: The first rule of CWIKI is don't link to CWIKI! This Confluence site is autoexported to HTML. Please link only to the exported pages. Do not link directly to the wiki! The autoexport include live links to allow easy editing of pages. By linking to the autoexport, we can scale the site for everyone's benefit. For more notes see: http://cwiki.apache.org/CWIKI/ -Ted. Request to create a space for Tuscany project on the CWIKI site --- Key: INFRA-1107 URL: https://issues.apache.org/jira/browse/INFRA-1107 Project: Infrastructure Issue Type: Task Security Level: public(Regular issues) Components: Confluence Reporter: Raymond Feng Assigned To: Ted Husted Hi, Would you please create a space for Tuscany (http://incubator.apache.org/tuscany) on the CWIKI site? Name: Apache Tuscany Key: TUSCANY I already have an account with the CWIKI site: rfeng (Raymond Feng) Thanks, Raymond Feng A Tuscany Committer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-882) Async samples fail in stanalone launcher
[ https://issues.apache.org/jira/browse/TUSCANY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Silva-Lepe closed TUSCANY-882. -- Resolution: Fixed Fix Version/s: (was: Java-M2) Java-Mx This now works with sca\runtime\standalone\assembly Async samples fail in stanalone launcher Key: TUSCANY-882 URL: https://issues.apache.org/jira/browse/TUSCANY-882 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: ant elder Assigned To: Ignacio Silva-Lepe Fix For: Java-Mx Simplecallback sample fails in stanalone launcher with the following exception: C:\SCA\SVN\TRUNK\samples\sca\simplecallbackjava -jar ..\..\..\..\..\StandaloneT\bin\launcher.jar target\sample-simplecallback-1.0-incubator-M2-SNAPSHOT.jar Main thread Thread[main,5,main] java.lang.IllegalStateException: Scope not running [6] at org.apache.tuscany.core.component.scope.AbstractScopeContainer.checkInit(AbstractScopeContainer.java:124) at org.apache.tuscany.core.component.scope.ModuleScopeContainer.getInstanceWrapper(ModuleScopeContainer.java:118) at org.apache.tuscany.core.component.scope.AbstractScopeContainer.getInstance(AbstractScopeContainer.java:105) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:117) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:94) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:59) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:60) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(NonBlockingBridgingInterceptor.java:70) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr237Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
On Jan 15, 2007, at 6:44 AM, Pete Robbins wrote: As part of this are you considering only multiple Java runtimes or can this proposal embrace a C++/Python/Ruby component implementation deployed on the C++ runtime? This is really about runtime-to-runtime cooperation - which implementation types a runtime can support would be something that was input to the decision making process (about what to run where). So, for example, a Ruby component could be allocated any C++ or Java runtime that supported that implementation type. I think we should use standard protocols for this communication, such as Bonjour, UPNP, JXTA etc. so that they can easily be supported by runtimes implemented in different languages. I.e we don't want a protocol that relies on synchronizing native Java/C++/... objects. Different domains may prefer different protocols (for networking reasons) so we want this to be plugable. Having said that, I wasn't planning on working on a non-Java version but if you see something that would be hard/impossible to implement in the C++ runtime please shout :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributed assemblies
On 15/01/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jan 15, 2007, at 6:44 AM, Pete Robbins wrote: As part of this are you considering only multiple Java runtimes or can this proposal embrace a C++/Python/Ruby component implementation deployed on the C++ runtime? This is really about runtime-to-runtime cooperation - which implementation types a runtime can support would be something that was input to the decision making process (about what to run where). So, for example, a Ruby component could be allocated any C++ or Java runtime that supported that implementation type. I think we should use standard protocols for this communication, such as Bonjour, UPNP, JXTA etc. so that they can easily be supported by runtimes implemented in different languages. I.e we don't want a protocol that relies on synchronizing native Java/C++/... objects. Different domains may prefer different protocols (for networking reasons) so we want this to be plugable. Having said that, I wasn't planning on working on a non-Java version but if you see something that would be hard/impossible to implement in the C++ runtime please shout :-) -- Jeremy Hey! everything is hard/impossible to implement in C++ ;-) I need to do some homework on this first but it's certainly an area I'm interested in. Cheers, -- Pete
Web site doesn't mention multi-language support
The Tuscany Web site seems to have very few clues about the multi-language (scripting) capabilities of Tuscany. We released quite a bit of support for scripting languages in SCA C++ M2, and we have had some support for acripting in SCA Java since M1, but the Web site seems strangely silent on these capabilities. The casual and not-so-casual reader of the Web site could be forgiven for thinking that the only languages that Tuscany supports are Java and C++. I know that there is more information about this if you download the releases and look inside them at samples, readmes, etc. But I can't find it on the Web site. Am I missing something? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-883) helloworldruby sample fails in the standalone launcher as jruby classes can't be found
[ https://issues.apache.org/jira/browse/TUSCANY-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-883. - Fixed helloworldruby sample fails in the standalone launcher as jruby classes can't be found -- Key: TUSCANY-883 URL: https://issues.apache.org/jira/browse/TUSCANY-883 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M2 helloworldruby sample fails in the standalone launcher as jruby classes can't be found: C:\SCA\SVN\M2\samples\standalone\helloworldRubyjava -jar ..\..\..\..\..\StandaloneT\bin\launcher.jar target\sample-hellowor d-ruby-1.0-incubator-M2-SNAPSHOT.jar Exception in thread main java.lang.NoClassDefFoundError: org/jruby/javasupport/JavaEmbedUtils at org.apache.tuscany.container.ruby.rubyscript.RubyScript.init(RubyScript.java:47) at org.apache.tuscany.container.ruby.RubyImplementationLoader.load(RubyImplementationLoader.java:81) at org.apache.tuscany.container.ruby.RubyImplementationLoader.load(RubyImplementationLoader.java:46) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94) at org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:183) at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:127) at org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:70) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:94) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:112) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponent ypeLoader.java:65) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.j va:57) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.j va:39) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:163) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76) at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) at org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:87) at org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:86) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-647) Axis2 resources not avaialable on thread context classloader
[ https://issues.apache.org/jira/browse/TUSCANY-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-647. - Resolution: Fixed Fix Version/s: (was: Java-M2) Java-M3 Fixed Axis2 resources not avaialable on thread context classloader Key: TUSCANY-647 URL: https://issues.apache.org/jira/browse/TUSCANY-647 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M3 Axis2 can't find its Messagereceivers and TransportSenders as Axis2 is looking in the thread context classloader but in Tuscany these are in the Tuscany launcher boot or extension class loader. For example, org.apache.axis2.deployment.DescriptionBuilder.processMessageReceivers. See also: http://issues.apache.org/jira/browse/AXIS2-1047 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-643) Integrate Spring NS handling into tuscany impl.spring
[ https://issues.apache.org/jira/browse/TUSCANY-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-643: --- Fix Version/s: (was: Java-M2) Java-M3 Integrate Spring NS handling into tuscany impl.spring - Key: TUSCANY-643 URL: https://issues.apache.org/jira/browse/TUSCANY-643 Project: Tuscany Issue Type: Improvement Affects Versions: Java-M2 Reporter: Andy Piper Priority: Minor Fix For: Java-M3 Attachments: spring.patch, springint.patch I fixed up the Spring impl to utiltize the namespace handling code properly. This is work in progress, but at least eliminates the need for changes to spring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-619) Fix classloader hierarchy for extensions
[ https://issues.apache.org/jira/browse/TUSCANY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-619: --- Fix Version/s: (was: Java-M2) Java-M3 Fix classloader hierarchy for extensions Key: TUSCANY-619 URL: https://issues.apache.org/jira/browse/TUSCANY-619 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jeremy Boynes Fix For: Java-M3 We have the start of a classloader hierarchy working for extension code but it is not being set up correctly in some environments e.g. the current web launcher. This is causing problems when loading extensions such as Axis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-294) Document the assembly model
[ https://issues.apache.org/jira/browse/TUSCANY-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-294: --- Fix Version/s: (was: Java-M2) Java-M3 Document the assembly model --- Key: TUSCANY-294 URL: https://issues.apache.org/jira/browse/TUSCANY-294 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jean-Sebastien Delfino Fix For: Java-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Sebastien has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-81) Make .componentType side files optional for JavaScript components
[ https://issues.apache.org/jira/browse/TUSCANY-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-81: -- Fix Version/s: (was: Java-M2) Java-M3 Make .componentType side files optional for JavaScript components - Key: TUSCANY-81 URL: https://issues.apache.org/jira/browse/TUSCANY-81 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-M2 Reporter: ant elder Priority: Minor Fix For: Java-M3 Currently JavaScript components require a .componentType side file. Thats because currently its the only way of defining the interface being implemented by the component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[ https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-824: --- Fix Version/s: (was: Java-M2) Java-M3 DataBinding: Is it a concern of Programming Model vs. Assembly? --- Key: TUSCANY-824 URL: https://issues.apache.org/jira/browse/TUSCANY-824 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Priority: Blocker Fix For: Java-M3 There have been some question about the DataBinding framework and if it should be a concern of the Programming Model vs. Assembly? See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html and a follow up mention in: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-746) on tuscany/mail-lists.html - commits list on www.mail-archive.com is not always complete
[ https://issues.apache.org/jira/browse/TUSCANY-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-746: --- Fix Version/s: (was: Java-M2) Java-M3 on tuscany/mail-lists.html - commits list on www.mail-archive.com is not always complete Key: TUSCANY-746 URL: https://issues.apache.org/jira/browse/TUSCANY-746 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Tom Seelbach Priority: Minor Fix For: Java-M3 The http://incubator.apache.org/tuscany/mail-lists.html commits points to : http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html This page appears to be missing some commits. For example the apache.org mail-archive: http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200609.mbox/browser Shows this commit : Thu Sep 21 12:04:16 2006 r448634 but that commit is missing from http://www.mail-archive.com/tuscany-commits%40ws.apache.org/maillist.html. (jumps from 448576 to 548682 My suggestion is to change the commits list pointer to http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-79) Document the JavaScript component type
[ https://issues.apache.org/jira/browse/TUSCANY-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-79: -- Fix Version/s: (was: Java-M2) Java-M3 Document the JavaScript component type -- Key: TUSCANY-79 URL: https://issues.apache.org/jira/browse/TUSCANY-79 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-M2 Reporter: ant elder Priority: Minor Fix For: Java-M3 Create some doc describing a JavaScript component and script file, and how to configure them with componentType side files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-773) Fix Property Value Loading from Component Definitions
[ https://issues.apache.org/jira/browse/TUSCANY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-773: --- Fix Version/s: (was: Java-M2) Java-M3 Fix Property Value Loading from Component Definitions - Key: TUSCANY-773 URL: https://issues.apache.org/jira/browse/TUSCANY-773 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: Raymond Feng Fix For: Java-M3 Attachments: rfeng.patch, Tuscany-kernel-core-02-Oct.diff, Tuscany-kernel-spi-02-Oct.diff, Tuscany-sca-kernel-core-03-Oct.diff, Tuscany-sca-kernel-spi-03-Oct.diff, Tuscany-spec-sca-02-Oct.diff, Tuscany-spec-sca-03-Oct.diff Currently property loading for application components does not work. There is NPE exception thrown when creating a property instance factory based on the property value defined in the Component Defn. Also the property loading works only for simply types whose values can be represented as a simple xml text content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-296) Document the architecture of the Java container
[ https://issues.apache.org/jira/browse/TUSCANY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-296: --- Fix Version/s: (was: Java-M2) Java-M3 Document the architecture of the Java container --- Key: TUSCANY-296 URL: https://issues.apache.org/jira/browse/TUSCANY-296 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jim Marino Fix For: Java-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Jim has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-505) xsi:type on root element fo XML doc causes problems
[ https://issues.apache.org/jira/browse/TUSCANY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-505: --- Fix Version/s: (was: Java-M2) Java-M3 xsi:type on root element fo XML doc causes problems --- Key: TUSCANY-505 URL: https://issues.apache.org/jira/browse/TUSCANY-505 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M1 Environment: Windows XP Reporter: Simon Laws Fix For: Java-M3 If I read the following doc: tns:RootElement xmlns:p=commonj.sdo xmlns:tns=http://www.apache.org/tuscany/interop; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement With the following schema schema xmlns= http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.apache.org/tuscany/interop; xmlns:tns= http://www.apache.org/tuscany/interop; include schemaLocation=interop10.xsd/ !-- top level test type -- complexType name=ComplexTypeRootType sequence !-- simple types -- element name=SimpleTypeWithName type=tns:SimpleTypeWithNameType/ /sequence /complexType element name=RootElement type=tns:ComplexTypeRootType/ /schema The I get a valid document (doc) with some data objects in it out of the following code: FileInputStream inFileStream = new FileInputStream (inFileName); XMLDocument doc = XMLHelper.INSTANCE.load(inFileStream); If I try in read in (note I have added and xsi:type attribute): tns:RootElement xmlns:p=commonj.sdo xsi:type=tns:ComplexTypeRootType xmlns:tns=http://www.apache.org/tuscany/interop xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.apache.org/tuscany/interop interop01.xsd SimpleTypeWithNameSimpleTypeWithName/SimpleTypeWithName /tns:RootElement The XMLHelper silently makes an empty document, i.e. the root element is null. I talked with Frank and he suggested changing the xsi:type to refer to a type that extends the root element type. This produced the same effect, i.e. and empty document. However xsi:type does seem to behave in both the base type and extension type case when attached to elements other than the root element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-989) Exception in Test set: echo.DataBindingIntegrationTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-989: --- Fix Version/s: (was: Java-M2) Java-M3 Exception in Test set: echo.DataBindingIntegrationTestCase -- Key: TUSCANY-989 URL: https://issues.apache.org/jira/browse/TUSCANY-989 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M1 Reporter: Rick Rineholt Assigned To: Venkatakrishnan Fix For: Java-M3 The following exception is happening in E:\dev\tuscany\java\samples\sca\echo.databinding testcase: something with the lastest passbyvalue code and the tc having non-serializable data PER IRC chat: I think we need to fix the pass-by-value code to support OMElement in this case --- Test set: echo.DataBindingIntegrationTestCase --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.735 sec FAILURE! testTransform(echo.DataBindingIntegrationTestCase) Time elapsed: 1.688 sec ERROR! java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.copy(PassByValueInterceptor.java:126) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.copy(PassByValueInterceptor.java:79) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(PassByValueInterceptor.java:49) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:149) at $Proxy22.echo(Unknown Source) at echo.ComponentBImpl.call(ComponentBImpl.java:43) 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.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:89) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:65) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(PassByValueInterceptor.java:50) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invoke(PassByValueInterceptor.java:50) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke(AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:149) at $Proxy21.call(Unknown Source) at echo.ComponentAImpl.call(ComponentAImpl.java:50) at echo.DataBindingIntegrationTestCase.testTransform(DataBindingIntegrationTestCase.java:34) Caused by: java.lang.IllegalArgumentException: Pass-by-value is not supported for the given object at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.copy(PassByValueInterceptor.java:123) ... 50 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-293) Document the architecture of the core runtime
[ https://issues.apache.org/jira/browse/TUSCANY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-293: --- Fix Version/s: (was: Java-M2) Java-M3 Document the architecture of the core runtime - Key: TUSCANY-293 URL: https://issues.apache.org/jira/browse/TUSCANY-293 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jim Marino Fix For: Java-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentation on our web site. Jim and Jeremry have volunteered to do this. Assigning to Jim for now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-690) Optimize JDK WireService
[ https://issues.apache.org/jira/browse/TUSCANY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-690: --- Fix Version/s: (was: Java-M2) Java-M3 Optimize JDK WireService Key: TUSCANY-690 URL: https://issues.apache.org/jira/browse/TUSCANY-690 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Affects Versions: Java-M2 Reporter: Venkatakrishnan Fix For: Java-M3 Attachments: Tuscany-kernel-core-jdkwireservice-Sept-4.diff This is going to involve several things. To begin with Jim Marino had suggested the creation of dynamic classes for the proxies (instead of java.lang.reflect.Proxy) using ASM and bytecode generation. Please refer to the thread http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg07271.html Here is a patch that changes the 'createProxy' method of the JDKService class. It generates bytecodes for a proxy implementation class for the wire's interface. It then instantiates this class and returns it (instead of an instance of java.lang.reflect.Proxy as it used to before). After instantiation this proxy is set with the chains that correspond to each of the service methods. Hence during invocation there is no seek into a map based on the invoked method, to find the right chain. The invocation is made with right chain directly. I have been able to successfully compile and run most of the testcases. But a few fail since there are assetions that check if the proxy generated is of 'java.lang.relect.Proxy' type, which obviously is not. Before I go ahead and make those changes I would like to know if the current implementation is fine. I have tested the JavaScript testcases after these changes to the wiring and they work. Thanks - Venkat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-83) JavaScript components don't support init/destroy/scope
[ https://issues.apache.org/jira/browse/TUSCANY-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-83: -- Fix Version/s: (was: Java-M2) Java-M3 JavaScript components don't support init/destroy/scope -- Key: TUSCANY-83 URL: https://issues.apache.org/jira/browse/TUSCANY-83 Project: Tuscany Issue Type: Bug Components: Java SCA JavaScript Container Affects Versions: Java-M2 Reporter: ant elder Assigned To: Michael John Edwards Priority: Minor Fix For: Java-M3 You can't use init, destroy or scope with JavaScript components as currently the .componetType schema doesn't support these so there's no way of specifying them. Need to get the schema changed or come up with something similar to Java annotations for JavaScript -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-292) Document our logging guidelines
[ https://issues.apache.org/jira/browse/TUSCANY-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-292: --- Fix Version/s: (was: Java-M2) Java-M3 Document our logging guidelines --- Key: TUSCANY-292 URL: https://issues.apache.org/jira/browse/TUSCANY-292 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jeremy Boynes Fix For: Java-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need these guidelines on our web site. Jeremy has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-751) Update SDO overview of Tuscany site
[ https://issues.apache.org/jira/browse/TUSCANY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-751: --- Fix Version/s: (was: Java-M2) Java-M3 Update SDO overview of Tuscany site --- Key: TUSCANY-751 URL: https://issues.apache.org/jira/browse/TUSCANY-751 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-M2 Reporter: Yang ZHONG Assigned To: Kelvin Goodson Fix For: Java-M3 Attachments: ChangeSummary.gif, DataObject.gif, NewSdoOverview.zip, NewSdoOverview2.zip, NewSdoOverview3.zip, overview.gif, property.gif, sdouml.zip, type.gif The overview says SDO simplify and unify ... SDO is language neutral. SDO is being implemented ... SDO PHP ... SDO can be used ... SDO is a natural format for representing data on the wire in an SOA environment. With new comer hat on, I still don't know what SDO is briefly. How about a brief description right after SDO is a natural format ... with a structural diagram clickable towards brief DataObject, Type, Property and ChangeSummary description? SCA overview has demonstrated such a good example. Thank Andrew for the support and thank Kelvin and Geoff for the text contribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-544: --- Fix Version/s: (was: Java-M2) Java-M3 WSDL2Java should support WSDLs with schema imports -- Key: TUSCANY-544 URL: https://issues.apache.org/jira/browse/TUSCANY-544 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Ron Gavlin Fix For: Java-M3 Many WSDLs choose to import schemas rather than embedding types inline. The tuscany WSDL2JavaGenerator does not currently support this type of usage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-612) Java SDO Overview doc doesnt address setting of M2_REPO variable
[ https://issues.apache.org/jira/browse/TUSCANY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-612: --- Fix Version/s: (was: Java-M2) Java-M3 Java SDO Overview doc doesnt address setting of M2_REPO variable Key: TUSCANY-612 URL: https://issues.apache.org/jira/browse/TUSCANY-612 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-M2 Reporter: Kelvin Goodson Fix For: Java-M3 when initializing a new eclipse environment as per the instructions in the java sdo overview, the eclipse projects generated by the mvn eclipse:eclipse commands don't build until the M2_REPO variable is set. This needs describing in the docvument (instruction outline -- right click a project, properties, build path, libraries, click a library with M2_REPO var referenced, edit, variable, folder, browse to repository (on windows this is c:\Documents and Settings\username\.m2\repository) and set the variable) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-756) WS binding returns wsdl with incorrect endpoint from ?wsdl
[ https://issues.apache.org/jira/browse/TUSCANY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-756: --- Fix Version/s: (was: Java-M2) Java-M3 WS binding returns wsdl with incorrect endpoint from ?wsdl -- Key: TUSCANY-756 URL: https://issues.apache.org/jira/browse/TUSCANY-756 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M3 Doing a ?wsdl on the service exposed by a service using the Axis2 ws binding returns a wsdl with the wrong endpoint address. To recreate deploy the helloworldws sample to tomcat and in a browser enter: http://localhost:8080/sample-helloworldws-1.0-incubator-M2-SNAPSHOT/services/HelloWorldWebService?wsdl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-76) Need a specifcation of how WSDL elements used in an SCA assembly get resolved
[ https://issues.apache.org/jira/browse/TUSCANY-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-76: -- Fix Version/s: (was: Java-M2) Java-M3 Need a specifcation of how WSDL elements used in an SCA assembly get resolved -- Key: TUSCANY-76 URL: https://issues.apache.org/jira/browse/TUSCANY-76 Project: Tuscany Issue Type: New Feature Components: Specification Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Michael John Edwards Fix For: Java-M3 The SCA 0.9 assembly spec references WSDL portTypes and ports by namespace + local name. The specification does not make any statement about how an SCA runtime or SCA tooling is supposed to resolve these WSDL elements. I think we have a number of options here: - define name mapping rules between WSDL namespaces and names and WSDL file locations, allowing a runtime and tooling to derive the location of the WSDL files from their namespaces for example (similar to the Java package - location mapping rules) - introduce a way to associate a WSDL namespace to a particular file or collection of files (similar to a WSDL import) As a temporary solution until the spec resolves this issue, In Tuscany we have introduced an SCDL extension for this. The app developer must add a import.wsdl namespace=namespace of the particular wsdl location=location of wsdl file element to his sca.module, sca.fragment or sca.subsystem SCA assembly file. The import.wsdl element makes the referenced WSDL available within the scope of the particular SCA assembly. The BigBank sample contains an example of this. This Tuscany extension can be used to cover most scenarios for now but will not address well scenarios where you want to share a .componentType that uses a WSDL portType in two different modules. You'd have to repeat the same wsdl.import in the two modules. So we need the SCA assembly spec to address this issue and then adjust our implementation to what the spec will define. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-695) JavaComponentTypeLoader.load() returns PojoComponentType which isn't a ModelObject
[
https://issues.apache.org/jira/browse/TUSCANY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-695:
---
Fix Version/s: (was: Java-M2)
Java-M3
JavaComponentTypeLoader.load() returns PojoComponentType which isn't a
ModelObject
--
Key: TUSCANY-695
URL: https://issues.apache.org/jira/browse/TUSCANY-695
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Environment: r440401
Reporter: Scott Kurz
Fix For: Java-M3
When I tried using a componentType file along w/ my Java impl I got:
org.apache.tuscany.spi.loader.UnrecognizedElementException :
{http://www.osoa.org/xmlns/sca/1.0}componentType
[{http://www.osoa.org/xmlns/sca/1.0}componentType ]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:113)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadFromSidefile(JavaComponentTypeLoader.java
)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:71)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java
:47)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java
:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:133)
at org.apache.tuscany.core.loader.ComponentLoader.load
(ComponentLoader.java:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java
:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
:118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
The problem wasn't the lack of a loader to load componentType
elems.rather, it was this line in JavaComponentTypeLoader:
protected PojoComponentType loadFromSidefile(URL url, DeploymentContext
deploymentContext) throws LoaderException {
return loaderRegistry.load(null, url, PojoComponentType.class,
deploymentContext);
}
Thie use of 'PojoComponentType.class' as argument is a problem. In
LoaderRegistryImpl.load, we do (line 109):
ModelObject mo = load(parent, reader, ctx);
if (type.isInstance(mo)) {
So we're loading into a ModelObject, (more specifically,
org.apache.tuscany.spi.model.ComponentType), but the 'type' here is :
PojoComponentType.class
which is in pkg org.apache.tuscany.core.implementation.java and passed into
the load(..) call.
On the dev list, Raymond Feng answered my email describing the problem with
this:
The ComponentTypeElementLoader creates a generic ComponentType from
the XML file but the code expects an instance of PojoComponentType. Now the
question is how to map the generic ComponentType into the PojoComponentType
if it's required. Jim, do you have ideas?
Jim Marino replied:
We should probably have the implementation loader handle creation of
the particular component type class and populate it by recursing back
into the loader since it is minimal code
(ComponentTypeElementLoader). This would be a nice patch for someone
to work on :-)
Jim
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Updated: (TUSCANY-545) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename.
[ https://issues.apache.org/jira/browse/TUSCANY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-545: --- Fix Version/s: (was: Java-M2) Java-M3 WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. Key: TUSCANY-545 URL: https://issues.apache.org/jira/browse/TUSCANY-545 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Ron Gavlin Fix For: Java-M3 WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-215) Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository
[ https://issues.apache.org/jira/browse/TUSCANY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-215: --- Fix Version/s: (was: Java-M2) Java-M3 Document how to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository --- Key: TUSCANY-215 URL: https://issues.apache.org/jira/browse/TUSCANY-215 Project: Tuscany Issue Type: Sub-task Components: Build System Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-M3 We need to document the steps to deploy the Tuscany jars to cvs.apache.org/maven-snapshot-repository. Dan suggested mvn source:jar javadoc:jar deploy. We need to add these steps to our Wiki or Web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-196) Fix Java5 warnings with references to un-parameterized generic types
[ https://issues.apache.org/jira/browse/TUSCANY-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-196. Resolution: Fixed I am not seeing these warnings anymore on recent builds. Fix Java5 warnings with references to un-parameterized generic types Key: TUSCANY-196 URL: https://issues.apache.org/jira/browse/TUSCANY-196 Project: Tuscany Issue Type: Bug Components: Java SCA Common Affects Versions: Java-Mx Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-Mx We have tens of warnings reporting un-parameterized references to raw generic types, in most runtime projects. Here is the text of the warnings X is a raw type. References to type XT should be parameterized. These warnings are easy to fix, just change X to XT, T being an actual type. To see these warnings with Eclipse you need to set your Compiler preferences (Preferences / Java / Compiler / Errors/Warnings / Generic Types / Usage of raw type) to warning. I am creating a top level JIRA issue to track this problem across the Tuscany runtime, if you're planning to fix only a subset of the warnings (for example in just one project) please create a sub-task under this one. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-288) Document the SCA programming model supported by this release
[ https://issues.apache.org/jira/browse/TUSCANY-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-288. Resolution: Fixed This is an old issue for M1, fixed since then. Document the SCA programming model supported by this release Key: TUSCANY-288 URL: https://issues.apache.org/jira/browse/TUSCANY-288 Project: Tuscany Issue Type: Improvement Components: Website Affects Versions: Java-Mx Reporter: Jean-Sebastien Delfino Assigned To: haleh mahbod Fix For: Java-Mx This has been identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. The consensus is that we need a tutorial doc easier to read than the spec. Jim has volunteered to provide the technical input to Haleh. Haleh volunteering to put the document together, assigning to Jim for now since he's a committer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-224) ModuleContext locateService should return a proxy if any interceptors are present in the invocation chain
[ https://issues.apache.org/jira/browse/TUSCANY-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-224. Resolution: Fixed This is working on M2. ModuleContext locateService should return a proxy if any interceptors are present in the invocation chain - Key: TUSCANY-224 URL: https://issues.apache.org/jira/browse/TUSCANY-224 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Jean-Sebastien Delfino Assigned To: Jim Marino Fix For: Java-Mx ModuleContext.locateService always returns the target service instance, instead of returning a proxy configured with the invocation chain for the particular service. If there are any interceptors in the invocation chain, they will never be invoked. This blocks development of any samples and test cases that use the SCA async PM from a simple client (JSP or J2SE client). Right now the helloworldasync sample must go through an intermediate component with a reference to the target service to be able to do any async invocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-640) Service and Reference do not support multiple binding elements
[ https://issues.apache.org/jira/browse/TUSCANY-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-640: --- Fix Version/s: (was: Java-Mx) Java-M3 Affects Version/s: (was: Java-Mx) Java-M3 Jim has been making changes to implement this and I think it is working now, so this it not deferred to Mx anymore. Service and Reference do not support multiple binding elements Key: TUSCANY-640 URL: https://issues.apache.org/jira/browse/TUSCANY-640 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M3 Reporter: Jeremy Boynes Priority: Critical Fix For: Java-M3 According to the spec, Service and Reference definitions can have multiple bindings associated with them. Our config model and the associated loaders and builders only support a single binding -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOA Scenarios
Hi Kelvin, Sorry for the confusion... I was thinking of user stories in the agile / xp sense which are/could be scenarios. The reason I mentioned abstract scenario was to avoid a scenario that runs along the lines of develop a service component and instead go for a more specific (concrete scenario/) user story of develop a service component using Java - perhaps I should not have mentioned this unless it happened. My, unexplained thinking, was it might become apparent that not all things need to be done in all languages/runtimes. This could help avoid writing code that is not (currently at least) wanted. For example is there a need for the C++ runtime to host a component written in Java ? It would be easier to enable a C++ runtime to use IPC/WS to invoke/compose a Java component rather than having the C++ runtime launch a JVM (IMHO). Apologies for the confusion thanks for pointing keeping me true :) Dan On 15/01/07, kelvin goodson [EMAIL PROTECTED] wrote: I think that sounds really good Dan. I'd love to know more about what's driving our users or potential users. This could be seen as a nitpick, but I think also there's the potential for some confusion, since you talk about 'abstract scenarios'. I don't see scenarios as particularly abstract, since they are instances of the more abstract 'use case', i.e. a scenario is a single given path through the use case, documenting only one path wherever the use case gives choices. I guess what we would really like to capture are the use cases, but getting some scenarios together is probably not a bad way to begin. So I think your stories are really the scenarios, and your scenarios are the use cases. Cheers, Kelvin. On 15/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, There have been a number of postings about scenarios. For example: - In July http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html about JSF using Tuscany - In Nov http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas part of the what next for C++ - More recently http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html Would it be useful to document and maintain a set of scenarios that Tuscany does/will support? These could be used to validate and help guide what get developed, rather than relying what next ? postings (more permentant record). It could also be used to help identify complexity and completeness. Lastley it might also make it clearer to differenticate Tuscany from similar projects. Perhaps a way to kick off would be to start gathering some user stories (rather than more abstract scenarios) WDYT ? Cheers, Dan
Tuscany-1045 - Merging component type information from two sources
I have started investigating TUSCANY-1045. Based on what the spec is saying, we should start by calculating the component type information from introspection and then looking into sidefile and merge the info from both in a compatible way : The component type is calculated in two steps where the second step adds to the information found in the first step. Step one is introspecting the implementation (if possible), including the inspection of implementation annotations (if available). Step two covers the cases where introspection of the implementation is not possible or where it does not provide complete information and it involves looking for an SCA component type file. Component type information found in the component type file must be compatible with the equivalent information found from inspection of the implementation. The component type file can specify partial information, with the remainder being derived from the implementation. The issue is that our code, inside JavaComponentTypeLoader is doing these two paths in a exclusive way. I'm planning to work on this, but I want some guidance on how to merge information from a componentType from two different sources. I have couple questions : - Do we already have some similar code available ? - Any special care while merging the info from the two sources (introspection and sideFile) ? - How to identify if the info from both sources are compatible ? -- Luciano Resende http://people.apache.org/~lresende
[jira] Updated: (TUSCANY-969) Add pass-by-value support for remotable interfaces
[ https://issues.apache.org/jira/browse/TUSCANY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-969: --- Fix Version/s: (was: Java-Mx) Java-M3 Changed to M3 as most of the changes seem to have been committed. I am not sure what's left, if this is complete Venkat could you please mark the issue resolved. Add pass-by-value support for remotable interfaces Key: TUSCANY-969 URL: https://issues.apache.org/jira/browse/TUSCANY-969 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Raymond Feng Assigned To: Venkatakrishnan Fix For: Java-M3 Attachments: PassByValueInterceptor.java, PassByValueInterceptorTestCase.java, Tuscany-JIRA-969-Dec07-06.diff I open this JIRa to track the efforts to add pass-by-value support for remotable interfaces as required by the SCA spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-199) Bigbank sample should use wires instead of hacked up SOAP addresses
[ https://issues.apache.org/jira/browse/TUSCANY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-199: --- Fix Version/s: (was: Java-Mx) Java-M3 Affects Version/s: (was: Java-Mx) Java-M3 Changing from Mx to M3 as nested composites and wires across composites are starting to get implemented, the sample should be adjusted to use this capabilities. Bigbank sample should use wires instead of hacked up SOAP addresses --- Key: TUSCANY-199 URL: https://issues.apache.org/jira/browse/TUSCANY-199 Project: Tuscany Issue Type: Bug Components: Java BigBank Scenario Affects Versions: Java-M3 Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-M3 The bigbank sample uses a hacked up / fixed SOAP address in the WSDL to connect the external service in the webclient module component to the entry point of the account module component. This is not how it should work. One very important feature of SCA illustrated by BigBank is to allow module components to be wired together. So we should change the sample to use wires. This is how the sample is actually described in the Building your first SCA application spec companion document. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-238) Unhelpful namespace for Tuscany schemata
[ https://issues.apache.org/jira/browse/TUSCANY-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-238. Resolution: Fixed Fix Version/s: (was: Java-Mx) Java-M3 I checked the trunk and this issue has been resolved. Unhelpful namespace for Tuscany schemata Key: TUSCANY-238 URL: https://issues.apache.org/jira/browse/TUSCANY-238 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Jeremy Boynes Priority: Minor Fix For: Java-M3 We define XML namespaces with the URI beginning http://org.apache.tuscany/xmlns/... This is not resolvable to a web address. It would be better if we changed these to a valid FQDN http://tuscany.apache.org/xmlns/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-437) StAX loader framework cannot handle xsi:type
[
https://issues.apache.org/jira/browse/TUSCANY-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-437:
---
Affects Version/s: Java-M3
Added M3 to the list of affected versions.
StAX loader framework cannot handle xsi:type
--
Key: TUSCANY-437
URL: https://issues.apache.org/jira/browse/TUSCANY-437
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2, Java-M3, Java-Mx
Reporter: Raymond Feng
Assigned To: Raymond Feng
Fix For: Java-Mx
The current StAX loader registration is against the QName of the element. It
cannot handle the xsi:type variant.
For example, if I change the sca.module for Helloworld to use the
xsi:type (which is legal against the SCA xsd).
module xmlns=http://www.osoa.org/xmlns/sca/0.9;
xmlns:v=http://www.osoa.org/xmlns/sca/values/0.9;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
name=helloworld
component name=HelloWorldServiceComponent
!--
implementation.java class=helloworld.HelloWorldImpl/
--
implementation xsi:type=JavaImplementation
class=helloworld.HelloWorldImpl/
/component
/module
I'm getting the following exception:
Exception in thread main
org.apache.tuscany.core.config.ConfigurationLoadException: Unrecognized
element [{http://www.osoa.org/xmlns/sca/0.9}implementation]
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:62)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:76)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.loader.assembly.CompositeLoader.loadComposite(CompositeLoader.java:43)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:41)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoaderImpl.loadModule(StAXModuleComponentConfigurationLoaderImpl.java:51)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:142)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67)
at helloworld.HelloWorldClient.main(HelloWorldClient.java:32)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-197) Fix Java5 warnings with references to un-parameterized ComponentT
[ https://issues.apache.org/jira/browse/TUSCANY-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-197. Resolution: Fixed Fix Version/s: (was: Java-Mx) Java-M3 Resolved, I am not seeing these warnings anymore. Fix Java5 warnings with references to un-parameterized ComponentT --- Key: TUSCANY-197 URL: https://issues.apache.org/jira/browse/TUSCANY-197 Project: Tuscany Issue Type: Sub-task Components: Java SCA Model Affects Versions: Java-Mx Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-M3 We need to fix the Java5 compiler warnings caused by references to un-parameterized ComponentT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-994) validation on override
[ https://issues.apache.org/jira/browse/TUSCANY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465052 ] Raymond Feng commented on TUSCANY-994: -- Can you either attach a test case or point to a test case in the Tuscany itest suite? Thanks, Raymond validation on override -- Key: TUSCANY-994 URL: https://issues.apache.org/jira/browse/TUSCANY-994 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Environment: windows XP Reporter: Yang Lei Assigned To: Raymond Feng 1.service : override=must , I can still define a using composite without defining a composite level service wire to the embedded component(composite implementation)'s serive override=no, I can still define a using composite with defining a composite level service wire to the embedded component(composite implementation) 's service 2. reference: override=no, I can still define in using composite the component(composite implementation) 's reference wired to a new service value -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-687) Add tuscany- as the prefix for our artifact ids
[ https://issues.apache.org/jira/browse/TUSCANY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465055 ] Jean-Sebastien Delfino commented on TUSCANY-687: Is this still valid? it actually looks like it went the other way around, looking at the M2 repository I can see old tuscany-core-*.jar and newer core-*.jar. Ant, could you please indicate if this issue is still valid? Thanks. Add tuscany- as the prefix for our artifact ids - Key: TUSCANY-687 URL: https://issues.apache.org/jira/browse/TUSCANY-687 Project: Tuscany Issue Type: Improvement Components: Build System Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Fix For: Java-M3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-294) Document the assembly model
[ https://issues.apache.org/jira/browse/TUSCANY-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-294. Resolution: Fixed This is obsolete. The Tuscany Java runtime does not have much of a model anymore, except for plain beans that are used to load the XML contentof SCDL files. Document the assembly model --- Key: TUSCANY-294 URL: https://issues.apache.org/jira/browse/TUSCANY-294 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Jean-Sebastien Delfino Fix For: Java-M3 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Sebastien has volunteered to do this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-871) Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed.
[ https://issues.apache.org/jira/browse/TUSCANY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-871: --- Component/s: Java SCA Core Assigning to the correct component Sharing of common utilitiy classes between extensions and extensions and application breaks if classloader isolation is followed. -- Key: TUSCANY-871 URL: https://issues.apache.org/jira/browse/TUSCANY-871 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M3 Reporter: Rick Rineholt Assigned To: Raymond Feng Priority: Critical Fix For: Java-M3 The current model tries to isolate each extension and the application to their own classloader. This works ok until there is a need to share objects between them. At this point these object's classs are each loaded by seperate classloaders. Classes loaded this way don't work well. For example, a class creating an instance by one classloader in an extension and then passed to an application that has the same class loaded by another class loader will see a classcast exception when an attempt is made to set a reference to the passed in object. Currently an example of this happens with databinding framework when using SDOs. The application creates SDOs loaded by its classloader. When the SDO object is sent on the wire the databinding framework intercepts to attempt to convert SDO to axiom for a webservice interface. But SDO classes in the SDO databinding framework are loaded via another classloader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1053: Priority: Major (was: Minor) Changing priority to major as it affects the programming model, samples, and many test cases. Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M3 Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-925) Complex properties not supported
[ https://issues.apache.org/jira/browse/TUSCANY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-925: -- Assignee: Venkatakrishnan Venkat, assigning to you to reflect your lsat comment, indicating that you're working on it. Complex properties not supported Key: TUSCANY-925 URL: https://issues.apache.org/jira/browse/TUSCANY-925 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Brent Daniel Assigned To: Venkatakrishnan This may be intented to be covered in TUSCANY-773, but it was not clear to me. Complex properties are currently not supported by the tuscany runtime. Caused by: java.lang.IllegalArgumentException: Complex property is not supported. at org.apache.tuscany.core.property.SimplePropertyObjectFactory.getInstance(SimplePropertyObjectFactory.java:56) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-909) Current Tuscany driver Spec API inconsistence with Spec 0.95
[ https://issues.apache.org/jira/browse/TUSCANY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-909. Resolution: Fixed Fixed, see associated Subversion commits Current Tuscany driver Spec API inconsistence with Spec 0.95 - Key: TUSCANY-909 URL: https://issues.apache.org/jira/browse/TUSCANY-909 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: WIndows XP Reporter: Yang Lei Assigned To: Jean-Sebastien Delfino Attachments: TUSCANY-909.patch 1.API(annotation) differences between the current driver and 0.95 spec CompositeContext: 0.95 Spec v.s. current Tuscany driver (incubator-M2) getName -- getCompositeName getURI -- getCompositeURI getMetaData -- none Annotation difference: there is no annotation @ComponentMetadata. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-999) No release notes in Tuscany Java SCA binary distribution
[ https://issues.apache.org/jira/browse/TUSCANY-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-999: --- Fix Version/s: Java-M3 Affects Version/s: (was: Java-Mx) Java-M3 Java-M2 Targeting to the next milestone, as this was identified on M2 and release notes are important. No release notes in Tuscany Java SCA binary distribution Key: TUSCANY-999 URL: https://issues.apache.org/jira/browse/TUSCANY-999 Project: Tuscany Issue Type: Improvement Components: Java SCA Common Affects Versions: Java-M2, Java-M3 Environment: all Reporter: Simon Nash Priority: Minor Fix For: Java-M3 Robert Burrell Donkin made the following comment on the Tuscany Java SCA M2 release: i couldn't see any obvious release notes. release notes are important guerilla advertising for open source projects. the same content can be used on the download page, grassroots media (freshmeat.org, for example), in announcements and (of course) in plain text in the root directory of the release. This information does exist but appears to be misplaced. There is a readme.html file in the samples distribution with information on what is in this release and what has changed since the previous milestone release. For future releases, it would be good to include release notes in the binary distribution with this information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
