I just want to give a feedback for this wonderful dev team (specially David, which was leading this thread): As a project decision, we are switching from the current development with Tomcat / OpenEJB / OpenJPA to Glassfish in our app. So, I'm sorry to say I won't have time (as I hadn't have since january, anyway) to keep working on the @Asynchronous subject. If anyone had not worked on it because I was doing some work, I apologize. Thank you guys for the support, specially on other subjects, like resolving the data source from the web app context path and handling the unauthenticated principal in Tomcat. I hope to work with OpenEJB again in some other project... Best wishes, -- Luis Fernando Planella Gonzalez
2010/1/22 Luis Fernando Planella Gonzalez <[email protected]>: > You are right about the Thread.sleep(), I hadn't liked it very much... > I've removed it from the class, and used the CountDownLatch on the test case, > as proposed. Much better! > Didn't have time to look further on descriptors... > The openejb3_AsynchronousRunner_v2.patch is attached on the Jira. > However, this create-patch-and-attach-on-issue won't scale in the long run... > -- > Luis Fernando Planella Gonzalez > > Em Quinta-feira 21 Janeiro 2010, às 21:31:46, David Blevins escreveu: >> >> On Jan 21, 2010, at 8:36 PM, Luis Fernando Planella Gonzalez wrote: >> >> > Well, seems this first part was not hard at all. >> > I've attached a patch on https://issues.apache.org/jira/browse/OPENEJB-1165 >> > Included the AsynchronousRunner and AsynchronousRunnerTest. >> >> That's great! All committed! >> >> We'll need to get those Thread.sleeps out of there. There are some >> cool java.util.concurrent classes we can which are actually easier >> once you get the hang of them. The one I use most for testing >> multithreaded code is java.util.concurrent.CountDownLatch. >> >> In your test case you could construct a "CountDownLatch latch = new >> CountDownLatch(1)" and pass that instance to your asynchronous method >> so both the test case and the target method have a reference to the >> same latch. The method will just call latch.await() which will cause >> the asynch thread to pause. Then in your test case you can test the >> 'isDone' logic on your future, then call latch.countDown() which will >> cause the asynch thread to resume and complete, then you can test your >> 'isDone' 'true' logic. Best to call get() on the future before >> calling isDone() or isDone() could return false. >> >> Aside from the test case, the next step is updating the descriptor >> reading code[1] so that it can handle the new async method related ejb- >> jar.xml syntax [2]. >> >> 1. container/openejb-jee/src/main/java/org/apache/openejb/jee/ >> SessionBean.java >> 2. http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd >> >> There's a test case[3] that reads in a sample ejb-jar.xml file[4]. It >> should be fairly easy to update the ejb-jar.xml file to have a few of >> the new async elements so that you can verify the reading/writing >> works fine. >> >> 3. container/openejb-jee/src/test/java/org/apache/openejb/jee/ >> JeeTest.java >> 4. container/openejb-jee/src/test/resources/ejb-jar-example1.xml >> >> >> -David >> >> >
