How can I use DefaultJobParametersValidator in a Java-based Spring Batch Application? Should I call it manually in a Tasklet? I cannot find any examples that does not used an xml configuration.
A JobParametersValidator is used to validate job parameters before every job execution. You do not call it manually, you need to register it in your job definition and Spring Batch will call it for you (this is how frameworks work). The DefaultJobParametersValidator will be used by default if you do not specify a custom validator.
The JobParametersValidator section in the reference documentation shows how to register a job parameter validator in both XML and Java configuration styles.
Related
I have a toml file being used to configure an application that uses Spring framework's KafkaListener annotation with the following signature:
#KafkaListener(id = "id0", topics = "some.hard.coded.topic.name")
I have a configuration manager class that reads a TOML file and configures various application settings based on the environment the app is running in. One of these is the topic to listen to. However, I do not know how I can pass this in to the Kafka Listener annotation. My understanding is that this can be done using SPEL in conjunction with yml files but I'm kind of locked in to using TOML here. Can anyone advise?
The topics property of the #KafkaListener indeed supports a SpEL including BeanFactory access, so if you have some bean which reads that TOML file and represents it as some set of runtime properties, e.g. getters, then you definitely can get a gain of the SpEL there. For example:
topics = "#{myTomlService.getTopic()}"
where myTomlService is a bean name for the mentioned service.
I am assessing whether spring-boot and how I could migrate to using it.
One question I have is whether a project that uses spring boot can be converted easily back to a regular spring project which uses the traditional spring configuration files if that is required. This would be useful in my mind for a few reasons.
1) merging with legacy projects, because as I have read moving from legacy spring to spring-boot is somewhat tedious.
2) Obtaining a view of the spring application context file and webapp configuration files to understand what the actual configurations being used are.
Another question I have is regarding the lack of application-context file, is there a way to have some kind of hybrid where there is still an application-context file that can be seen? Part of my concern is that spring-boot auto configures components without us knowing and learning how they are configured and work together.
Spring Boot provides auto-configuration.
When #SpringBootApplication is encountered, it triggers a search of the CLASSPATH for a file called META-INF/spring.factories which is just a regular text file that enumerates a list of Java configuration classes. Java configuration was introduced in 2006 and then merged into Spring 3 in 2009. So it's been around for a long time. These Java configuration classes define beans in the same way that XML does. Each class is annotated with #Configuration and therein you find beans defined using methods (factory methods, or provider methods) whose return value is managed and exposed via Spring. Each such provider method is annotated with #Bean. This tells Spring to consider the method and its return value the definition of the bean.
Spring Boot tries to launch all the Java configurations it sees enumerated in that text file. It tries to launch RabbitAutoConfiguration.class, which in turn provides beans for connecting to RabbitMQ and so on. Of course, you don't want those beans in certain cases, so Spring Boot takes advantage of Spring framework 4's #Conditional mechanism to conditionally register those beans only if certain conditions are met: is a type on the CLASSPATH, is a property exposed through the environment, has there been another bean of the same type defined by the user, etc. Spring boot uses these to only create the RabbitMQ-specific beans if, for example, the dependencies that you would get from org.springframework.boot:spring-boot-starter-amqp are on the CLASSPATH. It also considers that the user may have provided a different implementation of RabbitTemplate in some othe rbean definition (be it XML or Java configuration) so it uses that if it's there.
These java configuration classes are the same sort of Java configuration classes you would write without Spring Boot. BUT... WHY? 80% of the time, the auto-configuration that Spring Boot provides is going to be as good or better than the configuration you would write yourself. There are only so many ways to configure Spring MVC, Spring Data, Spring Batch, etc., and the wager you take using Spring Boot is that the leaders and engineers on those various projects can provide the most sensible 80%-case configuration that you probably don't care to write, anyway.
So, yes you could use Spring Boot with existing applications, but you'd have to move those existing applications to Spring 4 (which is easy to do if you're using the spring-boot-starter-* dependencies) to take advantage of #Conditional. Spring Boot prefers: NO configuration, Java configuration, XML configuration, in that order.
If you have an existing application, I'd do the following:
find out what dependencies you can remove from your Gradle/Maven build and just have taken care of for you with the various spring-boot-starter- dependencies.
add #SpringBootApplication to a root component class. Eg, if your package is a.b.c, put a class Application in a.Application and annotate that with #SpringBootApplication
You can run it as a Servlet 3 application or in an embedded servlet container. It might be easier to just run in a standard servlet container as you take baby steps. Go to http://start.spring.io and make sure to choose war in the packaging drop down. Copy the ServletInitializer class and the specification from the pom.xml to ensure that your application is a .war, not a .jar. Then, once everything works on Spring Boot, rm -rf the Initializer and then revert the Maven build to a simpler .jar using the Spring Boot plugin for extra win.
If your application has lots of existing configuration, import it using #Import(OldConfig.class) or #ImportResource("old-config.xml") on the a.Application configuration class. The auto-configuration will kick in but it will see, for example, that you may have already defined a DataSource so it'll plug that in in the right places. What I like to do now is just start the application up, see if everything's OK, then start removing code in my old Java or XML configuration. Don't remove your business code, but remove things related to turning on parts of Spring. Anything that looks like #Enable..* or ..:annotation-driven/>. Restart and verify things still work. The goal is to let Spring Boot do as much of the heavy lifting as possible. Viewing the source is very handy here so you can see what Spring Boot will try to do for you. Spring Boot will log information on what #Conditional conditions evaluated to true for you. Simply provide --Ddebug=true wen you start the application to see the output. You could also export DEBUG=true then restart your IDE to run it as long as the environment variable is ivsible in your shell.
I need to provide support for external preperties decryption in Spring application. I planned to use a mechanism from spring-cloud-config, which is triggered after the Environment is ready and add decrypted properties with higher precedence. Unfortunately it heavily relies on Spring Boot bootstrap mechanism which emits ApplicationEnvironmentPreparedEvent. Looking into the Spring Framework code the environment and context creation is highly coupled and it would be rather hard to run my own code between that. The application I am working with is a large, multi module "standard" Spring MVC application and I would not like to convert it into Spring boot application right now.
Question:
How could I execute my code after the environment was created and before the context creation (to modify properties before they will be injected into "normal" beans) in Spring (not Spring Boot) application?
Alternative question:
Is there any other way to get control over properties being injected into beans (for modify values originally resolved by Spring)?
You can create a custom ApplicationContextInitializer which adds decryption or whatever to the PropertySources of your choice.
We do something similair in one of the application I currently develop. After loading some custom properties from files and databases we wrap all the available PropertySources in a EncryptablePropertySource because several properties are encrypted (We use the Jasypt library for that).
Use #Value("${propname}") annotation on a setter method, instead of using on the field.
You can write code to handle transform/validate the property in the setter method, and then assign to the field.
In the mean time I have found customizeContext method in ContextLoader which reads defined ApplicationContextInitializers. It is executed after the environment was created and before the context is reloaded, so decryption in an initializer should work (at least in the base case):
ConfigurableEnvironment env = wac.getEnvironment();
(...)
customizeContext(sc, wac);
wac.refresh();
I am looking at Spring Batch 2.0 to implement a pipeline process. The process is listening to some event, and needs to perform a set of transformation steps base on the event type and its content.
Spring batch seem to be a great fit. However, going through the documentation, every example have them job and its steps configured in xml. Does the framework support creating jobs during run-time and configuring the steps dynamically?
the job configuration itself is set before the job runs, but it is possible to create a flexible job configuration with conditional flows
you can't just change the job configuration while the job runs, but between jobs its easy to replace the configuration
Addon for Michael answer:
Do you want to create a flow from beginning to end completely dynamically or you want to have some dynamics at certain point?
As Spring Batch instantiates jobs (will all internals) from XML configuration, that means all necessary beans have setters/getters and you can create the Job from empty page. This is long and bug-prone way (you need to create FlowJob as in JobParserJobFactoryBean goes, then SimpleFlow then StepState then TaskletStep as in SimpleStepFactoryBean and bind them together).
I think the alternative to XML flows could be your coded logic. For String Batch it will look as one step, but with custom implementation and subflow. See <tasklet ref="myCleverTasklet" /> example in Example Tasklet Implementation.
I am wondering if the below is possible in Spring
Read a property file using spring - this file has a list of jms queue names
Make spring loop on the above list and define beans that define Apache camel routes from that queue to a file
I could just create the routes using java code on the apache camel context, but wondering if it is possible through spring.
Reading a property file in a Spring XML wiring file is easy; e.g. using a PropertiesFactoryBean. However, the second part of the problem cannot (I believe) be solved without writing a significant amount of Java code.
I suggest that you read Section 3.8.3 of the Spring Reference that describes how to write your own FactoryBean classes. Another possibility is to create a custom Java configuration bean as described in Section 3.11. There may be other possibilities too.
Warning: none of this stuff is particularly straight-forward if you are coming at it for the first time.