Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Simplest Possible EJB 3.1 Timer

02.10.2010
| 6318 views |
  • submit to reddit

A timer doesn't have to be a singleton - it can be a @Stateless and even a @Stateful bean. The method doWork() will be invoked every second. There is no registration or configuration needed.

@Singleton
public class TimerService {
@EJB
HelloService helloService;

@Schedule(second="*/1", minute="*",hour="*", persistent=false)
public void doWork(){
System.out.println("timer: " + helloService.sayHello());
}
}

How to compile:

You will need the EJB 3.1 API in the classpath, or at least the @Singleton, @Schedule and @EJB annotation.

How to deploy:

Just JAR or WAR the interceptor with an EJB and put the archive into e.g: [glassfishv3]\glassfish\domains\domain1\autodeploy

Btw. the initial deployment of the entire WAR took on my machine:

INFO: Loading application SimpleTimer at /SimpleTimer
INFO: SimpleTimer was successfully deployed in 363 milliseconds.

How to use:

Another service can be easily injected to the timer and so invoked periodically:
@Stateless
public class HelloService {
public String sayHello(){
return "Hello from control: " + System.currentTimeMillis();
}
}

And: there is no XML, strange configuration, libraries, additional dependencies needed...You will find the whole executable project (tested with Netbeans 6.8 and Glassfish v3) in: http://kenai.com/projects/javaee-patterns/ [project name: SimpleTimer].

From http://www.adam-bien.com

0
Your rating: None
Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Nicky Mølholm replied on Wed, 2010/02/10 - 3:22pm

Hi Adam,

Good to see info on EJB 3.1 ;)- you provide us with lots of interesting Java news!

I have a minor remark to your introduction: We are actually not allowed to create timers on Stateful Session Beans. You can cross check this with the EJB 3.1 Core specification (JSR 318), section 18.2, page 510.

Java Greetings,

Nicky Moelholm

Liam Knox replied on Thu, 2010/02/11 - 12:06am

Needing EJB 3.1 to express a Timer seems a bit sledge hammer vs nut.

Henk De Boer replied on Thu, 2010/02/11 - 5:09am in response to: Liam Knox

Why? It's a small little construct that solves a specific problem elegantly.

Chad Hahn replied on Thu, 2010/02/11 - 9:23am

I blogged about Automatic Timers last month  Java EE 6 Automatic Timer

IMO, they can be cool for something quick and simple, but aren't that great in the overall scheme of things.  There doesn't appear to be an easy way to modify an existing timer without a recompile and redeploy. Each app server has it's own implementation.  There needs to be an api for these timers.

Reza Rahman replied on Thu, 2010/02/11 - 5:02pm in response to: Chad Hahn

Can you kindly expand on the API remark? Have you taken a look at the EJB 3.1 timer API? How is the recompile/redeploy requirement any different than Quartz, for example? As I see it, EJB 3.1 timers fulfill 80-90% of application use-cases.

Cheers,

Reza

Ryan Developer replied on Thu, 2010/02/11 - 11:15pm in response to: Henk De Boer

There probably isn't a post on this website that mentions EJB where Liam hasn't chimed in with such a remark.  If Liam didn't feel threatened by EJB 3.1 + CDI making it possible to develop enterise applications without Spring, then he wouldn't be wasting his valuable time arguing with us.  Anyone who knows anything about EJB 3.1/CDI knows that the tables have turned and it is now Spring that is the sledge hammer.

Reza Rahman replied on Thu, 2010/02/11 - 11:29pm in response to:

Ryan,

I'm afraid I've observed the same thing - a lot of flame bait posts from Liam on almost all EJB 3/CDI articles. It's OK to be a fan of Spring, but why the anti-Java EE venom?

Cheers,

Reza

Chad Hahn replied on Mon, 2010/02/15 - 9:47pm in response to: Reza Rahman

Yes, I've looked at the 3.1 timer API.  There doesn't seem to be much there.  Maybe I'm missing something, but I think it's very uncommon to expect to recompile/redeploy everytime a schedule needs changed.   We're specifially talking about Automatic timers here, which are annotation based.  I don't think you can configure Quartz jobs in the same way.  That's a nice feature for simple stuff, as I said.  However, that all breaks down when the going gets rough, which is where the Enterprise in Java EE is supposed to come into play.  Most of the other EJB 3.1 stuff is great, but this segment feels unfinished to me.  For reference, here is the cookbook example for a job reschedule in Quartz, fwiw.  Updating a trigger

Ryan Developer replied on Mon, 2010/02/15 - 10:32pm

This post was copied from Adam Bien's personal blog.  I had the same comments about the usefulness of  annotations vs APIs.  Adam's response was:

 

@Ryan,

o.k. then I will write a post especially for you :-). The API was always available, you had to use that. Annotation are new in Java EE 6. With EJB 3.1 comes also a fluent-API. Will write a post about that,

thanks for your feedback!,

adam

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.