RE: [OT] Handling JDBC transactions
Hi, I feel JTA is the solution. JOTM have a documentation on how to use it in Tomcat. But requiring to use JNDI is a problem because Tomcat JNDI is not available outside Tomcat and I cannot run unit tests. Thanks for the help. Cactus (as in the Jakarta in-container testing project) is good for this ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Handling JDBC transactions
Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. rgds Antony Paul - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, September 23, 2004 6:21 PM Subject: RE: [OT] Handling JDBC transactions Hi, I feel JTA is the solution. JOTM have a documentation on how to use it in Tomcat. But requiring to use JNDI is a problem because Tomcat JNDI is not available outside Tomcat and I cannot run unit tests. Thanks for the help. Cactus (as in the Jakarta in-container testing project) is good for this ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: [OT] Handling JDBC transactions
Hi, Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. Good luck. If you want to have tests that simulate real-world conditions, not just simple unit tests, you'll wake up to things like Cactus soon enough ;) Or maybe create your own framework for testing code as you write it complete with the plumbing required. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Handling JDBC transactions
Simulating real world is a QA fellows job. I write code, foresee any bugs that it may have, write tests for it, run tests using Ant, deploy to Tomcat(copy files) and test. Only JSP pages one need to test using a container with every change for- for the visual layout. rgds Anto Paul On Thu, 23 Sep 2004 09:02:06 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. Good luck. If you want to have tests that simulate real-world conditions, not just simple unit tests, you'll wake up to things like Cactus soon enough ;) Or maybe create your own framework for testing code as you write it complete with the plumbing required. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To strive,to seek,to find and not to yield - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Handling JDBC transactions
Hi, OK. To each their own testing philosophy ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Anto Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 9:10 AM To: Tomcat Users List Subject: Re: [OT] Handling JDBC transactions Simulating real world is a QA fellows job. I write code, foresee any bugs that it may have, write tests for it, run tests using Ant, deploy to Tomcat(copy files) and test. Only JSP pages one need to test using a container with every change for- for the visual layout. rgds Anto Paul On Thu, 23 Sep 2004 09:02:06 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. Good luck. If you want to have tests that simulate real-world conditions, not just simple unit tests, you'll wake up to things like Cactus soon enough ;) Or maybe create your own framework for testing code as you write it complete with the plumbing required. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To strive,to seek,to find and not to yield - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Handling JDBC transactions
Hi, Do you run unit test using Cactus for all code changes ? Just to know ?. I feel that such tools are useful for those who is responsible for integration testing. It's not that simple (at least for me and the organizations I've worked for/with). I don't have the luxury (and few people do) of leaving all integration testing to QA in the first place. Even if I did, I wouldn't consider a test like making sure a servlet can work with a connection pool an integration test (and such a test would obviously require JNDI). And even in places that consider that an integration test, I've found the quality of QA testing to be mediocre at best, and downright clumsy on average. So I, and the developers I manage, end up writing a good amount of tests that aren't plain JUnit tests: we use Cactus, MockObjects, and a variety of other tools. They get run automatically on a nightly basis on our test server, so we don't spend any time running them, we just check the results in the morning. There's also a nightly Clover run to give us an idea of how we're doing in test code coverage. I didn't stumble into this approach or invent it: there's an ample body of both theoretical SD research and practical experience that suggest waiting for QA to conduct all integration testing results in significantly worse product quality and delayed shipping. Tools like Cactus are priceless to quality-oriented shops. Yoav Anto Paul On Thu, 23 Sep 2004 09:12:12 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, OK. To each their own testing philosophy ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Anto Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 9:10 AM To: Tomcat Users List Subject: Re: [OT] Handling JDBC transactions Simulating real world is a QA fellows job. I write code, foresee any bugs that it may have, write tests for it, run tests using Ant, deploy to Tomcat(copy files) and test. Only JSP pages one need to test using a container with every change for- for the visual layout. rgds Anto Paul On Thu, 23 Sep 2004 09:02:06 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. Good luck. If you want to have tests that simulate real-world conditions, not just simple unit tests, you'll wake up to things like Cactus soon enough ;) Or maybe create your own framework for testing code as you write it complete with the plumbing required. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To strive,to seek,to find and not to yield - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- To strive,to seek,to find and not to yield This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Handling JDBC transactions
I don't have any knowledge of Cactus/MockObjects. I had never thought about such a testing strategy. Thanks for the info. Anto Paul On Thu, 23 Sep 2004 09:34:34 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Do you run unit test using Cactus for all code changes ? Just to know ?. I feel that such tools are useful for those who is responsible for integration testing. It's not that simple (at least for me and the organizations I've worked for/with). I don't have the luxury (and few people do) of leaving all integration testing to QA in the first place. Even if I did, I wouldn't consider a test like making sure a servlet can work with a connection pool an integration test (and such a test would obviously require JNDI). And even in places that consider that an integration test, I've found the quality of QA testing to be mediocre at best, and downright clumsy on average. So I, and the developers I manage, end up writing a good amount of tests that aren't plain JUnit tests: we use Cactus, MockObjects, and a variety of other tools. They get run automatically on a nightly basis on our test server, so we don't spend any time running them, we just check the results in the morning. There's also a nightly Clover run to give us an idea of how we're doing in test code coverage. I didn't stumble into this approach or invent it: there's an ample body of both theoretical SD research and practical experience that suggest waiting for QA to conduct all integration testing results in significantly worse product quality and delayed shipping. Tools like Cactus are priceless to quality-oriented shops. Yoav Anto Paul On Thu, 23 Sep 2004 09:12:12 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, OK. To each their own testing philosophy ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Anto Paul [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 9:10 AM To: Tomcat Users List Subject: Re: [OT] Handling JDBC transactions Simulating real world is a QA fellows job. I write code, foresee any bugs that it may have, write tests for it, run tests using Ant, deploy to Tomcat(copy files) and test. Only JSP pages one need to test using a container with every change for- for the visual layout. rgds Anto Paul On Thu, 23 Sep 2004 09:02:06 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, Cactus is in-container testing(I assume). Takes time. I want to test code as I write it. Already the development time for deploying an application is high because of having a different source directory than web application directory and of Ant. Good luck. If you want to have tests that simulate real-world conditions, not just simple unit tests, you'll wake up to things like Cactus soon enough ;) Or maybe create your own framework for testing code as you write it complete with the plumbing required. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To strive,to seek,to find and not to yield - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- To strive,to seek,to find and not to yield This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- To strive,to seek,to find and not to yield
Re: [OT] Handling JDBC transactions
I feel JTA is the solution. JOTM have a documentation on how to use it in Tomcat. But requiring to use JNDI is a problem because Tomcat JNDI is not available outside Tomcat and I cannot run unit tests. Thanks for the help. rgds Antony Paul - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 7:00 PM Subject: RE: [OT] Handling JDBC transactions Hi, What are the ways to handle transactions in Tomcat ?. No EJB here. I use Tomcat standalone. I am using JDBC calls to manage DB. I had used There are a couple of ways. One is to roll them yourself: add jta.jar (Java Transaction API, downloadable from Sun) and your implementation of choice (e.g. Tyrex) to WEB-INF/lib, and go read a JTA tutorial. This way is not hard, it's portable, and as a bonus you would be able to test your transaction code from unit tests as it won't depend on the servlet container. The other way is to use Tomcat's JNDI provider. The J2EE spec requires Tomcat to provide a UserTransaction (see the JTA docs) factory via JNDI. Tomcat 4.x used Tyrex for this, see http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples -howto.html#Tyrex%20Connection%20Pool. Tomcat 5 doesn't use Tyrex as the project seems to be dead: http://tyrex.sourceforge.net/#News. So you have to pick another JTA implementation and follow the guide for using a the JNDI factory (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/index.html), using the org.apache.naming.factory.UserTransactionFactory. Finally, you could simply use an external transaction manager. This solution is usually worthwhile only for mission-critical (as in someone will die if it fails) or very large installation, because these enterprise-grade transaction managers tend to be very expensive and complex. However, recently things like JOTM (ObjectWeb) have really grown into their own, so you might wish to investigate it. The downsides to using container- or externally-provided transaction manager are that you need to learn the configuration syntax, and that unit-testing is more difficult. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
[OT] Handling JDBC transactions
Hi all, What are the ways to handle transactions in Tomcat ?. No EJB here. I use Tomcat standalone. I am using JDBC calls to manage DB. I had used Connection.commit() and party in previous projects. But this have 2 draw backs 1. Need to pass Connection to methods which is coming under the transaction. 2. Some methods may need to be transactional in future which are not transactional now. Since now it is not transactional I am not passing the Connection object. Hence it requires modification of the method signature to implement the new changes which is not desirable in most cases. So I am looking for alternate ways. How you people handle this ?. rgds Antony Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Handling JDBC transactions
Hi, What are the ways to handle transactions in Tomcat ?. No EJB here. I use Tomcat standalone. I am using JDBC calls to manage DB. I had used There are a couple of ways. One is to roll them yourself: add jta.jar (Java Transaction API, downloadable from Sun) and your implementation of choice (e.g. Tyrex) to WEB-INF/lib, and go read a JTA tutorial. This way is not hard, it's portable, and as a bonus you would be able to test your transaction code from unit tests as it won't depend on the servlet container. The other way is to use Tomcat's JNDI provider. The J2EE spec requires Tomcat to provide a UserTransaction (see the JTA docs) factory via JNDI. Tomcat 4.x used Tyrex for this, see http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples -howto.html#Tyrex%20Connection%20Pool. Tomcat 5 doesn't use Tyrex as the project seems to be dead: http://tyrex.sourceforge.net/#News. So you have to pick another JTA implementation and follow the guide for using a the JNDI factory (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/index.html), using the org.apache.naming.factory.UserTransactionFactory. Finally, you could simply use an external transaction manager. This solution is usually worthwhile only for mission-critical (as in someone will die if it fails) or very large installation, because these enterprise-grade transaction managers tend to be very expensive and complex. However, recently things like JOTM (ObjectWeb) have really grown into their own, so you might wish to investigate it. The downsides to using container- or externally-provided transaction manager are that you need to learn the configuration syntax, and that unit-testing is more difficult. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Handling JDBC transactions
On Tue, Sep 21, 2004 at 04:31:25PM +0530, Antony Paul wrote: : What are the ways to handle transactions in Tomcat ?. No EJB here. I use : Tomcat standalone. I am using JDBC calls to manage DB. I had used : Connection.commit() and party in previous projects. But this have 2 draw : backs : 1. Need to pass Connection to methods which is coming under the transaction. : 2. Some methods may need to be transactional in future which are not : transactional now. Since now it is not transactional I am not passing the : Connection object. Hence it requires modification of the method signature to : implement the new changes which is not desirable in most cases. : So I am looking for alternate ways. How you people handle this ?. This is a design issue. With proper abstraction of/within your data layer, you can minimize the amount of Connection-passing to a specific set of database-related methods (preferably within the same object). Create methods that handle business processes; in turn, these methods call several (internal, private) methods that handle the Connection object. Look at the Thread-Safe Interface pattern for hints, then adjust as needed to fit your situation. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Handling JDBC transactions
Hi, BTW, recent versions of JOTM support lightweight usage inside a webpp, not just as an external Transaction Manager which was implied by my previous post. Yoav Shapira Millennium Research Informatics -Original Message- From: Shapira, Yoav Sent: Tuesday, September 21, 2004 9:30 AM To: Tomcat Users List Subject: RE: [OT] Handling JDBC transactions Hi, What are the ways to handle transactions in Tomcat ?. No EJB here. I use Tomcat standalone. I am using JDBC calls to manage DB. I had used There are a couple of ways. One is to roll them yourself: add jta.jar (Java Transaction API, downloadable from Sun) and your implementation of choice (e.g. Tyrex) to WEB-INF/lib, and go read a JTA tutorial. This way is not hard, it's portable, and as a bonus you would be able to test your transaction code from unit tests as it won't depend on the servlet container. The other way is to use Tomcat's JNDI provider. The J2EE spec requires Tomcat to provide a UserTransaction (see the JTA docs) factory via JNDI. Tomcat 4.x used Tyrex for this, see http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-example s -howto.html#Tyrex%20Connection%20Pool. Tomcat 5 doesn't use Tyrex as the project seems to be dead: http://tyrex.sourceforge.net/#News. So you have to pick another JTA implementation and follow the guide for using a the JNDI factory (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/index.html), using the org.apache.naming.factory.UserTransactionFactory. Finally, you could simply use an external transaction manager. This solution is usually worthwhile only for mission-critical (as in someone will die if it fails) or very large installation, because these enterprise-grade transaction managers tend to be very expensive and complex. However, recently things like JOTM (ObjectWeb) have really grown into their own, so you might wish to investigate it. The downsides to using container- or externally-provided transaction manager are that you need to learn the configuration syntax, and that unit-testing is more difficult. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
