Affects: 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5

I am working on a huge monolithic Spring-based application (already on Java 17) migration from 5.3.26 to Spring 6.1.4. The application has been working with 5.3.26 without any issues an has been in production for many years. We have upgraded from Jaa 8 - 11 - 17 with no issues at all. Now we are working on migration to 6.1.4 and strangely the @autowired field injection of interface implementation has stopped working partially and we are unable to get it working despite trying out different solutions.

We have tried

lazy initialization of all beans constructor injection of dependencies

but that did not work either.

Interestingly not every autowiring is failing, it is just some of the application paths where it is NULL therefore getting NPE.

known paths that is problematic: listofdocumentscontroller->listofdocumentsdelegate->documentservice->documenttypeappservice->workspaceappservice->workspaceDao
reportscontroller->reportsdelegate->documenttypeAppService->workspaceappservice->workspaceDao reportscontroller->reportsdelegate->documenttypeAppService->workspaceappservice->settlementAppService reportscontroller->reportsdelegate->documenttypeAppService->settlementAppService->settlementDao

**Known paths that is ok**
    reportscontroller->reportsdelegate->documenttypeAppService->documentTypeDao

another example

known paths that is problematic: reportscontroller->reportsdelegate->documenttypeAppService->settlementAppService->settlementDao (null settlementDao)

-Known paths that is ok reportscontroller->reportsdelegate->documenttypeAppService->documentTypeDao (no issues)

Could you please help me?

Thank you

Comment From: bclozel

Can you provide a minimal sample application showing the issue? There is nothing actionable right now in this issue since we don't have access to your codebase.

Comment From: snicoll

@mdeinum I know you're trying to help but please let the OP shares the sample as requested.

Comment From: pexa-araza

It's not that easy for me to publish the code and it is a huge monolithic application. But I will still try my best to add the code. FYI, for the last 3 weeks, we have been trying out multiple solutions but nothing has actually worked. @Autowired field instance is null for the same class but is not null in others but if I use setter injection, it works then. The problem is the volume of the change, I need to do if I change everything to setter-based dependency injection.

Comment From: pexa-araza

springissue.zip

This is just an example where the issue is but this issue exists across the application.

Current Working version: 5.3.26 Intended version: 6.1.5 (I have tried all 6.1.x versions)

The application has circular dependencies issues and it's not easy to resolve those. The question is why it has been working with the old spring version and what has broken this autowired functionality.

Thanks

Comment From: pexa-araza

samplelog.txt

See attached a sample log file

Comment From: snicoll

@pexa-araza if you cannot provide a sample that reproduces the issue, I am afraid we can't justify keeping this issue open. The zip you've attached is a bunch of source files with no way to run something that reproduces the issue. It's, in effect, the same thing as code in text in an issue's description.

The application has circular dependencies issues and it's not easy to resolve those.

This might be one of the reasons of why this is failing.

The question is why it has been working with the old spring version and what has broken this autowired functionality.

That's one way to see it. Circular dependencies are something you should not have in the first place. The fact that the container is coping with it in 5.3.x is best effort and calling the 6.0.x broken is inaccurate. Circular dependencies are disabled in Spring Boot by default for a long time for that reason.

You could try to avoid field injection for a start, which is not recommended in production code. And break the cycle with ObjectProvider or @Lazy.

If you provide a sample that we can run as requested, we can reconsider.