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
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>
