Thanks a lot for the advice Bartek! Yeah, of course I wasn't the first one that ran into this. I think changing the working directory and use Maven to clean that directory sounds like a good approach. I will look into it but first I'll see what options might be available in Pax Exam 2.
/Bengt 2010/9/13 Bartosz Kowalewski <[email protected]> > Hi, > > I guess you can go with approaches if you want to clean the cache: > 1) use PaxRunnerOptions.cleanCaches() > 2) change Pax Exam's working dir, i.e. like this > PaxRunnerOptions.workingDirectory(System.getProperty("user.dir") + > "/paxrunner/") and configure Maven clean plugin so that it is possible > to delete this extra directory if you explicitly tell Maven to do so > (for example by activating a profile) > > Oh, and I couldn't agree more - Toni is doing a great job :-). > > Bartek > > 2010/9/13 Bengt Rodehav <[email protected]>: > > Hi Toni, > > Glad to see you here :-) > > When browsing for information about Pax Exam your name came up of course. > I > > found an interesting presentation you held about the coming version of > Pax > > Exam 2. Sounds really interesting - looking forward to it. Judging from > the > > ops4j mailing list you're working fiercly with it at the moment. > > I've just started looking at Pax Exam thanks to advice from the guys here > at > > Aries. I'm beginning to think they're right - it's probably the best way > to > > go. I'm now trying to create a good configuration (a couple of > > configurations actually) and a lenient development process. It's looking > > good although I haven't seen how it works performance wise yet (when I > add > > more test cases and more start/stop of the OSGi container). Apparently > Pax > > Exam 2 has a lot to offer in this area. The issues I've had so far are: > > - Support for Felix 3.0.2. This I've seen is on the way. > > - Problems with caching of bundles. I've corrected errors in my bundles > and > > recompiled but it seems like Pax Exam is using cached versions (under > > C:\Document and Settings\....). I now delete the cache when I encounter > > unexplainable problems. I guess caching is necessary to gain performance. > I > > think cleaning out the cache (perhaps on every new build if specified) > > should be an option. > > Seems like a very useful product and sure beats having to start a JEE > > container (which often fails), deploy EJB's, run tests, stop the JEE > > container (which often fails), and so forth. > > Keep up the good work, > > /Bengt > > > > 2010/9/12 Toni Menzel <[email protected]> > >> > >> Regarding integration testing in OSGi, let me know if you need any > >> assistance/help when setting up Pax Exam tests for your Aries > Application. > >> Speaking of that: Glad to see Exam used in Aries! > >> -- > >> Toni Menzel || http://okidokiteam.com > >> > >> Hi Bengt, > >> > >> If set up properly, automated integration tests based on Pax Exam will > >> work out-of-the-box on every machine on which you trigger a Maven > >> build. Pax Runner started by the Pax Exam Junit test will setup an > >> embedded instance of an OSGi container. As long as you are able to > >> embed all components of your app inside a single test - either outside > >> or inside the OSGi container, everything should work. > >> > >> However, when creating those JUnit based itests you'll see that the > >> process of developing them/making them pass on all machines (no matter > >> how fast they are, etc.) might be really painful. OSGi container is a > >> really dynamic environment and you need to code your tests so that > >> they are ready to handle all timing related issues - different order > >> of initialization, longer then usual startup time for a specific > >> bundle, etc. If you take a look at the history of Aries CI build > >> failures, you'll see what I'm talking about :). There are still some > >> phantom test failures that happen every 20 builds :). > >> > >> Having said that, I highly recommend using Pax Exam :). As other guys > >> suggested - just take a look at itests projects that are attached to > >> most of Aries subcomponents. > >> > >> Best regards, > >> Bartek > >> > >> 2010/9/7 Bengt Rodehav <[email protected]>: > >> > Tim, > >> > Yes, I agree that tests involving a database is really integration > >> > testing > >> > and not unit testing. Nevertheless it would be convenient to be able > to > >> > run > >> > them without the requirement of an OSGi container. I guess the reason > >> > why I > >> > was hoping to do this is because it was easy to do in the past (with > >> > Spring/Hibernate) and I try to opt for the simplest solution. > >> > Maybe I'll have to rethink on this matter. I agree that testing in the > >> > container gives a more reliable result. Given that the tests are easy > to > >> > setup and run using Maven I guess it is preferable to do it this > >> > way.However, I'm a bit disillusioned with past experience regarding > >> > integration testing in JEE containers. In my experience it is very > >> > complex > >> > and error prone. Merely having to install, e g Weblogic on every > >> > developers > >> > workstation is a big hazzle (and in the past also a big cost). > >> > Furthermore, > >> > deploying, starting and stopping the application server really doesn't > >> > work > >> > very well at all. The result has been that developers only run a small > >> > subset of the tests since the setup is too complicated. > >> > I'll look in more detail how you handle these tests in Aries and see > if > >> > I > >> > can steal some of your ideas. > >> > Thanks, > >> > /Bengt > >> > 2010/9/7 Timothy Ward <[email protected]> > >> >> > >> >> Hi Bengt, > >> >> > >> >> I would like to re-iterate that dependency injection is the best way > to > >> >> get hold of an EntityManager instance (in fact it is the only way to > >> >> get a > >> >> container-managed EntityManager. > >> >> > >> >> At this point I would suggest that what you should do depends on your > >> >> unit > >> >> testing policy. Usually unit tests are lightweight and involve plenty > >> >> of > >> >> mock objects. I would suggest that actually using OpenJPA and a > >> >> database > >> >> isn't really unit testing anymore, as it's far too heavyweight. I > would > >> >> mock > >> >> up the EntityManager instance that I passed to my DAO bean in a unit > >> >> test > >> >> environment, and validate that the right calls are made. > >> >> > >> >> If you want to to a more complex test (usually called an iTest or > >> >> integration test in Apache) that includes a database then I would > >> >> strongly > >> >> recommend using the pax runner and setting up an OSGi framework. This > >> >> will > >> >> give you much better validation that the code actually works in situ, > >> >> and > >> >> you can use the real persistence.xml. > >> >> > >> >> Regards, > >> >> > >> >> Tim > >> >> > >> >> > >> >> ________________________________ > >> >> > Date: Tue, 7 Sep 2010 09:56:17 +0200 > >> >> > Subject: Re: Unit testing > >> >> > From: [email protected] > >> >> > To: [email protected] > >> >> > > >> >> > Thanks for your reply David, > >> >> > > >> >> > I will definitely have a look at ops4j pax-runner and how you use > it > >> >> > in > >> >> > Aries tests. Thanks for the advice. > >> >> > > >> >> > Your advice regarding DAO testing is also relevant. I do it in a > >> >> > similar way today but had some problems with the "out-of-OSGi" > >> >> > solution > >> >> > interferring with my "in-OSGi" solution. By using a default > >> >> > constructor > >> >> > + dependency injection in OSGi and a constructor taking the entity > >> >> > manager "in-OSGi" I can probably get rid of that problem. Will look > >> >> > into it. > >> >> > > >> >> > On the same subject (if you bear with me), I forgot to ask about > >> >> > handling a data source "in-OSGi" and "out-of-OSGi" respectively. > >> >> > > >> >> > Prior to deploying my project in an OSGi container, I specified the > >> >> > JDBC properties in persistence.xml. This doesn't work very well > under > >> >> > OSGi. Instead one specifies what data source service to use and > then > >> >> > deploys a bundle that publishes a data source as a service. The > >> >> > latter > >> >> > doesn't work well when performing unit tests "out-of-OSGi". > >> >> > > >> >> > My strategy so far has been to maintain separate persistence > >> >> > descriptors for the different scenarios: A persistence.xml for the > >> >> > unit > >> >> > tests and a persistence-openjpa.xml for use in the container. The > >> >> > latter won't be picked up automatically outside a container but can > >> >> > be > >> >> > specified explicitly using Meta-Persistence in OSGi. It's not an > >> >> > ideal > >> >> > solution and I'm not yet sure that it will work. Is there a best > >> >> > practice in this area? > >> >> > > >> >> > Thanks, > >> >> > > >> >> > /Bengt > >> >> > > >> >> > 2010/9/7 David Jencks> > >> >> > > >> >> > On Sep 7, 2010, at 12:10 AM, Bengt Rodehav wrote: > >> >> > > >> >> >> Lots of mails from me today - just trying to get on top of > >> >> >> things.... > >> >> >> > >> >> >> I'm investigating the best way to deploy a JPA based application > in > >> >> > OSGi. I've successfully used Karaf and iPojo in combination with > >> >> > Camel > >> >> > before but JPA seems a bit more complicated. > >> >> >> > >> >> >> Using Aries components (jpa, transaction and blueprint) seems to > >> >> > provide the functionality I need. However, one problem for me is > how > >> >> > to > >> >> > being able to unit test my services without having to startup a > Karaf > >> >> > instance. In the past I've been using Spring/Hibernate for this > >> >> > purpose. Spring is very flexible in the sense that I can configure > a > >> >> > test environment for my unit test and still being able to test > >> >> > services > >> >> > that uses transactions. > >> >> >> > >> >> >> In more detail, my problem is as follows: > >> >> >> > >> >> >> I have DAO objects containing persistence logic using JPA. These > are > >> >> > used by my service objects that contains business logic and also > >> >> > specifies transaction requirements. I can deploy those objects in > >> >> > Karaf using Aries. However, I don't know how to unit test those > >> >> > services since they need the presence of Aries. I know that this > >> >> > might > >> >> > be defined as integration tests (and not unit tests) for that > reason > >> >> > but I would still like a convenient way to execute these tests as > >> >> > part > >> >> > of my maven build and preferrably without having to deploy Karaf. > Is > >> >> > that possible? > >> >> >> > >> >> >> If not, what is the recommended way (best practice) for these kind > >> >> >> of > >> >> > tests? > >> >> > > >> >> > Use ops4j pax-runner. There are a bunch of integration tests in > aries > >> >> > that use this. > >> >> >> > >> >> >> BTW it is not easy to unit test the DAO objects either since I > need > >> >> > to get hold of an entity manager in completely different ways > >> >> > depending > >> >> > on if I'm in an OSGi environment or not. I could take some advice > on > >> >> > this subject as well... > >> >> > > >> >> > If you code your DAO objects using constructor dependency > injection, > >> >> > one of the arguments being the EMF, can't you inject it in > >> >> > blueprint/osgi and simply supply it as a constructor argument in > unit > >> >> > tests? > >> >> > > >> >> > If you do some kind of service lookup in your DAO then you will tie > >> >> > it > >> >> > to whatever lookup technology you are using (service registry for > >> >> > osgi, > >> >> > jndi for java ee,....) > >> >> > > >> >> > hope this is relevant to what you are asking about... > >> >> > david jencks > >> >> > > >> >> >> > >> >> >> Best regards, > >> >> >> > >> >> >> /Bengt > >> >> >> > >> >> > > >> >> > > >> >> > >> > > > >
