Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to solve the problem that the refresh project cannot be started by enabling Spring-Cloud-OpenFeign configuration". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Recently, the configuration that you want to implement OpenFeign in the project can be dynamically refreshed (mainly the Options configuration of Feign), for example:

Feign: client: config: default: # Link timeout connectTimeout: 500# read timeout readTimeout: 8000

We may observe that the timeout for calling a FeignClient is unreasonable and needs to be modified temporarily. We do not want to restart the process or refresh the entire ApplicationContext because of this, so we put this part of the configuration into the spring-cloud-config and use the dynamic refresh mechanism to refresh. Officially provide this configuration method, refer to: official documentation-Spring @ RefreshScope Support

That is, add the configuration to the project:

Feign.client.refresh-enabled: true

However, in our project, after adding this configuration, the startup failed and the relevant Bean error was not found:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'feign.Request.Options-testService1Client' available

At org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition (DefaultListableBeanFactory.java:863)

At org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition (AbstractBeanFactory.java:1344)

At org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean (AbstractBeanFactory.java:309)

At org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:213)

At org.springframework.context.support.AbstractApplicationContext.getBean (AbstractApplicationContext.java:1160)

At org.springframework.cloud.openfeign.FeignContext.getInstance (FeignContext.java:57)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.getOptionsByName (FeignClientFactoryBean.java:363)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.configureUsingConfiguration (FeignClientFactoryBean.java:195)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.configureFeign (FeignClientFactoryBean.java:158)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.feign (FeignClientFactoryBean.java:132)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.getTarget (FeignClientFactoryBean.java:382)

At org.springframework.cloud.openfeign.FeignClientFactoryBean.getObject (FeignClientFactoryBean.java:371)

At org.springframework.cloud.openfeign.FeignClientsRegistrar.lambda$registerFeignClient$0 (FeignClientsRegistrar.java:235)

At org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.obtainFromSupplier (AbstractAutowireCapableBeanFactory.java:1231)

At org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance (AbstractAutowireCapableBeanFactory.java:1173)

At org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean (AbstractAutowireCapableBeanFactory.java:564)

At org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean (AbstractAutowireCapableBeanFactory.java:524)

... 74 more

Analysis of problems

From this Bean name, you can see that this Bean is the Feign.Options that we started to mention to refresh dynamically, with configuration such as connection timeout, read timeout, and so on. The part after the name is the contextId in the @ FeignClient annotation above the FeignClient we created.

When you create a FeignClient, you need to load this Feign.Options Bean, each FeignClient has its own ApplicationContext, and this Feign.Options Bean belongs to a separate ApplicationContext for each FeignClient. This is done through Spring Cloud's NamedContextFactory. For an in-depth analysis of NamedContextFactory, you can refer to my article:

Enable dynamic refresh for the configuration of OpenFeign, that is, for FeignClient, you want to refresh the Bean of Feign.Options for each FeignClient. So how to achieve it? Let's first look at the implementation of spring-cloud 's dynamic refresh Bean. First of all, we need to figure out what Scope is.

Scope of Bean

Literally, Scope is the scope of Bean. From the implementation point of view, Scope is how we get the Bean when we get the Bean.

The Spring framework comes with two familiar Scope, singleton and prototype. Singleton means that every time you get a Bean from BeanFactory (getBean), the same Bean returns the same object each time, that is, singleton mode. Prototype means that every time you get a Bean from BeanFactory, a new object return is created for the same Bean, that is, factory mode.

At the same time, we can extend Scope according to our own needs and define how to get Bean. To take a simple example, let's customize a TestScope. A custom Scope needs to define a class that implements the org.springframework.beans.factory.config.Scope interface to define the operations related to the acquisition of Bean under this Scope.

