I am creating an EJB TimerService mock. Is there a way to manually trigger the call to a method with the #Timeout annotation?
You can create new timer with preferred duration. When you need to call timeout call bellow code segment with duration. Then Framework should call timeout method within given duration from now.
context.getTimerService().createTimer(duration, "Hello World!");
Full code
import javax.annotation.Resource;
import javax.ejb.SessionContext;
import javax.ejb.Timer;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
#Stateless
public class TimerSessionBean implements TimerSessionBeanRemote {
#Resource
private SessionContext context;
public void createTimer(long duration) {
context.getTimerService().createTimer(duration, "Hello World!");
}
#Timeout
public void timeOutHandler(Timer timer){
System.out.println("timeoutHandler : " + timer.getInfo());
timer.cancel();
}
}
Now let's take into account that
The method is not public.
If you would like to test only the logic contained in method annotated with #Timeout, there are few solutions.
I would recommend the last one, because it would also improve the overall design (see this answer).
Make that method protected or package-private. This one is the simplest way to make that logic testable.
Use reflection or PowerMock to invoke private method.
Here is a simple example, assuming that we want to invoke instance.timeOutHandlerMethod with Timer instance timer.
Whitebox.invokeMethod(instance, "timeOutHandlerMethod", timer);
See doc page for more details.
Extract logic to separate class and test it instead.
Here we extract logic from this.timeOutHandler to Delegate.execute:
#Timeout
private void timeOutHandler(Timer timer) {
// some complicated logic
timer.cancel();
}
to this:
private Delegate delegate;
#Timeout
private void timeOutHandler(Timer timer) {
delegate.execute(timer);
}
With Delegate declared as:
class Delegate {
public void execute(Timer timer) {
// some complicated logic
timer.cancel();
}
}
Now we can write a test for Delegate class.
Related
I have a workflow which is set up by spring with a scope of "workflow". The below code would show the message straight away instead of waiting 60 seconds. I think it's because of the way I'm constructing my Helper class... how do I fix Asynchronous methods to work within another class?
public class MyWorkflowImpl implements MyWorkflowImpl {
private Helper helper = new Helper();
#Override
public do() {
Promise<Void> timer = getTimer(60); //seconds
helper.showMessage(timer);
}
}
public class Helper {
#Asynchronous
public showMessage(Promise<Void> timer) {
// show random message
}
}
The code is correct. #Asynchronous should work on any method of any class having that AspectJ preprocessor is applied to all classes that use it.
I wanted to use Job so I can kick them off on the start of application. Now it seems like it has been removed from Play completely?
I saw some samples where people create a Global class, but not entirely sure if/how I should use that to replace Job.
Any suggestions?
Edit: If you gonna downvote, give a reason. Maybe I'm missing something in the question, maybe this doesn't belong here. At least something...
The Job class was removed in Play 2.0.
You have some alternatives though depending on your Play version and if you need asynchrony or not:
Akka Actors
For all version since Play 2.0 you can use Akka Actors to schedule an asynchronous task/actor once and execute it on startup via Play Global class.
public class Global extends GlobalSettings {
#Override
public void onStart(Application app) {
Akka.system().scheduler().scheduleOnce(
Duration.create(10, TimeUnit.MILLISECONDS),
new Runnable() {
public void run() {
// Do startup stuff here
initializationTask();
}
},
Akka.system().dispatcher()
);
}
}
See https://www.playframework.com/documentation/2.3.x/JavaAkka for details.
Eager Singletons
Starting with Play 2.4 you can eagerly bind singletons with Guice
import com.google.inject.AbstractModule;
import com.google.inject.name.Names;
public class StartupConfigurationModule extends AbstractModule {
protected void configure() {
bind(StartupConfiguration.class)
.to(StartupConfigurationImpl.class)
.asEagerSingleton();
}
}
The StartupConfigurationImpl would have it's work done in the default constructor.
#Singleton
public class StartupConfigurationImpl implements StartupConfiguration {
#Inject
private Logger log;
public StartupConfigurationImpl() {
init();
}
public void init(){
log.info("init");
}
}
See https://www.playframework.com/documentation/2.4.x/JavaDependencyInjection#Eager-bindings
What happens when a custom EventListener handles a custom EventObject?
Once the Handler is done:
Does the execution go back to the standard thread code? or,
Is the thread is closed?
EventListener is only Interface (actually very low level) and it only defines what should be implemented. How it is implemented is defined in the class which implements this interface. So, question should be how some particular class handles it. It could be started in separate thread or new thread could be created or current one could be used. Different classes handle it differently. I believe that majority of them just call listener's method in current own thread. That's the reason why it is not advised to do anything long (actually anything at all except few commands to notify about event) inside listener itself.
That's where flexibility comes - you decide what and when to do. Start new thread and finish it when job done or use existing thread or do your job quickly and hope that current thread doesn't stuck and, for example, GUI window is not frozen.
I create a custom EventListener interface, rather than use the Java standard EventListener interface. I do this so I can define the method(s). In this case, I created a handleEvent method that receives a ResultSetEventObject.
package com.ggl.event.listener;
public interface EventListener {
public void handleEvent(ResultSetEventObject eo);
}
So now, let's look at the ResultSetEventObject class.
package com.ggl.event.listener;
import java.sql.ResultSet;
import java.util.EventObject;
public class ResultSetEventObject extends EventObject {
private static final long serialVersionUID = 6904165475135245131L;
private ResultSet resultSet;
public ResultSetEventObject(Object source) {
super(source);
}
public ResultSet getResultSet() {
return resultSet;
}
public void setResultSet(ResultSet resultSet) {
this.resultSet = resultSet;
}
}
This class holds an SQL ResultSet, and has a getter and a setter for the ResultSet. You can have any variables you want in an EventObject, along with the variable getters and setters.
Finally, lets use the interface in an actual class, ResultSetListenerHandler.
package com.ggl.event.listener;
import java.sql.ResultSet;
import java.util.ArrayList;
import java.util.List;
public class ResultSetListenerHandler {
private List<EventListener> listeners;
public ResultSetListenerHandler() {
listeners = new ArrayList<EventListener>();
}
// Add method(s) to generate a ResultSet and perform the
// fireEvent method.
public void addListener(EventListener listener) {
listeners.add(listener);
}
public void removeListener(EventListener listener) {
for (int i = listeners.size() - 1; i >= 0; i--) {
EventListener instance = listeners.get(i);
if (instance.equals(listener)) {
listeners.remove(i);
}
}
}
public void fireEvent(final ResultSet resultSet) {
for (int i = 0; i < listeners.size(); i++) {
final EventListener instance = listeners.get(i);
Runnable runnable = new Runnable() {
public void run() {
ResultSetEventObject eo = new ResultSetEventObject(
resultSet);
eo.setResultSet(resultSet);
instance.handleEvent(eo);
}
};
new Thread(runnable).start();
}
}
}
There's a method to add listeners and a method to remove listeners.
The fireEvent method is the method that actually executes the listener code for each of the listeners.
In this case, I created a separate thread for each of the listeners. That way, the fireEvent method finishes quickly. The code in the ResultSetListenerHandler doesn't have to wait for the listener code to finish executing.
I'm honestly missing something here. I have no idea how to make an instance of TimerService object. It is always null. I don't have a constructor because it's an Interface. I can't use the create methods. #Resource doesn't seem to allocate anything to it.
I'm trying to setup a simple programmatic timer that does a task every X minutes. The timeout duration can vary based on configuration which can change throughout runtime. I am using a WebLogic 12 web application.
What I have so far:
import javax.annotation.Resource;
import javax.ejb.Singleton;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerService;
#Singleton
public class TimerBean {
#Resource
protected TimerService timerService;
public TimerBean(){
System.out.println("TimerBean constructor " + timerService);
}
#Timeout
public void timeoutHandler(Timer timer){
String name = timer.getInfo().toString();
System.out.println("Timer ticked. Name=" + name);
}
public void startOrModifyTimer(long initialExpiration, long interval, String name) {
System.out.println("Start or modify " + timerService);
}
}
This outputs:
TimerBean constructor null
& then after the server is running if I call start or modify:
Start or modify null
edit:
I got it to work by making the TimerBean #Singleton & #Startup & replacing constructor with #PostConstruct method.
however while it has an object for TimerService instantiated whenever I try to use its methods it gives me java.lang.IllegalArgumentException: Unknown bean state 0 for which there is no information...
If you're trying to use field injection, you're relying on the framework to come along after the object has already been instantiated and set the field, so it will always be null in the constructor. You can either do whatever logic you need in an #PostConstruct method or, my strong preference, inject the TimerService as a constructor argument instead of directly into the field.
#PostConstruct is never called. #Inject is not either (and Im unsure if I did it right)
I got it to work by making the TimerBean #Singleton & #Startup & replacing constructor with #PostConstruct method.
chrylis is right. From your description it looks like you instantiating TimerBean via constructor.
Result is that you manage life-cycle by yourself and container is not able to take care of this instance and inject anymore.
Inject your TimerBean into the class where you want to use it (Session for example), or use it as you did:
#Singleton
#Startup
public class TimerBean { .. }
Combination of these annotations basically create one instance of TimerBean during app server start sequence.
Btw. Constructor with #PostConstruct is wrong idea and it may behave really unpredictable during run-time (not sure if it is possible, but you creating circular instantiation with this combo).
I ended up using Timer & TimerTask for this. Couldn't figure TimerService out. Oh well. Seems to work fine.
For anyone curious:
long interval = minutes*60*1000;
long delay = interval;
if(prevTask != null){
delay = System.currentTimeMillis() - prevTask.scheduledExecutionTime(); //time left of previous setting
prevTask.cancel();
delay = interval - delay; //difference in time left & new interval
if(delay <=0) //if by new setting should've already ran, so run it ASAP...
delay = 2000;
logger.info(String.format("DB dump was already scheduled before. Set dump delay to %s minutes & setting new schedule to every %s minutes.", delay/60/1000, minutes));
}
TimerTask task = new TimerTask(){
private SimpleDateFormat ft = new SimpleDateFormat("yyyy.MM.dd 'at' HH:mm:ss SSS");
private int minutes;
public TimerTask initialize(int minutes){
this.minutes = minutes;
return this;
}
public void run() {
try {
logger.info(String.format("Doing scheduled %s dump to DB. (Configured to occur every %s minutes.)", ft.format(new Date(this.scheduledExecutionTime())), minutes));
dumpToDB();
} catch (NamingException | SQLException e) {
e.printStackTrace();
}
}
}.initialize(minutes);
timer.schedule(task, delay, interval);
prevTask = task;
How would you suggest to implement the following in JavaEE:
I need to have a background process in the app server (I was thinking a stateful session beans) that constantly monitors "something" and if some conditions apply it does operations with the database.
Most importantly it has to manipulated remotely by various clients.
So, basically, I need a process that will run constantly, keep its state and be open for method invocations by a number of remote clients.
Since I'm new to JavaEE I'm a bit confused which approach/"technology" to use. An help would be appreciated.
You can use a combination of a stateless session or singleton bean with an EJB timer an timer service. The bean would the interface used by the remote clients to control the background process. The timer service would periodically call back a method on the bean to verify the condition. The timers are automatically persisted by the EJB container, so they will do their job when your bean clients are disconnected.
Here is a sketch:
#Singleton
...
public TimerMangerbean implements TimerManager {
#Resource
private TimerService timerService;
public void startMonitoring() {
//start in 5 sec and timeout every 10 minutes
Timer timer = timerService.createTimer(5000, 60000, "MyTimer");
}
public void stopMonitoring() {
Collection<Timer> timers = timerService.getTimers();
for(Timer timer : timers) {
//look for your timer
if("MyTimer".equals(timer.getInfo())) {
timer.cancel();break;
}
}
}
//called every 10 minutes
#Timeout
public void onTimeout() {
//verify the condition and do your processing
}
}
See also: Using the timer service on Oracle JavaEE tutorial
What about Quartz? See the links
http://rwatsh.blogspot.com/2007/03/using-quartz-scheduler-in-java-ee-web.html
http://lanbuithe.blogspot.com/2011/07/using-quartz-scheduler-in-java-ee-web.html
http://www.mkyong.com/tutorials/quartz-scheduler-tutorial/
As you stated yourself, you have two requirements: 1) periodically perform some background job, and 2) respond to client requests.
For 1), you can use the TimerService or spawn a thread with a ServletContextListener. The second is not fully conform, but works. If you use timers, you can either create a periodic timer (as pointed out by #dcernahoschi), or a unique timer that reschedules itself:
#Timeout
public void onTimeout() {
//do something
// create a new timer
}
If your periodic timer fires each 10 sec and you have processing that last form more than 10 seconds, you might have a problem. Having a timer that reschedules itself works better if the processing time is not fixed.
For 2) you can go with statelesss or staefull EJB, that's precisely their purpose.
Java EE is the solution. You will need to follow thoses steps:
build a Java EE application, a jar containing a EJB:
1.1 you will need a IDE : Eclipse Juno is my favorit,
1.2 Many tuto exists on the web. Search for EJB3 and you will find,
have an application server to run your EJB. JBoss is a good choice, Glassfish is an another good choice. With JBoss and the JBoss Tools plugin for Eclipse installed, you will be able to build and run rapidly an basic application.
EDIT : a complete Timer EJB class (with automatic reload if needed)
package clouderial.saas.commons.utils;
import java.util.Map;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.ejb.ScheduleExpression;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerConfig;
import javax.ejb.TimerService;
import javax.inject.Inject;
import jmcnet.libcommun.exception.ExceptionTechnique;
import jmcnet.libcommun.utilit.mail.MailException;
import org.apache.commons.configuration.event.ConfigurationEvent;
import org.apache.commons.configuration.event.ConfigurationListener;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import clouderial.saas.commons.email.EmailSender;
import clouderial.saas.commons.jpamongo.JPAMongoBasePersistenceContextAccessor;
/**
* A base class for a periodic process
* #author jmc
*
*/
public abstract class PeriodicProcessBase extends JPAMongoBasePersistenceContextAccessor implements ConfigurationListener {
private static Logger log = LoggerFactory.getLogger(PeriodicProcessBase.class);
#Resource
private TimerService timerService;
#Inject
protected GlobalConfiguration _config;
#Inject
protected EmailSender _emailSender;
private Timer _timer=null;
private String _processName=null;
private Logger _log = null;
protected void initTimer(String processName, Logger log) {
if (processName != null) _processName = processName;
if (log != null) _log = log;
String second = _config.getString("timer."+_processName+".second","0");
String minute = _config.getString("timer."+_processName+".minute","0");
String hour = _config.getString("timer."+_processName+".hours","4");
String dayOfWeek = _config.getString("timer."+_processName+".dayOfWeek","*");
ScheduleExpression scheduleExp =
new ScheduleExpression().second(second).minute(minute).hour(hour).dayOfWeek(dayOfWeek);
cancelTimer();
if (timerService != null) {
_timer = timerService.createCalendarTimer(scheduleExp, new TimerConfig(_processName, false));
_log.info("{} : timer programmed for '{}'h, '{}'m, '{}'s for days '{}'.", _processName, hour, minute, second, dayOfWeek);
}
else _log.error("{} : no timer programmed because timerService is not initialized. (Normal during tests)", _processName);
// Listen to change
_config.addModificationListener(this); // on timer modification, configurationChanged is called
}
#PreDestroy
private void cancelTimer() {
if (_log != null) _log.info("Stopping timer for '{}'", _processName);
if (_timer != null) _timer.cancel();
_timer = null;
}
#Override
public void configurationChanged(ConfigurationEvent event) {
if (_log != null) _log.info("Configuration have change. Reloading config for ProcessBilling.");
_config.removeModificationListener(this);
initTimer(null, null);
}
#Timeout
private void run(Timer timer) {
runProcess(timer);
}
/**
* The entry point for runner the process. Must be overriden by super class
* #param timer
*/
protected abstract void runProcess(Timer timer); // do the job here
}
I hope this helps.