Skip to content
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

Wrong Spring repository bean name when using aggregate polymorphism #2514

Closed
maverick1601 opened this issue Dec 14, 2022 · 2 comments
Closed
Assignees
Labels
Priority 1: Must Highest priority. A release cannot be made if this issue isn’t resolved. Status: Resolved Use to signal that work on this issue is done. Type: Bug Use to signal issues that describe a bug within the system.
Milestone

Comments

@maverick1601
Copy link
Contributor

Basic information

  • Axon Framework version: 4.6.2
  • JDK version: 17
  • Complete executable reproducer if available (e.g. GitHub Repo):

Steps to reproduce

When using aggregate polymorphism, i.e. base aggregate class A (abstract) and subtypes B and C, Axon provides no Axon repository bean named in aRepository, which is the common super-type. This used to work in Axon 4.6.1. The repository is still created, but there is no control over the bean name. It seems to pick the bean name from the first sub-type in alphabetical order.

Expected behaviour

Axon should provide a bean name based on the super-type, as in Axon 4.6.1, not based on alphabetical order of sub-types to support proper auto wiring.

Actual behaviour

The repository is available in the Spring context with the "wrong" name. Still it is able to resolve/load types based on the super type, i.e. including the whole hierarchy. As such, it seems the bean name used for registering the correct repository is simply wrong.

@maverick1601 maverick1601 added the Type: Bug Use to signal issues that describe a bug within the system. label Dec 14, 2022
@smcvb smcvb added the Priority 1: Must Highest priority. A release cannot be made if this issue isn’t resolved. label Dec 15, 2022
@smcvb smcvb self-assigned this Dec 15, 2022
@smcvb smcvb added the Status: In Progress Use to signal this issue is actively worked on. label Dec 15, 2022
@smcvb smcvb added this to the Release 4.6.3 milestone Dec 15, 2022
@smcvb
Copy link
Member

smcvb commented Dec 15, 2022

Thanks for filing this bug with us, @maverick1601. We'll look into adding the Repository bean with the desired name to the Application Context again.
I assume this bug snuck in with the overhaul we did on the Spring configuration within the framework. My apologies for any issues this has caused you.

smcvb added a commit that referenced this issue Dec 19, 2022
Fix naming of Repository bean name, by using a lower cased initial
letter for the aggregate type. Furthermore, fix this for the
AggregateFactory bean too, as it adhered to the same adjusted, and
faulty, naming behavior.

#2514
smcvb added a commit that referenced this issue Dec 19, 2022
Fine tune test case to clearly state the wrong bean name, by extracting
all bean names for the Repository class.

#2514
smcvb added a commit that referenced this issue Dec 19, 2022
The AggregateStereotypeAutoConfigurationTest wrongfully expects the bean
 name to be the full @aggregate annotated class name for the Repository.
Next to fixing this, resolves some warnings in this file while we're at
it, like forcing the identifier to be an Object to *not* use the
deprecated VersionedAggregateIdentifier constructor.

#2514
smcvb added a commit that referenced this issue Dec 20, 2022
[#2514] Fix naming of registered `Repository` and `AggregateFactory` beans
@smcvb
Copy link
Member

smcvb commented Dec 20, 2022

Closing this issue as it has been resolved #2525.

@smcvb smcvb closed this as completed Dec 20, 2022
@smcvb smcvb added Status: Resolved Use to signal that work on this issue is done. and removed Status: In Progress Use to signal this issue is actively worked on. labels Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority 1: Must Highest priority. A release cannot be made if this issue isn’t resolved. Status: Resolved Use to signal that work on this issue is done. Type: Bug Use to signal issues that describe a bug within the system.
Projects
None yet
Development

No branches or pull requests

2 participants