Hey Jim, Thanks for your comments and observations.
Yes creating those file system artifacts are real PIA. I will talk to the ActiveMQ guys and see if there is a way to turn that off. I will probably use the in-VM stuff from ActiveMQ, but was a little to excited to test the real stuff :) Like u said we can move that stuff to the integration test suite. So I will send another patch (as time permits) which will clean up the code with better error handling, as well as use EasyMock or in-VM to run the test case. I also need to add more simple JUnit tests to cover the code base. I also need to bring this in-line with the released JMS binding spec draft. So let me do this stuff incrementally and send a series of patches. Hopefully ant will not get tired of applying my patches :) I will address the more nagging problem of creating those file system artifacts first. Regards, Rajith On 11/2/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Rajith, Thanks for the patch. I had a few comments regarding test cases... Having a testcase that is run from the checkin build create file system artifacts may be problematic since it can produce side- effects. Setting svn ignores isn't going to fix this so would it be possible to avoid having to create these artifacts? I was thinking this would involve two steps: 1. Have unit tests use EasyMock to stub out JMS APIs such as Destination to test the binding at a granular level independent of a particular JMS implementation. I would imagine there would not be many of these tests as the binding is mostly a wrapper around a JMS provider. These would just be normal JUnit test cases and not extend SCATestCase. 2. Have integration tests which test interoperating the binding with ActiveMQ. Eventually, these would be run as part of the integration test suite being worked on by Jeremy. For now, they could be test cases included as part of the checkin build until the integration test harness is operational. However, couldn't these integration tests use ActiveMQ's in-VM protocol? Also, would using the in-VM protocol eliminate the need to create file system artifacts as well as have port listeners? If there is no way around creating file system artifacts, then I think we really need to segregate these tests so they are not part of the checkin build. I'm happy to help out if needed. Thanks, Jim On Nov 2, 2006, at 1:04 AM, ant elder (JIRA) wrote: > [ http://issues.apache.org/jira/browse/TUSCANY-753?page=all ] > > ant elder closed TUSCANY-753. > ----------------------------- > > Resolution: Fixed > > Applied, thanks for the code Rajith! > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ > services/bindings/binding.jms/ > > Right now the testcases create an ActiveMQ folder in the top level > binding.jms folder, it would be better if that could be done within > the target folder so its excluded from the SVN artifacts. If its a > major problem i guess we could just add it to svn ignores but for > now I haven't added this to the main build so we can look at this. > >> JMS Binding >> ----------- >> >> Key: TUSCANY-753 >> URL: http://issues.apache.org/jira/browse/TUSCANY-753 >> Project: Tuscany >> Issue Type: New Feature >> Components: Java SCA Core >> Affects Versions: Java-Mx >> Reporter: Rajith Attapattu >> Assigned To: ant elder >> Fix For: Java-Mx >> >> Attachments: helloworldws.zip, jms-binding- >> JIRA_753-01-11-06.patch, jmsbinding_jira753_25sep06.patch >> >> >> Hi All, >> >> I have attached a patch for the JMS binding. By no means this is >> 100% complete. >> But I decided to post the source code so that others can have a >> look and comment on the direction and help out if there is >> something wrong. >> The unit tests are failing so I haven't attached the test code. >> JMS binding still has a dependency on SDO since I modeled it on >> the axis2 binding. >> However Raymond has changed that in axis2 and I am hoping to do >> the same soon. >> >> Please be kind enough to have a look and start a disucssion on >> how we can move this forward. >> Regards, >> Rajith >> >> > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: http://issues.apache.org/jira/secure/ > Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/ > software/jira > > > > --------------------------------------------------------------------- > 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]