Public interface Scope {/ / gets this bean, and Object get (String name, ObjectFactory objectFactory) will be called when BeanFactory.getBean is called; / / this method @ Nullable Object remove (String name) will be called when BeanFactory.destroyScopedBean is called; / / this is an optional implementation to register the callback of destroy and provide callbacks for external registrations to destroy bean. You can execute the callback passed in here when you remove. Void registerDestructionCallback (String name, Runnable callback); / / if a bean is not in BeanFactory but is created based on context, for example, create a separate bean for each http request so that you can't get it from BeanFactory, you will get / / this is also an optional implementation Object resolveContextualObject (String key); / / optional implementation, similar to String getConversationId () for session id users to distinguish between different contexts;}

Let's implement a simple Scope:

Public static class TestScope implements Scope {@ Override public Object get (String name, ObjectFactory objectFactory) {return objectFactory.getObject ();} @ Override public Object remove (String name) {return null;} @ Override public void registerDestructionCallback (String name, Runnable callback) {} @ Override public Object resolveContextualObject (String key) {return null;} @ Override public String getConversationId () {return null;}}

This Scope simply implements the get method. Create a new objectFactory directly from the incoming bean. Under this kind of Scope, a new Bean is returned every time you call BeanFactory.getFactory, and the Bean automatically loaded into this Scope of different Bean is also a different instance. Write tests:

@ Configurationpublic static class Config {@ Bean / / the name of the custom Scope is testScope @ org.springframework.context.annotation.Scope (value = "testScope") public An a () {return new A ();} / / automatically loaded in @ Autowired private An a;} public static class A {public void test () {System.out.println (this) }} public static void main (String [] args) {/ / create an ApplicationContext AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext (); / / register our custom Scope annotationConfigApplicationContext.getBeanFactory () .registerScope ("testScope", new TestScope ()); / / register the configuration Bean annotationConfigApplicationContext.register (Config.class) we need; / / call refresh to initialize ApplicationContext annotationConfigApplicationContext.refresh (); / / get Config this Bean Config config = annotationConfigApplicationContext.getBean (Config.class) / / call the automatically loaded Bean config.a.test (); / / call getBean from BeanFactory to get An annotationConfigApplicationContext.getBean (A.class) .test (); annotationConfigApplicationContext.getBean (A.class) .test ();}

Execute the code, and you can see from the bundle output that these three A's are different objects:

Com.hopegaming.spring.cloud.parent.ScopeTest$A@5241cf67com.hopegaming.spring.cloud.parent.ScopeTest$A@716a7124com.hopegaming.spring.cloud.parent.ScopeTest$A@77192705

Let's modify our Bean to make it a Disposable Bean:

Public static class An implements DisposableBean {public void test () {System.out.println (this);} @ Override public void destroy () throws Exception {System.out.println (this + "is destroyed");}}

Modify our custom Scope again:

Public static class TestScope implements Scope {private Runnable callback; @ Override public Object get (String name, ObjectFactory objectFactory) {return objectFactory.getObject ();} @ Override public Object remove (String name) {System.out.println (name + "is removed"); this.callback.run (); System.out.println ("callback finished"); return null } @ Override public void registerDestructionCallback (String name, Runnable callback) {System.out.println ("registerDestructionCallback is called"); this.callback = callback;} @ Override public Object resolveContextualObject (String key) {System.out.println ("resolveContextualObject is called"); return null;} @ Override public String getConversationId () {System.out.println ("getConversationId is called"); return null;}}

In the test code, add a call to destroyScopedBean to destroy bean:

AnnotationConfigApplicationContext.getBeanFactory () .destroyScopedBean ("a")

Run the code, and you can see the corresponding output:

RegisterDestructionCallback is called

An is removed

Com.hopegaming.spring.cloud.parent.ScopeTest$A@716a7124 is destroyed

Callback finished

For DisposableBean or other Bean,BeanFactory with related lifecycle types, the operation callback required by the lifecycle will be passed in through registerDestructionCallback. When BeanFactory.destroyScopedBean is used to destroy Bean, the remove method of Scope is called. When the operation is completed, we can call callback callback to complete the Bean life cycle.

Next, we try to implement a singleton Scope, which is very simple, mainly based on ConcurrentHashMap:

Public static class TestScope implements Scope {private final ConcurrentHashMap map = new ConcurrentHashMap (); private final ConcurrentHashMap callback = new ConcurrentHashMap (); @ Override public Object get (String name, ObjectFactory objectFactory) {System.out.println ("get is called"); return map.compute (name, (k, v)-> {if (v = null) {v = objectFactory.getObject ();} return v }); @ Override public Object remove (String name) {this.map.remove (name); System.out.println (name + "is removed"); this.callback.get (name). Run (); System.out.println ("callback finished"); return null;} @ Override public void registerDestructionCallback (String name, Runnable callback) {System.out.println ("registerDestructionCallback is called") This.callback.put (name, callback);} @ Override public Object resolveContextualObject (String key) {return null;} @ Override public String getConversationId () {return null;}}

We use two ConcurrentHashMap to cache the Bean under this Scope and the corresponding Destroy Callback. In this implementation, it is similar to the implementation of the singleton pattern. Then use the following test program to test:

Public static void main (String [] args) {AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext (); annotationConfigApplicationContext.getBeanFactory (). RegisterScope ("testScope", new TestScope ()); annotationConfigApplicationContext.register (Config.class); annotationConfigApplicationContext.refresh (); Config config = annotationConfigApplicationContext.getBean (Config.class); config.a.test (); annotationConfigApplicationContext.getBean (A.class). Test () The name of the method that registers Bean in the Config class is a, so the name of Bean is also an annotationConfigApplicationContext.getBeanFactory () .destroyScopedBean ("a"); config.a.test (); annotationConfigApplicationContext.getBean (A.class) .test ();}

Before destroying the Bean, we use automount and BeanFactory.getBean to request to get the A Bean and call the test method, respectively. Then destroy the Bean. After that, use autoload and BeanFactory.getBean to request the Bean of An and call the test method, respectively. You can see from the output that BeanFactory.getBean is requesting a new Bean, but the bean that is loaded automatically is still the one that has been destroyed. So how do you make the new Bean that is loaded automatically, that is, re-injected?

This involves another configuration above the Scope annotation, which specifies the proxy mode:

@ Target ({ElementType.TYPE, ElementType.METHOD}) @ Retention (RetentionPolicy.RUNTIME) @ Documentedpublic @ interface Scope {@ AliasFor ("scopeName") String value () default "; @ AliasFor (" value ") String scopeName () default"; ScopedProxyMode proxyMode () default ScopedProxyMode.DEFAULT;}

In the third configuration, ScopedProxyMode is configured to obtain the original Bean object or the proxy Bean object when the Bean is obtained (which also affects autoloading):

Public enum ScopedProxyMode {/ / default configuration, no other peripheral configuration is NO DEFAULT, / / use the original object as Bean NO, / / use JDK's dynamic proxy INTERFACES, / / use CGLIB dynamic proxy TARGET_CLASS}

Let's test the effect of specifying the actual object of Scope Bean as the proxy. Let's modify the above test code to use the CGLIB dynamic proxy. Modify the code:

@ Configurationpublic static class Config {@ Bean @ org.springframework.context.annotation.Scope (value = "testScope" / / specifies that the proxy mode is based on CGLIB, proxyMode = ScopedProxyMode.TARGET_CLASS) public An a () {return new A ();} @ Autowired private An a;}

Write the test master method:

Public static void main (String [] args) {AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext (); annotationConfigApplicationContext.getBeanFactory (). RegisterScope ("testScope", new TestScope ()); annotationConfigApplicationContext.register (Config.class); annotationConfigApplicationContext.refresh (); Config config = annotationConfigApplicationContext.getBean (Config.class); config.a.test (); annotationConfigApplicationContext.getBean (A.class). Test (); / / View the type of Bean instance System.out.println (config.a.getClass ()) System.out.println (annotationConfigApplicationContext.getBean (A.class). GetClass ()); / / at this time, we need to note that the name of the proxy Bean has changed, and we need to obtain annotationConfigApplicationContext.getBeanFactory () .destroyScopedBean (ScopedProxyUtils.getTargetBeanName ("a")); config.a.test (); annotationConfigApplicationContext.getBean (A.class) .test ();} through ScopedProxyUtils.

Execute the program, and the output is:

Get is called

RegisterDestructionCallback is called

Com.hopegaming.spring.cloud.parent.ScopeTest$A@3dd69f5a

Get is called

Com.hopegaming.spring.cloud.parent.ScopeTest$A@3dd69f5a

Class com.hopegaming.spring.cloud.parent.ScopeTest$A$$EnhancerBySpringCGLIB$$2fa625ee

Class com.hopegaming.spring.cloud.parent.ScopeTest$A$$EnhancerBySpringCGLIB$$2fa625ee

ScopedTarget.an is removed

Com.hopegaming.spring.cloud.parent.ScopeTest$A@3dd69f5a is destroyed

Callback finished

Get is called

RegisterDestructionCallback is called

Com.hopegaming.spring.cloud.parent.ScopeTest$A@3aa3193a

Get is called

Com.hopegaming.spring.cloud.parent.ScopeTest$A@3aa3193a

As can be seen from the output:

Each call to the automatically loaded Bean calls the get method of the custom Scope to retrieve the Bean

Every time the Bean is obtained through BeanFactory, the get method of the custom Scope is called to retrieve the Bean.

Gets the Bean instance, which is a CGLIB proxy object

After the Bean is destroyed, whether the Bean is obtained through BeanFactory or the automatically loaded Bean, it is the new Bean

So how does Scope achieve this? Next, let's briefly analyze the source code.

Basic principles of Scope

If a Bean does not declare any Scope, then its Scope will be assigned to singleton, that is, the default Bean is singleton. This corresponding BeanFactory needs to generate a Bean definition before registering Bean. This default value is assigned to the Bean definition, corresponding to the source code:

AbstractBeanFactory

Protected RootBeanDefinition getMergedBeanDefinition (String beanName, BeanDefinition bd, @ Nullable BeanDefinition containingBd) throws BeanDefinitionStoreException {/ / omit the source code if (! StringUtils.hasLength (mbd.getScope () {mbd.setScope (SCOPE_SINGLETON);} / / omit the source code that we don't care about.

Before declaring that a Bean has a special Scope, we need to define the custom Scope and register it with the BeanFactory. The Scope name must be globally unique, because that is the name by which the different Scope is distinguished later. Register the source code corresponding to Scope:

AbstractBeanFactory

@ Overridepublic void registerScope (String scopeName, Scope scope) {Assert.notNull (scopeName, "Scope identifier must not be null"); Assert.notNull (scope, "Scope must not be null"); / / cannot be preset scope if (SCOPE_SINGLETON.equals (scopeName) for singleton and prototype | | SCOPE_PROTOTYPE.equals (scopeName)) {throw new IllegalArgumentException ("Cannot replace existing scopes' singleton' and 'prototype'") } / / put it into the map of scopes. Key is the name and value is the custom Scope Scope previous = this.scopes.put (scopeName, scope). / / you can see that the one placed later will replace the one in front. We should try our best to avoid this. If (previous! = null & & previous! = scope) {if (logger.isDebugEnabled ()) {logger.debug ("Replacing scope'" + scopeName + "'from [" + previous + "] to [" + scope + "]") }} else {if (logger.isTraceEnabled ()) {logger.trace ("Registering scope'" + scopeName + "'with implementation [" + scope + "]");}

When you declare that a Bean has a special Scope, when you get the Bean, you will have special logic. Refer to the core source code of Bean obtained through BeanFactory:

AbstractBeanFactory

@ SuppressWarnings ("unchecked") protected T doGetBean (String name, @ Nullable Class requiredType, @ Nullable Object [] args Boolean typeCheckOnly) throws BeansException {/ / omit the source code we don't care about / / create a Bean instance if (mbd.isSingleton ()) {/ / create or return a singleton instance} else if (mbd.isPrototype ()) {/ / create a new instance at a time} else {/ / go here to represent this Bean belongs to custom Scope String scopeName = mbd.getScope () / / must have Scope name if (! StringUtils.hasLength (scopeName)) {throw new IllegalStateException ("No scope name defined for bean'" + beanName + "'");} / / obtain the corresponding Scope through the Scope name. Custom Scope needs to be manually registered Scope scope = this.scopes.get (scopeName) If (scope = = null) {throw new IllegalStateException ("No Scope registered for scope name'" + scopeName + "'") } try {/ / call the get method of custom Scope to get Bean Object scopedInstance = scope.get (beanName, ()-> {/ /) and pass in the callback of the lifecycle needed to create Bean to create Bean beforePrototypeCreation (beanName) Try {return createBean (beanName, mbd, args);} finally {afterPrototypeCreation (beanName);}}) BeanInstance = getObjectForBeanInstance (scopedInstance, name, beanName, mbd);} catch (IllegalStateException ex) {throw new ScopeNotActiveException (beanName, scopeName, ex);}} / / omit the source code that we don't care about

At the same time, if we define the proxy method of Scope Bean as CGLIB, then when we get the Bean definition, the Bean definition of Scope proxy will be created based on the original Bean definition, corresponding to the source code:

ScopedProxyUtils

Public static BeanDefinitionHolder createScopedProxy (BeanDefinitionHolder definition, BeanDefinitionRegistry registry, boolean proxyTargetClass) {/ / original target Bean name String originalBeanName = definition.getBeanName (); / / get original target Bean definition BeanDefinition targetDefinition = definition.getBeanDefinition (); / / get proxy Bean name String targetBeanName = getTargetBeanName (originalBeanName); / / create Bean RootBeanDefinition proxyDefinition = new RootBeanDefinition (ScopedProxyFactoryBean.class) of type ScopedProxyFactoryBean / / configure the relevant attributes of the proxy Bean definition according to the attributes defined by the original target Bean, and omit this part of the source code / / copy to the proxy Bean definition proxyDefinition.setAutowireCandidate (targetDefinition.isAutowireCandidate ()); proxyDefinition.setPrimary (targetDefinition.isPrimary ()); if (targetDefinition instanceof AbstractBeanDefinition) {proxyDefinition.copyQualifiersFrom ((AbstractBeanDefinition) targetDefinition) according to the autoload attribute of the original target Bean. } / / set the original Bean to be not automatically loaded and not Primary / / so that the Bean obtained through BeanFactory and automatically loaded are proxy Bean instead of the original target Bean targetDefinition.setAutowireCandidate (false); targetDefinition.setPrimary (false); / / register Bean registry.registerBeanDefinition (targetBeanName, targetDefinition) with a new name; return new BeanDefinitionHolder (proxyDefinition, originalBeanName, definition.getAliases ()) } private static final String TARGET_NAME_PREFIX = "scopedTarget."; / / this is the tool method to get the Bean name of the agent. We also use public static String getTargetBeanName (String originalBeanName) {return TARGET_NAME_PREFIX + originalBeanName;} when we use Destroy Bean above.

What is the function of this agent Bean? In fact, the main use is that every time any method of Bean is called, it will be called through BeanFactory to get the Bean. Reference source code:

Proxy class ScopedProxyFactoryBean

Public class ScopedProxyFactoryBean extends ProxyConfig implements FactoryBean, BeanFactoryAware, AopInfrastructureBean {private final SimpleBeanTargetSource scopedTargetSource = new SimpleBeanTargetSource (); / / this is the actual proxy generated through SimpleBeanTargetSource, and private Object proxy;} is called for Bean method calls through this proxy.

SimpleBeanTargetSource is the actual proxy source, and its implementation is very simple. The core method is to use the Bean name to get the Bean through BeanFactory:

Public class SimpleBeanTargetSource extends AbstractBeanFactoryBasedTargetSource {@ Override public Object getTarget () throws Exception {return getBeanFactory () .getBean (getTargetBeanName ();}}

Get the Bean through BeanFactory. From the above source code analysis, you can see that the Bean of the custom Scope will call the get method of the custom Scope.

Then there is the termination of Bean. When BeanFactory creates the Bean object, the registerDestructionCallback of the custom Scope is called to pass in the callback of Bean termination:

AbstractBeanFactory

Protected void registerDisposableBeanIfNecessary (String beanName, Object bean, RootBeanDefinition mbd) {AccessControlContext acc = (System.getSecurityManager ()! = null? GetAccessControlContext (): null); if (! mbd.isPrototype () & & requiresDestruction (bean, mbd)) {if (mbd.isSingleton ()) {/ / for singleton registerDisposableBean (beanName, new DisposableBeanAdapter (bean, beanName, mbd, getBeanPostProcessorCache (). DestructionAware, acc)) } else {/ / for custom Scope Scope scope = this.scopes.get (mbd.getScope ()); if (scope = = null) {throw new IllegalStateException ("No Scope registered for scope name'" + mbd.getScope () + "'") } / / call registerDestructionCallback scope.registerDestructionCallback (beanName, new DisposableBeanAdapter (bean, beanName, mbd, getBeanPostProcessorCache (). DestructionAware, acc);}

When we want to destroy Scope Bean, we need to call the destroyScopedBean method of BeanFactory, which calls the remove of custom Scope:

AbstractBeanFactory

@ Overridepublic void destroyScopedBean (String beanName) {RootBeanDefinition mbd = getMergedLocalBeanDefinition (beanName); / / use if (mbd.isSingleton ()) only for custom Scope Bean | | mbd.isPrototype () {throw new IllegalArgumentException ("Bean name'" + beanName + "'does not correspond to an object in a mutable scope");} String scopeName = mbd.getScope () Scope scope = this.scopes.get (scopeName); if (scope = = null) {throw new IllegalStateException ("No Scope SPI registered for scope name'" + scopeName + "'");} / / call the custom Scope remove method Object bean = scope.remove (beanName); if (bean! = null) {destroyBean (beanName, bean, mbd) This is the content of "how to solve the problem of enabling Spring-Cloud-OpenFeign configuration to refresh the project that cannot be started". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.