Skip to content

ConfigDataLocationResolvers and PropertySourceLoaders are loaded using a potentially different class loader #44427

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

Closed
wilkinsona opened this issue Feb 24, 2025 · 3 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@wilkinsona
Copy link
Member

ConfigDataLocationResolver implementations are loaded using the resource loader's ClassLoader

protected ConfigDataLocationResolvers createConfigDataLocationResolvers(DeferredLogFactory logFactory,
ConfigurableBootstrapContext bootstrapContext, Binder binder, ResourceLoader resourceLoader) {
return new ConfigDataLocationResolvers(logFactory, bootstrapContext, binder, resourceLoader,
SpringFactoriesLoader.forDefaultResourceLocation(resourceLoader.getClassLoader()));
}

One of these implementations, StandardConfigDataLocationResolver, then uses its class's own class loader to load PropertySourceLoader implementations:

public StandardConfigDataLocationResolver(DeferredLogFactory logFactory, Binder binder,
ResourceLoader resourceLoader) {
this.logger = logFactory.getLog(StandardConfigDataLocationResolver.class);
this.propertySourceLoaders = SpringFactoriesLoader.loadFactories(PropertySourceLoader.class,
getClass().getClassLoader());
this.configNames = getConfigNames(binder);
this.resourceLoader = new LocationResourceLoader(resourceLoader);
}

For consistency, it should use the ResourceLoader that's passed into its constructor instead.

@alexisgayte
Copy link

Hi @wilkinsona,

Just to let you know,
I believe that was used to load a xml resource from another jar.

This has created a regression altho I would agree we were using internal things.

Thanks for your hard work.

@wilkinsona
Copy link
Member Author

Apologies for the breakage, @alexisgayte, and thanks for letting us know. I'm not sure if you'd like us to investigate further. If you would, please open a new issue with a minimal sample that works without this change and fails with it.

@alexisgayte
Copy link

No problem,
I don't think it needs to be investigated. Just for you to know about it / keep in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants