Spring Boot: Capture event on context load time and on property change - spring-boot

I wanted to execute a custom logic as soon as the application started and also whenever properties change in Spring Cloud config repo/server. So I have written something like this:
import org.springframework.cloud.context.environment.EnvironmentChangeEvent;
import org.springframework.context.ApplicationListener;
import org.springframework.context.annotation.Configuration;
#Configuration
public class AppConfiguration implements ApplicationListener<EnvironmentChangeEvent> {
#Override
public void onApplicationEvent(EnvironmentChangeEvent event) {
// Custom logic goes here. It should be executed on both app context load time
// and on any property change time
}
}
This above code was working few months back during application load time and when property change. But this code stopped working recently with, I guess, Spring boot / cloud version updates.
Currently I am using Sprig boot 1.5.10 and Cloud Edgware.SR3

Found a way to run the custom logic to run it on both load time and property change time.
Basically changed to above code to be called upon any event and then inside the overridden methood onApplicationEvent checking only for below event
ContextRefreshedEvent - Event raised when an application context gets initialized or refreshed.
EnvironmentChangeEvent - Event published to signal a change in the environment such as properties in config repo.
import org.springframework.cloud.context.environment.EnvironmentChangeEvent;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.ApplicationListener;
import org.springframework.context.event.ContextRefreshedEvent;
public class AppConfiguration implements ApplicationListener<ApplicationEvent> {
#Override
public void onApplicationEvent(ApplicationEvent event) {
if (event instanceof EnvironmentChangeEvent || event instanceof ContextRefreshedEvent) {
// Custom logic goes here. It should be executed on both app context load time
// and on any property change time
}
}
}
Updated
We can also use #EventListener annotation to do the similar thing, which is very simple and easy use. Refer below example:
#Configuration
public class AppConfiguration {
#EventListener({EnvironmentChangeEvent.class, ContextRefreshedEvent.class})
public void onRefresh() {
// Your code goes here...
}
}

Related

Quartz scheduler thorntail

I am new to thorntail. I have integrated quartz in thorntail and able to hit it as REST API. But can I store the scheduler information in context so that scheduler runs once the application is up instead of hitting a URL to run it?
Please correct me if I am wrong .
The question doesn't have much details, but if I understand you correctly, you want to run some code when the application starts. There are at least these 2 ways how to do it:
Using CDI, create an #ApplicationScoped bean with an observer for the #Initialized(ApplicationScoped.class) event:
#ApplicationScoped
public class Initializer {
public void init(#Observes #Initialized(ApplicationScoped.class) Object event) {
...
}
}
This requires the io.thorntail:cdi fraction.
Using EJB, create a #Singleton #Startup EJB and add a #PostConstruct method:
#Singleton
#Startup
public class Initializer {
#PostConstruct
public void init() {
...
}
}
This requires the io.thorntail:ejb fraction.
I assume you already use CDI, so the 1st variant is probably preferable.

Is there a way to have a function run when a session is created or expired?

I am currently planning an application that requires a function to run whenever a session is created and expires. I'm planning on using something like redis but I am open to other ideas. What i am looking for is a n annotation such as #whenexpires and #whencreated. I know that most of the annotations for sessions are at the class, and notthemethod Thanks in regards.
As of Servlet specification 2.3, Java Servlet containers like Apache Tomcat provide the HttpSessionListener interface in order to execute custom logic in the event of created or destroyed sessions. Basic usage:
package com.example;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
public class MySessionListener implements HttpSessionListener {
#Override
public void sessionCreated(HttpSessionEvent event) {
}
#Override
public void sessionDestroyed(HttpSessionEvent event) {
}
}
Add MySessionListener to your web.xml or - in case of Spring - declare a Spring bean for it that is detected by Spring. However, Spring is not required as HttpSessionListener is part of the Java Servlet spec.
If you go for Spring Session with Redis, you can continue using your HttpSessionListener by adding it to the Spring configuration as described in the official docs.
#EnableRedisHttpSession
public class Config {
#Bean
public MySessionListener mySessionListener() {
return new MySessionListener();
}
// more Redis configuration comes here...
}
Moreover, Spring Session comes with support for the "Spring-native" way of event subscription and publishing: ApplicationEvent. Depending on the session persistence approach, there are currently up to three events that can be catched by your application: SessionExpiredEvent, SessionCreatedEvent, SessionDestroyedEvent.
Implement an EventListener in order to subscribe to Spring Session events, for example:
package com.example;
import org.springframework.context.event.EventListener;
import org.springframework.session.events.SessionCreatedEvent;
import org.springframework.session.events.SessionDestroyedEvent;
import org.springframework.session.events.SessionExpiredEvent;
import org.springframework.stereotype.Component;
#Component
public class MySessionEventListener {
#EventListener
public void sessionDestroyed(SessionDestroyedEvent event) {
}
#EventListener
public void sessionCreated(SessionCreatedEvent event) {
}
#EventListener
public void sessionExired(SessionExpiredEvent event) {
}
}

Spring Session - SessionDestroyedEvent is not called

I have a Spring application where sessions are stored in redis with a short timeout (1m). I want to call a function after my sessions timeout, however SessionDestroyedEvent #EventListener does not get called.
SessionListener.java:
import org.springframework.context.event.EventListener;
import org.springframework.session.events.SessionCreatedEvent;
import org.springframework.session.events.SessionDestroyedEvent;
import org.springframework.stereotype.Component;
#Component
public class SessionListener {
#EventListener
public void sessionCreated(SessionCreatedEvent event) {
System.out.println("created"); // gets called
}
#EventListener
public void sessionDestroyed(SessionDestroyedEvent event) {
System.out.println("destroyed"); // never gets called
}
}
application.properties:
spring.session.store-type=redis
server.servlet.session.timeout=1m
notes:
eventListener on SessionCreatedEvent gets called
sessions from redis disappear after the timeout
Section SessionDeletedEvent and SessionExpiredEvent in Spring Session reference describes how sessions are cleaned up.
From the documentation:
Firing SessionDeletedEvent or SessionExpiredEvent is made available through the SessionMessageListener which listens to Redis Keyspace events. In order for this to work, Redis Keyspace events for Generic commands and Expired events needs to be enabled

