SpringBoot comes with its own pre-configured Jackson2ObjectMapperBuilder that is used through the framework to configure the various ObjectMapper.
The builder doesn't expose all facets of the ObjectMapper and I was wondering how I could apply additional configuration to the builder before it is used?
I can obviously provide my own Jackson2ObjectMapperBuilder instance but then I would loose the default initialisation provided by SpringBoot...
Is there another way?
Create beans that extend com.fasterxml.jackson.databind.module.SimpleModule,
there you configure for example your own seriealizers and deserializers.
In the newer spring versions (dont know since when but at least since spring 4 ) these beans are picked up automatically.
In older versions of spring you may need to add the Modules manually to the ObjectMapper, which is tricky, because spring creates many beans of type ObjetMapper and its not easy to find the right one.
Related
We are trying to utilize pf4j and pf4j-spring to provide a flexible application based on Spring.
Ideally, we would like to define Spring beans (#Service, #Repository and others) in plugins and inject them in the main application.
From what I can see, it seems to fail due to timing issues. Or in other words, Springs expects the beans to be available before the PluginManager gets instantiated.
There is an example repository that illustrates the issue on GitHub.
The question would be: Can I change something, so that Spring instantiates the PluginManager first? Is there another approach to make this work?
Note: Yes, we are aware of sbp. Unfortunately, it seems to be dead, and we didn't get it working properly either.
I am having an architectural issue with the Apache HttpComponents HttpClient.
We have a system where we have several different remote endpoints that we want to contact, and each have some different configurations like ssl, basic auth, et cetera.
I am using Spring Boot and Cloud Sleuth from which I get a HttpClientBuilder that gives me tracing and other things. I want to re-use that HttpClientBuilder but on-top of that add my own specific configurations, for each unique endpoint.
The problem though is that the HttpCientBuilder is not immutable with withXYZ() methods, nor is there a copy or clone method on the builder, so I can't copy the original and change just my specific changes there without altering the base HttpClientBuilder and get into conflicts with others that use the same instance of the builder. Be it racing conditions between threads or conflicting configurations between the different endpoints.
One place in the Spring Boot project where I have seen them seemingly wanting to do something similar is in HttpClientConfiguration of Spring Cloud Commons where it creates an own ApacheHttpClientFactory which takes the original autowired HttpClientBuilder and then sets disableContentCompression(), disableCookieManagement() and useSystemProperties() -- but it seemingly does it to the original instance of the HttpClientBuilder which just seems completely wrong to me. It will alter how all the built HttpClient works, and not just the one they will later be using in their Ribbon code in HttpClientRibbonConfiguration of Spring Cloud Netflix Ribbon. A potential bug in hiding? To me it seems like it, since it highly depends on calling order.
Does anyone have any ideas how something like this should be solved?
The easy alternative that I could do is to just not try and build upon the given HttpClientBuilder from Sleuth, but instead build a completely new one from the ground-up every time I need one, and check if a HttpTracing bean is available and use TracingHttpCientBuilder instead of HttpClientBuilder in that case, but this seems counter-intuitive.
I ran into the exact same problem. However, I had the option of defining my own HttpClientBuilder bean. I am not sure you are in the same position?
But by making the bean scope "prototype" a new bean instance is created every time it is injected somewhere. Then I could safely modify the HttpClientBuilder after injection.
#Bean
#Scope("prototype")
public HttpClientBuilder tracingHttpClientBuilder(..) {
...
}
What happens when I build an object using new keyword in service using springboot framework?
Does the Object created using "new" keyword is built out of the container?
No, the object created out of a "new" keyword doesn't come out of the container. There are two disadvantages to this approach. The first being that it renders the Spring framework a bit useless. Secondly, if there are #Autowired or Spring managed beans inside your "new" bean, they won't get injected. Once you do a "new", spring leaves all the subsequent hierarchical dependency injection to you.
in Spring, objects that are created using new keyword, created outside of the container. So you wouldn't get benefits like life cycle management, Security etc
You should always use Spring dependency injection to create Beans (using the #Autowired annotation is the recommended way to do this) otherwise you're losing the benefits of using the Spring framework. I would suggest reading this documentation on Beans and Dependency Injection if you haven't already
I'm just learning Spring Security, and a lot of Spring's documentation appears to use Java-based bean configuration (as opposed to XML.) Overall, this seems to be the way a lot of their projects are going. However, portions of their documentation tend to start with Java configuration and then switch to XML config later on. I found a blurb in one document (http://docs.spring.io/spring-security/site/docs/3.2.0.RELEASE/reference/htmlsingle/) stating the following:
Spring Security’s Java Configuration does not expose every property of every object that it configures. This simplifies the configuration for a majority of users. . . . While there are good reasons to not directly expose every property, users may still need more advanced configuration options. To address this Spring Security introduces the concept of an ObjectPostProcessor which can used to modify or replace many of the Object instances created by the Java Configuration.
Can everything that can be done in XML configuration be done with Java config? Is there a definite direction that the Spring community is taking overall in terms of configuration style?
You can choose either java based or xml based configuration.Stick to one, don't mix both.But don't forget to use the annotation based configuration.You just need to annotate spring managed components with #component,#service etc.You don't need to have that bean defenition in xml or java class.
<context:annotation-config/>
<context:component-scan base-package="com.package"/>
or
#Configuration
#ComponentScan({"com.foo.bar", "org.foo.bar"})
http://docs.spring.io/spring-security/site/docs/3.2.0.RC2/reference/htmlsingle/#jc
You can use Java or XML based. But there is a thing
Usage of xml based configuration is decreasing in newer versions of Spring.
Like #EnableAutoConfiguration tag...
With this, web applications doesnt need any XML conf even web.xml
On Spring #Autowired usage question most of the people answer they prefer not using configuration files, if possible. It seems like a good answer at the first glance.
However, once you have quite a big application which uses Spring IoC and autowires all the stuff using annotations #Autowired, #Service, etc. you must hit this problem: you no longer are able to keep track of your bean dependencies.
How do you deal with that?
Using SpringSource Tool Suite one can create graphs of dependencies on the basis of configuration files.
Is there any tool out there which does the same with #Autowired stuff? (I understand graphs would have to be created on runtime).
Implement BeanFactoryAware and cast the factory that is passed into setBeanFactory() to a DefaultListableBeanFactory. Then use DefaultListableBeanFactory.getBeanDefinitionNames() and DefaultListableBeanFactory.getDependenciesForBean() to generate the dependency graph.