Use Flapdoodle Embedded MongoDB for integration tests

[vpavic]

This resolves #419.

I've signed the CLA.

[vpavic]

Closing & re-opening to force a new CI build.
Failure seems unrelated to these changes, the build passes for me locally.

[rwinch]

Thanks for the PR! I wonder if we want to enable this for the sample applications too? What are your thoughts @vpavic?

[vpavic]

@rwinch I've considered using this in sample app too but eventually decided to limit use to integration tests.

My reasoning was the following:

• Flapdoodle on its website clearly states the project is aimed at running Mongo in tests so we should follow this
• IMO sample apps should provide a realistic use case of how to use the framework
• sample apps include instructions on how to browse the session data using clients for underlying technology used to persist sessions, meaning you need Mongo (client at least) anyway to fully benefit from sample app (and I don't know how Mongo client would work with an embedded Flapdoodle instance)

This is in contrast to JDBC samples for example, which use H2 database, since H2 is full-blown RDBMS which also offers easily embeddable web client.

[rwinch]

@vpavic Thank you for your feedback. I somewhat see your point about the samples needing to provide a realistic experience for users. However, we do not want any extra noise for setting up samples.

Fladoodle should certainly not be used in production, but I think it is ideal for helping users run a sample application. We are testing the sample with Fladoodle so that is how users should experience it (since we know that is what works).

Finally Fladoodle is just downloading the executable and forking a process that starts up a full fledged Mongo instance. This means that this does not differ much from using an embedded relational database.

[vpavic]

@rwinch if we go with Flapdoodle to back the sample app, what happens with the part of the guide that describes usage of Mongo client to query and alter data (how does it work section)?

[rwinch]

@vpavic You can still connect to mongo when using Fladoodle using any Mongo client.

[vpavic]

@rwinch yes, I'm aware of that. But if you have Mongo client it's highly likely you also have Mongo server installed as well, that was one of my arguments for not moving sample app to Flapdoodle.

But OK, if that's your preference I'll move the sample app to Flapdoodle.

There's one more thing that crossed my mind today, and I've completely neglected it during initial implementation - embedded Flapdoodle instance needs to use random port to avoid any potential conflicts. That means in sample app scenario we also need to communicate this port to the user - is logging the port on startup good enough for this?

[rwinch]

@vpavic Thanks for the response.

But if you have Mongo client it's highly likely you also have Mongo server installed as well, that was one of my arguments for not moving sample app to Flapdoodle.

That is fair. However, I think there are many people that will not care about performing the steps with the client (they just want to get it running). We should have a disclaimer that you must have a client installed within the guide.

That means in sample app scenario we also need to communicate this port to the user - is logging the port on startup good enough for this?

This is an option. Alternatively (and probably preferably), we could default the port to using the standard port and ensure our test configuration overrides this to a random port.

[vpavic]

We should have a disclaimer that you must have a client installed within the guide.

OK.

Alternatively (and probably preferably), we could default the port to using the standard port and ensure our test configuration overrides this to a random port.

Even though this means sample app fails to start for users that run Mongo instance locally? This is somewhat in contradiction to "we do not want any extra noise for setting up samples" argument.

[rwinch]

@vpavic

Even though this means sample app fails to start for users that run Mongo instance locally? This is somewhat in contradiction to "we do not want any extra noise for setting up samples" argument.

That is a good point. Let's stick with logging. Perhaps it could even log "if you have the mongo client installed this is the command to connect"?

[vpavic]

@rwinch yes, that should be doable. I'll look into it and update the PR accordingly soon.

[vpavic]

@rwinch I've updated the PR, please review the changes.
I still need to update the guide. I'll take care of this when we finalize the implementation.

[rwinch]

Just curious why @DirtiesContext was necessary

[vpavic]

Good thing you pointed this out, @DirtiesContext can be removed now.

I've had issues similar to ones described in #396 with my initial implementation, since I had static port config for embedded MongoDB instance.

Moving to randomly assigned port fixed this.

[rwinch]

@vpavic Thanks for the fast turnaround. Overall looks good. I had one comment inline. When you update the documentation make sure that the guide either does not show the Flapdoodle config or it describes that this is just necessary to start mongo and not going to happen in a real world example.

[vpavic]

@rwinch

When you update the documentation make sure that the guide either does not show the Flapdoodle config or it describes that this is just necessary to start mongo and not going to happen in a real world example.

Yes, of course. Mongo-related config in sample app is in a separate @Configuration class, the original @Configuration class that contains asciidoc tags was left untouched.

[vpavic]

It completely slipped my mind that we could use Spring Boot's auto-configuration for an embedded MongoDB instance. I'll change this in next update.

[vpavic]

@rwinch I've updated the PR with the documentation/guide.

I also tried the Boot's Embedded MongoDB auto-configuration support, however I've run into spring-projects/spring-boot#5487. Not to confuse the users with this exception (even though its harmless as it occurs on shutdown) I've decided to stick with manual config until this gets fixed in Boot. Your thoughts?

---

UPDATE:

Somehow I managed to miss the fact that this exception on shutdown also happens when we use manual conf. So I'll update this to auto-configuration anyway. Also it appears that nothing within Boot itself would be able to fix this behavior.

[rwinch]

@vpavic Thanks for digging into this so deep and for the quality PR! This is now merged into master