Comment From: wilkinsona

Why? What do you want to be able to customise that cannot already be customized with a liquibase.integration.spring.Customizer<Liquibase> bean? We won't increase the public API without a reason.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

Comment From: shitikanth

One valid reason would be provide a custom resourceAccessor implementation - it is a final field in Liquibase so can't be customized using Customizer<Liquibase>.

Liquibase's spring integration has a bug when used with cloud native images (e.g. created with mvn spring-boot:image) where it resolves resources included by includeAll to a different path when run with an image as opposed to when you run locally or through a jar. For example: 

databaseChangeLog:
  - includeAll:
      path: classpath:/db/changelog/2025/09/

with a changelog at classpath:/db/changelog/2025/09/0001-changelog.yaml would resolve to path db/changelog/2025/09/0001-changelog.yaml when run using a jar and BOOT-INF/classes/db/changelog/2025/09/0001-changelog.yaml when run using the cloud-native image.

Ability to customize the resourceLoader or resourceAccessor would provide an elegant way to work around the issue until it gets fixed upstream.

Related issues: https://github.com/liquibase/liquibase/issues/1755 https://github.com/liquibase/liquibase/issues/3260

Comment From: wilkinsona

Once the SpringLiquibase instance has been returned from the @Bean method that defines it, Framework will honour the ResourceLoaderAware contract and set the context's ResourceLoader on the SpringLiquibase bean. This would overwrite any custom ResourceLoader that would have been configured. In short, setting the ResourceLoader doesn't seem like a valid reason for making SpringLiquibaseCustomizer public.

I'm going close this one again for now. We can reconsider in the future if anyone raises a case where customisation of SpringLiquibase would help.