Skip to content

@AutoConfigurationPackage unpredictable behaviour depending on package name #44812

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
Rostik96 opened this issue Mar 20, 2025 · 2 comments
Closed
Labels
status: invalid An issue that we don't feel is valid

Comments

@Rostik96
Copy link

Rostik96 commented Mar 20, 2025

Hello, team!

My issue is intertwined with #19024.

Suppose, I've "client" app that has spring-boot-data-jpa with its automatic scan for Entity's and JpaRepository's in main app.
Also, there are two spring-boot-starters that "client" uses:
first-starter
second-starter

Theirs packages names consequently:
▹ com.rost.starter
▹ ru

Both AutoConfiguration's [1, 2] contains @AutoConfigurationPackage annotation on top to add its Enity's and JpaRepository's to automatic scan in "client" service.

However, entity/repo from first-starter are added to AppContext, but entity/repo from the second one aren't, what we could see in appropriate test case.

But...when I rename package

ru.transport

to, let's say,

ez

It's starting to work!


I've tried a lot of different packages names in second-starter and still haven't identified any pattern.
For some names all is good, but for some – no.

The hours of debugging also didn't help to figure out the reason why package is cut off by name.
But It looks exactly like this ^))

So, tell me please, what's going on?

GitHub🔗

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 20, 2025
@wilkinsona
Copy link
Member

You have provided no ordering for you auto-configuration classes so they fall back to being ordering alphabetically. This means that com.rost.starter.FirstStarterAutoConfiguration runs before org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration and its entities are found but ru.SecondStarterAutoConfiguration runs after it and its entities are not found.

To make things as robust as possible, both should be @AutoConfiguration(before = HibernateJpaAutoConfiguration.class). All three packages' entities are then found, as can be seen in the logs:

2025-03-20T21:52:32.474Z  INFO 15546 --- [           main] o.h.m.i.EntityInstantiatorPojoStandard   : HHH000182: No default (no-argument) constructor for class: dev.rost.autoconfigurationpackagesandbox.pets.Pet (class must be instantiated by Interceptor)
2025-03-20T21:52:32.489Z  INFO 15546 --- [           main] o.h.m.i.EntityInstantiatorPojoStandard   : HHH000182: No default (no-argument) constructor for class: ru.transport.Car (class must be instantiated by Interceptor)
2025-03-20T21:52:32.492Z  INFO 15546 --- [           main] o.h.m.i.EntityInstantiatorPojoStandard   : HHH000182: No default (no-argument) constructor for class: com.rost.starter.people.Person (class must be instantiated by Interceptor)

@wilkinsona wilkinsona closed this as not planned Won't fix, can't repro, duplicate, stale Mar 20, 2025
@wilkinsona wilkinsona added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 20, 2025
@Rostik96 Rostik96 changed the title @AutoConfigurationPackage unpredictable behavior depending on the package name @AutoConfigurationPackage unpredictable behavior depending on a package name Mar 20, 2025
@Rostik96 Rostik96 changed the title @AutoConfigurationPackage unpredictable behavior depending on a package name @AutoConfigurationPackage unpredictable behaviour depending on package name Mar 20, 2025
@Rostik96
Copy link
Author

Dear @wilkinsona, thank you for the quick and clear clarification, sir🤝
Receiving a reply directly from you is a milestone for me!✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

3 participants