[jira] Resolved: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[ https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1465. --- Resolution: Fixed Allow passing ResultDescriptor for dynamic Commands --- Key: TUSCANY-1465 URL: https://issues.apache.org/jira/browse/TUSCANY-1465 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1465.patch, 1465.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html Action for the issue discussed in above mail. -- 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: Monitoring, logging and exceptions (again)
On 8/10/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 8/8/07, ant elder [EMAIL PROTECTED] wrote: On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote: We talked about this before ( http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html) but didn't come to any conclusions. So, 1/ What is the requirement? 2/ What is the technical solution? 3/ When should we try and get it done? To get things going again here are some thoughts drawn from what was said in the referenced thread. 1/ An API in line with accepted logging/management practices to support arbitrary debugging and runtime info, warning and error logging A common approach to exception/error handling specifically around the detail recorded in the error messages Internationalization/localization Execution Tracing 2/ Keeping it simple was a popular sentiment A number of java logging solutions have been proposed Log4J, SLF4J etc. I believe DAS is using Log4J. We have dependencies that also use logging tools. We can take a look at how others approach this, e.g, quick glance at the last CxF release shows they include SLF4J jars Aspects were investigated to show how they can be used for tracing, seems like an interesting optional facility but adds extra complexity/dependencies There was also a suggestion that we could implement some higher level tracing, e.g. runtime starts, stops, application loading, component instance creation etc. We need to move error message out of the code and into resource files 3/ I think we can reasonably expect to agree what approach we are going to take fairly quickly and provide some examples, i.e. before the next release? People suggested before that we take time out to go through the code based and bring it into line. This will take a lot of time but can we get it into 1.0? Please add your thoughts to the list and we can then draw them together, try some of it out and come to some conclusions. Simon +1 for going with SLF4J. If we can decide on this soon then we can all just start adding it in to the code we're working on and debugging, and then maybe have a focused sweep before 1.0 to make sure its in everywhere useful. ...ant Cross posting to the user list also as I expect this is close to everyone heart. Can everyone reply to both lists. Thanks Simon We had a similar discussion in April [1]. Here's what I suggest for logging: - Separate the trace calls from the runtime code. Insert them automatically at build time or run time using Aspectj. Raymond on SCA and Kelvin on SDO already showed how to do it. - Use SLF4J in these generated trace calls. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] Thoughts? There were several posts on that referenced thread less keen on using aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the simplicity of the more traditional approach of explicit logging calls in Tuscany. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
Ole Ersoy wrote: Hi Simon, SNIP assuming you have the source tree checked out of svn. Yes Can you try building that module before you run the eclipse generation? Sure - I'll give it a shot. If I'm in ./java how do I find the module? sca/modules/module-name-without-the-tuscany-prefix i.e. sca/modules/binding-sca-xml -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Failure on java trunk
Ole Ersoy wrote: Hi, I just tried building the entire java trunk, and I get the following build failure: --- T E S T S --- Running org.apache.tuscany.sca.contribution.services.ContributionMetadataDocumentProcessorTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.146 sec Running org.apache.tuscany.sca.contribution.processor.FolderContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec Running org.apache.tuscany.sca.contribution.services.PackageTypeDescriberImplTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec Running org.apache.tuscany.sca.contribution.resolver.ExtensibleArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.11 sec Running org.apache.tuscany.sca.contribution.resolver.ArtifactResolverTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.095 sec Running org.apache.tuscany.sca.contribution.processor.JarContributionPackageProcessorTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.098 sec Running org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.107 sec FAILURE! testStore(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.094 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) 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:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) testRemove(org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase) Time elapsed: 0.001 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:158) at org.apache.tuscany.sca.contribution.service.impl.ContributionRepositoryImpl.init(ContributionRepositoryImpl.java:93) at org.apache.tuscany.sca.contribution.services.ContributionRepositoryTestCase.setUp(ContributionRepositoryTestCase.java:37) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at
[jira] Assigned: (TUSCANY-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1496: -- Assignee: ant elder Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: ant elder Attachments: patch1, patch2 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- 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-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1496. -- Resolution: Fixed Patch applied, thanks for the code! Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: ant elder Attachments: patch1, patch2 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- 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: Rename itest artifacts to not include the tuscany- suffix?
They're specific to Tuscany. ...ant On 8/10/07, haleh mahbod [EMAIL PROTECTED] wrote: Are these tests specific to Tuscany SCA or can they be viewed as a community test suite for SCA Java? On 8/10/07, ant elder [EMAIL PROTECTED] wrote: Anyone mind if i change all the itest artifacts to not include the tuscany- suffix? Its a minor thing i know but it would mean then they don't get mixed up with the tuscany runtime modules in the IDE panel views. ...ant
SCA distribution is really big now
Our SCA binary distribution is over 100Meg now and there's still extensions and dependencies I've not added yet. This seems a little big considering we're trying to sell Tuscany as all svelte and light weight. So what to do? The reason its so big is that every webapp sample and demo we have ends up including a copy of most of the runtime and dependencies. One solution could be to just ship fewer prebuilt webapp samples and demos. Another could be to change the way we do those samples so that each sample/demo is just a simple SCA contribution jar and you have to deploy that to some Tuscany runtime. We've already the webapp runtime that would work for that, and the Geronimo Tuscany support, and we could create another standalone runtime if you don't want to use Tomcat or Geronimo. What do people think, does the size matter, are there some other things we could do? ...ant
Re: mvn eclipse:eclipse fails on java
SNIP i.e. sca/modules/binding-sca-xml Thanks for pointing this out Jean-Sebastien. OK - I tried building the module by itself. I'm running jdk 1.6, but that should be ok right? I get the following: [INFO] Compiling 2 source files to /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/target/test-classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[37,46] package org.apache.tuscany.sca.binding.sca.impl does not exist /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[40,46] package org.apache.tuscany.sca.binding.sca.impl does not exist /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[75,8] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.WriteTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/WriteTestCase.java:[75,47] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.WriteTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[71,32] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.ReadTestCase /home/ole/svn-workspace/java/sca/modules/binding-sca-xml/src/test/java/org/apace/tuscany/sca/binding/sca/xml/ReadTestCase.java:[80,43] cannot find symbol symbol : class SCABindingFactoryImpl location: class org.apace.tuscany.sca.binding.sca.xml.ReadTestCase [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Sat Aug 11 20:18:30 CDT 2007 [INFO] Final Memory: 9M/25M [INFO] I could probably work around these issues for updating the LDAP DAS code, but will be glad to keep trying things if we want to try to get to the bottom of this. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Failure on java trunk
Jean-Sebastien Delfino wrote: This is weird, the build works for me with Sun JDK 1.5.0_10 on Linux. The latest nightly confluence build [1] is successful too. Hmmm...Maybe it's my jdk... Which JDK are you using? Sun JDK 1.6.0 on Linux Can you try to run a simple program with a main() method calling XMLInputFactory.newInstance() and see what you get? Which maven dependency would I specify for this? Do I need to configure a custom repository? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
