Is it necessary to have a keycloak.json file even if we have configured everything in application.properties for a spring boot application.
If you are using Spring Security Adapter, add bean KeycloakConfigResolver in your configuration file. It will use application.properties instead of WEB-INF/keycloack.json
#Bean
public KeycloakConfigResolver KeycloakConfigResolver() {
return new KeycloakSpringBootConfigResolver();
}
See: https://developers.redhat.com/blog/2017/05/25/easily-secure-your-spring-boot-applications-with-keycloak/ Creating a SecurityConfig class section
Assuming yours spring-boot application , if you are using keycloak-spring-boot-starter spring-boot adapter, Then you have all your configurations in application.properties.
You can find examples here https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-springboot
Related
I have a custom properties file for my spring boot application for database configurations. I use spring data JPA for persistence, By default spring boot choose application.properties to load the configurations.
How to avoid it and use any custom file, to read the database configuration on application startup
Example : database-connection.properties
spring.datasource.driver-class-name=org.postgresql.Driver
spring.datasource.url=jdbc:postgresql://ip:5432/HP
spring.datasource.username=hpadmin
spring.datasource.password=hp#12345
Thank you
You will avoid future complications if you use just one and the classic application.properties.
Spring requires more than just database configurations so replace the entire application.properties by a simple database-connection.properties is not a good idea.
Anyway, if you need to add more properties alongside application.properties you could use
one of the following approaches:
PropertyPlaceholderConfigurer
You could load extra properties alongside the application.properties or replace it entirely if you delete the application.properties
In your main class:
#Configuration
public class PropertiesConfiguration {
#Bean
public PropertyPlaceholderConfigurer properties() {
final PropertyPlaceholderConfigurer ppc = new PropertyPlaceholderConfigurer();
ppc.setIgnoreResourceNotFound(true);
final List<Resource> resourceLst = new ArrayList<Resource>();
resourceLst.add(new ClassPathResource("database-connection.properties"));
ppc.setLocations(resourceLst.toArray(new Resource[]{}));
return ppc;
}
Shell
You could replace the entire application.properties file at the moment of run of your jar with spring parameter --spring.config.location
java -jar app.jar --spring.config.location=/foo/bar/database-connection.properties
PropertySource
Similar to PropertiesConfiguration but without java code, just #annotations
#PropertySources({#PropertySource(value = "classpath:database-connection.properties")})
public class Application {
I'm using Spring Boot 2.2.5.RELEASE and would like to split my application.properties into separate files. There are already similar questions on StackOverflow but none of them seem to work for configuring Jackson.
My current non working solution is the following:
root/
- application.properties (without Jackson configuration)
- jackson-configuration.properties (includes Jackson configuration)
Jackson configuration class:
#Configuration
#PropertySource("/jackson-configuration.properties")
public class JacksonConfiguration {
}
Please note, I've tried different ways to specify the path including:
"/jackson-configuration.properties"
"jackson-configuration.properties"
"classpath:/jackson-configuration.properties"
"classpath:jackson-configuration.properties"
Spring Boot does not seem to use the configuration. If I copy it over into the application.properties - it works.
Content of jackson-configuration.properties:
spring.jackson.property-naming-strategy=SNAKE_CASE
spring.jackson.mapper.sort-properties-alphabetically=true
spring.jackson.deserialization.fail-on-unknown-properties=true
spring.jackson.parser.strict-duplicate-detection=true
spring.jackson.time-zone=Europe/Zurich
My application is annotated with #SpringBootApplication , so it should scan for additional properties.
/edit
I just realized the problem is the testing, not the productive code itself. If I start the application it works. What doess not work is testing with #JsonTest. I can fix this problem by adding the following line to my tests #ContextConfiguration(classes = {JacksonConfiguration.class}). But in turn, this causes the annotation #JsonComponent to stop working but only for the #JsonTest annotated classes.
See the documentation here. Here is an excerpt from the documentation
In order to resolve ${...} placeholders in definitions or
#Value annotations using properties from a PropertySource, you must
ensure that an appropriate embedded value resolver is registered in
the BeanFactory used by the ApplicationContext. This happens
automatically when using in XML. When
using #Configuration classes this can be achieved by explicitly
registering a PropertySourcesPlaceholderConfigurer via a static #Bean
method.
You need to create a bean like this
#Bean
public static PropertySourcesPlaceholderConfigurer devPropertyPlaceholderConfigurer() throws IOException {
PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
configurer.setLocations(new PathMatchingResourcePatternResolver().getResources("file:pathtToFile"));
configurer.setIgnoreUnresolvablePlaceholders(true);
return configurer;
}
With Spring Boot 2.2.0 the "httptrace" Actuator endpoint doesn't exist anymore. How can I get this functionality back?
The functionality has been removed by default in Spring Boot 2.2.0.
As a workaround, add this configuration to the Spring environment:
management.endpoints.web.exposure.include: httptrace
and provide an HttpTraceRepository bean like this:
#Configuration
// #Profile("actuator-endpoints")
// if you want: register bean only if profile is set
public class HttpTraceActuatorConfiguration {
#Bean
public HttpTraceRepository httpTraceRepository() {
return new InMemoryHttpTraceRepository();
}
}
http://localhost:8080/actuator/httptrace works again.
You need to enable httptrace by having following application properties. By default it is disabled
management.trace.http.enabled: true
management.endpoints.web.exposure.include: httptrace
and Requires an HttpTraceRepository bean. You can use Your own Custom implementation or InMemoryHttpTraceRepository
I've got a Spring WebFlux application running successfully as a standalone spring boot application.
I am attempting to run the same application in a Tomcat container, and following the documentation, I've created a class that extends AbstractReactiveWebInitializer. The class requires that I implement a method getConfigClasses that would return classes normally annotated with #Configuration. If the working spring boot app started with a class called ApplicationInitializer, then the resulting implementations would look like this:
#SpringBootApplication(scanBasePackages = "my.pkg")
#EnableDiscoveryClient
#EnableCaching
public class ApplicationInitializer {
public static void main(String... args) {
SpringApplication.run(ApplicationInitializer.class, args);
}
}
and
public class ServletInitializer extends AbstractReactiveWebInitializer {
#Override
protected Class<?>[] getConfigClasses() {
return new Class[] {ApplicationInitializer.class};
}
}
When deployed, the only thing that starts is ApplicationInitializer, none of the autoconfigured Spring Boot classes (Cloud Config, DataSource, etc) ever kick off.
The documenation states this is the class I need to implement, I just expected the remainder of the spring environment to "just work".
How should I be using this class to deploy a Reactive WebFlux Spring Boot application to a Tomcat container ?
Edit:
After some additional research, I've narrowed it down to likely just Cloud Config. During bean post processing on startup, the ConfigurationPropertiesBindingPostProcessor should be enriched with additional property sources (from cloud config), but it appears to be the default Spring properties instead, with no additional sources.
The misisng properties is causing downstream beans to fail.
Spring Boot does not support WAR packaging for Spring WebFlux applications.
The documentation you're referring to is the Spring Framework doc; Spring Framework does support that use case, but without Spring Boot.
you can extend SpringBootServletInitializer, add add reactive servlet on onStartup method
We have a simple Spring Boot application with Jersey.
Spring Boot provides default monitoring end points
http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#production-ready-monitoring
Example:
#Component
public class JerseyConfig extends ResourceConfig {
public JerseyConfig() {
// registering resources from rest package
packages("com.xyx.abc.rest");
}
}
The REST end points that are provided by Spring Boot are not available in the context of a Spring Boot Jersey Application.
The Spring Boot dependency includes Jersey, starter-actuator, starter-tomcat.
Our REST resources show up fine, but the ones provided by Spring Boot for monitoring dont show up.
E.g http://abc.xyx.com:8080/health returns a 404
If you are using it as a Filter you need to tell Jersey not to handle those requests. E.g. by putting the Jersey resources under a separate path, like "/api/*" or something:
#Bean
public FilterRegistrationBean jersey() {
FilterRegistrationBean bean = new FilterRegistrationBean();
...
bean.setUrlPatterns(Lists.newArrayList("/api/*"));
return bean;
}
(from here).
Or by declaring that your admin endpoints are "static" (via another init parameter "com.sun.jersey.config.property.WebPageContentRegex"):
#Bean
public FilterRegistrationBean jersey() {
FilterRegistrationBean bean = new FilterRegistrationBean();
...
bean.addInitParameter("com.sun.jersey.config.property.WebPageContentRegex",
"/admin/.*");
return bean;
}
where we have set management.contextPath=/admin in the Spring Boot external configuration (otherwise you'd have to enumerate all the endpoints in the regex).
You can also tell Jersey to ignore unresolved requests (instead of sending a 404). That would also achieve your goal, but might affect your client apps (if they rely on a 404 for their behaviour).