Maven Surefire

persistence.xml in src/test/resources/META-INF is not taken into account

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.9
  • Fix Version/s: Backlog
  • Component/s: classloading
  • Labels:
  • Environment:
    Windows XP
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

When i have a persistence.xml in /src/main/resources/META-INF and in /src/test/resources/META-INF the xml for the test is never used. I found a few issues how to fix this but nobody had an explanation why this behavior is as it is. For me this behavior is really strange (and I couldn't believe that this is not my fault and is really not working). It seem this has to do with classloading - in my opinion, the test classes and the test resources should have priority, otherwise the whole separation of main/test is useless. I hope, that there is no real reason why this is so at the moment, because this behavior is really strange and absolutely against what the normal user would expect.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kristian Rosenvold added a comment -

Which issue/solutuion are you referring to ?

Show
Kristian Rosenvold added a comment - Which issue/solutuion are you referring to ?
Hide
Permalink
Wolfgang Grossinger added a comment -

Look at this link: http://stackoverflow.com/questions/385532/how-to-configure-jpa-for-testing-in-maven

Show
Wolfgang Grossinger added a comment - Look at this link: http://stackoverflow.com/questions/385532/how-to-configure-jpa-for-testing-in-maven
Hide
Permalink
Kristian Rosenvold added a comment -

Complain to JPA about this issue, proposing as wontfix here.

Show
Kristian Rosenvold added a comment - Complain to JPA about this issue, proposing as wontfix here.
Hide
Permalink
Marcin Cinik added a comment -

I'm facing the same issue. This is in my opinion not an issue with JPA. In any situation, there is a configuration file which must be different for testing/normal build, this problem occurs.
Let's say I have
src/main/resources/META-INF/ejb-jar.xml
src/test/resources/META-INF/ejb-jar.xml

those two files contain different configuration (for whatever reason - you can imagine that I'm binding mock session beans instead of real ones). In this case the plugin would create two directories
target/classes/META-INF/ejb-jar.xml
target/test-classes/META-INF/ejb-jar.xml

and include both files in the classpath which disables our embedded testing app-server from resolving the right one.

I don't understand the rationale behind the last comment of Kristian Rosenvold:

Complain to JPA about this issue

Can you spotlight a bit what you meant ? It looks like it doesn't only concern JPA...

Show
Marcin Cinik added a comment - I'm facing the same issue. This is in my opinion not an issue with JPA. In any situation, there is a configuration file which must be different for testing/normal build, this problem occurs. Let's say I have src/main/resources/META-INF/ejb-jar.xml src/test/resources/META-INF/ejb-jar.xml those two files contain different configuration (for whatever reason - you can imagine that I'm binding mock session beans instead of real ones). In this case the plugin would create two directories target/classes/META-INF/ejb-jar.xml target/test-classes/META-INF/ejb-jar.xml and include both files in the classpath which disables our embedded testing app-server from resolving the right one. I don't understand the rationale behind the last comment of Kristian Rosenvold: Complain to JPA about this issue Can you spotlight a bit what you meant ? It looks like it doesn't only concern JPA...
Hide
Permalink
Kristian Rosenvold added a comment -

The way this works is that when the tests are being run, the classpath for the /tests/ will be before the the classpath of the regular production files in the classpath. So even though there are multiple instances of the file, even the most brain damaged of tools should pick up the files in the correct classpath order.

In a multi-module project only the "test" scope of the module being run is included in the classpath, which means that your test-scoped configuration needs to be in src/test/resources of the actual unit test project being run. If this sounds like a limitation you can build a separate jar file with test scope that contains these jar files.

The linked stackoverflow post seems to indicate that JPA has somehow messed up this scheme.

Show
Kristian Rosenvold added a comment - The way this works is that when the tests are being run, the classpath for the /tests/ will be before the the classpath of the regular production files in the classpath. So even though there are multiple instances of the file, even the most brain damaged of tools should pick up the files in the correct classpath order. In a multi-module project only the "test" scope of the module being run is included in the classpath, which means that your test-scoped configuration needs to be in src/test/resources of the actual unit test project being run. If this sounds like a limitation you can build a separate jar file with test scope that contains these jar files. The linked stackoverflow post seems to indicate that JPA has somehow messed up this scheme.
Hide
Permalink
Marcin Cinik added a comment -

Thank you for the clarification - it's very helpful. And you are right that it is not a maven problem.
It looks like the problem also occurs for OpenEJB and it concerns ejb-jar.xml, but I'm still in progress of finding the root cause of my problems. Anyway it's not a good place to discuss this specific issue.

Show
Marcin Cinik added a comment - Thank you for the clarification - it's very helpful. And you are right that it is not a maven problem. It looks like the problem also occurs for OpenEJB and it concerns ejb-jar.xml, but I'm still in progress of finding the root cause of my problems. Anyway it's not a good place to discuss this specific issue.
Hide
Permalink
Kristian Rosenvold added a comment -

A common approach to solving this issue is to have the following dependency chain (A->B->C) (A depends on B depends on C). In module B & C you can have the test configuration in test scope only and not in main scope. In module A you have the configuration in main scope only. In that way module "A" will be the only one with the non-test configuration.

Show
Kristian Rosenvold added a comment - A common approach to solving this issue is to have the following dependency chain (A->B->C) (A depends on B depends on C). In module B & C you can have the test configuration in test scope only and not in main scope. In module A you have the configuration in main scope only. In that way module "A" will be the only one with the non-test configuration.
Hide
Permalink
Giovanni Silva added a comment -

I have this issue to, I think is related to class loading too because some times I run the tests and the correct file is matched sometimes not.

Show
Giovanni Silva added a comment - I have this issue to, I think is related to class loading too because some times I run the tests and the correct file is matched sometimes not.

People

  • Assignee:
    Unassigned
    Reporter:
    Wolfgang Grossinger
Vote (1)
Watch (2)

Dates

  • Created:
    Updated: