{"id":823,"date":"2011-03-31T22:23:00","date_gmt":"2011-03-31T20:23:00","guid":{"rendered":""},"modified":"2023-03-23T15:24:34","modified_gmt":"2023-03-23T14:24:34","slug":"testing-servicemix-4-3-services-with-paxexam","status":"publish","type":"post","link":"https:\/\/touk.pl\/blog\/2011\/03\/31\/testing-servicemix-4-3-services-with-paxexam\/","title":{"rendered":"Testing ServiceMix 4.3 services with PaxExam"},"content":{"rendered":"<p>In the project that I\u2019m currently working on we are developing a set of extensions for ServiceMix \u2013 more or less some monitoring stuff. It\u2019s pretty simple using SMX ExchangeListeners \u2013 you implement the interface, register it via Spring DM and voila \u2013 you have everything you need. But how are you going to test it? Of course, we write unit tests, and functional tests, but all of them are leaving NMR\/OSGi stuff behind \u2013 you just don\u2019t include osgi-beans.xml\u2019s. This leaves us with untested code \u2013 my baaaaad ;) Fortunately, here comes a rescue \u2013 it\u2019s PaxExam. It\u2019s a framework for testing OSGi services in various containers \u2013 most notably felix & equinox. But making it play nicely with latest & greates ServiceMix 4.3 was not so easy \u2013 so I what to share it. I made a sample project, it\u2019s on my\u00a0<\/p>\n<p><a href=\"https:\/\/github.com\/mproch\/paxExamServicemix\">github<\/a> It consists of 2 modules: first contains service & listener under test, and the second one contains The Test. I won\u2019t go into details about the service bundle \u2013 it\u2019s just cxf-bc endpoint passing invocations to camel router, which sets output message. The listener is also very simple. The point is that we have 2 of most widely used smx components, with OSGi packaging and OSGi-config configuration. This leaves us with itests module. It\u2019s core is BaseIntegrationTest, which contains Pax Exam configuration and some utility methods. Pax Exam configuration was the most difficult part for me. The reason is that servicemix consists of many, many dependant projects, each of them having own release cycle, and Pax Exam has it\u2019s own. Anyway, here is what works for me (note \u2013 it\u2019ll work with sun jdk 1.6 only I think). JUnit test (which is of course no unit test btw) using Pax Exam has to have static configuration method, which tells testing framework how to prepare container \u2013 which one, which parameters, which bundles to install. It looks like this: So, what should go into configuration method? First, we have to set up system packages. We have to exclude StAX API and some SOAP APIs from system packages: The system property \u201corg.ops4j.pax.runner.platform.ee\u201d tells PaxRunner where to look for system packages. I copied them from SMX distro \u2013 except that I had to add two Sun packages containing Schema and JAXP implementations \u2013 otherwise XPath & schema failed to work. Still, to make SchemaFactory work I had to manually add system property specifying implementation class. Next thing is rather standard PaxExam configuration: OSGi container, logging profile, spring and spring DM setup (note \u2013 you have to use 1.2 version, not the latest one): Two notes here. A profile is a set of bundles predefined to be used in PaxExam. Also note that we don\u2019t use System.setProperty, but PaxExam DSL expression. The reason is that the OSGi container is run separately, so we have to distinguish system properties used to start it, and properties that will be accessible to bundles inside it. Then comes felix install configuration. I wanted to mimic SMX configuration conventions (files in etc dir, ended with .cfg), so I copied felixInstall configuration and add appropriate system properties. Note, that we set start level to 2. In Karaf deafatul start level is 60, in PaxRunner \u2013 it\u2019s 5. But I decided to stay with Pax way \u2013 don\u2019t have that many bundles to need so fine grained configuration. Now, karaf configuration. It\u2019s also pretty standard, just remember that we need Aries bluepring in version 0.2-incubation, and not 0.1 (as PaxExam has it) or latest 0.3 Now, time for Servicemix components configuration. We\u2019ll use nice PaxExam feature \u2013 feature scan. This means that we can specify Karaf features package, and PaxExam will install appropriate bundles. So, we choose servicemix features, specify servicemix-camel, camel-nmr and servicemix-cxf-bc, and \u2026? And it turns out that servicemix-cxf-bc has unresolved dependencies :\/ The reason is that it was (at least it seems so ;)) tested with full distro, which contains also activemq-blueprint feature. Since we don\u2019t want activemq for our test setup, we\u2019ll install required bundles manually: Now, everything is ready for the final step \u2013 installation of services bundle: mavenBundle(\u201cpl.touk.smx4\u201d, \u201cpaxExamSample-service\u201d) To make testing easier I also created few util methods. Two interesting ones are: getBean and sendMessage. getBean uses ServiceTracker to get Spring\/Blueprint bean registered as a OSGi service. Note, that it is done asynchronously \u2013 that\u2019s why we need Thread.sleep for ServiceTracker. sendMessage wraps interaction with NMR \u2013 it creates inOut exchange, populates it and send synchronously via channel. Well\u2026 this setup is not particularly easy, but once we get through it, the tests look quite nice: This sends test message down the NMR, check that output is ok, and that it was caught by Listener. What\u2019s left to do? You can see some nasty explicit dependencies in configuration \u2013 should be taken from maven. Next goal would also be to run SOAPUI tests for testing end to end interaction. But let\u2019s leave it for next entry. To sum up: I think PaxExam is a great tool, although the setup is not so easy. Tests setup is quite long \u2013 actually it\u2019s faster to build the service bundle and run update on Servicemix to see changes. That\u2019s why I would rather recommend using PaxExam for regression tests, run on Hudson (whooops, Jenkins ;))<\/p>\n","protected":false},"excerpt":{"rendered":"In the project that I\u2019m currently working on we are developing a set of extensions for ServiceMix \u2013&hellip;\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[68,328,30],"class_list":{"0":"post-823","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-development-design","7":"tag-java","8":"tag-paxexam","9":"tag-testing"},"_links":{"self":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/823","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/comments?post=823"}],"version-history":[{"count":57,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/823\/revisions"}],"predecessor-version":[{"id":15652,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/823\/revisions\/15652"}],"wp:attachment":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/media?parent=823"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/categories?post=823"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/tags?post=823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}