We Keep Coding

How to trace all endpoints or methods with OpenTelemetry and manual configuring

I'm trying to use OpenTelemetry SDK to trace my java application. When I'm using auto configuration with opentelemetry-javaagent.jar I see a lot of methods traced. But when I'm using manual config I need to add spans for all methods I want to trace. How I can trace all methods and just filter some unnecessary ones with manual config?

Is there a way to make Spring reload bootstrap properties dynamically?

I have a spring-boot app that autoconfigures an instance of Netflix's DynamicPropertyFactory. This enables us to read any properties spring is aware of plus any additional sources we specify.
The issue arises when we change a spring property that is used in core spring classes. For example logging.level.org.springframework.web=INFO is used on core classes or spring before, during, and after applicationContext setup. If we change this property while the application is running to say logging.level.org.springframework.web=TRACE...
dynamicPropertyFactory.getInstance().getStringProperty() eventually realizes the change. However, the spring core classes continue to log at INFO rather than change to TRACE as expected.

Hystrix runtime configuration with Spring-Cloud-Config instead of Archaius?

I'm studying Spring-Cloud-Netflix and I learned that Archaius was used for Hystrix runtime configuration. (https://ahus1.github.io/hystrix-examples/manual.html#archaius)
I also found that Archaius was a soft-dependency since V1.5.0 (https://github.com/Netflix/Hystrix/pull/1083): "Archaius is now a soft-dependency of Hystrix, so you can supply your own configuration mechanism."
My question is, is it easy to configure Hystrix with Spring-Cloud-Config at runtime? I did some research but haven't found any examples.
Appreciate any ideas.

After several days' research, I managed to dynamically configure Hystrix properties with Spring Cloud Config. I also made a small demo on configuring the Hystrix instance property at runtime.
First, each Hystrix property has four levels of precendence:
Global default
Dynamic global default
Instance default
Dynamic instance property.
Where the 1st and 3rd levels only support static configurations. Since the 2nd level (dynamic global default) was not discussed a lot in the Hystrix Wiki, I choose the Dynamic Instance Property for runtime configuration. However, I believe my method should apply to Dynamic Global Default as well.
The practice is simple. First pull a config value from Spring Cloud Config using the #Value annotation:
#Value("{timeoutInMilliseconds:1500}")
String timeout;
Then use the string timeout in your Hystrix instance:
ConfigurationManager.getConfigInstance().setProperty("hystrix.command.HystrixHelloWorld.execution.isolation.thread.timeoutInMilliseconds", timeout);
Where the ConfigurationManager.getConfigInstance() is an Archaius method, returns a configuration instance. .setProperty() sets the property

How to NOT add HandlerMapping to Spring DispatchServlet

I have a SpringMVC application. It has in it a custom class that extends DefaultAnnotationHandlerMapping. This class is used for some meta tools to generate reports and tools for use with the API of the MVC app. It is NOT needed to be used by the DispatchServlet.
I am in the process of upgrading this system from Spring 3.2 to 4.1. One of the results of this upgrade is that the order of the HandlerMappers in the DispatchServlet changed. The custom class is now higher in priority than the RequestMappingHandlerMapping that we get the proper handler from.
So my question is:
Is there a way to ensure that the custom class NOT be added to the Dispatcher at all? I have not configured it to do so. I assume Spring is just picking it up because it is a HandlerMapping
If not where is the best place to set the Order so I can push it lower. AbstractHandlerMapping has made the getter and setter for order final (So I can't override the getter). I attempted to set a low priority in the constructor of the custom class but apparently spring then resets it back to 0 later on.

Set up your DispatcherServlet programmatically through a WebApplicationInitializer and set DispatcherServlet#setDetectAllHandlerMappings(boolean) to false.
In this case, Spring will only look for a HandlerMapping named handlerMapping. The one provided by the default MVC configuration will have that name.

Identifying bean dependencies associated with a specific operation

I am working on a JAX-RPC webservice that is already built. This is a huge service which consists of around 25-30 operations. A large number of Spring config files (around 50) are also present. A number of test classes are developed which loads all the spring references associated with the service. This takes a long time to load all the spring config files and associated bean references before executing the specific test method. I am trying to see if I can load only the specific spring config files / bean references that pertain to the operation.
I was told that setting default lazy load parameter in spring config might not help as it works only if it is run within a container. Would it be possible to help in suggesting in options that I can follow to decrease the initial loading time?

I don't know, but may be this help you. You can use annotations in you test classes to specify the config files you need to include to the context. Also, you can add spring profiles and activate them from the test class.
#RunWith(SpringJUnit4ClassRunner.class)
#ActiveProfiles({ "dev-test"})
#ContextConfiguration({"/application-context-persistence.xml", "/another-context.xml"})
public class Test{
}