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.
Related
TL;DR
Is there a way to mix Spring Web Security configuration with both annotations and xml?
Full Story
For our legacy spring web application we are looking into using annotation driven configuration for part of our web security.
Currently all our web security (<security:http>) is driven by xml based configuration. But we are adding a new login mechanism (SAML 2.0) that seems like it would be much easier to configure via annotations than xml.
We have been attempting to mix the use of annotations and xml, but it seems as though only one or the other works. Meaning that when any xml based web security is referenced, either via an xml (<import resource="classpath:web-security.xml"/> or via the #ImportResource annotation, the annotation based web security is ignored.
If we remove references to the xml based configuration our annotation configuration gets called.
Any friendly suggestions or advice is appreciated.
Mixing the Spring Web Security XML and annotation configurations would mean that that the same bean instance, viz., security:http is being configured via XML as well as JavaConfig. It would be configured with some intercept URL patterns using XML and some other Ant matchers using JavaConfig. But please note that intercept URL patterns are always evaluated in the order they are defined and also the matchers are considered in order. So, Spring Security only considers the XML configurations and ignores the JavaConfig ones as, if it considers both, it won't have any sense of order of URL definitions. I couldn't find any documentation that directly supports this theory. If you share the Spring Boot log statements that are produced when the application boots up, we may get a better view of what Spring Boot is doing.
So, I don't think that you can mix Spring Annotations with XML Configuration when configuring Spring Web Security and will advise to migrate legacy XML configurations to JavaConfig.
The background & requirements are:
there are a lot of old projects which have an applicationContext.xml and one or more dispatcher[-XXX]-servlet.xml. We hope those projects can still works while using spring boot(we developed a deployment tools to deploy spring boot applications, but the old projects are still deployed manually). But, #SpringBootApplication can't build the contexts as they were. And rewriting them into codes one by one costs too much, I think.
In those project, we use an extended RequestMappingHandlerMapping, so we can't use the native MVC.
the context.xml of tomcat, which contains jndi definitions, is maintained by OPs. We have to load it just like tomcat does.
i can't find where to set welcome file, which were set in web.xml
I currently using:
#Configuration
#ImportResource({"classpath:/applicationContext.xml", "classpath:/dispatcher-servlet.xml"})
Those simple projects without using jndi can startup.
But as my understanding, in this case, the applicationContext and dispatcher-servlet are in the same level(dispatcher-servlet should the child of applicationContext, isn't it?). So, i can't even ensure this one works properly.
We did a similar thing about a year ago and your setup was more or less the same as ours and importing those XML files did the trick; the only thing we had to do was to ensure our application class was in a different package hierarchy in order to avoid conflicting/duplicate bean definitions due to its inherent #ComponentScan.
And having dispatcher servlet and application context in the same context won't cause any issues - yes, dispatcher servlet's context is usually defined as a separate context and is a child of the more broad applicationContext but what most people fail to grasp is that that separation only matters if your application wants to have more than one dispatcher servlet, which is rarely the case any more, if it ever was.
In case of multiple dispatcher servlets it was a must to enable them to have different WebMVC configurations, and applicationContext was there to allow you to share common beans and configuration between your servlet contexts so that you don't have to do the same work twice.
I am trying to figure out how can I dynamically update/reload externalized configuration in a Spring Boot application without restarting the whole application.
Most of the advice involves reloading ApplicationContext after changing the externalized configuration, but that is equivalent to restarting the entire application, so this is not really all that useful.
Reading through SpringBoot reference documentation, I found a chapter 23.7 Typesafe Configuration Properties.
If I understand it correctly, this allows to define simple POJO classes that will hold your application (externalized) configuration values as attributes.
In theory at least, this scheme could be used to bind beans only once to the required configuration POJO and upon configuration change just update the values in the POJO. Components could easily pick up the changes next time they access getters on the POJO...
However, I have yet not managed to figure out how to enable this type of behavior. Is there some glaringly obvious way to dynamically update components annotated with #ConfigurationProperties when relevant configuration has changed?
It sounds like you're looking for #RefreshScope which is provided by Spring Cloud. From the Spring Cloud documentation:
A Spring #Bean that is marked as #RefreshScope will get special treatment when there is a configuration change. This addresses the problem of stateful beans that only get their configuration injected when they are initialized. For instance if a DataSource has open connections when the database URL is changed via the Environment, we probably want the holders of those connections to be able to complete what they are doing. Then the next time someone borrows a connection from the pool he gets one with the new URL.
I'v mostly used XML based configuration for applicationContexts. I have a requirement where I need to use #configuration to create my beans using #Bean now.
Brief description of why ?
weblogic deploys a spring web-app "A". A makes calls to B(not spring,not web app-no WEB_INF). B just contains common service calls to external servers. Hence B.jar is bundled into A and A is then deployed on web-logic.
Now i need to use spring beans in B.)
So the options available at this point:
Bundle applicationContext.xml and all the property files into B.jar. (keep in mind it is a very complex build process with 20 property files and 100s of beans. So I also need to register propertymanager bean etc..). Then initialize appcontext in a static initializer block and look for appcontext within B.jar.
Use #configuration to register an Appconfig.class instead of an XML. (no changes to build process here).
With this option i need to use a clientInterceptor. Could you provide me with the #Bean definition of this.
How do I configure clientInterceptor in #appconfig.class.
*please let me know if there any other options.
Spring-ws-core - 2.1.4.release
spring-core-3.2.4
expression,context,beans - 3.0.5
spring-oxm-1.0.3
weblogic - 12c
jdk - 1.7
This is my first post here. Any suggestions would be welcome and appreciated. Apologize for any forum faux paus.
I am programming service for getting data from database and providing them via REST service. It uses spring mvc. My database connection cofiguration is in property file from where it is loaded by spring as a data source bean during context initialization.
Now my problem is - I want to change configuration in properties file (for example change database info) but I can't afford to restart the application server so the new configuration does not load.
How can I re-initialize spring context or some particular beans so the newly defined properties are used?
If you want multiple data source in spring and need to deciding appropriate data source dynamically at runtime you can do this with AbstractRoutingDataSource provided with spring. You have to implement your lookup key logic for determining data-source in method determineCurrentLookupKey(). With this you can map different beans to different data-sources at runtime. following are few questions relating to this context.
How to programatically change databases in Spring with one DataSource?
Also
dynamically change Spring data source