Introduce an AOT alternative to using components index in DefaultPersistenceUnitManager to look up JPA entities

[sdeleuze]

I tried to remove spring.components resource native configuration since I thought it was not needed anymore at runtime, I did that by commenting this line in SpringBootHints and this line in ConfigurationCollector but I then have the following error at startup in petclinic-jpa:

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'ownerController': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ownerRepository': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Not a managed type: class org.springframework.samples.petclinic.owner.Owner
	at org.springframework.aot.beans.factory.InjectedConstructionResolver.resolve(InjectedConstructionResolver.java:90) ~[na:na]
	at org.springframework.aot.beans.factory.InjectedElementResolver.resolve(InjectedElementResolver.java:19) ~[na:na]
	at org.springframework.aot.beans.factory.InjectedElementResolver.create(InjectedElementResolver.java:50) ~[na:na]
	at org.springframework.aot.beans.factory.BeanDefinitionRegistrar$InstanceSupplierContext.create(BeanDefinitionRegistrar.java:168) ~[na:na]
	at org.springframework.samples.petclinic.owner.ContextBootstrapInitializer.lambda$registerOwnerController$1(ContextBootstrapInitializer.java:10)

After discussing with @snicoll, @christophstrobl and @schauder it seems it could come from ClassPathScanningCandidateComponentProvider usage in org.springframework.data.jpa.support.ClasspathScanningPersistenceUnitPostProcessor. We could implement a custom BeanPostProcessor like we did for invoke init/destroy callbacks to perform that step at buildtime and allow spring.components hint and synthesize removal.

[ch4mpy]

@sdeleuze I have a quite similar exception, reported in gh-963, when trying to run native image with entities and repositories from separate jar.

This could mean that current class-path scanning is already broken in case of multi-jar AOT build.

I recently commited a data-jpa sample modification which produces:

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'dataJpaApplication': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'fooRepository': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Not a managed type: class org.springframework.experimental.domain.Foo

[johanloke]

@ch4mpy I experience the same thing also. I thought my setup is wrong. The JPA reference to an entity from another jar. I can't really solve even if I put in EntityScan in the SpringBootApplication

[christophstrobl]

Thanks for bringing this to our attention. To address this issue we require changes in data-commons that will likely not be resolved prior to the next major data release that is planned to be supported by Boot 3.

[christophstrobl]

@sdeleuze The ClasspathScanningPersistenceUnitPostProcessor is about to be deprecated in Spring Data. This issue seems to be better solved for DefaultPersistenceUnitManager which does also use the components index (scanPackage(...)) to identify candidate types.

[mikhilsanghvi]

Hi, I am facing similar issue when trying to update my project to build native images. My project requires to register entities from another dependent jar. Is there a workaround for this while it is being addressed?

[snicoll]

This should be fixed in Spring Boot 3.0.0-M5. Please give that a try.

[mikhilsanghvi]

Thanks for the reply @snicoll As suggested i'm giving it a try with 3.0.0-M5 but I face below issue when trying to execute the native image. Any pointers?

Caused by: jakarta.persistence.PersistenceException: Unable to resolve persistence unit root URL
	at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl(DefaultPersistenceUnitManager.java:643) ~[na:na]
	at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.preparePersistenceUnitInfos(DefaultPersistenceUnitManager.java:462) ~[na:na]
	at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.afterPropertiesSet(DefaultPersistenceUnitManager.java:443) ~[na:na]

Caused by: java.io.FileNotFoundException: class path resource [] cannot be resolved to URL because it does not exist

[snicoll]

Thanks for trying @mikhilsanghvi. Can you please create a new issue in the Spring Framework issue tracker with a small sample that reproduces the issue?

[sdeleuze]

Spring Native is now superseded by Spring Boot 3 official native support, see the related reference documentation for more details.

As a consequence, I am closing this issue, and recommend trying your use case with latest Spring Boot 3 version. If you still experience the issue reported here, please open an issue directly on the related Spring project (Spring Framework, Data, Security, Boot, Cloud, etc.) with a reproducer.

Thanks for your contribution on the experimental Spring Native project, we hope you will enjoy the official native support introduced by Spring Boot 3.