I'm developing an app with Spring boot, I'm using the MVC model.
I have an entity called A, which has its controller, service and repository. all right up here.
I have an utility class, which is runnable and is called when the server start. This utility class create a set of A entities, and then, stored it into database. The problem is that the autowired service of the class is null, because I have created a new instance of the utility class in order to run it, so Spring doesn't create the autowired service correctly.
that is:
Main.java
#SpringBootApplication
public class MainClass {
public static void main(String[] args) {
...
Runnable task = new Utility();
...
}
}
Utility.java
#Autowired
private Service service;
...
public void run() {
...
service.save(entities); <-- NPE
}
I know that Spring cannot autowired the service of this new instance, but I need to create the utility instance in order to run it.
I have tried to access to the service through application context, but the problem is the same:
#Autowired
private ApplicationContext applicationContext;
I have tried to make runnable the controller (where the service is autowired correctly), but the problem is the same, since I need to do the new controller();.
I have read these posts
post 1
post 2, but any solution works.
UPDATE: I need that the task run in a new thread, since it will be executed each X hours. The task downloads a data set from Internet and save it into database.
If you need to do some task periodically:
#SpringBootApplication
#EnableScheduling
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application .class, args);
}
}
#Component
class Runner {
#Autowired
private Service service;
#Scheduled(cron = "0 */2 * * * ?") // execute every 2 hours
public void run() {
// put your logic here
}
}
If I understood correctly, you're trying to populate your database with dummy data.
This utility class create a set of A entities, and then, stored it
into database
Why are you using a Runnable? Is this task run via a new Thread?
If not, then use #PostConstruct inside your #Controller, which has access to the right #Service. The marked method is guaranteed to be invoked after the Bean has been completely constructed, and all its dependencies have been satisfied.
#PostConstruct
private void persistEntities() {
...
service.save(entities);
}
If you're on Spring Boot, you can just place a data-*.sql file under src/main/resources/. It will be run at startup.
Just as said #CoderinoJavarino in comments, I need to use #Scheduled instance of a runnable class.
With scheduled, Spring can autowired correctly the service. So, finally, my initial runnable utility class has become into a scheduled class.
Related
I am trying to find a way to have a graceful Runnable bean creation in Spring boot. The point of the app is to have a service, which would take in some data, and start a monitored external process.
In my previous attempts I simply formed a regular new MyRunnable() and passed it to the execution service. Now I'm thinking how to properly do so using the Spring environment, and use the #Scope("prototype").
I did find examples, which used ApplicationContext.getBean(...), and a better approach of Why is Spring's ApplicationContext.getBean considered bad?, but I still fail to properly digest how to actually call the new MyRunnable() in terms of one service, which would follow the simple idea of:
class MyService {
public void triggerNewExternalTask() {
....
executionService.run(new MyRunnable());
I believe you're on the wrong path here.
Spring dependency injection is wonderful, but that does not mean that you'll never find a call to new in a properly written Spring Boot app.
This is a case where calling new is the right thing to do. Every Executor in the pool should get its own instance of Runnable/Callable when it starts.
This is true for any method scoped variable: better to instantiate it in method scope and let the garbage collector clean it up when you exit the method. No reason for Spring to be responsible for the bean life cycle in that case.
You go too far when you try to share Runnable instances, especially if they have state.
Even as the question is closed, stumbled over another solution, which is - #Lookup, which meets the task:
entity:
#Component
#Scope("prototype")
public class Proto {
private static int counter;
public Proto() {
System.out.println("count: "+counter++);
}
}
service:
#Service
public class ProtoService {
#Lookup
public Proto getProto() {
return null;
}
}
and the test:
#Service
public class LookupWorks {
#Autowired
private ProtoService serv;
#PostConstruct
private void test() {
System.out.println(">>>>>>>>>>>>>>");
serv.getProto();
serv.getProto();
serv.getProto();
serv.getProto();
serv.getProto();
System.out.println(">>>>>>>>>>>>>>");
}
}
with the output:
>>>>>>>>>>>>>>
count: 0
count: 1
count: 2
count: 3
count: 4
>>>>>>>>>>>>>>
In what circumstances CommandLineRunner is preferred instead of writing additional code in the main method of SpringBoot application.
I understand that CommandLineRunner gets executed before main gets completed.
In simple cases, there is no difference.
But if the code need to access features provided by spring, such as ioc or only interface repositories/services, you need to wait for the complete application startup. And the call of the overrided run method after completion is garanteed.
Besides, CommandLineRunner has other advantages:
Can be implemented multiple times
The capability to start any scheduler or log any message before application starts to run
I have used it to decouple code. Instead of placing a bunch of code into main method, the CommandLineRunner lets you distribute it more evenly around the codebase. It really depends on what kind of flags you are passing in and why you need to pass them in. Spring offers a lot of flexibility for you to get the job done in the easiest way.
For a full on command line tool, you can decouple initialization and config a little bit by dividing your code between init and core behavior.
A spring boot server can overwrite configuration based on args passed in from the command line.
I would suggest all time time. It adds a lot of flexibility to your "bootstrapping code".
1) For example, command line runners are spring #Beans, so you can activate/deactivate them at run-time.
2) You can use them in an ordered fashion by appending the #Order annotation
3) You can unit test them just like regular classes
4) You can inject dependencies into them. Each runner can then have its own dependencies.
All of the above are more difficult, if not impossible to achieve if you add all your bootstrapping logic in the main() method of the Spring Application class.
Hope my answer helps,
Cheers
I haven't found any good reason for using it over just writing code after starting the application.
The only thing I can think of is that the command line runners are called before any SpringApplicationRunListeners have #finished called.
I have seen people use them to perform main application logic, but I think this is an antipattern.
One of the annoying things about doing so is that the application start timer is still running and when the task completes you will see a log entry like Started DemoApplication in 5.626 seconds (JVM running for 0.968).
It's confusing to see a message about your application starting despite, in reality it having just finished.
I encountered a scenario where i had to keep a certain data from the db loaded into the cache before the method was hit from the controller end point the first time. In this scenario it was desirable to hit the method for populating the cache using the run method after extending CommandLineRunner class so that before the application even starts up the data is already available in the cache.
I use this to populate my Default Data. I usually create ApplicationInitializer class that extends CommandLineRunner.
I have methods like createDefaultUser(), createDefaultSytemData() etc.
This way I do not rely on sql files to populate database for me. :)
ApplicationRunner and CommandLineRunner:
two of them can execute some custom code before your application finished starting up.
ComandLineRunner:
#Component
public class CommandLineAppStartupRunner implements CommandLineRunner {
private static final Logger logger = LoggerFactory.getLogger(CommandLineAppStartupRunner.class);
#Override
public void run(String...args) throws Exception {
logger.info(Arrays.toString(args));
}
}
you can get the args directly
ApplicationRunner：
#Component
public class AppStartupRunner implements ApplicationRunner {
private static final Logger logger = LoggerFactory.getLogger(AppStartupRunner.class);
#Override
public void run(ApplicationArguments args) throws Exception {
logger.info(args.getOptionNames());
}
}
ApplicationRunner has many methods to get params
ComandLineRunner can get params directly
if you custom two runner class, you can use annotation #Order to Specify the order of execution
public class Phone {
#Autowired
BeanExample beanExample;
public void print(){
beanExample.fn();
}
}
public class BeansCreatorClass {
#Bean
public BeanExample getBeanExample(){
return new BeanExample();
}
#Bean
public Phone getPhone(){
return new Phone();
}
}
#SpringBootApplication
public class SpringBootRunnerConfigurationPropertiesApplication implements CommandLineRunner, ApplicationRunner {
public static void main(String[] args){
SpringApplication.run(SpringBootRunnerConfigurationPropertiesApplication.class, args);
System.out.println("==== spring boot commandLine is running === ");
// beans creator class is the class contains all beans needed
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansCreatorClass.class);
Phone phone = applicationContext.getBean(Phone.class);
phone.print();
}
// commandLineRunner
public void run(String... args) throws Exception {
System.out.println("=== commandLine Runner is here ==== ");
}
// application runner
#Override
public void run(ApplicationArguments args) throws Exception {
System.out.println("=== application runner is here ====");
}
}
I mostly use CommandLineRunner to:
Apply initial migrations
Run a code that is independent of REST/SOAP calls.
all,
I am using spring boot in my project. It is great.
My project has a part of it that operates on database periodically(with a timer), and not in response to a http request.
It's periodically queries a sensor(a lot of sensors) and collects temperature readouts, and stores the readouts into database.
Before storing it into database, the readout number is compared to a warning threshold to test if a warning should be generated.
The threshold number is to be queried(complicated) out from database, too.
I have a ThresholdRepository extending JPAResository for this query, so I want to use it in this scenario.
My question is: Could I use #Autowire to make spring boot generate ThresholdRepository instance for me? If not, how to instantiate ThresholdRepository in this timer thread?
I find some code at :http://www.yjs001.cn/java/spring/33161827667841434606.html
unfortunately, the code is outdated and RepositoryMetadata has no getDomainClass and I don't know which alternative should be used.
Please someone help me out.
Any recommendation is appreciated.
The repository I mentioned is as following:
public interface ThresholdInfoRepository extends JpaRepository<ThresholdInfo, Long> {
ThresholdInfo findOneByGatewayIdAndNodeAddrAndChannel(Long gatewayId, Byte nodeAddr, Byte channel);
List<ThresholdInfo> findByGatewayId(Long gatewayId);
}
It's short, but does a lot of work.
Yes, you can,
You have to #EnableJpaRepositories for your repositories to become a bean.
Then, to be able to autowire it, your TimerTask needs to be a Spring Bean as well. You could use spring-tasks https://spring.io/guides/gs/scheduling-tasks/
#SpringBootApplication
#EnableScheduling
#EnableJpaRepositories
public class Application {
public static void main(String[] args) throws Exception {
SpringApplication.run(Application.class);
}
}
#Component
public class UpdateTask {
#Autowired
ThresholdInfoRepository thresholdInfoRepository;
#Scheduled(fixedRate = ...)
public void updateSensor() {
thresholdInfoRepository.find(...)
readoutRepository.save(...);
}
}
Spring boot will start a timer thread to execute your scheduled method.
Got a pretty standard Spring Boot (1.3.5) application.
Enabled scheduling with #EnableScheduling (tried on main application entry point and a #Configuration annotated class.
Created a simple class with a #Scheduled method (simple fixedDelay schedule).
Scheduled task executes twice (always).
From what I have gathered so far, it is probably because two contexts are being loaded, and thusly picking up my beans twice.
Ok.
So how do I fix/prevent this double execution, since all the config is basically hidden Spring Boot magic?
Framework versions:
Spring Boot 1.3.5
Spring Cloud Brixton SR1
Main application:
#SpringBootApplication
#EnableDiscoveryClient
#EnableAsync
#EnableCircuitBreaker
public class AlertsApplication {
public static void main(final String[] args) {
SpringApplication.run(AlertsApplication.class, args);
}
}
My task class (HookCreateRequest list is pulled in from application.yml - I do not believe that to be relevant currently, but if required, can be provided):
#ConditionalOnProperty(name = "init.runner", havingValue = "InitRunner")
#ConfigurationProperties(prefix = "webhook")
public class InitRunner /*implements CommandLineRunner*/ {
private final List<HookCreateRequest> receivers = new ArrayList<>();
#Autowired
private WebHookService hookService;
#Scheduled (fixedRate = 300000)
public void run() throws Exception {
getReceivers().stream().forEach(item -> {
log.debug("Request : {}", item);
hookService.create(item);
});
}
public List<HookCreateRequest> getReceivers() {
return receivers;
}
}
There is zero xml configuration.
Not sure what else might be relevant?
EDIT 2016/07/04
I have modified to output the scheduled instance when it runs (I suspected that two different instances were being created). However, the logs seem to indicate it is the SAME instance of the task object.
logs:
15:01:16.170 DEBUG - scheduled.ScheduleHookRecreation - Schedule task running: scheduled.ScheduleHookRecreation#705a651b
...task stuff happening
...first run completes, then:
15:01:39.050 DEBUG - scheduled.ScheduleHookRecreation - Schedule task running: scheduled.ScheduleHookRecreation#705a651b
So it would seem it is the same task instance (#705a651b). Now why would in the name of sweet things would it be executed twice?
EDIT 2016/07/05
I added a #PostConstruct method to the class that carries the scheduled method, with just some logging output in. By doing that I could verify that the #PostConstruct method is being called twice - which seems to confirm that the bean is being picked up twice, which which presumably means it is fed to the scheduler twice. So how to prevent this?
Had the same problem, in my case the reason was in #Scheduled annotation's initialDelay parameter absence - method was called on application start.
I want to have a service in my Spring application that watches a directory for changes using the Java 7 WatchService. The idea is that when a file in the directory is changed, clients connected via WebSockets are notified.
How do I get a bean to run in its own thread as a service?
What you are looking for is Asynchronous execution. With a correctly configured context (see the link), you declare a class like so
#Component
public class AsyncWatchServiceExecutor {
#Autowired
private WatchService watchService; // or create a new one here instead of injecting one
#Async
public void someAsyncMethod() {
for (;;) {
// use WatchService
}
}
}
Everything you do in someAsyncMethod() will happen in a separate thread. All you have to do is call it once.
ApplicationContext context = ...; // get ApplicationContext
context.getBean(AsyncWatchServiceExecutor.class).someAsyncMethod();
Use the WatchService as described in the Oracle documentation.
If you don't have direct access to your ApplicationContext, you can inject the bean in some other bean and call it in a #PostConstruct method.
#Component
public class AsyncInitializer {
#Autowired
private AsyncWatchServiceExecutor exec;
#PostConstruct
public void init() {
exec.someAsyncMethod();
}
}
Careful which proxying strategy (JDK or CGLIB) you use.