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.
I'd like to use Prometheus' JMX exporter to collect custom application metrics using Prometheus. I have an application that I've packaged into a jar file ApplicationToMonitor.jar-- it exposes port 8989 and declares Prometheus metrics, but doesn't expose an end-point for prometheus to scrape (from what I've read, the prometheus javaagent takes care of this).
I'm not sure what the configuration.yaml file should look like. Also, why is it recommended that one use the shaded.io.prometheus library (and register new metric variables under the default registry) as opposed to the regular io.prometheus library and not using a registry at all?
I'm referencing the Prometheus JMX exporter documentation, just simply not understanding the aforementioned components.
You would only use the JMX exporter for code you don't control that's exposing JMX metrics. In this case you need to add some exposition per https://github.com/prometheus/client_java#http. The HTTPServer is simplest.
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.
While it's well known that Websphere's JAX-WS implementation is based on Axis2, I have had trouble finding information how to set "scope" for the service.
In axis 2 scope can be defined using services.xml. Is this file also available in Websphere?
http://axis.apache.org/axis2/java/core/docs/axis2config.html
scope: (Optional Attribute) The time period during which runtime information of the deployed services will be available. Scope is of several types- "application", "soapsession", "transportsession", "request". The default value (if you don't enter any value) will be "request"
It seems it is possible to do what you want in WebSphere (not using services.xml):
Configuring the scope of a Web service port using wsadmin scripting
Did not try it myself, also, could not find such settings in the admin console or deployment descriptor of some kind but that might be possible as well.
OSGi employs a service-oriented architecture: Bundles register service objects, that other bundles consume. Service publishing and binding is managed by the framework. This decouples service providers from service users completely (except for the need to agree on a service interface).
Is there a way to limit (by configuration) what services are visible to what bundles ?
For example, if I have an HttpService, all bundles that feel like doing so can install servlets into it. I would like to make the HttpService not visible to selective bundles.
For extra credits: In addition to just filtering service registrations, the ability to modify registration properties. So that even if a bundle registers a Servlet with alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web Extender Whiteboard.
Is there a way to limit (by configuration) what services are visible to what bundles?
As you are aware, it is possible to filter on service properties, though this probably doesn't give the sort of control you are asking for: the services are still visible to other bundles deployed in the framework.
In SpringSource's dm Server (an open-source, modular, OSGi-based Java application server) an application can be Scoped when it is deployed. This allows you to deploy multiple applications (in separate scopes) that might include inconsistent versions of dependent bundles, while still allowing common bundles to be shared (by deploying them outside of a scope—in the so-called global scope).
If a scoped application/bundle registers an OSGi service it is only available to the bundles in the same scope. (The services are 'scoped' as well.)
This is not magic: the server wraps the OSGi services interfaces and uses service properties 'under the covers' to perform the filtering required on-the-fly.
I think this would give you the sort of separation you are looking for.
For information about dm Server (not to be confused with Spring DM) go to the SpringSource.org dmServer page.
Steve Powell
SpringSource; dm Server Development
The upcoming R4.2 of the OSGi specification define a component called Find Hook that allows exactly to:
"inspect the returned set of service references and optionally shrink the set of returned services"
See
http://www.osgi.org/download/r4-v4.2-core-draft-20090310.pdf section 12.5
Please note that R4.2 is not final yet, still I believe the major OSGi implementations (Felix and Equinox) already have the code for this additional functionality in their trunk
Is there a way to limit (by configuration) what services are visible to what bundles ?
There is no way to do that using service properties. You could define your own service property that specifies which bundles should consume the service you are exporting, but there is no way to prevent other bundles from consuming it as well.
For extra credits: In addition to just filtering service registrations, the ability to >modify registration properties. So that even if a bundle registers a Servlet with >alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web >Extender Whiteboard.
Well... that's a tough one. You could define your own Servlet interface "MyServlet" and export your Servlets using that interface. Then, another bundle could consume those MyServlets and re-export them as Servlets with modified service properties.
Other than that ... no idea.
I haven't tried this, but seems like it may help you...
In the OSGi R4 Component Spec describes the "Configuration Admin Service" which, from a 5 minutes inspection, appears to be able to alter services dynamically.
Ultimately I think it will be up to you to control access to the services based on some agreed upon configuration values
For extra credits: In addition to just filtering service registrations, the ability to modify registration properties. So that even if a bundle registers a Servlet with alias=/admin, I can change that to alias=/somethingelse for consumption by Pax Web Extender Whiteboard.
using iPOJO you can change properties of the exposed services pretty simple. It has bunch of other features, which could be interessting to someone using OSGi a lot.
If you want to limit the visibility of services, your best bet is to enable OSGi security. It is designed to limit what services, packages and other things are visible to what bundles. You can for example only make a certain service available to a bundle that is signed by you (or use various other criteria).
The other option, already mentioned, it to use the 4.2 service hooks, which allow a sort of "do it yourself" security mechanism.
The second question, changing properties like the endpoint under which a service is registered, is something you can do via the ServiceRegistration that you get back when registering your service. Changes can be triggered by becoming a ManagedService and use ConfigurationAdmin to configure yourself.