Announcement Announcement Module
No announcement yet.
Spring-Data JPA JUnit and Load Time Weaving Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring-Data JPA JUnit and Load Time Weaving

    Hi all,

    wie have some serious problems to get our JUnit Test running. Here is our setup:
    • Java 1.7
    • Spring-Data JPA 1.3.0.RELEASE
    • EclipseLink 2.4.1 with Load Time Weaving (LTW)
    • JUnit 4.11
    • H2 Database for tests
    • target Servlet container Tomcat 7

    We want to use LTW in our JUnit Tests to ensure the tests behave the same in tests and in the target servlet container.

    Our POM contains
    to ensure the LTW for the tests.

    Before using LTW in tests we had several helper methods in our testcases to create business models like
    public class BrandRepositoryTest{
        private BrandRepository brandRepository;
        private Brand createTestBrand(){...}
    With this approach the LTW was broken for all tests. We figured out the problem was something with the JUnit classloader, the model entities were loaded before the EclipseLink weaving process was done and the result are annoying error messages like
    ERROR! java.lang.NoSuchMethodError: ..._persistence_checkFetchedForSet(Ljava/lang/String;)V
    We were able to solve that issue creating helper classes for creating our test models and the helper classes are injected by Spring so JUnit does not find the business models in the signature or as return value in the test methods.

    This approach works for single tests or for a bunch of tests, but if we try to run all tests in the buildprocess it may fail or may not fail - absolutely not acceptable.

    Is there any official approach to use Spring-Data JPA in JUnit tests with LTW? Something which ensures that JUnit waits for the weaving process?

    Any help is appreciated,

  • #2
    It's been awhile since you posted this obviously, but this was an issue for us as well and I found it really annoying to have to deal with. Essentially, you had to ensure that your JUnit test cases did not have a load time reference (direct or otherwise) to any code that would cause your entities to get loaded by the junit classloader before the load time weaving could occur. We had a very large codebase with thousands of integration tests so I thought it would be a battle to try and deal with this without a clever solution.

    So I wrote this thing:

    Basically, you just add this to the top of your JUnit test:


    And then things should just work. The way this functions is by essentially copying the classpath after the JUnit class gets loaded into a new custom classloader and then using that to load the test for each run. So you sort of get a second chance to do load time weaving within the context of the new classloader.

    Furthermore, I implemented this so the custom classloader is actually "instrumentable" so there is no need to use a -javaagent anymore when you set up the jvm that is going to run your test. So that's sort of a nice bonus

    Try it out and let me know if you have any luck with it. It seemed to work for us.



    • #3
      Hi everybody,

      I apologize for my late reply. I found a solution different from Eric's for the Load Time Weaving. In my case the solution was to use Static Weaving.
      You can find a detailed description for project setup with Maven and a demo project on my blog on

      Hope that helps somebody,
      My last Vaadin project at work is a somehow complex application and I was looking for a persistence layer which matches perfectly the given techniques Maven and Spring. I wanted to avoid Hibernate's lazy loading exceptions, so I searched for alternatives and found EclipseLink as standard JPA implementation (I also planed to use JPA&