Package io.mats3.spring.jms.factories

Class ScenarioConnectionFactoryProducer

java.lang.Object
io.mats3.spring.jms.factories.ScenarioConnectionFactoryProducer
All Implemented Interfaces:
MatsProfiles
public class ScenarioConnectionFactoryProducer extends Object implements MatsProfiles
Provides a factory for a Spring-integrated Wrapper/Facade around a JMS ConnectionFactory, which in addition to supporting the production setup, also facilitates the development situation where you often want to run against either an in-vm MQ Broker or against a MQ Broker running on localhost, and also integrates with the "mats-spring-test" integration test library where when run with the MatsTestProfile you will most probably want an in-vm setup (typically mocking up the project-external Mats endpoints that the tested endpoints collaborate with). In the in-vm broker situations, the JMS ConnectionFactory instantiation lambda you provide for what will be used in the production setup will not be invoked, but instead an in-vm ActiveMQ Broker will be started, and an ActiveMQ ConnectionFactory will be produced. (ActiveMQ is default, but this class by default employs the MatsTestBroker tool class for creating these connections, and this class can be directed to instead create, or connect to, an Artemis broker).

Note: The actual decision logic and "Spring interfacing" is done in ScenarioConnectionFactoryWrapper, which is the actual class of instances that will end up as Spring beans - this class is a producer of such instances, simplifying the configuration, providing sane defaults.

Do note that this is purely a convenience functionality, and is in no way required for the Mats system to work!

As a matter of fact, you can achieve the exact same with Spring's Profiles (or any other "switch configuration based on some property or state"-logic you can cook up), but this class effectively represents an opinionated implementation of the config switching that will be needed in most scenarios working with Mats, and will probably yield less configuration overall. Moreover, Mats will most probably be employed in a micro/multiple service architecture, and in such situations, it is nice to make some in-house library that constitute basic building blocks that all the services will need. With that in mind, this class also facilitates so you can easily construct an @CompanyMatsSetup-type annotation which alone will pull up both the needed ConnectionFactory (with URL and whatever needed already set) and MatsFactory, which handles all the mentioned scenarios, by merely placing that annotation on the main config class of your service.

The point is this: If you are new to Message Queue based development, you will probably soon sit with the problem of how to create a code base that efficiently lets you run it in production, while also is easy to develop on, and being simple to perform integration test on your endpoints - the problem being that you need different types of ConnectionFactories for the different scenarios, and in some cases also needing an in-vm MQ Broker.

There are typically four different scenarios that you need to juggle between, the two latter being identical wrt. the Mats setup (which is the reason that MatsScenario only has three scenarios defined):

  • Production / External Broker (any production-like environments, e.g. Staging/Pre-prod): This is the standard/regular situation for a MQ-based application or service: Connect to the common external production or staging MQ Broker that all other services and their Mats endpoints connect to. (Note that for the scenarios taken into account by this mechanism, all "external environments" (i.e. "production-like") are considered the same. However, you will most probably want the URLs to the external MQ Broker to be different between production and staging and any other such environment. Such switching must be handled by another mechanism.)
  • Localhost development, where you are developing on one project employing Mats Endpoints, but also run this project's required collaborating projects/services with their Mats Endpoints on your local development box (typically running the project you currently develop on directly in the IDE, while the other can either run in IDE or on command line): Connect to a MQ Broker that you've fired up on your local development box, i.e. localhost, which the other services running locally also connects to.
  • Local-VM development, where you just want to run the service alone, probably with some of the other collaborating Mats Endpoints from other projects/services mocked up in the same project: Connect to an in-vm MQ Broker. An important thing to ensure here is that these mocks, which by definition resides on the same classpath, must NOT end up running in the production environment! - preferably such mocks should not even be included in the production artifact.
  • Local-VM integration testing, where you have integration tests either utilizing the full app config with overwriting of certain beans/endpoints using "Remock" or @MockBean, and mocking out collaborating Mats Endpoints from other projects/services; or piece together the required beans/endpoints using e.g. @Import and mocking out other endpoints: Connect to an in-vm MQ Broker.
Please now read (all the) JavaDoc of MatsProfiles and its enum values!

For the localhost and localVM scenarios, this class by default utilizes the ActiveMQ Broker and ConnectionFactory. For all scenarios, but in particular for the "regular" (production-like), you can provide whatever ConnectionFactory you want (configured as you desire) - this class will just wrap it.