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.

Sign up for GitHub

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

Jump to bottom

SpringAxonAutoConfigurer warns about multiple beans defined for polymorphic aggregates. #2512

Closed
maverick1601 opened this issue Dec 12, 2022 · 5 comments
Closed

SpringAxonAutoConfigurer warns about multiple beans defined for polymorphic aggregates. #2512

maverick1601 opened this issue Dec 12, 2022 · 5 comments
Assignees
@smcvb
Labels
Priority 4: Would Lowest priority. Would-be-nice to include issues when time allows it. 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
Release 4.6.3

Comments

@maverick1601
Copy link
Contributor

Basic information

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

Steps to reproduce

Define an aggregate hierarchy, as described in https://docs.axoniq.io/reference-guide/v/4.5/axon-framework/axon-framework-commands/modeling/aggregate-polymorphism and start up using Spring Axon auto configuration.

Expected behaviour

SpringAxonAutoConfigurer should not log warnings about multiple beans of the same aggregate super type, since Axon requires us to annotate super classes as well, in order for the hierarchy to be properly detected.

Actual behaviour

SpringAxonAutoConfigurer uses beanName(Class) which logs warnings when more than one bean is defined, which is always the case for such hierarchies.
@maverick1601 maverick1601 added the Type: Bug Use to signal issues that describe a bug within the system. label Dec 12, 2022
@smcvb
Copy link
Member

smcvb commented Dec 13, 2022

Thanks for filing this issue with us, @maverick1601!
Just out of curiosity, but have you tested this behavior against Axon Framework 4.6.x too?

@smcvb smcvb added Priority 4: Would Lowest priority. Would-be-nice to include issues when time allows it. Status: Information Required Use to signal this issue is waiting for information to be provided in the issue's description. labels Dec 13, 2022
@maverick1601
Copy link
Contributor Author

@smcvb just checked by upgrading to 4.6.x on a test branch and the warning still occurs.

@smcvb
Copy link
Member

smcvb commented Dec 15, 2022

That's...curious. The SpringAxonAutoConfigurer is deprecated in 4.6 and shouldn't be picked up by Axon Framework's auto-configuration anymore.
Are you certain the log messages in a 4.6.x branch originate from the SpringAxonAutoConfigurer, @maverick1601?

Sorry for pressing here, but I need a little more to go for here.
Perhaps you can share the exact message you're seeing, or where we invoke the referred beanName(Class) method you're talking about.

@maverick1601
Copy link
Contributor Author

@smcvb you're right, I was to focused on the message itself. The message says for instance:

o.a.spring.config.SpringAggregateLookup  : There are 2 beans defined for 'de.syna.esp.middleware.domain.aggregate.ProposalAggregate'.

But as you pointed out, it's now originating from the SpringAggregateLookup.beanName(). For me, the code in there looks the same, so it seems to have been moved there from SpringAxonAutoConfigurer.

@smcvb smcvb added this to the Release 4.6.3 milestone Dec 16, 2022
@smcvb smcvb added Status: In Progress Use to signal this issue is actively worked on. and removed Status: Information Required Use to signal this issue is waiting for information to be provided in the issue's description. labels Dec 16, 2022
smcvb added a commit that referenced this issue Dec 16, 2022
@smcvb
Adjust log level from WARN to DEBUG
a121e60 
The method used to retrieve the bean names,
ListableBeanFactory#getBeanNamesForType(Class), will *always* return
more than one entry if there are several beans of the given type or a
subtype. The only reason those beans won't show, is if they're not
annotated with @aggregate. And if they aren't, the polymorphic
configuration wouldn't be polymorphic anyhow. As such, marking this log
statement as warn was unnecessary to begin with.

Resolves #2512
smcvb added a commit that referenced this issue Dec 16, 2022
@smcvb
Fine tune text
c5598be 
Fine tune text

Resolves #2512
@smcvb
Copy link
Member

smcvb commented Dec 16, 2022

Closing this issue as resolved through commit a121e60.
@maverick1601, after some investigation, I don't think it's mandatory to log a warn statement for this scenario.
Actually, I would expect that line to return at all times when using a polymorphic aggregate.
As such, I believe DEBUG is more in line than WARN.

@smcvb smcvb closed this as completed Dec 16, 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 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@smcvb smcvb

Labels
Priority 4: Would Lowest priority. Would-be-nice to include issues when time allows it. 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
Milestone
Release 4.6.3
Development

No branches or pull requests
2 participants
@maverick1601 @smcvb