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.
Comment From: 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.
Comment From: thoroughsoft
Ticket for ServiceBus https://github.com/Azure/azure-sdk-for-java/issues/45942
Comment From: 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.
Comment From: 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.
Comment From: thoroughsoft
Here is the ServiceBus implementation for reference https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/spring/spring-cloud-azure-autoconfigure/src/main/java/com/azure/spring/cloud/autoconfigure/implementation/jms It is quite similar to what is is spring-boot so it is likely they started off from a copy of some spring-boot version.
Comment From: wilkinsona
Thanks for the additional details. Unfortunately, I am still not in favor of the ArtemisConnectionFactoryClassResolver idea as I currently understand it as I think it will have quite limited utility. If you have a custom connection factory sub-class that requires further configuration, for example through some additional configuration properties of your own, you won't have an opportunity to apply them. We can still look at other ways of providing a customized connection factory without having to duplicate ArtemisConnectionFactoryFactory.
Comment From: thoroughsoft
We don't have a need for additional configuration. We have a need to inject ourselves in the call chain to provide additional functionality. No amount of configuration in the world is able to provide this. We need to override the methods in the jms objects to inject additional functionality. All jms related calls happen through the Connection object that is created by the ConnectionFactory. The ConnectionFactory is right now hardcoded.
According to the names of the relevant classes here, we are talking about factories. Factories are meant to allow for users to decide what type of objects the factory should produce.
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, Jul 10, 2025 at 10:04 AM Andy Wilkinson @.***> wrote:
wilkinsona left a comment (spring-projects/spring-boot#46365) https://github.com/spring-projects/spring-boot/issues/46365#issuecomment-3056201036
Thanks for the additional details. Unfortunately, I am still not in favor of the ArtemisConnectionFactoryClassResolver idea as I currently understand it as I think it will have quite limited utility. If you have a custom connection factory sub-class that requires further configuration, for example through some additional configuration properties of your own, you won't have an opportunity to apply them. We can still look at other ways of providing a customized connection factory without having to duplicate ArtemisConnectionFactoryFactory.
— Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/46365#issuecomment-3056201036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMKQAB245BBEM5UYWY3RI33HYNABAVCNFSM6AAAAACBDQYVOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANJWGIYDCMBTGY . You are receiving this because you authored the thread.Message ID: @.***>
Comment From: snicoll
@thoroughsoft please watch your tone and review the guidelines for contributing before interacting again.
Andy didn't close any door, we are just mentioning we don't want to provide this feature as you suggest, see
We can still look at other ways of providing a customized connection factory without having to duplicate ArtemisConnectionFactoryFactory.
Comment From: wilkinsona
We don't have a need for additional configuration
I understand that, however we need to consider the broader picture when deciding which features to add.
As things stand, if someone wants to provide a custom connection factory of any sort they can do so by defining a custom ConnectionFactory bean. This isn't ideal if they want to keep (most of) the configuration that's performed by ArtemisConnectionFactoryFactory as it's package-private so you end up copy-pasting code from Boot into your app.
If we introduced a connection factory class resolver as you propose, this would allow ArtemisConnectionFactoryFactory to create instances of that custom class. However, it wouldn't help those that want to configure some settings on that custom connection factory. You do not have that need, but those that do would be left with things no better than they are now.
I think it should be possible for us to introduce something that allows you to define a custom connection factory bean that's configured as ArtemisConnectionFactoryFactory would do today and also apply additional configuration that's specific to the custom factory. This would, I think, meet both needs.
Comment From: thoroughsoft
I made a slight change to the interface to accommodate for the configuration. I tried it out in the ServiceBus code since they are using configuration parameters to determine how the instance is created.
public interface AzureServiceBusJmsConnectionFactoryFactory {
ServiceBusJmsConnectionFactory createServiceBusJmsConnectionFactory();
}
The default config code then becomes
@Bean
@ConditionalOnMissingBean
AzureServiceBusJmsConnectionFactoryFactory
azureServiceBusJmsConnectionFactoryFactory(final
AzureServiceBusJmsProperties properties) {
return () -> {
if (properties.isPasswordlessEnabled()) {
String hostName =
properties.getNamespace() + "." +
properties.getProfile().getEnvironment().getServiceBusDomainName();
Properties passwordlessProperties =
properties.toPasswordlessProperties();
enhancePasswordlessProperties(AzureServiceBusJmsProperties.PREFIX,
properties, passwordlessProperties);
TokenCredentialProvider tokenCredentialProvider =
TokenCredentialProvider.createDefault(new
TokenCredentialProviderOptions(passwordlessProperties));
TokenCredential tokenCredential = tokenCredentialProvider.get();
return new ServiceBusJmsConnectionFactory(tokenCredential,
hostName, new ServiceBusJmsConnectionFactorySettings());
} else {
return new
ServiceBusJmsConnectionFactory(properties.getConnectionString(), new
ServiceBusJmsConnectionFactorySettings());
}
};
}
This construct has the added bonus that it is compile time safe and allows for a pretty good cleanup of the FactoryFactory class.
I also implemented a version with generics but that does not add any value.
The generics will only be used inside the FactoryFactory class meaning it becomes pointless.
The only reason for having it would be to explicitly show the developer that there is a subclass expected.
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#m_-5872126719996919524_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, Jul 10, 2025 at 10:50 AM Andy Wilkinson @.***> wrote:
wilkinsona left a comment (spring-projects/spring-boot#46365) https://github.com/spring-projects/spring-boot/issues/46365#issuecomment-3056393016
We don't have a need for additional configuration
I understand that, however we need to consider the broader picture when deciding which features to add.
As things stand, if someone wants to provide a custom connection factory of any sort they can do so by defining a custom ConnectionFactory bean. This isn't ideal if they want to keep (most of) the configuration that's performed by ArtemisConnectionFactoryFactory as it's package-private so you end up copy-pasting code from Boot into your app.
If we introduced a connection factory class resolver as you propose, this would allow ArtemisConnectionFactoryFactory to create instances of that custom class. However, it wouldn't help those that want to configure some settings on that custom connection factory. You do not have that need, but those that do would be left with things no better than they are now.
I think it should be possible for us to introduce something that allows you to define a custom connection factory bean that's configured as ArtemisConnectionFactoryFactory would do today and also apply additional configuration that's specific to the custom factory. This would, I think, meet both needs.
— Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/46365#issuecomment-3056393016, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMKQAFL2EKCHYFR22H64ZD3HYSODAVCNFSM6AAAAACBDQYVOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANJWGM4TGMBRGY . You are receiving this because you were mentioned.Message ID: @.***>
Comment From: wilkinsona
@snicoll and I discussed this today and concluded that we don't want to do anything here. We haven't seen any demand for the requested feature beyond this issue which makes it hard to justify the cost of adding it. ArtemisConnectionFactoryFactory isn't that large so copy-paste of the relevant parts feel like the best option here at this time. Thanks anyway for the suggestion.