SpringBoot Set Tomcat's WebappClassLoader as the main thread's context classloader

This problem is closely linked to issue https://github.com/spring-projects/spring-boot/issues/2308. I am working with Spring Boot 2.6.13.

It seems to me that there is the same problem as the above issue, in case you are using the spring boot scheduler with the embedded tomcat. The two classes involved follow:

Scheduler.java

@Component
public class Scheduler {

    @Scheduled(initialDelay = 1000 * 10, fixedRate = 1000 * 60)
    public void scheduleFixedRateTask() {
                // here use any db connection
    }

TomcatConfigs.java

@Configuration
public class TomcatConfigs {
    @Bean
    public ServletWebServerFactory servletContainer() {
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory() {

            @Override
            protected TomcatWebServer getTomcatWebServer(org.apache.catalina.startup.Tomcat tomcat) {
                tomcat.enableNaming();
                return super.getTomcatWebServer(tomcat);
            }

If the thread context class loader isn't the web app classloader then the JNDI context is empty, hence the lookup failure.

Using the following work around on TomcatConfigs.java solves the problem:

for (Container child : container.getTomcat().getHost().findChildren()) {
    if (child instanceof Context) {
        ClassLoader contextClassLoader = ((Context) child).getLoader().getClassLoader();
            Thread.currentThread().setContextClassLoader(contextClassLoader);
            break;
        }
}

Could you tell me if there is already a version that solves it directly?

Thanks for your time

Comment From: wilkinsona

Thanks for opening a separate issue, @FellinRoberto.

Unfortunately, a few code snippets don't tell us enough to be able to help you. For example, // here use any db connection doesn't tell us enough. I guess that you're using a DataSource retrieved from JNDI but that's not clear. I also can't tell what thread your @Scheduled method will use as you haven't shown how you've configured scheduling.

If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: FellinRoberto

Thanks for the prompt response.

Unfortunately I can't provide the complete code, but I will try to provide you more information.

I have nothing more than this in Application.java:

@SpringBootApplication(scanBasePackages = { "package" })
@EnableScheduling
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

I don't think I used any particular configuration for the scheduler (apologies, I'm quite new with spring boot).

In TomcatConfig.java I am overriding the method postProcessContext, adding a ContextResource of type DataSource.java defining my db connection.

I am calling javax.naming.InitialContext.lookup(). org.apache.naming.NamingContext.java:840 gets the error that my db connection url is not bound in this Context. This because javax.naming.spi.NamingManager.java:561 can't find the context. This is due to the fact that the initialization of the db connection is done by the scheduler thread.

Hoping this will help to reproduce the problem.

Comment From: wilkinsona

We don't need your complete application, in fact we prefer not to have that. Instead, all we need is the bare minimum that's required to reproduce the problem. I'm afraid we don't have time to try to reproduce a problem based on guesses about what you may be doing. There's no guarantee that we'll be able to reproduce the problem and, even if we do, it may end up being a different problem with the sam symptoms and any fix wouldn't work for you. If you would like us to spend any more time on this, please spend some time producing a complete yet minimal sample that reproduces the problem.

Comment From: FellinRoberto

I don't think I have anything more than what I have already given you. What do you need besides this?

Comment From: wilkinsona

All of the code and build configuration that's required to reproduce the problem. It should be zipped up and attached to this issue or pushed to a separate repository on GitHub. To reproduce the problem, we should be able to unzip or clone the repository and run it without having to copy-paste anything or fill in any blanks.

Comment From: FellinRoberto

Unfortunately I can't provide the complete code, but I gave you all the affected pieces of code.

Comment From: wilkinsona

Then I'm afraid we will have to close this issue as we can't diagnose a problem that we cannot precisely reproduce. Just to be clear, as I said above, we don't need the complete code, just what is required to reproduce the problem. From what you've described, it sounds like that would be a few relatively small additions to an app generated from https://start.spring.io. If you reconsider and decide to create a minimal sample, please comment here and we will happily re-open the issue and take a look.