I'm running out of ideas...
My spring boot app behaves fine when I run it in indellij and gradle idea plugin is applied (apply plugin: 'idea').
Once I remove the plugin from build.gradle it behaves similarly to app executed with java -jar app.jar - there is subtle but important difference, description below.
I have the following scenario, current tx fails due to some exception, tx is marked as roll-back-only, exception is caught and its handling consists of registering post tx recovery activity with TransactionSynchronizationManager.registerSynchronization (new tx).
The code works fine in intellij with idea plugin, when I remove plugin declaration or run spring boot jar with java -jar registering process (post tx failure task) fails with exception:
Caused by: java.lang.IllegalStateException: Transaction synchronization is not active
at org.springframework.transaction.support.TransactionSynchronizationManager.registerSynchronization(TransactionSynchronizationManager.java:291) ~[spring-tx-4.3.10.RELEASE.jar!/:4.3.10.RELEASE]
Btw, the code is in kotlin if it matters.
Any ideas?
UPDATE
I think there is some kind of race condition because in debug mode, even w/o idea plugin, the app behaves as expected (registering process is successful).
I solved my problem and the root cause was quite surprising...
Apparently there's a problem with correct processing of custom Spring annotation.
The method which was supposed to open a new transaction was not annotated with a standard #Transactional annotation, but with custom, application specific annotation (#Transactional with custom tx settings). Debugging session revealed that new tx was not being open. That's it! Inlining custom annotation nearly solved a problem.
Another flaw I detected was a function which was not open, quite strange because the function was not transaction entry point (som further call).
Kotlin compiler bug?
Anyway, lessons learned - pay attention to custom annotations behaviour; refresh knowledge about rules for final/open.
Related
I have a Spring Boot 2.6.0 application that depends on libraries which use fields initialised with SpEL syntax, e.g.
#Value("${some.value.in.library}") aField;
I attempted to write a Spring MVC test for a controller with #WebMvcTest. However I kept getting failed to load applicationcontext errors due to a SpELEvaluationException for the fields mentioned above.
Even after trying many, many, different test annotations such as #ConfigurationProperties and other fixes. I could see the properties that are defined in application-test.yml being loaded in the startup logs but they were not getting injected into the class.
Finally, I tried using:
MockMvcBuilders.standaloneSetup
and the test was able to start and run successfully.
Unfortunately, due to the complexity of the application and the use of a library where the problem occurs, it is difficult to create a minimal reproducable example.
So my question is, why does MockMvcBuilders.standaloneSetup work, whereas #MockMvcTest doesn't?
This answer suggests that #MockMvcTest should not load the full application context. But that does not seem to be the case based on the failed to load applicationcontext errors.
I have used a Spring Boot Scheduler with #Scheduled annotation along with fixedRateString of 1 sec. This scheduler intermittently stops working for approx 2 min and then starts working automatically. What can be the possible reasons for this behavior and do we have any resolution to this?
Below is the code snippet for the scheduler.
1st) Please read SO guidelines
DO NOT post images of code, data, error messages, etc. - copy or type
the text into the question. Please reserve the use of images for
diagrams or demonstrating rendering bugs, things that are impossible
to describe accurately via text.
2nd) To your problem
You use a xml spring based configuration where you have configured your sheduler. Then you also use the annotation #Scheduled. You should not mix those 2 different types of configuring beans.
Also you use some type of thread synchronization into this method. Probably some thread is stuck outside of the method because of the lock and this messes the functionality that you want.
Clean either the xml configuration or the annotation for scheduling and try with debug to see why the method behaves as it does which most probable would be from what I have mentioned above about the locks and the multiple configurations.
Prior to Spring Boot v1.5.11, the following worked for referring to a file called auth.json in src/main/resources:
spring.cloud.gcp.credentials.location=auth.json
Starting with v1.5.11 and continuing through into 1.5.12, the above results in a FileNotFound exception. But the following works:
spring.cloud.gcp.credentials.location=classpath:auth.json
What changed in Spring Boot 1.5.12 (or its underlying dependencies) that was responsible for this?
This was caused by a fix to another issue and is being tracked via another reported instance here: https://github.com/spring-projects/spring-boot/issues/12786
Practitioners hitting this behavior may either update their implementation in an appropriate way (e.g., in our sanitized sample, it would be to prefix the property with "classpath:") or to wait to see if further resolution (that doesn't regress the other fix that caused this) is possible.
h/t #Stephane-Nicoll and Andy Wilkinson.
I have a Spring Boot 2 application (still in the development stage) running well with JPA, hibernate and so on. The single persistence test I've got right now goes thru fine.
However, when I add #EnableBatchProcessing to the main boot class (the one annotated with #SpringBootApplication) I get the following error during the test phase of the maven build:
javax.persistence.TransactionRequiredException: no transaction is in
progress
If I just remove this annotation the test runs successfully again.
I read somewhere that spring Batch uses a different transaction manager than that used for JPA persistence.
How can I fix this issue?
Thanks in advance.
This is very simple.#EnableBatchProcessing annotation causes Spring Batch to automatically register a transaction manager to use for its transactions, and your JpaTransactionManager never gets used.
Reason:
By default, #EnableBatchProcessing triggers the creation of a DataSourceTransactionManager. This transaction manager knows nothing about JPA/Hibernate which causes the problem you're seeing.
Solution:
Now, if you want to change the transaction manager that Spring Batch uses for transactions, you have to implement the interface BatchConfigurer. There is a link to an example where a user has done this. What he is doing is switching the transaction manager to his own transactionmanager.
This question has been posted before but I am not sure if it was ever resolved. I am facing exactly the same issue as (19608050 - same title). I am using spring-boot-started-web:1.1.0.RC1 ,spring-data-hadoop 1.0.2.RELEASE and hbase 0.94.3. I can see the hadoop-core-1.2.1 jar under the lib\ in the jarred file which I deploy.
I have a small sample project which I posted on: https://github.com/klopes/test-spring-boot-hadoop.git. It compiles (and unit tests worked successfully) but it fails to deploy.
If I start the app by clicking on the main class in my IDE, it runs without any exceptions and the jar is loaded, also gradle runBoot works just fine. Seems like a spring boot class loader bug.
#EnableAutoConfiguration(exclude = {VelocityAutoConfiguration.class})
You are using a very old version of Spring Boot. Your app runs for me with Spring Boot 1.1.0.BUILD-SNAPSHOT, at least the context starts with no errors. There are no test cases so I'm not sure if it's actually working though.