I have written some JUnit tests using JUnit 4 and spring-test libraries. When I run the tests inside Eclipse then run fine and pass. But when I run them using Maven (during the build process), they fail giving a spring related error. I am not sure what is causing the problem, JUnit, Surefire or Spring. Here is my test code, spring configuration and the exception that I get from Maven:
PersonServiceTest.java
package com.xyz.person.test;
import static com.xyz.person.util.FjUtil.toFjList;
import static junit.framework.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
import java.util.List;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;
import com.xyz.person.bo.Person;
import com.xyz.person.bs.PersonService;
import fj.Effect;
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = { "classpath*:personservice-test.xml" })
#TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = false)
public class PersonServiceTest {
#Autowired
private PersonService service;
#Test
#Transactional
public void testCreatePerson() {
Person person = new Person();
person.setName("abhinav");
service.createPerson(person);
assertNotNull(person.getId());
}
#Test
#Transactional
public void testFindPersons() {
Person person = new Person();
person.setName("abhinav");
service.createPerson(person);
List<Person> persons = service.findPersons("abhinav");
toFjList(persons).foreach(new Effect<Person>() {
public void e(final Person p) {
assertEquals("abhinav", p.getName());
}});
}
}
personservice-test.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<import resource="classpath:/personservice.xml" />
<bean id="datasource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource"
lazy-init="true">
<property name="driverClassName" value="org.apache.derby.jdbc.EmbeddedDriver" />
<property name="url" value="jdbc:derby:InMemoryDatabase;create=true" />
</bean>
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="datasource" />
<property name="persistenceUnitName" value="PersonService" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="databasePlatform" value="org.hibernate.dialect.DerbyDialect" />
<property name="showSql" value="true" />
<property name="generateDdl" value="true" />
</bean>
</property>
<property name="jpaPropertyMap">
<map>
<entry key="hibernate.validator.autoregister_listeners" value="false" />
<entry key="javax.persistence.transactionType" value="RESOURCE_LOCAL" />
</map>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="dataSource" ref="datasource" />
</bean>
<tx:annotation-driven transaction-manager="transactionManager"
proxy-target-class="false" />
<bean id="beanMapper" class="org.dozer.DozerBeanMapper">
<property name="mappingFiles">
<list>
<value>personservice-mappings.xml</value>
</list>
</property>
</bean>
</beans>
Exception in Maven
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.xyz.person.test.PersonServiceTest
23:18:51,250 WARN JDBCExceptionReporter:77 - SQL Warning: 10000, SQLState: 01J01
23:18:51,281 WARN JDBCExceptionReporter:78 - Database 'InMemoryDatabase' not created, connection made to existing database instead.
23:18:52,937 WARN JDBCExceptionReporter:77 - SQL Warning: 10000, SQLState: 01J01
23:18:52,937 WARN JDBCExceptionReporter:78 - Database 'InMemoryDatabase' not created, connection made to existing database instead.
23:18:52,953 WARN TestContextManager:429 - Caught exception while allowing TestExecutionListener [org.springframework.test.context.transaction.TransactionalTestExecutionListener#359a359a] to process 'after' execution for test: method [public void com.xyz.person.test.PersonServiceTest.testCreatePerson()], instance [com.xyz.person.test.PersonServiceTest#1bc81bc8], exception [org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! JpaTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single JpaTransactionManager for all transactions on a single DataSource, no matter whether JPA or JDBC access.]
java.lang.IllegalStateException: No value for key [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean#3f563f56] bound to thread [main]
at org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager.java:199)
at org.springframework.orm.jpa.JpaTransactionManager.doCleanupAfterCompletion(JpaTransactionManager.java:489)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager.java:1011)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:804)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener$TransactionContext.endTransaction(TransactionalTestExecutionListener.java:515)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.endTransaction(TransactionalTestExecutionListener.java:290)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.afterTestMethod(TransactionalTestExecutionListener.java:183)
at org.springframework.test.context.TestContextManager.afterTestMethod(TestContextManager.java:426)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:90)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
23:18:53,078 WARN TestContextManager:377 - Caught exception while allowing TestExecutionListener [org.springframework.test.context.transaction.TransactionalTestExecutionListener#359a359a] to process 'before' execution of test method [public void com.xyz.person.test.PersonServiceTest.testFindPersons()] for test instance [com.xyz.person.test.PersonServiceTest#79f279f2]
org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! JpaTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single JpaTransactionManager for all transactions on a single DataSource, no matter whether JPA or JDBC access.
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:304)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:371)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener$TransactionContext.startTransaction(TransactionalTestExecutionListener.java:507)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.startNewTransaction(TransactionalTestExecutionListener.java:269)
at org.springframework.test.context.transaction.TransactionalTestExecutionListener.beforeTestMethod(TransactionalTestExecutionListener.java:162)
at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:374)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:73)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 15.625 sec <<< FAILURE!
Results :
Tests in error:
testCreatePerson(com.xyz.person.test.PersonServiceTest)
testCreatePerson(com.xyz.person.test.PersonServiceTest)
testFindPersons(com.xyz.person.test.PersonServiceTest)
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0
I had the same problem (JUnit tests failed in Maven Surefire but passed in Eclipse) and managed to solve it by setting forkMode to always in the maven surefire configuration in pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<forkMode>always</forkMode>
</configuration>
</plugin>
Surefire parameters: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
Edit (January 2014):
As Peter Perháč pointed out, the forkMode parameter is deprecated since Surefire 2.14. Beginning from Surefire 2.14 use this instead:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
<configuration>
<reuseForks>false</reuseForks>
<forkCount>1</forkCount>
</configuration>
</plugin>
For more information see Fork Options and Parallel Test Execution
I suddenly experienced this error, and the solution for me was to disable to run tests in parallel.
Your milage may vary, since I could lower number of failing tests by configuring surefire to run parallel tests by ´classes´.:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<parallel>classes</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
As I wrote first, this was not enough for my test suite, so I completely disabled parallel by removing the <configuration> section.
Test execution result different from JUnit run and from maven install seems to be symptom for several problems.
Disabling thread reusing test execution did also get rid of the symptom in our case, but the impression that the code was not thread-safe was still strong.
In our case the difference was due to the presence of a bean that modified the test behaviour. Running just the JUnit test would result fine, but running the project install target would result in a failed test case. Since it was the test case under development, it was immediately suspicious.
It resulted that another test case was instantiating a bean through Spring that would survive until the execution of the new test case. The bean presence was modifying the behaviour of some classes and producing the failed result.
The solution in our case was getting rid of the bean, which was not needed in the first place (yet another prize from the copy+paste gun).
I suggest everybody with this symptom to investigate what the root cause is. Disabling thread reuse in test execution might only hide it.
I had a similar problem, the annotation #Autowired in the test code did not work under using the Maven command line while it worked fine in Eclipse. I just update my JUnit version from 4.4 to 4.9 and the problem was solved.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.1</version>
</dependency>
This doesn't exactly apply to your situation, but I had the same thing -- tests that would pass in Eclipse failed when the test goal from Maven was run.
It turned out to be a test earlier in my suite, in a different package. This took me a week to solve!
An earlier test was testing some Logback classes, and created a Logback context from a config file.
The later test was testing a subclass of Spring's SimpleRestTemplate, and somehow, the earlier Logback context was held, with DEBUG on. This caused extra calls to be made in RestTemplate to log HttpStatus, etc.
It's another thing to check if one ever gets into this situation. I fixed my problem by injecting some Mocks into my Logback test class, so that no real Logback contexts were created.
I have the similar problem, but with IntelliJ IDEA + Maven + TestNG + spring-test. (spring-test is essential of course :) )
It was fixed when I've change config of maven-surefire-plugin to disable run tests in parallel. Like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
<configuration>
<skipTests>${maven.test.skip}</skipTests>
<trimStackTrace>false</trimStackTrace>
<!--<parallel>methods</parallel>-->
<!-- to skip integration tests -->
<excludes>
<exclude>**/IT*Test.java</exclude>
<exclude>**/integration/*Test.java</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skipTests>${maven.integration-test.skip}</skipTests>
<!-- Make sure to include this part, since otherwise it is excluding Integration tests -->
<excludes>
<exclude>none</exclude>
</excludes>
<includes>
<include>**/IT*Test.java</include>
<include>**/integration/*Test.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
I had the same issue, but the problem for me was that Java assertions (e.g. assert(num > 0)) were not enabled for Eclipse, but were enabled when running maven.
Therefore running the jUnit tests from Eclipse did not catch trigger the assertion error.
This is made clear when using jUnit 4.11 (as opposed to the older version I was using) because it prints out the assertion error, e.g.
java.lang.AssertionError: null
at com.company.sdk.components.schema.views.impl.InputViewHandler.<init>(InputViewHandler.java:26)
at test.com.company.sdk.util.TestSchemaExtractor$MockInputViewHandler.<init>(TestSchemaExtractor.java:31)
at test.com.company.sdk.util.TestSchemaExtractor.testCreateViewToFieldsMap(TestSchemaExtractor.java:48)
I had a similar problem with a different cause and therefore different solution. In my case, I actually had an error where a singleton object was having a member variable modified in a non-threadsafe way. In this case, following the accepted answers and circumventing the parallel testing would only hide the error that was actually revealed by the test. My solution, of course, is to fix the design so that I don't have this bad behavior in my code.
[I am not sure that this is an answer to the original question, since the stacktrace here looks slightly different, but it may be useful to others.]
You can get tests failing in Surefire when you are also running Cobertura (to get code coverage reports). This is because Cobertura requires proxies (to measure code use) and there is some kind of conflict between those and Spring proxies. This only occurs when Spring uses cglib2, which would be the case if, for example, you have proxy-target-class="true", or if you have an object that is being proxied that does not implement interfaces.
The normal fix to this is to add an interface. So, for example, DAOs should be interfaces, implemented by a DAOImpl class. If you autowire on the interface, everything will work fine (because cglib2 is no longer required; a simpler JDK proxy to the interface can be used instead and Cobertura works fine with this).
However, you cannot use interfaces with annotated controllers (you will get a runtime error when trying to use the controller in a servlet) - I do not have a solution for Cobertura + Spring tests that autowire controllers.
I had a similar problem: JUnit tests failed in Maven Surefire but passed in Eclipse when I used JUnit library version 4.11.0 from SpringSource Bundle Repository. Particulary:
<dependency>
<groupId>org.junit</groupId>
<artifactId>com.springsource.org.junit</artifactId>
<version>4.11.0</version>
</dependency>
Then I replaced it with following JUnit library version 4.11 and everything works fine.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
I had this problem today testing a method that converted an object that contained a Map to a JSON string. I assume Eclipse and the Maven surefire plugin were using different JREs which had different implementations of HashMap ordering or something, which caused the tests run through Eclipse to pass and the tests run through surefire to fail (assertEquals failed). The easiest solution was to use an implementation of Map that had reliable ordering.
This has helped me in troubleshooting my problem. I had a similar symptoms in that maven would fail however running junit tests runs fine.
As it turns out my parent pom.xml contains the following definition:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
<configuration>
<forkMode>pertest</forkMode>
<argLine>-Xverify:none</argLine>
</configuration>
</plugin>
And in my project I override it to remove the argLine:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
<argLine combine.self="override"></argLine>
</configuration>
</plugin>
Hopefully this will help someone in troubleshooting surefire plugin.
In my case the reason was a bug in the code. The test relied on a certain order of elements in a HashSet, which turned out to be different when run either in Eclipse or in Maven Surefire.
I had a similar problem, I ran my tests disabling the reuse of forks like this
mvn clean test -DreuseForks=false
and the problem disappeared.
The downside is that the overall test execution time will be longer, that's why you may want to do this from the command line only if necessary
You don't need to inject a DataSource in the JpaTransactionManager since the EntityManagerFactory already has a datasource. Try the following:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
Usually when tests pass in eclipse and fail with maven it is a classpath issue because it is the main difference between the two.
So you can check the classpath with maven -X test and check the classpath of eclipse via the menus or in the .classpath file in the root of your project.
Are you sure for example that personservice-test.xml is in the classpath ?
I had the same problem, and the solution for me was to allow Maven to handle all dependencies, including to local jars. I used Maven for online dependencies, and configured build path manually for local dependencies.
Thus, Maven was not aware of the dependencies I configured manually.
I used this solution to install the local jar dependencies into Maven:
How to add local jar files in maven project?
It is most likely that your configuration files are in src/main/resources, while they must be under src/test/resources to work properly under maven.
https://cwiki.apache.org/UIMA/differences-between-running-unit-tests-in-eclipse-and-in-maven.html
I'm replying this after two years 'cause I couldn't find this answer here and I think it is the right one.
Related
After adding module-info.java files to my project my checkstyle plugin start failing with:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
(default-cli) on project email: Failed during checkstyle
configuration: NoViableAltException occurred during the analysis of
file
/home/xxx/IdeaProjects/blynk-server/server/notifications/email/src/main/java/module-info.java.
unexpected token: module -> [Help 1]
I tried
<module name="BeforeExecutionExclusionFileFilter">
<property name="fileNamePattern" value="module\-info\.java$"/>
</module>
However, it failed with:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
(default-cli) on project blynk: Failed during checkstyle
configuration: cannot initialize module
BeforeExecutionExclusionFileFilter - Unable to instantiate
'BeforeExecutionExclusionFileFilter' class, it is also not possible to
instantiate it as
com.puppycrawl.tools.checkstyle.checks.annotation.BeforeExecutionExclusionFileFilter
What is the correct way for skipping module-info.java files during checkstyle for maven-checkstyle-plugin?
Not sure why the Checkstyle filter is not working (this reported bug seems very similar to yours and it was fixed in version 7.3.0, so maybe you need to update Checkstyle).
Anyway the Maven excludes element is also supposed to do this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<excludes>**/module-info.java</excludes>
</configuration>
</plugin>
More in the plugin goal documentation.
BeforeExecutionExclusionFileFilter was added in Checkstyle 7.2.
But the maven-checkstyle-plugin version 3.0.0 (which is the latest version as of 2018-04-01) uses Checkstyle 6.18 by default.
"Checkstyle" and "Checkstyle Maven Plugin" are different things and have different release cycles.
You may want to upgrade the Checkstyle version as follows:
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.0.0</version> <!-- Checkstyle Plugin version -->
<!-- ... Configuration, Executions ... -->
<dependencies>
<dependency>
<groupId>com.puppycrawl.tools</groupId>
<artifactId>checkstyle</artifactId>
<version>8.8</version> <!-- Checkstyle version -->
</dependency>
</dependencies>
</plugin>
After that, BeforeExecutionExclusionFileFilter as well as other newer Checkstyle features (e.g. new checks) will be recognized.
Though this doesn't possibly qualify as an answer. Yet being too long to fit in comment, just to keep a note of the track that the maven-checkstyle-plugin is in:-
The last release of the was version 2.17 on 15-Oct-2015 which was almost 2 years back.
The current trunk of maven-plugins points to an ongoing work within the plugin in its 3.0.0-SNAPSHOT version which might mean we can soon expect a org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0 sometime in near future and which would understand the module-info.java as a class.
This doesn't align with the Java+9+-+Jigsaw doc that specifies the list of modules and plugins that are being upgraded to support JDK-9.
I was trying to use JOOQ in glassfish. I used code generator like this:
java -cp jOOQ-lib/jooq-3.3.1.jar:jOOQ-lib/jooq-meta-3.3.1.jar:jOOQ-lib/jooq-codegen-3.3.1.jar:mysql-connector-java-5.1.29-bin.jar:. org.jooq.util.GenerationTool /db.xml
Then imported the generated folder to my project.(I'm not using jooq maven plugin). When I deploy web app in glassfish I see this in server.log
[#|2014-04-06T14:53:37.720+0430|SEVERE|glassfish3.1.2|com.sun.xml.ws.server.sei.TieHandler|_ThreadID=670;_ThreadName=Thread-2;|org.jooq.impl.TableImpl.<init>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/Table;[Lorg/jooq/Field;Ljava/lang/String;)V
java.lang.NoSuchMethodError: org.jooq.impl.TableImpl.<init>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/Table;[Lorg/jooq/Field;Ljava/lang/String;)V
I have not changed any maven config just netbeans default config. maven artifact:
<dependency>
<groupId>org.jooq</groupId>
<artifactId>jooq</artifactId>
<version>3.3.1</version>
</dependency>
my db.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
<!-- Configure the database connection here -->
<jdbc>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://127.0.0.1/bulkdb?useUnicode=true</url>
<user>user</user>
<password>pass</password>
</jdbc>
<generator>
<database>
<name>org.jooq.util.mysql.MySQLDatabase</name>
<inputSchema>bulkdb</inputSchema>
<includes>.*</includes>
<excludes></excludes>
</database>
<target>
<packageName>bulkdb</packageName>
<directory>/home/user/jooq</directory>
</target>
</generator>
</configuration>
What is going wrong? Can someone help?
[UPDATE]
Actually there is two version of JOOQ in app server class path: one in lib directory of the domain(domain1/lib/) with version 3.1 and second one is 3.3.1 that is bundled in war file. Does this cause problems?
Actually there is two version of JOOQ in app server class path: one in lib directory of the domain(domain1/lib/) with version 3.1 and second one is 3.3.1 that is bundled in war file. Does this cause problems?
Yes, of course :-)
If you want to use both versions in parallel (do you really?), then you will probably need to resort to something like OSGi to be able to load the same class names in separate class loaders.
In your case, jOOQ 3.1 is loaded first by your application server, and thus jOOQ 3.3 cannot be loaded fully any more. The code generated with jOOQ 3.3 operates on new internal methods in TableImpl, which have been added in jOOQ 3.2 or 3.3, but since you're loading jOOQ 3.1, those methods aren't there. Note that this can happen with any external dependencies.
The solution here is really to remove jOOQ 3.1 from your application server.
I am trying to generate aggregate javadoc for multiple projects with Maven Javadoc plugin. If I run javadoc:javadoc goal the build finishes with SUCCESS. Anyhow I would like to combine all javadocs with javadoc:aggregate goal and it fails when trying to find org.jboss.msc.service package:
org.apache.maven.reporting.MavenReportException:
Exit code: 1 - /home/me/proj/proj/subproject1/src/main/java/com/test/hasingleton/HATimerServiceActivator.java:6: error: package org.jboss.msc.service does not exist
import org.jboss.msc.service.DelegatingServiceContainer;
How can I configure the maven javadoc plugin to exclude this import? I have tried with following settings:
<excludePackageNames>org.jboss.msc.service.*</excludePackageNames>
<dependencySourceExcludes>
<dependencySourceExclude>org.jboss.msc.service:*</dependencySourceExclude>
</dependencySourceExcludes>
But no luck. All help is appreciated!
You could try this way (include instead of exclude)
<configuration>
<!-- switch on dependency-driven aggregation -->
<includeDependencySources>true</includeDependencySources>
<dependencySourceIncludes>
<!-- include ONLY dependencies I control -->
<dependencySourceInclude>org.test.dep:*</dependencySourceInclude>
</dependencySourceIncludes>
</configuration>
Other way is to use artifact id (rather than package name)
<configuration>
<!-- switch on dependency-driven aggregation -->
<includeDependencySources>true</includeDependencySources>
<dependencySourceExcludes>
<!-- exclude ONLY commons-cli artifacts -->
<dependencySourceExclude>commons-cli:*</dependencySourceExclude>
</dependencySourceExcludes>
</configuration>
Background
/pom.xml
...
<properties>
...
<jdbc.driver>com.mysql.jdbc.Driver</jdbc.driver>
<jdbc.url>jdbc:mysql://${database.host}/${database.name}</jdbc.url>
<jdbc.user>${database.user}</jdbc.user>
<jdbc.password>${database.password}</jdbc.password>
...
</properties>
...
<profiles>
<profile>
<id>dev</id>
<properties>
...
<database.name>database</database.name>
<database.host>localhost</database.host>
<database.user>root</database.user>
<database.password></database.password>
...
</properties>
</profile>
</profiles>
...
/src/main/resources/database.properties
...
jdbc.driver=${jdbc.driver}
jdbc.url=${jdbc.url}
jdbc.user=${jdbc.user}
jdbc.password=${jdbc.password}
...
/src/main/resources/spring/applicationContext.xml
<beans ... xmlns:p="http://www.springframework.org/schema/p" ...>
...
<bean
id="dataSource"
...
p:driverClassName="${jdbc.driver}"
p:url="${jdbc.url}"
p:username="${jdbc.user}"
p:password="${jdbc.password}"
... />
...
</beans>
/src/test/java/com/company/project/service/MyItemServiceImplTest.java
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = { "/spring/applicationContext.xml" })
public class MyItemServiceImplTest {
#Resource
private MyItemService myItemService;
#Test
public void testSave() {
MyItem myItem = new MyItem();
myItemService.save(myItem);
...
}
}
Question
When running the tests, it throws an exception:
java.lang.IllegalStateException: Failed to load ApplicationContext
...
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in class path resource [spring/applicationContext.xml]: Could not resolve placeholder 'database.password'
...
I guess it's because I need to run the tests while specifying the dev profile like I do when I launch the webapp (using -P dev). But I can't make it work. Is it even possible?
PS
The filtered applicationContext.xml file (i.e. the one in /target/classes/spring/applicationContext.xml) is identical to the one in /src/*, but the filtered database.properties file (i.e. /target/classes/database.properties) looks like
jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://${database.host}/${database.name}
jdbc.user=${database.user}
jdbc.password=${database.password}
It means that from the pom.xml file to the .properties one, the properties have been well filtered, but within the pom.xml itself, the properties that depend on the chosen profile won't get filtered. Probably because I want to specify anywhere the profile I need when launching the tests. But as I said before, -P dev doesn't seem work with JUnit...
Resource filtering is performed in the process-resources phase. So if you state mvn test -Pdev you will have passed that phase and all filtering has been done. It doesn't matter to JUnit what profile you are running since you are not doing anything else differently in that dev profile.
I want to use the JPA EntityListener to support spring security ACLs.
On #PostPersist events, I create a permission corresponding to the persisted entity.
I need this operation to participate to the current Transaction.
For this to happen I need to have a reference to the application TransactionManager in the EntityListener.
The problem is, Spring can't manage the EntityListener as it is created automatically when EntityManagerFactory is instantiated.
And in a classic Spring app, the EntityManagerFactory is itself created during the TransactioManager instantiation.
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
So I have no way to inject the TransactionManager with the constructor, as it is not yet instantiated.
Making the EntityManager a #Component create another instance of the EntityManager.
Implementing InitiliazingBean and using afterPropertySet() doesn't work as it's not a Spring managed bean.
Any idea would be helpful as I'm stuck and out of ideas.
In addition to nodje's instruction you should add one more thing - add AnnotationBeanConfigurerAspect as dependency for your entity manager, otherwise your entity listeners will be created BEFORE spring context will be initialized:
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
depends-on="org.springframework.context.config.internalBeanConfigurerAspect">
A solution is to use Spring's #Configurable annotation on the EntityListener.
It should in theory allow a non Spring managed instance, the EntityListener in my case, to be aspect woven and thus allowing this instance to get DI.
So here're the different steps:
add #Configurable to the EntityListener and #Autowired on the filed to inject (TransactionManager here)
add <context:spring-configured/> to the Spring context
use aspects-maven-plugin to do Compile Time Weaving (see config below)
So far so good, but it's not working for me. The logs says the EntityListerner is woven:
[INFO] Extending interface set for type 'org.project.commons.security.DefaultEntityListener' (DefaultEntityListener.java) to include 'org.springframework.beans.factory.aspectj.ConfigurableObject' (AnnotationBeanConfigurerAspect.aj)
[INFO] Join point 'initialization(void org.springframework.beans.factory.aspectj.ConfigurableObject.<init>())' in Type 'org.project.commons.security.DefaultEntityListener' (DefaultEntityListener.java:38) advised by before advice from 'org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect' (spring-aspects-3.1.2.RELEASE.jar!AbstractDependencyInjectionAspect.class:78(from AbstractDependencyInjectionAspect.aj)) [with runtime test]
[INFO] Join point 'initialization(void org.springframework.beans.factory.aspectj.ConfigurableObject.<init>())' in Type 'org.project.commons.security.DefaultEntityListener' (DefaultEntityListener.java:38) advised by afterReturning advice from 'org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect' (spring-aspects-3.1.2.RELEASE.jar!AbstractDependencyInjectionAspect.class:87(from AbstractDependencyInjectionAspect.aj)) [with runtime test]
[INFO] Join point 'initialization(void org.project.commons.security.DefaultEntityListener.<init>())' in Type 'org.project.commons.security.DefaultEntityListener' (DefaultEntityListener.java:38) advised by afterReturning advice from 'org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect' (spring-aspects-3.1.2.RELEASE.jar!AbstractDependencyInjectionAspect.class:87(from AbstractDependencyInjectionAspect.aj)) [with runtime test]
but I never get the expected injection.
I anyone has a clue, I welcome it...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<showWeaveInfo>true</showWeaveInfo>
<proceedOnError>true</proceedOnError>
<outxml>true</outxml>
<source>1.6</source>
<target>1.6</target>
<complianceLevel>1.6</complianceLevel>
<encoding>${encoding}</encoding>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
<weaveDependencies>
<weaveDependency>
<groupId>org.project</groupId>
<artifactId>commons</artifactId>
</weaveDependency>
</weaveDependencies>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<!--<goal>test-compile</goal>-->
</goals>
</execution>
</executions>
</plugin>