IllegalStateException - UnitOfWork is not started

[michael-hamburg]

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)

Here is the source of the MailManager:

http://code.google.com/p/axon-auction-example/source/browse/trunk/auction-command-server/src/main/java/org/fuin/auction/command/server/MailManager.java

How do I add a new Unit Of Work?

[Seamus Venasse]

Hi Michael,

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.

Seamus

[Allard Buijze]

Michael,

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!

Cheers,

Allard

[michael-hamburg]

Hi Allard,

> 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".

Yes, I'm working with the snapshot - If you like to investigate the
problem you can use this revision: http://code.google.com/p/axon-auction-example/source/detail?r=107

> 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.

@Seamus:
I agree with Allard that this is a business rule as it concerns the
state of the user. So it's now completely included in the User
aggregate:
http://code.google.com/p/axon-auction-example/source/browse/trunk/auction-command-server/src/main/java/org/fuin/auction/command/server/User.java

Cheers,
Michael