Trying to issue a new command from an EventHandler results in an
IllegalStateException:
java.lang.IllegalStateException: UnitOfWork is not started
at
org.axonframework.unitofwork.UnitOfWork.assertStarted(UnitOfWork.java:
169)
at
org.axonframework.unitofwork.UnitOfWork.rollback(UnitOfWork.java:72)
at
org.axonframework.commandhandling.SimpleCommandBus.doDispatch(SimpleCommandBus.java:
102)
at
org.axonframework.commandhandling.SimpleCommandBus.dispatch(SimpleCommandBus.java:
63)
at
org.fuin.auction.command.server.MailManager.handleContactCreatedEvent(MailManager.java:
62)
I don’t believe you can fire commands within an Event Listener. I also would believe that the management of user verification would be outside the scope of your aggregate. As such the verification system would be notified by some other means. I use Spring Integration in an event listener to communicate to submodules that have their lifecycle dependent on external systems. These submodules fire a command to update the aggregate when their task has completed.
sending commands from event listeners is something that Axon should support. It’s actually a quite common practice, to be honest. Usually when you fire commands from an event listener, the latter is called a saga. Explicit support for saga’s is on its way.
I created a small application context, with a flow quite similar to the flow you have. It has an asynchronous processor and a default commandbus, event bus and FS event store. I could dispatch the command without problems. Bot with a normal event listener and an asynchronous one.
Did you migrate to 0.7-SNAPSHOT? If so, you shouldn’t need to care about creating a UnitOfWork. The command bus does that for you (and it can even cope with nesting). So I’m afraid I can only report “works on my machine”.
I am not sure if this was the point that Seamus was making, but the creation of a verification token is a business rule. Typically, that means that the aggregate that creates a user will also create a token en send an event that a new (but unconfirmed) account has been created. You can then confirm that account using the token known by the user aggregate. The fact that you’re sending a command towards a user based on an event by that same user is an indication that you’ve got business logic that should be included in the aggregate itself.
The email mechanism would just have to send the token from the received event to the user (whose email address is in the event too). That’s a good example of an asynchronous event listener, by the way!
Did you migrate to 0.7-SNAPSHOT? If so, you shouldn't need to care about
creating a UnitOfWork. The command bus does that for you (and it can even
cope with nesting). So I'm afraid I can only report "works on my machine".
The fact that you're sending a command towards a user based on an
event by that same user is an indication that you've got business logic
that should be included in the aggregate itself.
Of yourse you're right - I changed it and the user now generates the
token itself. This removed the above problem too as I don't dispatch a
command any more from the event listener.