Make it possible to inject desired subclass of ActiveMQConnectionFactory into the configuration

[thoroughsoft]

Is your feature request related to a problem? Please describe.
For our projects we have wrapper classes for several of the relevant JMS classes to provide additional functionality besides the standard stuff in artemis.
We therefore want to have our own ActiveMQConnectionFactory to generate our ActiveMQConnection subclass.

Describe the solution you'd like
We copied the existing ActiveMQConnectionFactoryConfiguration and ActiveMQConnectionFactoryFactory and with very small changes were able to get the desired outcome.
The existing configuration code is pretty much already ready for this improvement, all that is needed is a way to provide the desired class.
Core to the solution is a very simple interface that can be implemented as a bean to state the desired class.
PR will be provided.

Additional context
The artemis configuration is very similar to the one for Azure ServiceBus and since we use both this functionality is requested there too.
In case you come up with a different (read better) solution this should be coordinated with the ServiceBus team.

[wilkinsona]

ActiveMQConnectionFactoryFactory

What version of Boot are you using? Unless I have missed something, there's no such class in a currently support version of Spring Boot. You mention Artemis later on in your comment. Perhaps you meant ArtemisConnectionFactoryFactory?

Core to the solution is a very simple interface that can be implemented as a bean to state the desired class.

I don't think we have anything else like that in Spring Boot's auto-configuration so it would be quite unusual. I think we'll want to consider alternatives.

We have an existing pattern in Boot where we provide *Configurer classes as beans. These configurers can be used to define a custom bean that's largely configured as the auto-configuration would have done. ArtemisConnectionFactoryFactory is a bit like one of our existing public *Configurer classes in that it creates something using configuration properties. On the ActiveMQ side, we also have ActiveMQConnectionFactoryConfigurer although it's currently package-private.

Can you please clarify whether you're interested in ActiveMQ or Artemis.

PR will be provided.

Thanks for the offer, but we need to accept the request first and, if we do that, determine how best to implement it before a PR would be appropriate.

[thoroughsoft]

Ticket for ServiceBus Azure/azure-sdk-for-java#45942

[snicoll]

I've flagged this waiting-for-feedback again as it wasn't provided. What part of the auto-configuration would like to retain vs. exposing your own connection factory bean? For cases like this, providing your own looks warranted to me.

[thoroughsoft]

It was a bit confusing in terms of finding out what classes are currently active when I was trying to sort out this information in the ticket.
We are currently using sprint-boot-autoconfigure 3.3.3 and was not sure if names had changed with newer spring-boot versions.
Anyway, we are using Artemis so that is the primary target.

We don't want to create our own setup for configuring this.
It would be identical to what is currently present in the spring-boot code base meaning we end up in the exact situation we are in right now with a copy of the existing spring-boot code that we have to maintain ourselves.
As I pointed out already, the existing code is pretty much prepared for a configurable class but then at the absolute end the Factory class is hardcoded instead of provided.

What we did is to go with the ServiceBus solution where they define the Class instead of having a Function.
This allows ServiceBus to provide different numbers of parameters to the constructor and it makes the (extended) configuration easier.

We defined

@FunctionalInterface
public interface ArtemisConnectionFactoryClassResolver {

  Class<? extends ActiveMQConnectionFactory> getActiveMQConnectionFactoryClass();
}

which we simply use as

  @Bean
  public ArtemisConnectionFactoryClassResolver artemisConnectionFactoryClassResolver() {
    return () -> OurNiftyMQConnectionFactory.class;
  }

The upside with providing a proper bean instead of a stated class in the properties is compile time safety.
In the configuration we then extend the declaration to contain

    JmsPoolConnectionFactory jmsConnectionFactory(
        @Nullable final ArtemisConnectionFactoryClassResolver classResolver,

and if no class resolver is provided we fall back to the default value.

If this is instead implemented properly by you, we could have a default class resolver bean in spring-boot that is marked with a fitting @ConditionalXxx annotation that allows us mortals to provide our own override.
I think this would resolve the objections raised by @wilkinsona

Since Artemis has two flavors of possible factories (even if the same class is currently used sort handle both) it would probably mean having two interfaces, one for embedded and one for standard.