Axonframework: Axon doesn't work in combination with spring-boot-dev-tools on class path

[moifort]

Axon version: 3.0.2
With: spring-boot-axon + H2 + No cache repository

If you add spring-boot-dev-tools in your class path, axon will not work. I am not sure, but spring-boot-dev-tools will change the path class name of event message object and during the publishing this event will not match.

I make an example here -> https://github.com/moifort/axon-sample-with-spring-dev-tools

Make the test by removing/adding spring-boot-dev-tools dependency

[kazarian]

We've noticed the same behavior in our stack. We removed spring-boot-dev-tools
to enable execution from within the IDE.

On Sun, Feb 26, 2017 at 11:38 AM, Thibaut Mottet [e-mail]
wrote:

If you add spring-boot-dev-tools in your class path, axon will not work.
I am not sure, but spring-boot-dev-tools will change the path class name
of event message object and during the publishing this event will not match.

I make an example here -> https://github.com/moifort/
axon-sample-with-spring-dev-tools

Make the test by removing/adding spring-boot-dev-tools dependency

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AxonFramework/AxonFramework/issues/282, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABKsHZgNbKB2EoWGiktQpuYbDUhYy65cks5rgcbCgaJpZM4MMeMg
.

--

---

CONFIDENTIALITY NOTICE

This message and any attachments are only for the intended recipient and
contain confidential information. All intellectual property and other
proprietary rights associated with this message and any attachments are
owned and retained by PromonTech. No license or other conveyance of such
rights is intended or granted with respect to this message and any
attachments. If you are not the intended recipient or the person
responsible for delivering this message to the intended recipient, then you
are notified of the strict prohibition against copying, distribution,
further transmission or other disclosure of this message and any
attachments, and taking any action in reliance on this message and any
attachments. If you have received this message in error, please notify the
sender immediately by reply e-mail, delete this message and any
attachments from your system, and destroy any hard copy that you may have
made. Thank you for your cooperation.

[pbit]

Its the classloader used by devtools.

The behavior is described in the docs: http://docs.spring.io/spring-boot/docs/1.5.1.RELEASE/reference/htmlsingle/#using-boot-devtools-customizing-classload.

[moifort]

@pbit yes, I already set the META-INF/spring-devtools.properties, but I still have the issue.

[pbit]

@moifort Can you provide a small sample project with the issue?

[moifort]

Sample project: https://github.com/moifort/axon-sample-with-spring-dev-tools

• I try to disable the restart in application.properties with spring.devtools.restart.enabled=false
• I try to exclude axon framework jar in META-INF/spring-devtools.properties with restart.exclude.axon=axonframework/*

I still have the error

[abuijze]

I think the solution may to do the opposite: make sure Axon jar is also reloaded. The default behavior is to only reload project classes. The Axon repository (especially the model inspectors) probably benefit from a 'refresh'.
I can't test right now, but if it helps, I can include this property in the Axon-Spring module.

[pbit]

Did some test with the sample project given by @moifort
The Axon jars are just one part, the serializer has to be included too.
What finally worked:

restart.include.axon-core=axon-core-3.0.2.jar
restart.include.axon-spring=axon-spring-3.0.2.jar
restart.include.axon-spring-boot-autoconfigure=axon-spring-boot-autoconfigure-3.0.2.jar
restart.include.xstream=xstream-1.4.9.jar

Depending on the serializer chosen by the developer you have to include more dependencies (with unknown side effects).
I think this should not be handled by Axon.
Just add a section to the README and give some examples for common use cases.

[moifort]

It's work, thanks @pbit, I updated my repo. Should I make a PR adding the spring-devtools.properties in the axon-spring project?

[smcvb]

Feel free to make a PR for it @moifort, I'd say it's valuable and @abuijze also suggest to do so (in Axon-Spring module).

[abuijze]

@pbit, why don't you think this should be handled by Axon? I could agree for the serializer part (although we can add configuration for the Jackson and XStream serializers provided). But if the 'Axon include' is included, people will not run into annoying trouble.
Curious to know what you reason is.

[pbit]

@abuijze I just meant the serializer part.

Just afraid what happens if you put a common dependency like Jackson on a different classloader.
This could break deserialization of other libs using Jackson.

In theory everything _should_ work by just including Axon libs, as the serializer is created by Axon.
I'm currently trying to figure out why the AggregateIdentifier is not populated when the second event is send.

[pbit]

Seems like this can be resolved without touching XStream.
There are multiple locations involved:

The JpaEventStorageEngine in JpaConfiguration is constructed without the Serializer Bean:

https://github.com/AxonFramework/AxonFramework/blob/master/spring-boot-autoconfigure/src/main/java/org/axonframework/boot/AxonAutoConfiguration.java#L173

The XStream instance of the XStreamSerializer is configured without a classLoader.
So the ClassLoader of the library is used.

A working example is:

Add to spring-devtools.properties:

restart.include.axon-core=axon-core-3.0.2.jar
restart.include.axon-spring=axon-spring-3.0.2.jar
restart.include.axon-spring-boot-autoconfigure=axon-spring-boot-autoconfigure-3.0.2.jar

Add a configuration class:

    @Configuration
    public static class AxonConfiguration {

        @Bean
        public Serializer serializer() {
            final XStream xStream = new XStream(new CompactDriver());
            xStream.setClassLoader(this.getClass().getClassLoader());
            final XStreamSerializer serializer = new XStreamSerializer(xStream);

            return serializer;
        }

        @Bean
        public EventStorageEngine eventStorageEngine(Serializer serializer, EntityManagerProvider entityManagerProvider, TransactionManager transactionManager) {
            JpaEventStorageEngine engine = new JpaEventStorageEngine(serializer, null, null, null, entityManagerProvider, transactionManager, null, null, true);

            return engine;
        }

    }

This solves the issues at least for XStream without adding the lib to devtools.
Seems like Jackson provides an explicity ClassLoader too.

Does anybody know how to unit test such class loader related stuff?

[roy-t]

I think this problem returned in Axon 3.2, if I include spring-boot-devtools my @EventHandler's are no longer processed. If I exclude it everything works again. Maybe a newer version of spring-boot-devtools. I'm using 2.0.4.RELEASE of spring-boot-devtools.

[somratcste]

I removed spring-boot-devtools from my pom.xml this is also working for me in production. Thanks a lot :)

[MrFix93]

In 4.3.1 this problem still occurs. It's a pity because spring-dev-tools would really speed up the development process (I saw that the Axon team is using it too). Maybe it is an easy fix @abuijze ?

I tried to configure devtools to include the axon framework as jars, however, that doesn't fix it, unfortunately.

Let me know if I can help.

[smcvb]

We've prioritized a fix/solution for the spring-dev-tools issue in #1382 for release 4.4.
That issue links to the majority of the created issues around spring-dev-tools, although I forget to reference this one; sorry for that unclarity.

By the way, the file you're referencing was intended as a fix for the users, although it indeed doesn't work as expected.