Fix issue 16083: Consumer is not registered as a Spring bean when the Dubbo generic invocation mode is used and the consumer is created with @Bean annotation

[ban-xiu]

What is the purpose of the change?

Close #16083

Checklist

• Make sure there is a GitHub_issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.85%. Comparing base (ed0e11e) to head (d94a29a).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16144      +/-   ##
============================================
- Coverage     60.86%   60.85%   -0.01%     
+ Complexity    11768    11766       -2     
============================================
  Files          1953     1953              
  Lines         89260    89260              
  Branches      13471    13471              
============================================
- Hits          54329    54322       -7     
  Misses        29350    29350              
- Partials       5581     5588       +7     

Flag	Coverage Δ
integration-tests-java21	32.14% <100.00%> (+0.05%)	⬆️
integration-tests-java8	32.16% <100.00%> (-0.05%)	⬇️
samples-tests-java21	32.15% <80.00%> (-0.01%)	⬇️
samples-tests-java8	29.84% <80.00%> (+0.01%)	⬆️
unit-tests-java11	59.08% <100.00%> (-0.01%)	⬇️
unit-tests-java17	58.56% <100.00%> (-0.02%)	⬇️
unit-tests-java21	58.56% <100.00%> (+<0.01%)	⬆️
unit-tests-java25	58.54% <100.00%> (+0.01%)	⬆️
unit-tests-java8	59.12% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ban-xiu]

In this mode, ensure that invoker.getInterface() (i.e., GenericService) is placed at the forefront.

[zrlw]

this pr might cause problem if the dubbo generice service references are created without annotation @Bean.
Dubbo registers reference beans into the Spring container automatically no matter using annotation @Bean or not.

[ban-xiu]

this pr might cause problem if the dubbo generice service references are created without annotation @Bean. Dubbo registers reference beans into the Spring container automatically no matter using annotation @Bean or not.

It seems that the only scenario where the interface order of AbstractProxyFactory needs to take effect for Spring is when users entirely bypass ReferenceBean and directly call referenceConfig.get() in a @bean method—which is precisely the case this PR aims to fix.

[ban-xiu]

It seems that scenarios without @bean won't cause issues either, because those cases are protected by the lazy proxy layer.

[ban-xiu]

@zrlw I looked into this concern. This change only reorders two code blocks — the final set of interfaces the proxy implements stays exactly the same, just the iteration
order in LinkedHashSet changes.

My understanding is that for references created without @bean (via @DubboReference or XML), Spring resolves bean type through ReferenceBean.getObjectType(), which
returns interfaceClass directly and doesn't depend on proxy interface order. So I think this change should not affect those scenarios. But please correct me if I'm
missing something here.

As for why the reorder helps the @bean case: Javassist Proxy.getProxy() uses ics[0].getClassLoader() to create the proxy class. Before this change, ics[0] was the
user's business interface (e.g. com.xxx.XxxService), whose classloader might not be compatible with GenericService. After this change, ics[0] becomes GenericService,
and its classloader (Dubbo's classloader) generally has better visibility.

Would love to hear your thoughts — happy to adjust the approach if there are cases I haven't considered.

[zrlw]

LGTM

[zrlw]

@AlbumenJ PTAL