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

EventHandler declaring UnitOfWork as parameter doesn't match incoming message #477

Closed
abuijze opened this issue Jan 12, 2018 · 0 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

@abuijze
Copy link
Member

abuijze commented Jan 12, 2018

When using a TrackingProcessor, a UnitOfWork is only started when a matching handler has been found. When a handler declares a UnitOfWork as parameter, it will only match if there is an active Unit of Work.

Instead, the parameterResolver should always match, as the ParameterResolver may assume that any Axon component will start a Unit of Work before invoking a handler. In case any other component invokes the handler, without starting a Unit of Work, the parameter will resolve to null.

@abuijze abuijze added the Type: Bug Use to signal issues that describe a bug within the system. label Jan 12, 2018
@abuijze abuijze added this to the Release 3.1.2 milestone Jan 12, 2018
abuijze added a commit that referenced this issue Jan 12, 2018
If there isn't an active Unit of Work, a parameter should resolve to
`null`. The reason for this behavior is that the TrackingEventProcessor
will find suitable handlers before starting a UnitOfWork, and that one
may assume that Axon components will always start a UnitOfWork before
invoking any handler.

Resolves #477
@abuijze abuijze closed this as completed Jan 12, 2018
@smcvb smcvb added 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. labels Feb 28, 2019
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