-
Notifications
You must be signed in to change notification settings - Fork 40.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failure during test AOT processing when multiple merged context configurations result in the Logback model being written multiple times #36997
Comments
Can reproduce this:
Tested against Spring Boot 3.2.0-SNAPSHOT and Spring Cloud 2023.0.0-SNAPSHOT and it still happens. Looks like |
We should shield ourselves from problems like this (contributor called twice for something we expect to be present only once). Perhaps something that is missing in the core AOT api? |
Just a note about developer experience on this: it was tricky to track the actual problem because the TestContextAotGenerator log is debug level and the So I was always getting the message
And running Perhaps this is a chance to expose the failOnError flag to the maven plugin and also increase the log level to error since the next step will fail anyways. edit: just noticed that spring-projects/spring-framework#30977 sets the default value of failOnError to true. I have tested with 6.0.12-SNAPSHOT and have not seem this behavior being applied for this case. Perhaps I was doing something wrong here - but it worths a double check that it will work as expected and fail the mvn plugin execution |
Unfortunately, I think it's more complicated than this. When the model is generated multiple times it implies that there are multiple merged context configurations. When there are multiple merged context configurations, there may be multiple different Logback models, for example because the merged context configurations have different To avoid the failure where we try to write the resource multiple times to the same location, I think the resources will have to be namespaced somehow. This would require changes to both the code that generates the resource and the code that loads it. |
I've opened spring-projects/spring-framework#31331. |
Until #31331 has been fixed, we could improve the situation by detecting whether the model that we want to write is identical to the existing file. If it is, we can skip writing it rather than failing. We'd still have to fail in situations where the models are different. @snicoll @sbrannen do you have a feel for when spring-projects/spring-framework#31331 may be fixed? It would be useful to know as it would allow us to determine if implementing the above workaround would be a good use of time. |
It's not strictly related to testing but rather to mutiple context handling within the same context. This could happen if a child context had to write a file that the main one had to do as well. I have a few ideas to implement this but it might require an API change. If it does, then 6.2. I think it would be interesting to implement the workaround. |
I've already discussed this with @snicoll, but wanted to make a note here so that I don't forget. Looking at the workaround for the Logback model writing problem. It's not straightforward unfortunately. private boolean duplicateModel(byte[] newModel, IllegalStateException failure) {
if (failure.getCause() instanceof FileAlreadyExistsException faex) {
try {
byte[] existingModel = Files.readAllBytes(new File(faex.getFile()).toPath());
return Arrays.equals(existingModel, newModel);
}
catch (IOException ex) {
// Continue
}
}
return false;
} I'm relying on an implementation detail of Unfortunately, I think we'd need some changes to |
FWIW, I managed to reproduce the issue at my repo, using the There is one test class that is using an So, it is the same root cause, but through a different code path. I thought I should post my results here in case that changes anything in your internal prioritization system. I would also greatly appreciate a workaround for my case, if you can think of something, since I strongly depend on the use of |
@meletis, So, if you're using Spring Boot 3.2, I suggest you look into the newly introduced |
@sbrannen , oooh! I didn't know that because I'm really new to AOT in general. Thank you very much for the guidance! |
The underlying issue in Framework is scheduled for 6.2.x. In the absence of a robust workaround, this needs to move out to Boot 3.4. |
Hi,
I'm getting the following error when running
./mvnw -Dspring.aot.enabled=true test
:This is because during
./mvnw clean test spring-boot:process-test-aot
the following exception is thrown, preventing theAotTestContextInitializers
from being generated for some of the IT classes:I have tested with fw 6.0.12-SNAPSHOT containing spring-projects/spring-framework#30861 patch but the error still occurs.
Reproducing
This issue is similar to #34337 and can be reproduced when:
Minimal project example: https://github.com/chicobento/test-context-spring-native
The text was updated successfully, but these errors were encountered: