In a previous post, we demonstrated how to create and configure Quartz jobs with annotations in a Spring container. We used a class-level annotation to add some metadata to a bean which implements Quartz's Job; the annotation defines the job's name, group, and its cron-expression. Later, a big portion of the code is dedicated to handling that annotation: find the beans, read the annotation, create the JobDetail and the CronTrigger, apply their properties, and pass them over to the scheduler.
If you are working on an average to big-size spring project, you will probably soon enough start to see boilerplate configuration and code which can be often refactored by encapsulating it in annotations; the @QuartzJob annotation is a good example.
At masetta we tried to use the Polyforms project to use annotations for implementing DAO methods (which usually consist of some boilerplate code around a JPA Query). Soon enough we found it was not as configurable and extendable as we needed, had problems handling named query parameters and initialization-order problems (because how Polyforms uses aspects to to implement abstract methods). In addition, we used custom annotations and handled them â€œmanuallyâ€?, but they were getting too many...
What we came up with is spann. Spann is an open source extension for the spring framework, which allows advanced configuration of spring beans using annotations. To give a peek at one of spann's features I will rely on our previous post and implement similar functionality. Instead of coding, I will use spann. As you will see, the implementation is very brief.
Read more at :