init method in jersey jax-rs web service

I'm new with jax-rs and have build a web service with jersey and glassfish.
What I need is a method, which is called once the service is started. In this method I want to load a custom config file, set some properties, write a log, and so on ...
I tried to use the constructor of the servlet but the constructor is called every time a GET or POST method is called.
what options I have to realize that?
Please tell, if some dependencies are needed, give me an idea how to add it to the pom.xml (or else)
There are multiple ways to achieve it, depending on what you have available in your application:
Using ServletContextListener from the Servlet API
Once JAX-RS is built on the top of the Servlet API, the following piece of code will do the trick:
#WebListener
public class StartupListener implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent event) {
// Perform action during application's startup
}
#Override
public void contextDestroyed(ServletContextEvent event) {
// Perform action during application's shutdown
}
}
Using #ApplicationScoped and #Observes from CDI
When using JAX-RS with CDI, you can have the following:
#ApplicationScoped
public class StartupListener {
public void init(#Observes
#Initialized(ApplicationScoped.class) ServletContext context) {
// Perform action during application's startup
}
public void destroy(#Observes
#Destroyed(ApplicationScoped.class) ServletContext context) {
// Perform action during application's shutdown
}
}
In this approach, you must use #ApplicationScoped from the javax.enterprise.context package and not #ApplicationScoped from the javax.faces.bean package.
Using #Startup and #Singleton from EJB
When using JAX-RS with EJB, you can try:
#Startup
#Singleton
public class StartupListener {
#PostConstruct
public void init() {
// Perform action during application's startup
}
#PreDestroy
public void destroy() {
// Perform action during application's shutdown
}
}
If you are interested in reading a properties file, check this question. If you are using CDI and you are open to add Apache DeltaSpike dependencies to your project, considering having a look at this answer.

Multiple ApplicationRunners on classpath, how to make SpringApplication.run() only run one

Context: I have a project with some utilities to do things like data fixing. Each utility is a Java application, i.e. class with main() method. I want to define them as Spring Boot applications so I can use the ApplicationRunner and ApplicationArguments facility. The Spring configuration is defined via annotations in a shared configuration class. I've put a minimal example of this setup below.
Expectation: if I call SpringApplication.run(SomeClass.class, args) where SomeClass is an ApplicationRunner, it runs the run() on that class and not on any other classes that may be in the app context.
What actually happens: it calls all ApplicationRunners that it has in the context.
Why? I understood SpringApplication.run(Class, String[]) to mean, "run this class" whereas it appears to mean "load an app context from this class and run anything you can find in it". How should I fix it to run only 1 class? I don't mind if my other application class isn't in the app context, because all the configuration I need is in the shared config class. But I don't want to have to edit code (e.g. add or remove annotations) according to which class I need to run.
Minimal example:
A Spring config class (shared):
package com.stackoverflow.example;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
#Configuration
public class ExampleSpringConfig {
/** Some bean - just here to check that beans from this config are injected */
#Bean public FooService fooService () {
return new FooService();
}
}
Two application classes
package com.stackoverflow.example;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import javax.annotation.Resource;
#SpringBootApplication
public class SomethingJob implements ApplicationRunner {
#Resource private FooService fooService;
public void run(ApplicationArguments args) throws Exception {
System.out.println("Doing something"); // do things with FooService here
}
public static void main(String[] args) {
SpringApplication.run(SomethingJob.class, args);
}
}
and another that is identical except that it prints "Doing something else".
Output:
[Spring Boot startup logs...]
Doing something else
Doing something
[Spring Boot shutdown logs...]
Firstly, only one class should be annotated with #SpringBootApplication. As you've noticed in your answer, this defines the external "main" entry point. I would recommend this is a different class to your ApplicationRunner classes for clarity and conceptual separation.
To only have some but not all runners run, I've done this by parsing the arguments, and quickly exiting from the runner which should not be called. e.g.
package com.stackoverflow.example;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import javax.annotation.Resource;
#Component
public class SomethingJob implements ApplicationRunner {
#Resource private FooService fooService;
public void run(ApplicationArguments args) throws Exception {
if (!args.containsOption("something")) return
System.out.println("Doing something"); // do things with FooService here
}
}
That way you can do java -jar myjar.jar --something or java -jar myjar.jar --something-else depending which one you want to be run.
I found a workaround while experimenting with my minimal example.
#SpringBootApplication is just an alias for #ComponentScan, #EnableAutoConfiguration and #Configuration. By applying them separately, I discovered that it's the #Configuration annotation that causes this behaviour. If I only apply the other 2, I don't get the issue.
I guess this is because #Configuration means "I'm a configuration class, and any beans I define should be pulled into the context during component scan" and although this class doesn't define an ApplicationRunner, it is one, which has the same effect. Therefore if you have 2 such beans on the classpath, they both get pulled into the app context.
Without #Configuration, the bean you want to run still gets registered since it's referenced by the call to run(), but other ApplicationRunners on the classpath don't.
This fixes my immediate problem by making sure I only have one ApplicationRunner in my app context. But it doesn't answer the wider question, "If I do have several ApplicationRunners, how do I tell Spring Boot which one to run?" So I'd still appreciate any more complete answer or suggestions for a different approach.

Resources