Re: It seems a problem inside our json support module
Thanks for respond: Yes, it is trunk code. Detail is: 1. testcase inside demos/alert-aggregator-webapp runs into a error. 2. error came out from JSON2XMLStreamReader, when it initiate an org.codehaus.jettison.badgerfish.BadgerFishXMLStreamReader (I checked its doc, there is a little missmatch of data structure) 3. I noticed there are necessity to transform JSONObject into pojo, but I did not see the chain from XMLStreamReader into a pojo. (If you run the test successful inside this demo, just let me know) Luciano Resende [EMAIL PROTECTED] wrote: Please provide more information about the issue you are seeing... There has been some issues found recently, that are being fixed and/or discussed. Also, I'm assuming you are using trunk code, is this correct ? On Nov 18, 2007 10:26 PM, shaoguang geng wrote: Hi, developers: I am not farmilar with JSON before, but I 'm learing it recently, since it has became a import wep applicatioin standard now. I check binding-json and databinding-json, they all seems good. But a problem came out from alert-aggregator-webapp when JSON2XMLStreamReader transform JSONObject. I checked specs on http://badgerfish.ning.com/, it seems our input data structure as a little problem. I 'm looking for a work around inside the tuscany's code, but if any one knows how, please give me a clue. - Get easy, one-click access to your favorites. Make Yahoo! your homepage. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
On Nov 19, 2007 9:22 AM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant Welcome Rajini, It's well deserved. Simon
Re: Sample dependencies not pulled in distribution
On Nov 17, 2007 6:18 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip I think that there are two types of sample dependencies: A) samples/store uses implementation-data; implementation-data can technically run with other databases, but we've selected derby as our preferred database; derby.jar needs to be on the classpath of the sample for it to run. B) a theoretical example, samples/store uses the Apache batik toolkit to generate an SVG logo for the store UI, because it's cool; no-other Tuscany module has that dependency. My opinion: (A) - derby.jar should be in the distro/lib, implementation-data should have derby as a runtime dependency. (B) - simplify samples/store, a technology sample should get to the point without extra dependency JARs, and if they really can't be avoided they should be in the sample's directory. Those both sound right to me. ...ant
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 18, 2007 9:31 PM, Simon Nash [EMAIL PROTECTED] wrote: I'm starting a new thread for this as suggested by Sebastien. Simon Simon Laws wrote: On Nov 15, 2007 6:54 PM, Simon Nash [EMAIL PROTECTED] wrote: (cut) I don't think we should put sample dependencies in the bin distro lib folder. If we need to include them in the bin distro (and I'm not 100% convinced about that), then I think they should go in some other directory. An alternative approach would be to have a samples distro that contains the samples plus dependencies that are only used by the samples and not by the main runtime. I think this is better as it allows us to add more samples without pushing up the size of the main binary distro. Personally I like to see samples with whatever I download and I'd rather have a bigger binary distro than a separate download. If there is a real need to reduce the distribution size can we do it in a different way, for example, have groups of extensions (and their samples) distributed separately? Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. 2. Tuscany samples source, READMEs and build files in samples. 3. Tuscany samples binaries in modules/samples, with their dependencies in lib/samples. By doing this we solve the conflict problems and it becomes a distro size issue to decide whether 3 should be in the main binary distro or available separately. Since 3 will be clearly separated from 1 and 2, it will be easy to see how much extra size it is contributing. The other dimension of splitting the distro by functional contents is orthogonal to the above and is also worth exploring. I'd suggest the following distro packages: 1. Base runtime with functional capabilities that almost everyone will want to use, and associated samples. 2. A number of extension bundles (either depending only on the base, or possibly depending on other bundles), and associated samples. If people think this approach makes sense then we could talk about what the base distro and extension bundles should contain. Simon I think we should try to get to where the samples are just simple sca contribution jars - just the .composite files and whatever resources, Java classes or BPEL or Javascript files etc that the sample uses. All the dependency jars Tuscany uses to support running that - Ode, Axis2, Rhino and BSF etc and all the various Tuscany module jars - are a Tuscany implementation detail and the samples should be free from any reference to those. If we can do this then the sample build scripts become simple and the samples are tiny so there's no size problem at all with including them in a distribution. ...ant
[jira] Updated: (TUSCANY-1911) Amazon Cart for Tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1911: --- Fix Version/s: Java-SCA-Next Amazon Cart for Tutorial Key: TUSCANY-1911 URL: https://issues.apache.org/jira/browse/TUSCANY-1911 Project: Tuscany Issue Type: Improvement Components: Java SCA Samples Reporter: Mario Antollini Priority: Minor Fix For: Java-SCA-Next Attachments: tutorial-amazon.zip I am attaching the amazon components for the tutorial. It is composed of two folders which must be located under the tutorial folder. I could not test the amazon-cart project since I was not able to run the testcase. Therefore I am not sure it works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1907) Dynamic Wiring: Adding a new component to a contribution
[ https://issues.apache.org/jira/browse/TUSCANY-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1907: --- Fix Version/s: Java-SCA-Next Dynamic Wiring: Adding a new component to a contribution - Key: TUSCANY-1907 URL: https://issues.apache.org/jira/browse/TUSCANY-1907 Project: Tuscany Issue Type: New Feature Reporter: Giorgio Zoppi Fix For: Java-SCA-Next Attachments: editedpatch.txt, mypatch.txt My second patch is a working patch. Now with this patch you're able to add a new component to a composition in a contribution. I provided a new component processor in artifacts' processor registry and modified parts of ConfigureBuilderImpl, WireBuilderImpl to adapt to a single component. I still modified ActivatorComponentImpl for the same reason. So you can inside a SCANodeImpl configure and start a new component, subclassing a MetaComponent interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1785) INSTALL file still refers to the 0.91 July release
[ https://issues.apache.org/jira/browse/TUSCANY-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1785. -- Resolution: Fixed fixed INSTALL file still refers to the 0.91 July release -- Key: TUSCANY-1785 URL: https://issues.apache.org/jira/browse/TUSCANY-1785 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Environment: All Reporter: Simon Nash Priority: Minor Fix For: Java-SCA-1.0.1 The file java/sca/distribution/src/main/release/bin/INSTALL still refers to the 0.91 release with a date of July 2007. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1782) Minor issues with RELEASE_NOTES file
[ https://issues.apache.org/jira/browse/TUSCANY-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1782. -- Resolution: Fixed fixed Minor issues with RELEASE_NOTES file Key: TUSCANY-1782 URL: https://issues.apache.org/jira/browse/TUSCANY-1782 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Environment: All Reporter: Simon Nash Priority: Minor Fix For: Java-SCA-1.0.1 A few small changes are needed to the RELEASE_NOTES file in the binary distribution. 1. BPEL is in the first list of specs that are implemented in 1.0. It is also in the next list of things that are implemented but not part of the specs. It should be removed from the second list. 2. Databindings for SDO and JAXB are mentioned (briefly) in the SCA specs, so these shouldn't be included in the list of features not yet defined by the SCA specs. For these we need another category of things that are mentioned in the specs as optiional features. 3. Fix typo in line 44: Wepapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
ant elder [EMAIL PROTECTED] writes: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant Congratulations Rajini and welcome on board. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
Sebastien, There's the basis of a Java interface to SDO generator at [1] but it hasn't been developed to a working state and hasn't been looked since the initial drop of code into Tuscany. It would be great to get this or similar function up and running. If you take a look at the noInterfaces test [2] of the toolsTest project you'll see that we don't need interfaces, we can use classes. I think in the scenario that you paint it's just abut possible you may just about be able to get away without a factory. As evidence I changes the referenced sample [2] to have //com.example.noInterfaces.simple.Quote quote = //(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class); com.example.noInterfaces.simple.Quote quote = new Quote(); and the test passed. But this wouldn't be acceptable in general. The major showstopper that occurs to me instantly is having a Type that has a Property of a generated Type. so the call to myComplexType.createDataObject(myPropertyOfGeneratedType); must have a means to create a child DataObject using the generated class rather than the generic DataObject. It does this by maintaining an association with the Type of the Property and the associated Factory. Regards, Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/Interface2JavaGenerator.java [2] http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/tools-test/src/test/java/org/apache/tuscany/sdo/test/GenPatternsTestCase.java?view=markup On 17/11/2007, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java Thanks. Follow-up questions: - Is there an SDO Helper that can introspect my handwritten Item Java class and drive the calls to the TypeHelper APIs? If not, can I add one? - I see that I can associate a class with a type, does it have to be an interface or can it be a class? - If it can be a class do I really need a factory class or is the SDO runtime able to instantiate the class? - I see methods like getStaticType on generated SDOs, do I need to implement that method in my handwritten SDO and why? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Congratulations and Welcome! :) - Venkat On Nov 19, 2007 2:52 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant
Re: How to write a simple SDO class for the tutorial?
I missed you last point in my reply. getStaticType() is required to underpin fundamental EMF behaviour. Without it EMF's capacity to know the class of an EObject (which all our DataObjects are derived from) is broken for all static classes, and that would break many SDO behaviours, e.g. serialization, copying, and I'm sure lots more. Kelvin. On 17/11/2007, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample.java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring.java [5] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java Thanks. Follow-up questions: - Is there an SDO Helper that can introspect my handwritten Item Java class and drive the calls to the TypeHelper APIs? If not, can I add one? - I see that I can associate a class with a type, does it have to be an interface or can it be a class? - If it can be a class do I really need a factory class or is the SDO runtime able to instantiate the class? - I see methods like getStaticType on generated SDOs, do I need to implement that method in my handwritten SDO and why? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URLs in servlet containers was: Starting a domain manager on a url including a path?
On Nov 19, 2007 10:22 AM, Simon Laws [EMAIL PROTECTED] wrote: I've just committed changes to the Jetty and Tomcat host containers. (r596243 and r596246) to ensure that URLs are formed correctly when context is included in the Node URI, e.g. http://localhost:8080/somecontext is combined with mycomponent/myservice to give http://localhost:8080/somecontext/mycomponent/myservice Tomcat was working OK in most circumstances but the original changes to jetty meant it was exposing services as http://localhost:8080/somecontext/somecontext/mycomponent/myservice I've reverted the original changes so that the context is not set on the server but is added to the servlet path in getURLMapping(String) as it needs to be set back into the binding uri. If we want to set the context to the server we will have tomake more changes so that the binding can manipulate the complete URL and not get it confused with the context when the servlet is registered. After this the calculator-distributed sample no longer works for me nor Tomcat using nodes with paths in the urls. Whats the reasons we can't get Jetty to work with the context path on the http server? I'm wondering if that might be easier, it also has to be the way the webapp host works as we can't change the context path of the webapp, but i don't want to go off looking at this if you've already tried it and hit blocking issues? ...ant
Re: URLs in servlet containers was: Starting a domain manager on a url including a path?
On Nov 19, 2007 11:29 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 19, 2007 10:22 AM, Simon Laws [EMAIL PROTECTED] wrote: I've just committed changes to the Jetty and Tomcat host containers. (r596243 and r596246) to ensure that URLs are formed correctly when context is included in the Node URI, e.g. http://localhost:8080/somecontext is combined with mycomponent/myservice to give http://localhost:8080/somecontext/mycomponent/myservice Tomcat was working OK in most circumstances but the original changes to jetty meant it was exposing services as http://localhost:8080/somecontext/somecontext/mycomponent/myservice I've reverted the original changes so that the context is not set on the server but is added to the servlet path in getURLMapping(String) as it needs to be set back into the binding uri. If we want to set the context to the server we will have tomake more changes so that the binding can manipulate the complete URL and not get it confused with the context when the servlet is registered. After this the calculator-distributed sample no longer works for me nor Tomcat using nodes with paths in the urls. Whats the reasons we can't get Jetty to work with the context path on the http server? I'm wondering if that might be easier, it also has to be the way the webapp host works as we can't change the context path of the webapp, but i don't want to go off looking at this if you've already tried it and hit blocking issues? ...ant I'm seeing the calculator-distributed issue too. I've not hit a blocking issue. To make contexts work as intended we need to be a bit smarter at the way the URL is resolved as we need to resolve the URL provided by the servler with the default URL that the server now has. If you want to look into that that would be great as I haven't got back to it yet. Simon
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Thank you all. I look forward to working with all of you. I would also like to thank everyone for integrating my patches over the last few months. Thank you... Regards, Rajini On 11/19/07, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Rajini, Thanks for your excellent contributions. This is very well deserved. Congratulations and welcome! Simon Rajini Sivaram wrote: Thank you all. I look forward to working with all of you. I would also like to thank everyone for integrating my patches over the last few months. Thank you... Regards, Rajini On 11/19/07, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URLs in servlet containers was: Starting a domain manager on a url including a path?
On Nov 19, 2007 11:44 AM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 19, 2007 11:29 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 19, 2007 10:22 AM, Simon Laws [EMAIL PROTECTED] wrote: I've just committed changes to the Jetty and Tomcat host containers. (r596243 and r596246) to ensure that URLs are formed correctly when context is included in the Node URI, e.g. http://localhost:8080/somecontext is combined with mycomponent/myservice to give http://localhost:8080/somecontext/mycomponent/myservice Tomcat was working OK in most circumstances but the original changes to jetty meant it was exposing services as http://localhost:8080/somecontext/somecontext/mycomponent/myservice I've reverted the original changes so that the context is not set on the server but is added to the servlet path in getURLMapping(String) as it needs to be set back into the binding uri. If we want to set the context to the server we will have tomake more changes so that the binding can manipulate the complete URL and not get it confused with the context when the servlet is registered. After this the calculator-distributed sample no longer works for me nor Tomcat using nodes with paths in the urls. Whats the reasons we can't get Jetty to work with the context path on the http server? I'm wondering if that might be easier, it also has to be the way the webapp host works as we can't change the context path of the webapp, but i don't want to go off looking at this if you've already tried it and hit blocking issues? ...ant I'm seeing the calculator-distributed issue too. I've not hit a blocking issue. To make contexts work as intended we need to be a bit smarter at the way the URL is resolved as we need to resolve the URL provided by the servler with the default URL that the server now has. If you want to look into that that would be great as I haven't got back to it yet. Simon I have a fix for the calculator-distributed problem. It's unrelated to the jetty problem and it to do with accidentally having loaded a composite twice. Need a test to prevent that. Just doing a full build now. Simon Simon
Re: Intermittent build failure in node-impl
I noticed that today's continuum build failed in node-impl. The error looks similar to this but not identical. It would be good to resolve this so that the continuum build works. As a temporary workaround, perhaps we could comment out the failing test case. Simon Simon Laws wrote: On Nov 18, 2007 7:16 PM, Simon Nash [EMAIL PROTECTED] wrote: When doing a top-level build of modules today from a fairly recent checkout of trunk, I got two errors in the node-impl tests. Rerunning the build of this module from its own directory was successful. Any ideas? My stack trace output is below. Simon --- T E S T S --- Running org.apache.tuscany.sca.node.impl.DomainDrivenTestCase Setting up domain 18-Nov-2007 15:48:18 org.apache.tuscany.sca.domain.impl.SCADomainImpl init INFO: Domain management configured from file:/H:/tuscany55/sca/modules/domain-im pl/target/tuscany-domain-impl-1.1-incubating-SNAPSHOT.jar 18-Nov-2007 15:48:23 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 18-Nov-2007 15:48:24 org.apache.catalina.startup.ContextConfigdefaultWebConfig INFO: No default web.xml 18-Nov-2007 15:48:24 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http- 18-Nov-2007 15:48:24 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http- 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/domain/* 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agerNodeEventService 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agementService/* 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agementService 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/SCADomain/scaDomain.js Setting up calculator nodes 18-Nov-2007 15:48:25 org.apache.tuscany.sca.domain.impl.SCADomainImplremoveNode INFO: Removed node: http://localhost:8100/nodeA 18-Nov-2007 15:48:25 org.apache.tuscany.sca.domain.impl.SCADomainImpladdNode INFO: Registered node: http://localhost:8100/nodeA at endpoint http://localhost: 8100/nodeA 18-Nov-2007 15:48:25 org.apache.tuscany.sca.node.impl.SCADomainProxyImplstart INFO: Domain management configured from file:/H:/tuscany55/sca/modules/node-impl /target/classes/ 18-Nov-2007 15:48:26 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterSe rviceEndpoint INFO: Registered service: DomainManagerComponent 18-Nov-2007 15:48:26 org.apache.tuscany.sca.binding.sca.axis2.impl.Axis2SCAServi ceBindingProvider init WARNING: Unable to register service: http://localhost: http://localhost:810 0/nodeA DomainManagerComponent org.apache.tuscany.sca.assembly.SCABindinghttp:/ /EUREKA:8100/DomainManagerComponent org.apache.tuscany.sca.node.NodeException: org.apache.tuscany.sca.domain.DomainE xception: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.Ru ntimeException: org.apache.axis2.AxisFault: The module.xml file cannot be found for the module: jar:file:/H:/tuscany55/sca/modules/binding-ws-axis2/target/tusca ny-binding-ws-axis2-1.1-incubating-SNAPSHOT.jar!/org/apache/tuscany/sca/binding/ ws/axis2/engine/config/modules/rampart-1.3.mar Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.973 sec FA ILURE! testCalculator(org.apache.tuscany.sca.node.impl.DomainDrivenTestCase) Time elap sed: 0.01 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.testCalculator( DomainDrivenTestCase.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody (TestMet hodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected (TestMethod Runner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected (BeforeAn dAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod (TestMethodRunne r.java:75) at org.junit.internal.runners.TestMethodRunner.run( TestMethodRunner.java :45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(Te stClassMethodsRunner.java:75) at
Re: Intermittent build failure in node-impl
On Nov 19, 2007 12:10 PM, Simon Nash [EMAIL PROTECTED] wrote: I noticed that today's continuum build failed in node-impl. The error looks similar to this but not identical. It would be good to resolve this so that the continuum build works. As a temporary workaround, perhaps we could comment out the failing test case. Simon Simon Laws wrote: On Nov 18, 2007 7:16 PM, Simon Nash [EMAIL PROTECTED] wrote: When doing a top-level build of modules today from a fairly recent checkout of trunk, I got two errors in the node-impl tests. Rerunning the build of this module from its own directory was successful. Any ideas? My stack trace output is below. Simon --- T E S T S --- Running org.apache.tuscany.sca.node.impl.DomainDrivenTestCase Setting up domain 18-Nov-2007 15:48:18 org.apache.tuscany.sca.domain.impl.SCADomainImplinit INFO: Domain management configured from file:/H:/tuscany55/sca/modules/domain-im pl/target/tuscany-domain-impl-1.1-incubating-SNAPSHOT.jar 18-Nov-2007 15:48:23 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 18-Nov-2007 15:48:24 org.apache.catalina.startup.ContextConfigdefaultWebConfig INFO: No default web.xml 18-Nov-2007 15:48:24 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http- 18-Nov-2007 15:48:24 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http- 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/domain/* 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agerNodeEventService 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agementService/* 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/DomainManagerComponent/DomainMan agementService 18-Nov-2007 15:48:25 org.apache.tuscany.sca.http.tomcat.TomcatServeraddServletM apping INFO: Added Servlet mapping: http://EUREKA:/SCADomain/scaDomain.js Setting up calculator nodes 18-Nov-2007 15:48:25 org.apache.tuscany.sca.domain.impl.SCADomainImplremoveNode INFO: Removed node: http://localhost:8100/nodeA 18-Nov-2007 15:48:25 org.apache.tuscany.sca.domain.impl.SCADomainImpladdNode INFO: Registered node: http://localhost:8100/nodeA at endpoint http://localhost: 8100/nodeA 18-Nov-2007 15:48:25 org.apache.tuscany.sca.node.impl.SCADomainProxyImplstart INFO: Domain management configured from file:/H:/tuscany55/sca/modules/node-impl /target/classes/ 18-Nov-2007 15:48:26 org.apache.tuscany.sca.domain.impl.SCADomainImplregisterSe rviceEndpoint INFO: Registered service: DomainManagerComponent 18-Nov-2007 15:48:26 org.apache.tuscany.sca.binding.sca.axis2.impl.Axis2SCAServi ceBindingProvider init WARNING: Unable to register service: http://localhost: http://localhost:810 0/nodeA DomainManagerComponent org.apache.tuscany.sca.assembly.SCABindinghttp:/ /EUREKA:8100/DomainManagerComponent org.apache.tuscany.sca.node.NodeException: org.apache.tuscany.sca.domain.DomainE xception: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.Ru ntimeException: org.apache.axis2.AxisFault: The module.xml file cannot be found for the module: jar:file:/H:/tuscany55/sca/modules/binding-ws-axis2/target/tusca ny-binding-ws-axis2-1.1-incubating-SNAPSHOT.jar!/org/apache/tuscany/sca/binding/ ws/axis2/engine/config/modules/rampart-1.3.mar Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.973sec FA ILURE! testCalculator(org.apache.tuscany.sca.node.impl.DomainDrivenTestCase) Time elap sed: 0.01 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.testCalculator( DomainDrivenTestCase.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody (TestMet hodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected (TestMethod Runner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected (BeforeAn dAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod (TestMethodRunne r.java:75) at
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Congratulations and welcome Rajini! -Amita On Nov 19, 2007 2:52 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1912) Promoted reference with binding.ws and callback causes null pointer
Promoted reference with binding.ws and callback causes null pointer --- Key: TUSCANY-1912 URL: https://issues.apache.org/jira/browse/TUSCANY-1912 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: All Reporter: Simon Laws Fix For: Java-SCA-Next In a binding.ws where client and server are running out of separate composites changing the client composite from component name=MyClientComponent implementation.java class=simplecallback.MyClientImpl / reference name=myService interface.java interface=simplecallback.MyService callbackInterface=simplecallback.MyServiceCallback / binding.ws wsdlElement=http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort) / callback binding.ws wsdlElement= http://simplecallback#wsdl.port(MyServiceCallbackSoapService/MyServiceCallbackSoapPort) / /callback /reference /component to component name=MyClientComponent implementation.java class=simplecallback.MyClientImpl / reference name=myService/ /component reference name=MyService promote=MyClientComponent/myService interface.java interface=simplecallback.MyService callbackInterface=simplecallback.MyServiceCallback / binding.ws wsdlElement=http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort) / callback binding.ws wsdlElement=http://simplecallback#wsdl.port(MyServiceCallbackSoapService/MyServiceCallbackSoapPort) / /callback /reference I.e, I've turned the component reference into a promoted reference. Causes java.lang.NullPointerException at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.createOpe rationClient(Axis2BindingInvoker.java:152) at org.apache.tuscany.sca.binding.ws.axis2.Axis2OneWayBindingInvoker.inv okeTarget(Axis2OneWayBindingInvoker.java :45) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Ax is2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterc eptor.invoke(DataTransformationInterceptor.java :74) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java:233) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java :130) at $Proxy7.someMethod(Unknown Source) at simplecallback.MyClientImpl.aClientMethod(MyClientImpl.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Congrats and welcome Rajini! On Nov 19, 2007 4:22 AM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1913) host-tomcat fails to find servlet if it is added, removed and then added again.
host-tomcat fails to find servlet if it is added, removed and then added again.
---
Key: TUSCANY-1913
URL: https://issues.apache.org/jira/browse/TUSCANY-1913
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.0
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-Next
Extending the Tomcat unit test with the following
public void testRegisterUnregisterMapping() throws Exception {
TomcatServer service = new TomcatServer(workScheduler);
TestServlet servlet = new TestServlet();
service.addServletMapping(http://127.0.0.1:; + HTTP_PORT + /foo,
servlet);
{
Socket client = new Socket(127.0.0.1, HTTP_PORT);
OutputStream os = client.getOutputStream();
os.write(REQUEST1.getBytes());
os.flush();
read(client);
}
assertTrue(servlet.invoked);
service.removeServletMapping(http://127.0.0.1:; + HTTP_PORT + /foo);
{
Socket client = new Socket(127.0.0.1, HTTP_PORT);
OutputStream os = client.getOutputStream();
os.write(REQUEST1.getBytes());
os.flush();
read(client);
}
servlet = new TestServlet();
service.addServletMapping(http://127.0.0.1:; + HTTP_PORT + /foo,
servlet);
{
Socket client = new Socket(127.0.0.1, HTTP_PORT);
OutputStream os = client.getOutputStream();
os.write(REQUEST1.getBytes());
os.flush();
read(client);
}
assertTrue(servlet.invoked);
service.stop();
}
Leads to
INFO: Added Servlet mapping: http://L3AW203:8085/foo
19-Nov-2007 14:37:20 org.apache.tuscany.sca.http.tomcat.TomcatServer
removeServletMapping
INFO: Remove Servlet mapping: /foo
19-Nov-2007 14:37:31 org.apache.catalina.core.StandardWrapperValve invoke
INFO: Servlet /foo is currently unavailable
19-Nov-2007 14:37:40 org.apache.tuscany.sca.http.tomcat.TomcatServer
addServletMapping
INFO: Added Servlet mapping: http://L3AW203:8085/foo
19-Nov-2007 14:37:49 org.apache.catalina.core.StandardWrapperValve invoke
INFO: Servlet /foo is currently unavailable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r595217 - /incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
On Nov 17, 2007 5:49 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip I was only considering the first composite as I still think that a node should only run a single composite :) Ok, any helpful suggestions on the discussion in [1] relating to problems starting a domain and multiple nodes in the same webapp/Tomcat/Geronimo instance? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200711.mbox/[EMAIL PROTECTED]
Re: svn commit: r595217 - /incubator/tuscany/java/sca/modules/node-impl/src/main/java/org/apache/tuscany/sca/node/impl/SCANodeImpl.java
On Nov 19, 2007 2:49 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 17, 2007 5:49 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip I was only considering the first composite as I still think that a node should only run a single composite :) Ok, any helpful suggestions on the discussion in [1] relating to problems starting a domain and multiple nodes in the same webapp/Tomcat/Geronimo instance? ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200711.mbox/[EMAIL PROTECTED] Ant I've been thinking about this a little so I'll reply on the original thread. On the subject of this thread... I understand what you are trying to do now. Thanks for the explanation. I still think it feels a little odd that is takes a port number from one of the bindings. If you haven't specified a uri in a binding then I guess you don't care what port number you get. So choosing a port number from a binding doesn't do any harm and is slightly more efficient in terms of port resources then using the default port number that the node invents when no node url is provided. Just justifying it to myself ;-) Simon
Re: Starting a domain manager on a url including a path?
On Nov 16, 2007 12:06 PM, Simon Laws [EMAIL PROTECTED] wrote:
On Nov 16, 2007 11:59 AM, ant elder [EMAIL PROTECTED] wrote:
On Nov 16, 2007 11:25 AM, Simon Laws [EMAIL PROTECTED] wrote:
On Nov 16, 2007 10:58 AM, ant elder [EMAIL PROTECTED] wrote:
On Nov 13, 2007 4:25 PM, Simon Laws [EMAIL PROTECTED]
wrote:
On Nov 13, 2007 4:06 PM, ant elder [EMAIL PROTECTED] wrote:
Trying to run a domain manager node within a webapp and it fails
as
right
now you can only use a domain manager url without a path, eg
http://localhost:8080 not
http://localhost:8080/tuscany/domainManager.
I'd
like to try to fix this so a path if supported if no one has any
objections,
also if there are any pointers to where in the node and domain
code this
is
handled that would be great too!
...ant
No objections from me. It's dealt with in three places..
SCADomainImpl.init() - sets up the domain runtime
SCANodeImpl.init() - sets up the node runtime
SCADomainProxy.start() - sets up a local runtime if no node is
provided
The code you are looking for is something like...
// Configure the default server port
int port = URI.create(domainModel.getDomainURI
()).getPort();
if (port != -1) {
ServletHostExtensionPoint servletHosts =
domainManagementRuntime.getExtensionPointRegistry().getExtensionPoint(
ServletHostExtensionPoint.class);
for (ServletHost servletHost:
servletHosts.getServletHosts
())
{
servletHost.setDefaultPort(port);
}
}
This is stripping the port out of the provided URL and putting it
into the
servlet host. I think we would need to change this interface to
allow the
whole base URL to be set on the servlet host.
External web app container - The web app container controls the
actual
endpoint and the NodeURL simply tells the tuscany runtime what
endpoints
to
register. It's seems awkward that we have to provide the URL here
but
there
doesn't appear to be an easy way round it.
Embedded web app container - The NodeURL should instruct the
embedded
container what base URL to use for services.
For the Node URL you must either provide a valid URL or nothing.
If
nothing
then one will be chosen for you.
For Domain URL (at the node) you must either provide the URL of
the domain
or nothing.If nothing then the node will run standalone.
Regards
Simon
This is working now for the standalone strawman testcase with both
the
domain and node running at a url including a path. There's a problem
though
with running it within the same webapp or same Tomcat container (and
probably the Tuscany Geronimo integration) in that the nodes try to
talk to
the domain when they're started but the domain doesn't accept
connections
until after the container is completely up and started, so the node
sends
the register request to the domain and hangs waiting for the domain
to
answer. Not sure whats the best way to get around this, anyone have
any good
ideas?
...ant
In trying to understand the problem here I see two scenarios.
- I want to run my webapp as a standalone SCA application in which
case I don't specify a domain URL and the node doesn't try to connect to
the
domain.
- I want to run my webapp as part of an SCA domain. The SCADomain
could include many nodes using different runtimes in different hosting
environments so I think we should expect that it is already available when
the webapp is started.
I accept that it's possible to start the domain manager within the
same webapp but I'm not sure why you would want to. I'm a little more
convinced by wanting to start the domain manager in the same Tomcat
container. Currently the domain and node SCA applications assume remote
connections between each other, hence the problem you are seeing. There
are
some solutions of increasing complexity...
- Advise users not to do it. It's very easy to start the domain using
the inbuilt HTTP server. In reality you are likely to want to deploy it
as a
Web App to some clustered app server so you need to be careful how this is
done w.r.t the nodes that are started.
- Change the binding used to wire nodes to the domain to be something
other than binding.ws that relies on HTTP
- Enhance the way that nodes register such that they try again when
other API operations are called if they were unsuccessful the first time.
Would fail altogether if it can't connect when you start() the node.
- Change the domain model
Re: How to write a simple SDO class for the tutorial?
Hi Sebastien, One thing to note is that the static SDO supported in Tuscany today is an EMF-style pattern that is intended to be the highest performance in-memory static DataObjects. Other less-performant patterns, that use a dynamic (DataObject) proxy, for example, are possible and probably easier achieve without a code generator. There are two features in the SDO 3 charter related to this topic: 1) standard SDO annotations on Java interfaces to define SDO metadata, and 2) unify static SDO with other static bindings like JAXB (this covers POJOs as well). If you want to experiment with some ideas in this area, that would be great. We could use it as input to the SDO 3 discussions when they start. Thanks, Frank. [EMAIL PROTECTED] wrote on 11/19/2007 05:53:25 AM: I missed you last point in my reply. getStaticType() is required to underpin fundamental EMF behaviour. Without it EMF's capacity to know the class of an EObject (which all our DataObjects are derived from) is broken for all static classes, and that would break many SDO behaviours, e.g. serialization, copying, and I'm sure lots more. Kelvin. On 17/11/2007, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: kelvin goodson wrote: If you are discounting using XSD for the source of metadata to describe the SDO types then there is the SDO API provided for dynamic metadata creation. The sample at [1] gives an introduction to this. The paper at [2] discusses the subject also, and the program underlying the discussion in the paper is at [3] (no change monitoring) and [4] (with change monitoring). You say that you want to write the minimum code. There is a quick and simple Tuscany API for simple cases that you could use instead (See the MetaDataBuilder inner class in [5]). Whilst the code to create the type system with this project specific API is simple to understand and implement it has some drawbacks. We don't have a sample program for this, but I believe the DAS uses it) I'm happy to discuss further if you want some more insight into this. Kelvin. [1] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/intermediate/DynamicCustomerTypeSample. java [2] http://java.sys-con.com/read/358059_2.htm [3] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario. java [4] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenarioWithChangeMonitoring. java [5] http://svn.apache. org/repos/asf/incubator/tuscany/java/sdo/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper. java Thanks. Follow-up questions: - Is there an SDO Helper that can introspect my handwritten Item Java class and drive the calls to the TypeHelper APIs? If not, can I add one? - I see that I can associate a class with a type, does it have to be an interface or can it be a class? - If it can be a class do I really need a factory class or is the SDO runtime able to instantiate the class? - I see methods like getStaticType on generated SDOs, do I need to implement that method in my handwritten SDO and why? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote: Sebastien, There's the basis of a Java interface to SDO generator at [1] but it hasn't been developed to a working state and hasn't been looked since the initial drop of code into Tuscany. It would be great to get this or similar function up and running. If you take a look at the noInterfaces test [2] of the toolsTest project you'll see that we don't need interfaces, we can use classes. I think in the scenario that you paint it's just abut possible you may just about be able to get away without a factory. As evidence I changes the referenced sample [2] to have //com.example.noInterfaces.simple.Quote quote = //(com.example.noInterfaces.simple.Quote)scope.getDataFactory().create(com.example.noInterfaces.simple.Quote.class); com.example.noInterfaces.simple.Quote quote = new Quote(); and the test passed. But this wouldn't be acceptable in general. The major showstopper that occurs to me instantly is having a Type that has a Property of a generated Type. so the call to myComplexType.createDataObject(myPropertyOfGeneratedType); must have a means to create a child DataObject using the generated class rather than the generic DataObject. It does this by maintaining an association with the Type of the Property and the associated Factory. If the Type already has an association with the corresponding class (and I think it does if the DataObject is represented by a class and not an interface) then again we would not need the factory, right? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1899) Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char?
[ https://issues.apache.org/jira/browse/TUSCANY-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1899: Component/s: (was: Java SDO Tools) In the SDO tools we do this is in generation of XML schemas from existing Properties and Types. We do have a method formGlobalElementName which does this lower casing of the first letter when generating a global element in the schema. The behaviour is due to the paragraph in section 10 of the SDO spec which says ... The global element for the type: • lowercase(TYPE.NAME) is the type name with the first letter converted to lower case as defined type java.lang.Character.toLowerCase() Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char? -- Key: TUSCANY-1899 URL: https://issues.apache.org/jira/browse/TUSCANY-1899 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1 Reporter: Scott Kurz Priority: Trivial Fix For: Java-SCA-Next The fact that: TuscanyWSDLTypesGenerator .createSchemaTypeForMethodPart on line 267 calls: globalElement.setName(formGlobalElementName(localPartName)); which lowercases the first char in the parm passed to formGlobalElementName ends up implying that method names must start in a lowercase char. Because otherwise..the elem name so constructed won't match the operation name... which will cause us to not end up with doc-lit-wrapped WSDL. Since everyone uses lowercase method names this in Java, I ranked this as 'trivial'. Still, I opened this anyway because I didn't see why we bother to lowercase this string at all, and thought that if someone cancelled this JIRA, at least I'd learn there was a good reason for doing so. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote:
I missed you last point in my reply. getStaticType() is required to
underpin fundamental EMF behaviour. Without it EMF's capacity to know
the class of an EObject (which all our DataObjects are derived from)
is broken for all static classes, and that would break many SDO
behaviours, e.g. serialization, copying, and I'm sure lots more.
Kelvin.
Assuming that my DataObjects are simple classes without interfaces,
isn't the type already registered with my DataObject's class?
In other words can I implement getStaticType generically as follows:
Type getStaticType() {
TypeHelper.INSTANCE.getType(this.getClass());
}
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Hi, Rajini. Congratulations and welcome. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Cc: [EMAIL PROTECTED] Sent: Monday, November 19, 2007 1:22 AM Subject: [NOTICE] Rajini Sivaram voted as Tuscany committer The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
Congratulations and Welcome! On Nov 19, 2007 5:38 AM, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Congrats and welcome Rajini! On Nov 19, 2007 4:22 AM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a simple SDO class for the tutorial?
Sebastien,
You're generic implementation is fine as long as TypeHelper.INSTANCE is
the right scope where the type is registered.
If you aren't interested in supporting dynamic subclasses of static
classes, then getStaticType() is always == DataObject.getType(), so you
might not even need to implement getStaticType().
Frank
Jean-Sebastien Delfino [EMAIL PROTECTED]
11/19/2007 11:25 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: How to write a simple SDO class for the tutorial?
kelvin goodson wrote:
I missed you last point in my reply. getStaticType() is required to
underpin fundamental EMF behaviour. Without it EMF's capacity to know
the class of an EObject (which all our DataObjects are derived from)
is broken for all static classes, and that would break many SDO
behaviours, e.g. serialization, copying, and I'm sure lots more.
Kelvin.
Assuming that my DataObjects are simple classes without interfaces,
isn't the type already registered with my DataObject's class?
In other words can I implement getStaticType generically as follows:
Type getStaticType() {
TypeHelper.INSTANCE.getType(this.getClass());
}
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Rajini Sivaram voted as Tuscany committer
ant elder wrote: The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a Tuscany committer. Congratulations and welcome Rajini! ...ant Welcome Rajini! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Databinding transformation generating different invocation message
Hi, I debugged the issue and found out there are two databinding intecerptors added to the invocation chain. The main issue here is that we insert databinding interceptors independently for the reference side and service side. In your case, the reference is defined as follows: component name=BPELHelloWorld implementation.java class=helloworld.HelloWorld/ reference name=helloService target=BPELHelloWorldService interface.wsdl interface=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl#wsdl.interface(HelloPortType) / /reference /component a) The introspected type is a java interface for reference helloService but it's configured in the component definition with a WSDL portType. Since the java interface is bare style while the wsdl is doc-lit-wrapped, we add an interceptor for the reference side. b) For the service wire, the target (bpel) service expects data for the wsdl portType. When we create an invoker for SCA binding, we set the source interface contract to the reference interface (which is a java interface). We add interceptor for the service side too. So one workaround is to remove the interface.wsdl for reference. Then no databinding interceptor will be added because the interface contract of the component is the same as the one of the component type. We need to bypass the interceptor for a) in case of the local optimization. We could fix that in SCAReferenceBindingProvider and SCAServiceBindingProvider.getBindingInterfaceContract() to return the interface contract on the component type. I verified both the workaround and fix work. You can use the workaround 1st and I'll check in the fix after I come back from vacation next week. Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Saturday, November 17, 2007 10:16 PM Subject: Databinding transformation generating different invocation message I have two components defined, A and B, and B has a Reference to A. If I make a call to A.foo, there is only one databinding transformation happening and I get the proper message on the implementation type invoker : ?xml version=1.0 encoding=UTF-8? messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;messageHello/message/hello/TestPart/message If I make a call to B.foo, it looks like the databinding transformation is happening twice, and the message reaching the implementation type invoker has wrong value : ?xml version=1.0 encoding=UTF-8? messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;message[hello: null]/message/hello/TestPart/message This can be reproduced by the two tests available in the iTest/bpel/helloworld project. I was expecting that both messages to be equal. Is my expectation right ? Any ideas or suggestions ? Any -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Databinding transformation generating different invocation message
Thanks Raymond, i have the workaround working locally... will just run a full build before i can commit. On Nov 19, 2007 2:43 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I debugged the issue and found out there are two databinding intecerptors added to the invocation chain. The main issue here is that we insert databinding interceptors independently for the reference side and service side. In your case, the reference is defined as follows: component name=BPELHelloWorld implementation.java class=helloworld.HelloWorld/ reference name=helloService target=BPELHelloWorldService interface.wsdl interface=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl#wsdl.interface(HelloPortType) / /reference /component a) The introspected type is a java interface for reference helloService but it's configured in the component definition with a WSDL portType. Since the java interface is bare style while the wsdl is doc-lit-wrapped, we add an interceptor for the reference side. b) For the service wire, the target (bpel) service expects data for the wsdl portType. When we create an invoker for SCA binding, we set the source interface contract to the reference interface (which is a java interface). We add interceptor for the service side too. So one workaround is to remove the interface.wsdl for reference. Then no databinding interceptor will be added because the interface contract of the component is the same as the one of the component type. We need to bypass the interceptor for a) in case of the local optimization. We could fix that in SCAReferenceBindingProvider and SCAServiceBindingProvider.getBindingInterfaceContract() to return the interface contract on the component type. I verified both the workaround and fix work. You can use the workaround 1st and I'll check in the fix after I come back from vacation next week. Thanks, Raymond - Original Message - From: Luciano Resende [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Saturday, November 17, 2007 10:16 PM Subject: Databinding transformation generating different invocation message I have two components defined, A and B, and B has a Reference to A. If I make a call to A.foo, there is only one databinding transformation happening and I get the proper message on the implementation type invoker : ?xml version=1.0 encoding=UTF-8? messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;messageHello/message/hello/TestPart/message If I make a call to B.foo, it looks like the databinding transformation is happening twice, and the message reaching the implementation type invoker has wrong value : ?xml version=1.0 encoding=UTF-8? messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;message[hello: null]/message/hello/TestPart/message This can be reproduced by the two tests available in the iTest/bpel/helloworld project. I was expecting that both messages to be equal. Is my expectation right ? Any ideas or suggestions ? Any -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1912) Promoted reference with binding.ws and callback causes null pointer
[ https://issues.apache.org/jira/browse/TUSCANY-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543738 ] Simon Nash commented on TUSCANY-1912: - The NullPointerException is caused by the name of the promoted composite reference (MyService) being different from the name of the component reference (myService). If the name of the promoted composite reference is changed to myService, I get a different failure: java.lang.reflect.UndeclaredThrowableException at $Proxy15.receiveResult(Unknown Source) at myserver.MyServiceImpl.someMethod(MyServiceImpl.java:50) 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.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:105) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:74) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:118) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:89) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:83) RuntimeException invoking receiveResult: java.lang.reflect.UndeclaredThrowableException at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWireImpl.java:127) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:567) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInMessageReceiver.invokeBusinessLogic(Axis2ServiceInMessageReceiver.java:48) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:352) at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61) at org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.axis2.AxisFault: The system cannot infer the transport information from the MyClientComponent URL. at org.apache.axis2.description.ClientUtils.inferOutTransport(ClientUtils.java:73) at org.apache.axis2.client.OperationClient.prepareMessageContext(OperationClient.java:302) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:174) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:100) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:74) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:249)
[jira] Assigned: (TUSCANY-1891) Delete operation in Impl.data module
[ https://issues.apache.org/jira/browse/TUSCANY-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1891: Assignee: Luciano Resende Delete operation in Impl.data module Key: TUSCANY-1891 URL: https://issues.apache.org/jira/browse/TUSCANY-1891 Project: Tuscany Issue Type: New Feature Components: Java SCA Java Implementation Extension Reporter: Douglas Siqueira Leite Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: tuscany1891_douglas_2007_11_05.patch -Add Delete operation in implementation.data SCA module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1891) Delete operation in Impl.data module
[ https://issues.apache.org/jira/browse/TUSCANY-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1891. -- Resolution: Fixed Patch applied. Thanks !!! Delete operation in Impl.data module Key: TUSCANY-1891 URL: https://issues.apache.org/jira/browse/TUSCANY-1891 Project: Tuscany Issue Type: New Feature Components: Java SCA Java Implementation Extension Reporter: Douglas Siqueira Leite Assignee: Luciano Resende Fix For: Java-SCA-Next Attachments: tuscany1891_douglas_2007_11_05.patch -Add Delete operation in implementation.data SCA module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1903) An implementation openjpa work with policy-transaction is almost done
[ https://issues.apache.org/jira/browse/TUSCANY-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gengshaoguang updated TUSCANY-1903: --- Attachment: next-intention-of-managed-resource.png Hi, developers. This graph illustrates my intention of a manageable resource. It means a boundary of a tranaction should be held by the JavaImplementationInvoker If transacitonal intent is marked, this class should use begin and commit before and after the invoke method (and rollback on any or specific Excepiton). As well, any other component referenced by a component will be managed by the same transaction (because only the top component goes through the invoker); I am looking forward to any suggestion from you. An implementation openjpa work with policy-transaction is almost done - Key: TUSCANY-1903 URL: https://issues.apache.org/jira/browse/TUSCANY-1903 Project: Tuscany Issue Type: Improvement Components: Java SCA Misc Implementation Extensions Affects Versions: Java-SCA-Next Environment: jdk1.6 svn trunk derby policy-transaction Reporter: gengshaoguang Fix For: Java-SCA-Next Attachments: diff.txt, implementation-openjpa-u.zip, implementation-openjpa.zip, next-intention-of-managed-resource.png Hello every one, I would like to contribute implementation-openjpa to Tuscany. This implementation has features like: EntityManager runtime implemented by Apache Openjpa and almost all good points provided by openjpa. Way of openjpa's working with JTA is changed by this module that not JNDI was nessary, and it now works with Tuscsany's policy-transaction. This contribution is not 100% done, there are places need improving. After implementation-hibernate, I wish this time I could have done a valuable thing here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1761) tuscany-maven-wsdl2java or wsdl2java doesn't define a plugin repo for java.net
[ https://issues.apache.org/jira/browse/TUSCANY-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1761. -- Resolution: Cannot Reproduce I don't see any issues while building. Please re-open if you still see the issue. tuscany-maven-wsdl2java or wsdl2java doesn't define a plugin repo for java.net -- Key: TUSCANY-1761 URL: https://issues.apache.org/jira/browse/TUSCANY-1761 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Reporter: Raymond Feng Fix For: Java-SCA-Next I see this from a top-down build. The tuscany-wsdl2java module defines the java.net repo as a runtime repo but not a plugin repo. In this case, the reference is from a plugin and it will fail. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.sun.xml.bind:jaxb-xjc:jar:2.1.4 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun.xml.bind -DartifactId=jaxb-xjc \ -Dversion=2.1.4 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.sun.xml.bind -DartifactId=jaxb-xjc \ -Dversion=2.1.4 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-maven-wsdl2java:maven-plugin:1.0-incub ating 2) org.apache.tuscany.sca:tuscany-wsdl2java:jar:1.0-incubating 3) com.sun.xml.bind:jaxb-xjc:jar:2.1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1903) An implementation openjpa work with policy-transaction is almost done
[ https://issues.apache.org/jira/browse/TUSCANY-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543751 ] Luciano Resende commented on TUSCANY-1903: -- I'd recommend starting a discussion thread on the dev-list, as it can catch the attention of a broader audience there... you could then point to the jira for the image or more details... An implementation openjpa work with policy-transaction is almost done - Key: TUSCANY-1903 URL: https://issues.apache.org/jira/browse/TUSCANY-1903 Project: Tuscany Issue Type: Improvement Components: Java SCA Misc Implementation Extensions Affects Versions: Java-SCA-Next Environment: jdk1.6 svn trunk derby policy-transaction Reporter: gengshaoguang Fix For: Java-SCA-Next Attachments: diff.txt, implementation-openjpa-u.zip, implementation-openjpa.zip, next-intention-of-managed-resource.png Hello every one, I would like to contribute implementation-openjpa to Tuscany. This implementation has features like: EntityManager runtime implemented by Apache Openjpa and almost all good points provided by openjpa. Way of openjpa's working with JTA is changed by this module that not JNDI was nessary, and it now works with Tuscsany's policy-transaction. This contribution is not 100% done, there are places need improving. After implementation-hibernate, I wish this time I could have done a valuable thing here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
binding-json doesn't support inward Object
Hello, every one: The binding-json (trunk) runs fine, but there is a very important thing I found: The test case uses a primary type as the input type. But if I use a custom type pojo, the Object got no transform! This is a very very thing need our attention. Is there any point over this? I expect words from any of you. Thanks. - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.
IMPORTANT: intention of manageable component, suggestion expected
There is a graph and its explain in the topic: https://issues.apache.org/jira/browse/TUSCANY-1903 I expect a disscusion amongst tuscany developers and any tuscany fans. Thanks. - Never miss a thing. Make Yahoo your homepage.
[jira] Assigned: (TUSCANY-1766) Target shipped in helloworld-bpel sample in SCA 1.0 RC3a
[ https://issues.apache.org/jira/browse/TUSCANY-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1766: Assignee: Luciano Resende Target shipped in helloworld-bpel sample in SCA 1.0 RC3a Key: TUSCANY-1766 URL: https://issues.apache.org/jira/browse/TUSCANY-1766 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Reporter: Simon Laws Assignee: Luciano Resende Priority: Minor Fix For: Java-SCA-Next The target dir is shipped in the helloworld-bpel sample -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1766) Target shipped in helloworld-bpel sample in SCA 1.0 RC3a
[ https://issues.apache.org/jira/browse/TUSCANY-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1766. -- Resolution: Fixed Fixed in trunk Target shipped in helloworld-bpel sample in SCA 1.0 RC3a Key: TUSCANY-1766 URL: https://issues.apache.org/jira/browse/TUSCANY-1766 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Reporter: Simon Laws Assignee: Luciano Resende Priority: Minor Fix For: Java-SCA-Next The target dir is shipped in the helloworld-bpel sample -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binding-json doesn't support inward Object
There is a thread discussion Databinding transformation from/to Pojo. I guess that threats the same issue you are reporting, and binding-json will support this scenario once the databinding framework is enhanced. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg25781.html On Nov 19, 2007 6:35 PM, shaoguang geng [EMAIL PROTECTED] wrote: Hello, every one: The binding-json (trunk) runs fine, but there is a very important thing I found: The test case uses a primary type as the input type. But if I use a custom type pojo, the Object got no transform! This is a very very thing need our attention. Is there any point over this? I expect words from any of you. Thanks. - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binding-json doesn't support inward Object
Hi, Lucaino: I tried more, and I noticed that to make JSONObject-pojo work, I need to annote the service interface as @Remoteable. The actual transform happens as: JSONObject-JSON2XMLStreamReader-XMLStreamReader-XML2JavaBeanTransformer-pojo So inside this chain, I don't care what the xml is. But unfortrunately, result of this transformation doesn't meed saitisfaction. Luciano Resende [EMAIL PROTECTED] wrote: There is a thread discussion Databinding transformation from/to Pojo. I guess that threats the same issue you are reporting, and binding-json will support this scenario once the databinding framework is enhanced. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg25781.html On Nov 19, 2007 6:35 PM, shaoguang geng wrote: Hello, every one: The binding-json (trunk) runs fine, but there is a very important thing I found: The test case uses a primary type as the input type. But if I use a custom type pojo, the Object got no transform! This is a very very thing need our attention. Is there any point over this? I expect words from any of you. Thanks. - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Get easy, one-click access to your favorites. Make Yahoo! your homepage.
[ANNOUNCE] Apache Tuscany SCA Java 1.0.1 released
The Apache Tuscany team are delighted to announce the 1.0.1 release of the Java SCA project. Apache Tuscany provides a runtime environment based on the Service Component Architecture (SCA). SCA is a set of specifications aimed at simplifying SOA application development. These specifications are being standardized by OASIS as part of the Open Composite Services Architecture (Open CSA). The Tuscany SCA Java 1.0.1 is mainly a bug-fix release. It also comes with some improvements. Please see: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0.1/distribution/src/main/release/CHANGES. For full details about the release and to download the distributions please go to: http://incubator.apache.org/tuscany/sca-java-releases.html To find out more about OASIS Open CSA go to: http://www.oasis-opencsa.org. Apache Tuscany welcomes your help. Any contribution, including code, testing, contributions to the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
[jira] Updated: (TUSCANY-1654) Problem getting wsdl for service ws binding
[ https://issues.apache.org/jira/browse/TUSCANY-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-1654: - Attachment: TUSCANY-1654-new.patch Though getContextPath() is added to ServletHost, it is not used in Axis2ServiceProvider to adjust the servicename. TUSCANY-1654-new.patch fixes this. Problem getting wsdl for service ws binding --- Key: TUSCANY-1654 URL: https://issues.apache.org/jira/browse/TUSCANY-1654 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.99 Environment: Tuscany SCA 0.99 runtime used in Tuscany plugin for Geronimo 2.0.1 Tomcat distro. Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-1654-new.patch, TUSCANY-1654.patch I have encountered this problem with getting wsdl for service ws binding with helloworld webservice sample deployed in Geronimo using Tuscany plugin for Geronimo. Creating this JIRA to keep track of any observations and progress on this problem. I suspect the problem is introduced in rev 569074. Part of the discussion on tuscany-dev is available at http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22334.html. Problem: After deploying helloworld webservice sample with ws binding URI http://localhost:8080/hello/HelloWorldService, accessing http://localhost:8080/hello/HelloWorldService?wsdl; throws StringIndexOutOfBoundsException. Observations: 1. Though accessing http://localhost:8080/hello/HelloWorldService?wsdl results in an error, the service is still available at http://localhost:8080/hello/HelloWorldService 2. If a URI http://localhost:8080/HelloWorldService is used, then http://localhost:8080/HelloWorldService?wsdl does not result in any errors i.e. when the context-root is /. 3. The HelloWorldService sample under samples runs fine with either URI's in standalone tuscany runtime. This is because / is used as the context-root in both the cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1769) Helloworld-ws-sdo sample contains duplicate classes.
[ https://issues.apache.org/jira/browse/TUSCANY-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1769. -- Resolution: Cannot Reproduce Can't reproduce using distribution generated from current trunk code. Please reopen if you still see the issue. Helloworld-ws-sdo sample contains duplicate classes. Key: TUSCANY-1769 URL: https://issues.apache.org/jira/browse/TUSCANY-1769 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.0, Java-SCA-Next Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Sample helloworld-ws-sdo built from Ant contains duplicate copies of the SDO generated classes. This only causes a problem on WebSphere 6.1.0.9. The sample works on Tomcat. A workaround is to remove line 76 of build.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
