Develop Reference

How to Instantiate #configuration bean based on request parameters in java spring?

I have multiple configuration files in java spring.
I need to instantiate it based on the request parameters.
Is there any way to do it?
Thanks in advance!!
Sakthi

This is not possible, as Spring initializes the configuration before the service starts (or more accurate, when it starts) so when you get a request, it is too late - the configuration is already built.
You can, however, control it with spring profiles- either via env variable on the machine or arguments passed to the jvm when you run your app. This way you can control which spring profile to use and set the configurations per profile.

Can you use scoped proxies with Spring Boot 2 #ConfigurationProperties?

Using Spring Boot 1.5.12, we create scoped proxies for #ConfigurationProperties beans. We do this so that we can effectively have property values that are scoped to the user/session/etc. We use a BeanFactoryPostProcessor to register a scoped proxy created by ScopedProxyUtils.createScopedProxy and change the scope of the target bean definition to our custom scope.
This worked great in Spring Boot 1.5.12. However, in Spring Boot 2, the introduction of the Binder API has made this stop working. This is because when Spring Boot binds #ConfigurationProperties in its ConfigurationPropertiesBindingPostProcessor, it uses Bindable.of(type).withExistingValue(bean) passing in a type (e.g. org.example.Foo) and the bean which is an instance of ScopedProxyFactoryBean. Bindable checks that bean is an instance of type which it's not and things blow up.
Does anyone know of a general way to accomplish this? Specifically, to replace the #ConfigurationProperties bean definition with a proxy while still allowing the properties to bind to the instance? I've considered delaying the creation of the proxy until after the target has already been bound by ConfigurationPropertiesBindingPostProcessor (i.e. in my own BeanPostProcessor). However, at this point the bean is instantiated and my proxy can only replace the bean. It can't really leave the original bean in the context as a target. So I'm struggling with how to do this using a BeanPostProcessor.
EDIT: I've created a simple example project that demonstrates the issue (with the ability to check out code that works on Spring Boot 1 and fails on Spring Boot 2).

How to detect unused spring beans configured in XML?

I have a java project in which many .xml files are present.
All these xml files contain many beans.
The test for unused is:
A bean that is defined but never injected.
A bean that is injected but is never called in the code.
A bean that is defined but never loaded into the Spring context.
Questions
How do I identify which bean is used or not?
Is there a utility to do that?

There is no tools for detecting the unused springbeans in xml file. You can use the Spring Tools Suite for detecting. But it is taking too much time for checking.

I think that you can use spring actuator to check the opposite problem - which beans have been loaded in your context.
https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html
Actuator endpoints allow you to monitor and interact with your
application. Spring Boot includes a number of built-in endpoints and
you can also add your own. For example the health endpoint provides
basic application health information.
The way that endpoints are exposed will depend on the type of
technology that you choose. Most applications choose HTTP monitoring,
where the ID of the endpoint is mapped to a URL. For example, by
default, the health endpoint will be mapped to /health.
beans Displays a complete list of all the Spring beans in your application.
Looking for all the beans which are unused requires scanning XML files within application, then you can compare it with the list of beans produced by actuator.

CGLIB errors converting a weblogic spring web app to springboot app

I am attempting to convert an existing spring weblogic application to a spring boot embedded tomcat application.
There are lots of moving parts so it's hard to show any code, I'm hoping there is some general answer that might clue me in to the issue.
Under weblogic, using the spring-framework 4.3.6.RELEASE libraries, the application deploys fine. It has no problems creating the different service, repository and component beans.
However, when I migrate it to Spring Boot 1.5.1.RELEASE, I get the following error:
2017-06-21 17:08:16,402 [ERROR] SpringApplication reportFailure (815) - Application startup failed
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'alertEventServiceImpl': Unsatisfied dependency expressed through field 'alertEventDao'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'alertEventDaoImpl' defined in URL [jar:file:/Users/username/Development/source/carma-war/target/carma-war-2.0.0-SNAPSHOT.war!/WEB-INF/lib/protocol-manager-1.8.0-SNAPSHOT.jar!/org/ihc/hwcir/protocol/dao/AlertEventDaoImpl.class]: Initialization of bean failed; nested exception is org.springframework.aop.framework.AopConfigException: Could not generate CGLIB subclass of class [class org.ihc.hwcir.protocol.dao.AlertEventDaoImpl]: Common causes of this problem include using a final class or a non-visible class; nested exception is java.lang.IllegalArgumentException: Cannot subclass final class org.ihc.hwcir.protocol.dao.AlertEventDaoImpl
Many of our service classes are final as they shouldn't be extended. Since there are so many that are final, I wanted to minimize the amount of code in our different libraries that we modify to make this work.
I thought because the bean creation process works under weblogic, it should work under spring boot.
Things I have tried to force not using the cglib proxies:
All implementations implement interfaces already
In beans created via xml, added <aop:scoped-proxy proxy-target-class="false"/>
In beans created through annotations, added (example for service bean)
#Service
#Scope(proxyMode = ScopedProxyMode.INTERFACE)
However, in the end, I'm perplexed as to why spring can create beans (the classes marked as final) under the weblogic container but unable to do so under the embedded tomcat spring-boot container.

Spring Boot by default uses class based proxies, which will not work with final classes/methods.
To disable this add spring.aop.proxy-target-class=false to the application.properties to enable JDK Dynamic Proxies instead of class based proxies. (And revert your modifications).
NOTE: To have everything take into account the spring.aop.proxy-target-class you might need to upgrade to Spring Boot 1.5.3 as some final patches where made to include this property in parts that were missed in previous versions.
See the following issues for more information 8434, 8869 and 8887.

I was unable to make this work using M. Deinums' answer using spring.aop.proxy-target-class=false.
What worked for me was to add in the application.properties file
spring.dao.exceptiontranslation.enabled=false
Please note that this option disables proxy creation for repositories.
And in my spring boot application configurer the annotation to handle transactions without using a proxy class.
#EnableTransactionManagement(proxyTargetClass = false)
This is using Spring Boot version 1.5.1.RELEASE.

Tomcat 6 Virtual Hosting Same Spring Application

I want to deploy the same .war file to two different virtual hosts on the same Tomcat 6 instance. However, I am running into a problem with the Spring framework and registering a bean. Here is the error I am seeing...
org.springframework.jmx.export.UnableToRegisterMBeanException:
Unable to register MBean
[com.dti.servlets.Configuration#3a1834]
with key 'EAM:name=webConfig'; nested
exception is
javax.management.InstanceAlreadyExistsException:
EAM:name=webConfig
I am pretty sure that I need to define my contexts for each virtual host but I am not having any luck. The only fix I have found that works is to change the name of the bean key. Any other suggestions would be great.

The problem is that the name of the bean must be unique per JVM. Since you're deploying the same war twice, you have two solutions:
change the registration behaviour of the Spring JMX exporter (see the documentation)
define your own ObjectNamingStrategy to dynamically change the name of the beans at startup (you would end up with names like app1.mybean and app2.mybean)