Axon Framework extension

[Jasper Huzen]

Hi,

I build an Axon extension for integration with Axon Framework. 

The extension handles the following tasks:

• Setup the basic configuration and starts the Axon client that will connect to an Axon server.
• Search for classes annotated with Axon annotations and register them to the Axon client. Aggregates and Saga's are supported, even Command handlers, Events handlers and Query handlers 
• Added a bean resolver factory that inject beans into methods called by Axon (also in non-beans).
• Makes beans available just like CommandGateway and QueryGateway to use for sending commands/queries in runtime projects.
• "Publishes" all the configuration beans to make it possible to control the Axon client configuration in runtime projects.

Because it's my first Quarkus extension I would be great to get some feedback and maybe some advice how to continue with this extension (is it in the basic a candidate for PR?).

Some of my questions:

1. Can the dependency injection cleaner/smarter? 
2. Can code be move to BUILD_TIME or did I make the right choices about the locations.
3. How to test? I added some unit tests but I can't enable them because there is no Axon embedded available. Maybe a testcontainers can be used to start a docker container with Axon but I don't know if that a good idea (have some drawbacks). 

The current version of the Axon extension can be found at: https://github.com/feaster83/quarkus/tree/feature/axon-framework-extension

Regards,

Jasper

[Alexey Loubyansky]

Hi Jasper,

looks great! Thanks for letting us know. Have you seen how the jdbc drivers are tested in our integration-tests module? At least that's how we are doing it now. Testing will definitely have to be addressed in one way or another.

Now where it should live is a great question. The answer will very much depend on who will be standing behind it, enhancing, maintaining, etc and what will be more convenient for the maintainer (and the quarkus team): keeping the extension in its own project repo or a part of the quarkus repo. Unfortunately, the only way to integrate an extension into the Quarkus ecosystem today is to actually merge it into the Quarkus repo. OTOH, correct me if I'm wrong, having an extension in its own project would be a lot easier for the maintainer (building, testing, releasing, etc). Actually, we are having a few Quarkus extensions (Apache Camel) moving out from the Quarkus repo for those reasons in the next week or two. There will be a so called Quarkus Platform repo whose role will be to promote extensions aggregated from the Quarkus (core) repo and various community repos (including their testsuites!). Here is the basic prototype of that https://github.com/aloubyansky/quarkus-platform-poc including Quarkus (core) extensions and external Apache Camel ones. How does that integration model sound to you?

Thanks,

Alexey

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
Visit this group at https://groups.google.com/group/quarkus-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/bddd1136-0006-49ad-86d7-bcecd72faad1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Kouba]

Dne 12. 07. 19 v 19:20 Jasper Huzen napsal(a):

> Hi,
>
> I build an Axon extension for integration with Axon Framework.
>
> The extension handles the following tasks:
>

> * Setup the basic configuration and starts the Axon client that will

> connect to an Axon server.

> * Search for classes annotated with Axon annotations and register them

> to the Axon client. Aggregates and Saga's are supported, even
> Command handlers, Events handlers and Query handlers

> * Added a bean resolver factory that inject beans into methods called

> by Axon (also in non-beans).

> * Makes beans available just like CommandGateway and QueryGateway to

> use for sending commands/queries in runtime projects.

> * "Publishes" all the configuration beans to make it possible to

> control the Axon client configuration in runtime projects.
>

> Because it's *my first Quarkus extension* I would be great to get some

> feedback and maybe some advice how to continue with this extension (is
> it in the basic a candidate for PR?).
>
> Some of my questions:
>

> 1. Can the dependency injection cleaner/smarter?

Hey Jasper. Could you be more specific? This is a very general question ;-)

> 2. Can code be move to BUILD_TIME or did I make the right choices about
> the locations.
> 3. How to test? I added some unit tests but I can't enable them because

> there is no Axon embedded available. Maybe a testcontainers can be
> used to start a docker container with Axon but I don't know if that
> a good idea (have some drawbacks).
>
> The current version of the Axon extension can be found at:
> https://github.com/feaster83/quarkus/tree/feature/axon-framework-extension
>
>
> Regards,
>
> Jasper
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com

> <mailto:quarkus-dev...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/quarkus-dev.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/quarkus-dev/bddd1136-0006-49ad-86d7-bcecd72faad1%40googlegroups.com

> <https://groups.google.com/d/msgid/quarkus-dev/bddd1136-0006-49ad-86d7-bcecd72faad1%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

[Johnny T]

Hi,

the idea to have an "set and forget" extension for axon in quarkus is great. 

I guess it would be possible to even provide a guide to set up quarks and axon in a short amount of time. 

This would make it easy for everyone to try out axon and quarkus and get event sourcing up an running in no time. 

Thumps up for that!

As written into the merge request (maybe the wrong place for that), i'm also trying out quarkus with axon.

I haven't tried axon server, though.

I managed to get it to run with a PostgreSql (works well together with quarkus) via jdbc and some of the micro profile parts (CDI, JTA, JSONB).

It also works as a native image.

1.) Discovering all building blocks like aggregates, query-handler, ... can be done using Standard CDI as described here: 

http://www.adam-bien.com/roller/abien/entry/how_to_discover_all_deployed

Be aware, that quarkus CDI implementation ArC removes "unused" beans. 

Either they are all annotated additionally with @Named (standard annotation, not quarkus specific), 

or "quarkus.arc.remove-unused-bean=none" needs to be configured for it.

3.) Testing using @QuarkusTest is easy without axon server. 

A H2 in memory database can be used as well. 

Together with flyway it really gets awesome.

I also managed to get server sent events and axon subscription queries to run. :-)

I'll put it on https://github.com/JohT, when i'm finished. That may take a while.

At the end, my approach may not be something to start with and get fast results.

On the other hand, i'll focus on minimized dependencies, maximized server-portability (micro-profile) and some other ideas....

Regards. J.

[Johnny T]

I've just uploaded my showcase to github.com/JohT/showcase-quarkus-eventsourcing

[Johnny T]

I've just updated my showcase for axon using microprofile on quarkus:

github.com/JohT/showcase-quarkus-eventsourcing

Native image generation works now. 

Maybe this is helpful to others, that try to use axon with quarkus. I commented everything i found out using "Note" comment tags and inside the ReadMe.md.

This was harder than i thought. Every class that is used by reflection needs to be found an configured...

Now i get it. Using reflection-heavy frameworks without an existing extension is extremely time consuming, if a native-image is the goal.

The "substrate" is much easier to configure and works pretty well.