Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve documentation for FactoryBean's getObject automatic call through @ManagedResource [SPR-17139] #21676

Closed
spring-projects-issues opened this issue Aug 7, 2018 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: documentation A documentation task
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Manuel Jordan opened SPR-17139 and commented

I have the following situation about FactoryBean for the getObject() execution.

I have for example:

@Bean
ActiveMQConnectionFactoryFactoryBean connectionFactoryInstanceARemoteHostFactoryBean(){
	logger.info("@Bean connectionFactoryInstanceARemoteHostFactoryBean ...");
	ActiveMQConnectionFactoryFactoryBean factoryBean = new ActiveMQConnectionFactoryFactoryBean();
	....
	logger.info("	{}", factoryBean.toString());
	return factoryBean;
}

Where:

public class ActiveMQConnectionFactoryFactoryBean implements FactoryBean<ActiveMQConnectionFactory>{

...

       @Override
	public ActiveMQConnectionFactory getObject() throws Exception {
            ...
        }

}

From above:

  • The @Bean method is created/managed by Spring
  • In other @Bean method that works with @Conditional I can call and execute manually the getObject() method.

Until here all work how is expected.

My problem is with RabbitMQ, I have the following:

@Bean
RabbitMQCachingConnectionFactoryFactoryBean cachingConnectionFactoryInstanceARemoteHostFactoryBean() {
	logger.info("@Bean cachingConnectionFactoryInstanceARemoteHostFactoryBean ...");
	RabbitMQCachingConnectionFactoryFactoryBean factoryBean = new RabbitMQCachingConnectionFactoryFactoryBean();
        ...
	logger.info("	{}", factoryBean.toString());
	return factoryBean;
}

and

public class RabbitMQCachingConnectionFactoryFactoryBean implements FactoryBean<CachingConnectionFactory> {

   ...
   @Override
   public CachingConnectionFactory getObject() throws Exception {

Thus the following:

  • The @Bean method is created/managed by Spring
  • In other @Bean method that works with @Conditional I can call and execute manually the getObject() method.

When @Conditional is false that other @Bean never calls and execute manually the getObject() method. It is expected.

Problem: but because implements FactoryBean<ActiveMQConnectionFactory> works with ActiveMQConnectionFactory and it is declared how:

@ManagedResource
public class CachingConnectionFactory extends AbstractConnectionFactory
		implements InitializingBean, ShutdownListener, PublisherCallbackChannelConnectionFactory {

I did realise that because the component is marked with @ManagedResource, Spring through JMX, calls automatically the getObject() method. Arising errors.

I have the following:

@Configuration
@EnableMBeanExport
public class JmxConfig {

}

If I comment @EnableMBeanExport the app starts up without problem. But I need use JMX for other components, I need Spring does not execute automatically that @ManagedResource.

This behaviour about JMX triggers automatically the getObject() method when the FactoryBean's type is marked with @ManagedResource (i.e: CachingConnectionFactory) is not covered neither 1.8.3. Customizing instantiation logic with a FactoryBean nor 4. JMX


Affects: 5.0.8

@spring-projects-issues
Copy link
Collaborator Author

Manuel Jordan commented

Is it the expected behavior? 

With the current API what is the best approach to avoid this situation?

Thank you.

@spring-projects-issues spring-projects-issues added type: documentation A documentation task in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.x Backlog milestone Jan 11, 2019
@rstoyanchev rstoyanchev added the type: task A general task label Nov 15, 2019
@jhoeller jhoeller removed the type: task A general task label Jul 14, 2023
@jhoeller jhoeller modified the milestones: 6.x Backlog, General Backlog Jul 14, 2023
@jhoeller
Copy link
Contributor

jhoeller commented Aug 7, 2023

The common solution here is to declare the target bean definition as lazy-init. The MBeanExporter takes that into account already. I'll document that in the JMX chapter.

@jhoeller jhoeller self-assigned this Aug 7, 2023
@jhoeller jhoeller modified the milestones: General Backlog, 6.0.12 Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: documentation A documentation task
Projects
None yet
Development

No branches or pull requests

3 participants