Re: M3
On Mar 13, 2007, at 2:57 PM, Christian Landbo Frederiksen wrote: Hi everybody When is the M3 planned for release? /Chr Hi, I think you may be inquiring about C++ SCA, which I'll let someone working on that project respond to. For Java SCA, we're in the process of releasing an Alpha of the SCA Kernel. You can read the release notes here: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/kernel/ README.txt Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS User's guide
On Mar 6, 2007, at 11:50 AM, Kevin Williams wrote: I modified the DAS overview page to include a link to the RDB DAS User's Guide since, with the move to cwiki, there was no path to this documentation. Sorry! I must have missed the link. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NPE if we define a sca java component via side file, meanwhile the implemetnation class impements multiple interfaces.
On Jan 14, 2007, at 9:45 PM, lee zhenghui wrote: hi, I am writing a sample to test the feature described in section 2.2.5 of SCA_ClientAndImplementationModeforJava_v96.doc. I am describing the details of my test sample here: 1. Create two component -- Customer and CustomerInfo. 2. Make sure the implementation class of CustomerInfo will implements more than two inferfaces. 3. Define ComponentType via @Service etc. make sure it works fine. 4. remove @Service descriptions in source code, and replace it with a ComponentType side file. Result: I got a exception: java.lang.NullPointerException at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build (JavaComponentBuilder.java:120) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build (JavaComponentBuilder.java:1) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build (BuilderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.AbstractCompositeBuil der.build(AbstractCompositeBuilder.java :35) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.buil d(CompositeBuilder.java:44) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build (BuilderRegistryImpl.java:107) at org.apache.tuscany.core.deployer.DeployerImpl.build (DeployerImpl.java:142) at org.apache.tuscany.core.deployer.DeployerImpl.deploy (DeployerImpl.java:97) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication (LauncherImpl.java:215) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:88) at tuscany.sample.sync.customer.CustomerImplTest.setUp (CustomerImplTest.java:16) at junit.framework.TestCase.runBare (TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run ( JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run (TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196) I am attaching my sample PI zip file here, Does anyone know whether this is a runtime issue, or I missing something in my test sample? Hi, This is a problem with both the code and the SCA Java specification. The spec issue is that we have not defined all of the equivalent component type extensions for Java annotations. In this particular case it is support for the @Constructor annotation. If you are interested, we could work on a proposal to the spec group for adding this into the component type side file. In terms of the code, it looks as if the side file introspection process does not create a ConstructorDefinition, which basically tells the builder which constructor to use during instantiation. If we were to support selection of a constructor in a side file, we would have to provide a mechanism that would first allow a user to specify the constructor to use in XML (by parameter type). If no constructor was specified, we would need to determine this heuristically. The Java annotation introspection mechanism does this, which you can see in org.apache.tuscany.core.implementation.processor.HeuristicPojoProcessor. Supporting constructor selection in the side file as described above is quite a bit of work. If you are interested, I can help point you to places in the code to get started. However, this may be more than what you need to get past the issue you are facing. If you just want to get past the NPE, a simple fix would be to create a ConstructorDefinition and have it point to the default no-args constructor of the implementation. I would do this in JavaComponentTypeLoader.loadFromSideFile() after the component type as been populated with side file info and before it is returned from this method. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem for sca groovy service.
For the Groovy extension, I'd prefer that it remain independent as it is distinct from the other containers. This will also promote modularity and the ability to release it independently from the other scripting extensions. Jim On Jan 13, 2007, at 4:37 AM, ant elder wrote: Thanks very much for this, I've committed these changes. I added a JIRA component for this that you mentioned was missing. It maybe worth reviewing the components and consolidating some into a more generic scripting or container extension component. ...ant On 1/13/07, lee zhenghui [EMAIL PROTECTED] wrote: hi,ant elder I have opened JIRA TUSCANY-1051 to trace this issue, and also attached the patch and helloworld sample(I have added ASF copyright in the sample code) there. if you have time, could you review them, anything incorrect, pls feel free to let me know. thanks in advance. By the way, I have run all existing UT cases, all of them passed. For your convenience, i am listing the updated code here: 1.ImplementationLoader.java : add two fields with getter/setters. applicationLoader, this will be used for construct GroovyClassloader scriptResourceName, this is script resource name, will be used for generate side file name (componentType) 2. ImplementationLoader.loader() add following statement: implementation.setApplicationLoader( deploymentContext.getClassLoader()); implementation.setScriptResourceName(script); 3. GroovyComponentBuilder.build groovyClassLoader = new GroovyClassLoader( implementation.getApplicationLoader()); 4. GroovyComponentType.java Adding two constructor method , it is similar with what did in javaScriptComponentType 5. GroovyComponentTypeLoader.java adding sild file(ComponentType) support, just like what we have in JavaScript. TODO: i did not implement loadFromIntrospection now, I am not sure whether it will use the same logic as javaScript. So mark it as TODO section in this patch now. 6. GroovyComponentTypeLoaderTestCase enhancement due to corresponding modification above. One quick question is, During opening JIRA , I can not found Groovy component in the list, maybe it belong to antoher component, but I did not know, who can tell me which component does Groovy container belong to in JIRA system? On 1/12/07, ant elder [EMAIL PROTECTED] wrote: Thats wonderful! Could you attach it to a new JIRA instead of the wiki? The Tuscany JIRA system is at: http://issues.apache.org/jira/browse/TUScany. If you don't already have a JIRA account you'll have to create yourself one before you can open a new JIRA. Thanks, ...ant On 1/12/07, lee zhenghui [EMAIL PROTECTED] wrote: hi, ant.elder Thanks for your advices, I have fixed the issue(both GroovyClassloader and initializing the Scope issues ), for now, my helloworld samle works fine. For safe, I will double check the patch and sample. and Will post them on wiki several hours later. also I will provide my detailed modification here too. By the way, I am really happy to have chance to do something for SCA. I like it very much.. :-) On 1/12/07, ant elder [EMAIL PROTECTED] wrote: Hey its great to hear you're writing a groovy sample, would you contribute it back to Tuscany to include in our samples? I think you're correct, the classloader is not being initialized correctly. In the GroovyComponentBuilder the ClassLoader from the DeploymentContext is the wrong one to be using, its null as you've seen. It really wants the application ClassLoader which is available in the DeploymentContext passed into the load method of the ImplementationLoader class in the Groovy package. I think what needs to happen is GroovyImplementation should have a ClassLoader field added with getter/setters, the ImplementationLoader.loadmethod should set the Classloader on the GroovyImplementation from the DeploymentContext, then the GroovyComponentBuilder should create the GroovyClassLoader using the ClassLoader from the GroovyImplementation (the implementation variable) instead of the DeploymentContext. You can see all that being done if you look at the Tuscany JavaScript container. Does this make sense to you? Would you be interested in submitting a patch for this? Say if you'd prefer to be just be using Groovy and I'll fix this for you right away. ...ant PS. Note, i think there's another problem you'll hit after fixing this which is the GroovyComponentType is not initializing the Scope correctly. This could be done in a a default constructor just as the JavaScriptComponentType does. On 1/12/07, lee zhenghui [EMAIL PROTECTED] wrote:
Re: Tuscany development status
On Jan 2, 2007, at 6:04 AM, Francesco Furfari wrote: Thank you Jean-Sebastian, I was supposing that it wasn't so easy to answer, especially to my last question, but it didn't discourage me from continuing ;-). Just to inform you, there was general consensus respect the SCA initiative, as well as caution because the work is still in progress. Obviously there were also motivations against the SCA adoption as for example the reuse of code already developed by the involved partners ;-). But we are still defining the conceptual model so there is room for any (maybe mixed) solution ... people asked me references. What I haven't found is a roadmap about the SCA specification, even an approximate date for the version 1.0 can ease managers to go over their hesitation (but I understand that it can produce negative effects). Working in team we are particularly interested in the deployment aspects of a service networks, so next months I've intention to investigate such area to give them a practical demo of how SCA can help our collaborative work. Ciao Francesco, The SCA specification is targeting Q1 this year. Are you specifically interested in the Java implementation, C++ implementation or both? I'm happy to help answer any questions you have on the former as well as the SCA specs. Buon anno! Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Apache Tuscany compatible with J2EE1.4
Hi Kiran, I'm not sure about DAS or SDO but the Java SCA runtime requires Java 5 as a minimum. Jim On Oct 25, 2006, at 3:13 PM, Kiran Kumar Rangaswamy wrote: Dear all, Is Apache Tuscany compatible with J2EE1.4? Regards, Kiran Kumar Rangaswamy Email: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] URL: www.valuemomentum.com outbind://20/www.valuemomentum.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
