At this moment we have monolith app where all mbeans are defined in single place.
In future they will be migrated and placed in dedicated modules, each module will have their spring context definition.
Found #EnableMBeanExport(registration = RegistrationPolicy.IGNORE_EXISTING) useful for migration from original solution to a new approach. My spring version is 5.2.4
I wish to have control over mbeans export, but noticed from javadoc (AnnotationMBeanExporter) that by default using this annotation export ALL mbeans from spring context. It means that jmx configuration from module A will publish mbeans from other modules B or C, even mbeans from 3rd party libraries will be available.
I planned to set JMX configuration only on specific modules that would like to expose mbeans and not sure if:
have to change approach and place #EnableMBeanExport once, somewhere in main configuration
have to create a new annotation, that would change default process
add sth to annotation to activate it on specific module
See the javadocs for #EnableMBeanExport.
* <p>The resulting {#link org.springframework.jmx.export.MBeanExporter MBeanExporter}
* bean is defined under the name "mbeanExporter". Alternatively, consider defining a
* custom {#link AnnotationMBeanExporter} bean explicitly.
*
So simply declare the AnnotationMBeanExporter as a #Bean and configure it to only register the beans you need.
See Controlling the Registration Behavior.
Related
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.
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 have a spring project where I have my custom mbeans(defined by user) and mbeans provided by jars. If I don't have to expose few operations of custom mbeans, I can put the mathod name values in assembler under properties : ignoredMethods.
My question is : If i don't have to expose the method of a third party jar mbean which is already exposed, what should I do?
If the third party jars are themselves registering the MBeans with the MBeanServer internally, you have no control. If you are using Spring to expose the MBeans, then you can control what's exposed.
EDIT:
If you are using <context:mbean-export/>, it creates an AnnotationMBeanExporter which will auto-detect classes matching the MBean naming rules by default.
You can turn it off by declaring the exporter as a <bean/> instead and setting its autoDectedMode to 0, or autoDetectModeName to AUTODETECT_NONE.
I have a Swing project using Spring for DI and now I am trying to migrate to Eclipse 4 and OSGi.
Using the configuration files of Spring the user could comment/uncomment beans in order to add/remove functionality (offered by these back-end beans).
Now in Eclipse and OSGi I am looking for the best way to do this based on OSGi.
I know that I can make the beans as services and define start levels in OSGi but this does not solve my use case, which is:
The application starts without these beans/modules running and if the user updates the configuration from the running UI these beans/modules start and they are also started on the next start-up of the application.
Is there a nice/clean approach for my problem?
You probably want to use Eclipse Gemini Blueprint to do the management of how everything is integrated between Spring and OSGi (Gemini Blueprint is the successor to Spring Dynamic Modules). In particular, it can handle virtually all the complexity relating to dynamic service registration for you; your beans can remain virtually identical.
Another approach would be to use Declarative Services together with Configuration Admin to let configuration data determine which services to activate. In more detail here.
Like you already found out services are a good aproach to this. Simply install all your modules but do not start them. Then your UI can start and stop modules as the user selects the functionality he wants. THe OSGi framework then remembers the installed and started modules on a restart.
The absolute best approach for this is Declarative Services (DS). DS is integrated with OSGi's Configuration Admin, making it trivial to control the number of service instances as well as their configuration and service properties. For example, the following component (with the bnd annotations [which will resemble similar functionality in the OSGi specs soon]):
#Component(designateFactory=Config.class)
public MyComp implements MyService {
interface Config {
int port();
String host();
}
Config config;
#Activate
void activate(Map<String,Object> map) {
config = Configurable.createConfigurable(Config.class,map);
start();
}
void foo() { ... do the MyService stuff ... }
#Reference
void setDataSource( DataSource ds ) { ... }
}
This component requires a Configuration Admin factory configuration. The best way to see how powerful this is, is to setup a framework with Apache Felix Webconsole. The designateFactory=Config.class tells bnd to create a metatype XML file in the bundle. This is used by the Webconsole to create a pretty nice looking form for the configuration data, derived from the interface and its methods. This form is type aware, i.e. you cannot enter a non-nummeric value for the port number. Through the webconsole you can now instantiate multiple components by creating multiple factory configurations. Deleting these factory configurations, removes the service. In your application, you can manipulate Configuration Admin yourself under the control of the user.
Another advantage is that through Configuration Admin you can control the binding of the component's dependencies. In the aforementioned example, you can set the dataSource.target property to a filter like (db=accounting) to select the accounting database. All configuration properties are added as service properties so you can easily set the 'db' service property on the configuration that creates the Data Source (if it was implemented this way).
This is one of the least understood advantages of DS, and I can tell you it is HUGE. To get started with this this, just create a DS project in bndtools and then a new Run Descriptor and select the Webconsole template.
Another advantage of DS is that it is small and it is not try to hide the dynamics, which in Blueprint can be painful.