I'm receiving a NullPointerException in a method with the Annotation #Bean, but before I never got this NullPointerException there:
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [dev.teamnight.command.CommandFramework]: Circular reference involving containing bean 'config' - consider declaring the factory method as static for independence from its containing instance. Factory method 'commandFramework' threw exception; nested exception is java.lang.NullPointerException
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:651) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
... 68 common frames omitted
Caused by: java.lang.NullPointerException: null
at dev.teamnight.nightbot.Config.commandFramework(Config.java:84) ~[classes/:na]
at dev.teamnight.nightbot.Config$$EnhancerBySpringCGLIB$$2d4937ec.CGLIB$commandFramework$3(<generated>) ~[classes/:na]
at dev.teamnight.nightbot.Config$$EnhancerBySpringCGLIB$$2d4937ec$$FastClassBySpringCGLIB$$3fbdfefd.invoke(<generated>) ~[classes/:na]
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) ~[spring-core-5.2.6.RELEASE.jar:5.2.6.RELEASE]
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) ~[spring-context-5.2.6.RELEASE.jar:5.2.6.RELEASE]
at dev.teamnight.nightbot.Config$$EnhancerBySpringCGLIB$$2d4937ec.commandFramework(<generated>) ~[classes/:na]
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:na]
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
... 69 common frames omitted
The code of the file causing the Exception:
#Configuration
#PropertySource("file:bot.properties")
public class Config {
#Autowired
private ShardManager shardManager;
#Autowired
private PermissionProvider permissionProvider;
#Autowired
private LanguageProvider languageProvider;
#Autowired
private PrefixProvider prefixProvider;
#Autowired
private HelpProvider helpProvider;
#Bean
public ShardManager shardManager() throws LoginException, IllegalArgumentException {
DefaultShardManagerBuilder builder = DefaultShardManagerBuilder.createDefault(this.botToken)
.enableIntents(GatewayIntent.GUILD_MEMBERS)
.setMemberCachePolicy(MemberCachePolicy.ALL)
.setStatus(OnlineStatus.IDLE)
.setShardsTotal(this.totalShards)
.addEventListeners(Arrays.asList(this.jdaListener()));
return builder.build();
}
#Bean
public CommandFramework commandFramework() {
Logger log = LogManager.getLogger();
//Line causing the error below!
log.error("Name of helpProvider: " + this.helpProvider.getClass().getCanonicalName());
return new FrameworkBuilder()
.addOwners(Arrays.stream(this.ownerIds).filter(ownerId -> ownerId.matches("^(\\d)+$")).map(ownerId -> Long.parseLong(ownerId)).collect(Collectors.toList()))
.setLogger(NightBot.logger())
.allowBots(false)
.allowDM(false)
.allowMention(true)
.allowRainbowColors(true)
.withPrefixProvider(this.prefixProvider)
.withLanguageProvider(this.languageProvider)
.withPermissionProvider(this.permissionProvider)
.withHelpProvider(this.helpProvider)
.withCustomArgumentProcessor(new NamedArgumentProcessor())
.registerClient(this.shardManager)
.build();
}
}
As I said, before the code fully worked, and I changed nothing on the Config.java file, so this error is confusing me as hell.
You are seeing this NullPointerException because the autowired HelperProvider not being injected in.
You are attempting to call .getClass() on a null object.
General Dependency Injection Debugging
Just want to add a quick basic mentions, since the main answer to this question has to make some assumption on your codebase. There are several things that you want to check when dependency injection fails.
Configuration files - Are these being loaded in correctly. Is your component scanning recently disabled?
Do your Components have the necessary #Component and or #Service/#Controller/#Repository annotations?
The Likely Root Problem - Circular Reference - BeanInstantiationException
There is also a mention of a circular reference in your stacktrace which is likely what is causing the problem.
Caused by: org.springframework.beans.BeanInstantiationException: Circular reference involving containing bean 'config' - consider declaring the factory method as static for independence from its containing instance. Factory method 'commandFramework' threw exception; nested exception is java.lang.NullPointerException
Since you received this error message, you have introduced a circular reference. This means... that a component relies on a component which relies on that component.
For example:
#Component
class HelperProvider {
#Autowired
Config config;
}
and
#Configuration
class Config {
#Autowired
HelperProvider helperProvider
}
This pattern will stump the spring framework because they rely on each other to load each component up. It can happen if you introduce a dependency further down the line. Say HelperProvider requires HelperHelperProvider which requires Config.
You will want to check for any new injections of Config or CommandFramework in your recent edits.
What you should do
You will want to redesign your configuration to break it's reliance on the HelperProvider. Doing this can resolve a lot of headaches in your future.
What you shouldn't do
It's possible to lazyload the component or configuration with #Lazy annotation. That way the bean is only instantiated upon invocation. It's recommended if you want to learn more nuances in booting up the Spring ApplicationContext, but it will become a nightmare to maintain down the road.
The error you are getting is most probably because you have a cyclic dependency in your project. And since you are getting it in commandFramework method as illustrated in error it is because of the HelpProvider class in which you are using the Config class again.
So when spring is creating a bean of Config it has to create a bean of HelpProvider which in terms wants to create a bean of Config(Autowired in HelpProvider) and leads to a never ending cycle giving the error. Also check if HelpProvider has the #component annotataion.
Config -> HelpProvider -> Config -> HelpProvider -> Config .............
Solution:-
Either you can remove the config from the HelpProvider and try to redesign it.
Use #Lazy on Config in HelpProvider which will load this dependency on object instantiation. Will suggest it as a last resort.
Related
Currently I am using AspectJ Load Time Weaving to intercept the constructor of a base entity for auditing purposes. However when running the application I am getting incredibly inconsistent results revolving around the aspectOf() method that aspectJ weaves into LTW classes.
In some cases the application runs, the weaving is done correctly, and the code is functioning as expected. Other times I am met with:
java.lang.NoSuchMethodException: ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect.aspectOf()
Currently I am using https://github.com/subes/invesdwin-instrument to dynamically attach the instrumentation agent into the JVM so our deployment guys don't need to do any extra configuration.
My Spring application main:
#SpringBootApplication
#EntityScan(basePackages = {"ca.gc.cfp.model"})
public class CfpWsApplication {
public static void main(final String[] args) {
DynamicInstrumentationLoader.waitForInitialized();
DynamicInstrumentationLoader.initLoadTimeWeavingContext();
if (!InstrumentationLoadTimeWeaver.isInstrumentationAvailable()) {
throw new IllegalStateException(
"Instrumentation is not available AspectJ weaver will not function.");
}
SpringApplication.run(CfpWsApplication.class, args);
}
The LTW Aspect:
#Aspect
public class BaseEntityAspect {
Logger logger = LoggerFactory.getLogger(BaseEntityAspect.class);
/** Application context property needed to fetch the AuditDate bean */
#Autowired private ApplicationContext context;
#AfterReturning(
"onBaseEntityCreated() && !within(ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect)")
public void injectAuditTimeStamp(JoinPoint joinPoint) {
try {
AuditDate auditDate = context.getBean(AuditDate.class);
Object entityTarget = joinPoint.getTarget();
// Inject the auditing date for this Entity instance
if (entityTarget instanceof BaseEntity) {
BaseEntity baseEnt = (BaseEntity) entityTarget;
baseEnt.setAuditDate(auditDate.getAuditingTimeStamp());
}
} catch (NullPointerException e) {
logger.error(
e.getMessage()
+ " Not yet in the conext of an httpRequest, the AuditDate bean has not yet been instantiated.");
}
}
#Pointcut(
"execution(ca.gc.cfp.model.entity.BaseEntity.new(..)) && !within(ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect)")
public void onBaseEntityCreated() {}
}
The Aspect config class with a temporary factory method using the Aspects utils to let spring know it should ask aspectJ for the woven Aspect:
#Configuration
#EnableAspectJAutoProxy
public class AspectConfig {
/**
* Static factory for access to the load time woven aspect. This allows the aspect to be injected
* with the application context and beans from the spring IoC
*/
#Bean
public BaseEntityAspect getBaseEntityAspect() {
return Aspects.aspectOf(BaseEntityAspect.class);
}
}
aop.xml:
<aspectj>
<weaver options="-verbose -showWeaveInfo -Xreweavable -debug">
<include within="ca.gc.cfp.model" />
<include within="ca.gc.cfp.model..*" />
<include within="ca.gc.cfp.core.cfpws.repository.aspect..*"/>
</weaver>
<aspects>
<aspect name="ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect" />
</aspects>
</aspectj>
In a lot of cases when I run with this configuration I get the following:
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect]: Factory method 'getBaseEntityAspect' threw exception; nested exception is org.aspectj.lang.NoAspectBoundException: Exception while initializing ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect: java.lang.NoSuchMethodException: ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect.aspectOf()
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:622) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
... 19 common frames omitted
Caused by: org.aspectj.lang.NoAspectBoundException: Exception while initializing ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect: java.lang.NoSuchMethodException: ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect.aspectOf()
at org.aspectj.lang.Aspects.aspectOf(Aspects.java:50) ~[aspectjrt-1.9.4.jar:1.9.4]
at ca.gc.cfp.core.cfpws.configuration.AspectConfig.getBaseEntityAspect(AspectConfig.java:22) ~[classes/:na]
at ca.gc.cfp.core.cfpws.configuration.AspectConfig$$EnhancerBySpringCGLIB$$1cae4c58.CGLIB$getBaseEntityAspect$0(<generated>) ~[classes/:na]
at ca.gc.cfp.core.cfpws.configuration.AspectConfig$$EnhancerBySpringCGLIB$$1cae4c58$$FastClassBySpringCGLIB$$84edb9e.invoke(<generated>) ~[classes/:na]
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) ~[spring-core-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:363) ~[spring-context-5.1.4.RELEASE.jar:5.1.4.RELEASE]
at ca.gc.cfp.core.cfpws.configuration.AspectConfig$$EnhancerBySpringCGLIB$$1cae4c58.getBaseEntityAspect(<generated>) ~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_211]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_211]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_211]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_211]
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ~[spring-beans-5.1.4.RELEASE.jar:5.1.4.RELEASE]
... 20 common frames omitted
Caused by: java.lang.NoSuchMethodException: ca.gc.cfp.core.cfpws.repository.aspect.BaseEntityAspect.aspectOf()
at java.lang.Class.getDeclaredMethod(Class.java:2130) ~[na:1.8.0_211]
at org.aspectj.lang.Aspects.getSingletonOrThreadAspectOf(Aspects.java:134) ~[aspectjrt-1.9.4.jar:1.9.4]
at org.aspectj.lang.Aspects.aspectOf(Aspects.java:45) ~[aspectjrt-1.9.4.jar:1.9.4]
... 31 common frames omitted
However this is not always the case, occasionally the application runs just fine, the code executes as expected and there are no issues. This has been eluding me for a couple weeks now and I cannot seem to figure out what could be causing this code to occasionally work and occasionally not work. Could it be that CGLIB proxies are hiding the aspectOf() method from the compiler??
EDIT / UPDATE: I was able to remove the use of the above third party dependency for dynamically loading the java agent into the Spring application context. I instead used javaagent arguments and it is working fine from within my IDE. However building and running via Maven in a terminal is still causing issues. I've specified the javaagent argument via the Environment variable : MAVEN_OPTS. After doing so maven seems to be picking it up but my class still isn't being woven.
With regard to your own answer: The AspectJ Maven plugin helps you with compile-time weaving (CTW), not load-time weaving (LTW). For LTW you need to make sure that the weaving agent is active before any of the target classes have been loaded because LTW works at class-loader level. AspectJ Maven is only necessary if either you use aspects in native syntax (not annotation-based) or you want to use CTW.
I don't know about this invesdwin-instrument tool, but the AspectJ weaver offers its own capability to attach it during runtime. A third-party tool should not be necessary. Anyway, I do recommend to modify the Java command line in order to ensure the weaving agent is in place before anything else is loaded in your container. Your deployment guys ought to help you make sure that the -javaagent:... parameter is there. It is their job! To work around that in order to make life easier for them but the behaviour of your application potentially unpredictable is not going to improve its stability.
As per Kieveli's comment. My TL was thinking similarly. I'm new to Maven, Spring boot, and AOP. Looking into it externally run Maven and the build from within Eclipse seem to be "clobbering" one another.
I've been using maven via MINGW64 to clean / install / build, and the project doesn't specify usage of the AspectJ compiler which is likely why the factory method is not being woven into the class.
We're discussing a solution to this as we use Jenkins for build automation on our server. I am thinking that this Maven plugin may be the solution. https://www.mojohaus.org/aspectj-maven-plugin/
I am doing unit tests for a rest controller, which is only a small part of a bigger application.
My test context isn't recognized by my application and I have the following exception : java.lang.IllegalStateException: Failed to load ApplicationContext
This is my test class:
Test RestController
#RunWith(SpringJUnit4ClassRunner.class)
#SpringApplicationConfiguration(locations = "classpath:/META-INF/spring/context-test.xml")
#WebIntegrationTest
public class MyRestControllerTest extends AbstractTransactionnalTest {
#Autowired
private IManager manager;
#Test
// my unit tests
}
The thing is that if instead of locations = "classpath:/META-INF/spring/context-test.xml" I use classes = Production.class with the following application class, it works fine:
#Configuration
#EnableAutoConfiguration
#EnableTransactionManagement
#EnableScheduling
#ImportResource({ "classpath:/META-INF/spring/context-production.xml" })
public class Production {
// class content
}
I've read all the posts with similar problem and I know it is linked to the #Configuration and #EnableAutoConfiguration annotation however when I tried a custom configuration class which used these annotation and imported the settings from the context.xml it did not work.
I ideally wish not to add any configuration class and would like to only add a bean to my test-context.xml.
Is it possible to solve this issue with a bean in my context.xml or an annotation on TestRestController ?
Here is my stack trace:
java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:124)
at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:83)
at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:117)
... 26 more
Caused by: org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.context.ApplicationContextException: Unable to start EmbeddedWebApplicationContext due to missing EmbeddedServletContainerFactory bean.
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onRefresh(EmbeddedWebApplicationContext.java:133)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:531)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118)
... 35 more
Caused by: org.springframework.context.ApplicationContextException: Unable to start EmbeddedWebApplicationContext due to missing EmbeddedServletContainerFactory bean.
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.getEmbeddedServletContainerFactory(EmbeddedWebApplicationContext.java:185)
... 39 more
Here is the bean I used to mock the manager in my test-context.xml :
<bean id="IManager"
class="org.mockito.Mockito" factory-method="mock">
<constructor-arg value="com.service.impl.Manager"/>
Update :
I tried to used a custom manager mock where the database is replaced with a list.
If I remove the annotation #WebIntegrationTest, the application context loads correctly however I get another exception because the server isn't launched without the #WebIntegrationTest annotation.
I/O error on GET request for network address :Connection refused
I am running on spring 1.3.7.
#ContextConfiguration defines class-level metadata that is used to determine how to load and configure an ApplicationContext for integration tests. Specifically #ContextConfiguration declares the application context resource locations or the annotated classes that will be used to load the context.
#ContextConfiguration("/test-config.xml")
public class XmlApplicationContextTests {
// class body...
}
Spring Boot provides a
#SpringBootTest
annotation which can be used as an alternative to the standard spring-test
#ContextConfiguration
annotation when you need Spring Boot features. The annotation works by creating the ApplicationContext used in your tests via SpringApplication.
You can use the webEnvironment attribute of #SpringBootTest to further refine how your tests will run.
Spring Boot’s #*Test annotations will search for your primary configuration automatically whenever you don’t explicitly define one.
The search algorithm works up from the package that contains the test until it finds a #SpringBootApplication or #SpringBootConfiguration annotated class. As long as you’ve structured your code in a sensible way your main configuration is usually found.
If you want to customize the primary configuration, you can use a nested #TestConfiguration class. Unlike a nested #Configuration class which would be used instead of a your application’s primary configuration, a nested #TestConfiguration class will be used in addition to your application’s primary configuration.
http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html 40.2
I am trying to add a new Spring bean to one of my projects. The bean is defined and created in another package like so:
#Configuration
public class UtilityBeans {
public static String MY_BEAN_NAME = "my.bean.name";
#Bean(name = MY_BEAN_NAME)
public MyUtilBeanClass getMyBeanClass() {
return new MyUtilBeanClass();
}
}
I use it in my other package like this:
#Configuration
#Import({
UtilityBeans.class
)}
...
#Resource(name = UtilityBeans.MY_BEAN_NAME)
private MyUtilBeanClass myUtilBeans;
During runtime I get:
ERROR
Caused by: org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'my.bean.name': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
...
The logs do not give me any useful information as the stack trace is all in Spring library. How can I find out what failed? Is it incorrect usage of resource or is it that the bean creation itself is wrong?
I am using Spring-4 with JDK8.
The issue here was that the bean was being created in 2 different points in my spring configuration due to some refactoring and the fix was to remove duplicate code. I had the same bean creation code:
#Bean(name = MY_BEAN_NAME)
public MyUtilBeanClass getMyBeanClass() {
return new MyUtilBeanClass();
}
... in another class I had half way refactored.
In this case my mistake was that I did not grep across all the log files being generated. The exceptions were being split and then buried into 2 different logs, one for a server start up and one for application runtime. The above exception was being posted to the application log. The other logs contained the relevant exception which stated that duplicate bean creation failed and the fix was to remove duplicate code.
We are using Spring Boot for our application.
After starting the application, in the runtime we are adding(loading) a new Bean to the existing Applicationcontext.
AnnotationConfigApplicationContext appContext = new AnnotationConfigApplicationContext();
appContext.register(NewBean.class);
appContext.refresh();
after adding the bean we are doing a refresh of applicationContext
During the refresh the MBean is trying to reregister some endpoints and we are getting the following error
(getting error for all these endpoints - requestMappingEndpoint, environmentEndpoint, healthEndpoint, beansEndpoint, infoEndpoint, metricsEndpoint, traceEndpoint, dumpEndpoint,
autoConfigurationAuditEndpoint, shutdownEndpoint, configurationPropertiesReportEndpoint)
Caused by: javax.management.InstanceAlreadyExistsException: org.springframework.boot:type=Endpoint,name=configurationPropertiesReportEndpoint
at com.sun.jmx.mbeanserver.Repository.addMBean(Unknown Source)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(Unknown Source)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(Unknown Source)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(Unknown Source)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(Unknown Source)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(Unknown Source)
at org.springframework.jmx.support.MBeanRegistrationSupport.doRegister(MBeanRegistrationSupport.java:195)
at org.springframework.jmx.export.MBeanExporter.registerBeanInstance(MBeanExporter.java:662)
at org.springframework.jmx.export.MBeanExporter.registerBeanNameOrInstance(MBeanExporter.java:605)
Can anyone please tell how to skip this exception?
I have tried the following too
#EnableIntegrationMBeanExport(registration = RegistrationPolicy.REPLACE_EXISTING)
but getting the below exception
Caused by: org.springframework.jmx.export.UnableToRegisterMBeanException: Unable to register MBean [org.springframework.integration.monitor.IntegrationMBeanExporter#16c5464] with key 'integrationMbeanExporter'; nested exception is javax.management.InstanceAlreadyExistsException: org.springframework.integration.monitor:name=integrationMbeanExporter,type=IntegrationMBeanExporter
at org.springframework.jmx.export.MBeanExporter.registerBeanNameOrInstance(MBeanExporter.java:609)
at org.springframework.jmx.export.MBeanExporter.registerBeans(MBeanExporter.java:534)
at org.springframework.jmx.export.MBeanExporter.afterPropertiesSet(MBeanExporter.java:416)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1612)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1549)
... 22 more
Caused by: javax.management.InstanceAlreadyExistsException: org.springframework.integration.monitor:name=integrationMbeanExporter,type=IntegrationMBeanExporter
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at org.springframework.jmx.support.MBeanRegistrationSupport.doRegister(MBeanRegistrationSupport.java:195)
at org.springframework.jmx.export.MBeanExporter.registerBeanInstance(MBeanExporter.java:662)
at org.springframework.jmx.export.MBeanExporter.registerBeanNameOrInstance(MBeanExporter.java:599)
... 26 more
Before you call refresh on an existing ApplicationContext, you should first destroy it else beans keep running.
AnnotationConfigApplicationContext appContext = new AnnotationConfigApplicationContext();
appContext.register(NewBean.class);
appContext.refresh();
What you show here is that you are constructing a new context instead of reusing an existing one. The register method is also intended for #Configuration classes not arbitrary beans. If you want to add those just use one of the methods on the ApplicationContext like, registerSingleton. But in general adding beans at runtime should be a bad thing (imho).
Some applicationContext can refresh times, but not AnnotationConfigApplicationContext.
when you construct AnnotationConfigApplicationContext, which had run the refresh method, so it will be reported exception, you can destroy it first, and then refresh
So i have a situation when I need to use spring integration. So I create application context for it and then i describe my all logic in it. But now, I have an error something like this:
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [java.util.Properties] is defined: expected single matching bean but found 2: [integrationGlobalProperties, systemProperties]
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:800)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:707)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireByType(AbstractAutowireCapableBeanFactory.java:1184)
... 61 more
Does someone faced with this problem with systemProperties and integrationGlobalProperties? What does it mean?
P.s. my application context is imported into another application context which has "default-autowire="byType"
As you see your context has two bean of java.util.Properties. That means that you can't inject byType.
Use #Qualifier("systemProperties") to restrict it to specific Properties.
The integrationGlobalProperties isn't only one bean which is populated by Framework. And it isn't a surprise that autowire byType is more and more bad for real applications.
I recently faced same issue. After some research I have decided to wirte a CustomBeanPostProcessor class (implementing BeanFactoryPostProcessor) which will try to find conflicting bean and change its 'autowire' property to 'byName', thus avoiding conflict.
Please have a look at a code below:
public class CustomBeanPostProcessor implements BeanFactoryPostProcessor{
#Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
if (beanFactory.containsBean("integrationGlobalProperties")){
//Choose on of the options - either disable autowiring for bean completly,
//or change autowiring type
beanFactory.getBeanDefinition("integrationGlobalProperties").setAutowireCandidate(false);
beanFactory.getBeanDefinition("integrationGlobalProperties").setAttribute("autowire", "byName");
}
}
}
Do not forget to declare this class as Spring bean as well:
<bean class="edu.stackoverflow.spring.misc.CustomBeanPostProcessor"/>