Calculator Sample WebApp test fails when built separately
Hi, If I do a full build of java\sca using: mvn -o -fn clean install The Calculator Sample WebApp builds and the unit test passes OK. If I go to the java\sca\samples\calculator-webapp folder and issue the same command the code builds but the test fails on a NPE. --- T E S T S --- Running calculator.CalculatorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.265 sec FAILURE! testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.187 sec ERROR! org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69) at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:34) 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:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:94) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:93) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 20 more I'm new to Tuscany (and Maven) can somebody give me a hint as to what I might be doing wrong? Thanks, Steve.
Re: [DAS] Transaction support
Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always going to have a handle to it and so the only option should be to make user control the transaction. Current DAS code issues commit/rollback / Command for this case, which is an erroneous behavior. Due to this user loses its ability to group commands based on business need in a transaction. ---check testUserUnableToControlExternallyInitedTransaction() 2) when managedtx=false and connection is created by DAS, NEITHER DAS NOR USER issue any commit/rollback ANYTIME. This is equaly
Re: [DAS] Transaction support
By doing a quick debug on Amita's testcase from JIRA-1543, looks like we might have some bugs in our current code, that might be causing this whole confusion. Let me spend couple hours on this over the weekend, and send some feedback after that. I'll also write a wiki page with what I think the Transaction support should do/work. On 8/17/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Just trying to see what changes will be needed (marked with ) 1) when connection from user, and he wants to delegate transaction control to DAS, allow it only per/Command. This will save user from issuing one commit/rollback per command in the client code. (i.e. current way of managetx=true default, connection passed from user). So this is as of today, no changes needed. 2) when connection from user and user wants to control single/group of commands, he should set managedtx=false. -As default managedtx=true, user in this case will need to put ConnectionInfo element in config just for the sake of passing managedtx=false Giving new test case showing this 3)-- fix logic of DASImpl.managingConnections() - should just look at managedtx 4) when connection from DAS and user wants to control single/group of commands, he should set managedtx=false --- new test cases showing manage single/group of Commands 5)DAS will expose getConnection() for all cases except when connection by DAS, tx management by DAS --public Connection DAS.getConnection(); For exception case throw RuntimeException from DAS - DAS is controlling transaction, can not expose Connection! 5) awhen user passes connection in DAS() and also sets ConnectionInfo -datasource/drivermanager - specify that passed connection will be used and config connection will be ignored. bDAS can manage connection only when it is created internally and only/Command. i.e. DAS does not support internally managing transactions for group of commands -- Document - FAQs? 6) DAS throws RuntimeException with embedded SQLException - may it be connection closed, integrity violation etc. ---no changes needed I will submit patch for JIRA-1466 using above summary shortly. Regards, Amita On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: forwarding last message to dev list... On 8/17/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi Amita, thanks for the examples, it always helps to clarify : ). My comments: Use Case 1: I think if there is part of the code the user needs to control the transaction directly, he would never set the managedtx=true, that's why managedtx is an option, to give a chance to the user decide if he wants or not to control anytime the transaction. So, on my opinion it's an user error that set the managedtx as true when he wants to control the transaction, and not a DAS error. I understand that your point is try to avoid a user mistake like this, although the user needs to know well what the DAS interface does or not, and on this case the DAS interface says: DAS will control the transactions when you set managedtx=true. This kind of user mistake could be easily resolved if a Connection object could be easily copied, but as far as I know it can't. Use Case 2: Here I agree that not to expose the Connection when its created by DAS and managedtx is false is a DAS mistake. That's why I vote to expose getConnection and I see no problem to throw some kind of exception when user tries to invoke getConnection when managedtx=true. Use Case 3: a) About user invoking closeConnection, it's the same case I described on Use Case 1's comments, the user needs to be aware that DAS is controlling the transactions. However, DAS should throw some kind of exception when the Connection is closed externally, I don't know if it's doing that. b) If exposing the getConnection, I do not see anything new in using these new methods, start/endTransactions, that user cannot perform only using a Connection object. c) About data integrity, I think it's also wrong decision if the user set the managedtx=true if he may further want to perform a rollback on the db. In conclusion: +1 for exposing getConnection - for adding methods startTransaction and endTranscation Regards, Adriano Crestani On 8/16/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Haleh, Please see all the use case details below. There are three user cases going wrong which I am trying to fix. I have created a JIRA-1543 to demonstrate with examples how DAS is failing in these use case scenarios. Patch contains 3 new test cases as below in TransactionTests.java. So far TransactionTests.java had only 1 test case and was not enough to uncover these issues. 1) when user passes connection to DAS, it is obvious that user is always
