Log4j2LoggingSystem pollutes Log4j2's environment with a SpringEnvironmentPropertySource that is never removed #40178
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Thanks for the sample. With commit ca981de8, the restart appears to be getting stuck here: Undertow is trying to throw the exception reported in #33450 but, for a reason that's unknown to me, the JVM's unable to fill in the exception's stack trace. This is the problem mentioned by @koww in #33450 (comment). The fact that the JVM's getting stuck when filling in the stack trace, means that the fix in Log4j2 to catch and swallow the exception does not help. I'm going to close this is a duplicate of #33450 as I don't think there's anything unique to your situation that needs to be tracked separately. |
wilkinsona
added
status: duplicate
|
On further investigation, I no longer consider this issue to be a duplicate. The JVM isn't getting stuck when filling in the stack trace, it's in an infinite loop due to some behavior of Log4j2 3.0 beta 1:
|
It's not just due to Devtools. The problem also occurs if you run one app after the other in the same JVM, like so: With Log4j2 3.0 beta 1, this will produce an infinite loop as we end up with two There's still a problem with Logj2 2.x as being stuck with the first Log4j2 will always see I think we need apache/logging-log4j2#2454 in order to fix this as it adds a /cc @ppkarwasz @rgoers |
spring-projects-issues
added
the
status: waiting-for-triage
|
@rlratcliffe Here's a hack that gets restarts working again with Log4j2 3.0 beta 1: public static void main(String[] args) {
SpringApplication app = new SpringApplication(CamelApplication.class);
app.addListeners(new ApplicationListener<ContextClosedEvent>() {
@Override
public void onApplicationEvent(ContextClosedEvent event) {
PropertiesUtil properties = PropertiesUtil.getProperties();
try {
Field environmentField = properties.getClass().getDeclaredField("environment");
environmentField.setAccessible(true);
Object environment = environmentField.get(properties);
Field sourcesField = environment.getClass().getDeclaredField("sources");
sourcesField.setAccessible(true);
@SuppressWarnings("unchecked")
Set<PropertySource> sources = (Set<PropertySource>) sourcesField.get(environment);
Iterator<PropertySource> iterator = sources.iterator();
while (iterator.hasNext()) {
PropertySource candidate = iterator.next();
if ("org.springframework.boot.logging.log4j2.SpringEnvironmentPropertySource".equals(candidate.getClass().getName())) {
iterator.remove();
System.out.println("Removed " + candidate);
}
}
}
catch (Exception ex) {
ex.printStackTrace();
}
}
});
app.run(args);
}This will be much more elegant once |
wilkinsona
changed the title
wilkinsona
added
type: bug
Yes, unfortunately you need for |
wilkinsona
removed
the
status: blocked
|
I think we can minimise the damage by using a static-scoped |
Sounds like a plan. That was actually the original implementation of |
|
Per Log4j 2.24 release notes, |
|
I'm not sure that it's worth refining things as the current implementation appears to be working well. While we could change the implementation to use the new |
|
Hello @wilkinsona |
|
Submitted as new ticket and attached sample app there #43430 |
It appears that reloading of route changes made in a project using spring-boot-devtools is no longer working with Camel 4 and Spring Boot 3. It was previously working with these versions:
But stops working with:
and upwards
Tested with corretto-18 and corretto-21
I made a sample repo to reproduce the issue: https://github.com/rlratcliffe/openapi27-test. Separate commits for working vs not working. Instructions below. I recognize that this could be more of a Camel problem, but since it worked previously on the older versions of SB/devtools I thought I would try here first. Thank you for your time.
Clone the repo mentioned above and then:
Working with old versions:
git checkout 3fec6482c5042d6bc944771ab9ddd7dbd223c9a6curl http://localhost:9000/api/hellowhich should output "hola".setBody(simple("hello"))Expected result: SB application restarts, Camel routes also restart and
curl http://localhost:9000/api/hello== "hello"Actual result: same as expected result
Not working with new versions:
git restore .or similargit checkout ab358fc7756bf8a7c3f341ada447cbc739e681c5curl http://localhost:9000/api/hellowhich should output "hola".setBody(simple("hello"))Expected result: SB application restarts, Camel routes also restart and curl
http://localhost:9000/api/hello== "hello"Actual result: Camel routes stop and
curl http://localhost:9000/api/hello== "Connection refused"The text was updated successfully, but these errors were encountered: