David Blevins kirjoitti:
Great start on the EJBCronTrigger, Alex. I went ahead and applied the
patch in OPENEJB-928 (thank you!).
I added some code for the annotation scanning and xml overriding
behavior. Slightly modified from what I posted before.
Now we're looking at something that's a bit closer to the interceptor
xml syntax, rather than the transaction attribute syntax:
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee";>
<enterprise-beans>
...
</enterprise-beans>
<assembly-descriptor>
<method-schedule>
<ejb-name>MyBean</ejb-name>
<method>
<method-name>runAction</method-name>
<method-params/>
</method>
<schedule>
<dayOfMonth>6</dayOfMonth>
<month>2</month>
<year>2009</year>
</schedule>
<schedule>
<dayOfMonth>30</dayOfMonth>
<month>3</month>
<year>2009</year>
</schedule>
</method-schedule>
</assembly-descriptor>
</ejb-jar>
Though not visible here there are big difference in that there is only
one allowed method, that method must have parameters and the binding
itself is stuck to an ejb-name. The transaction and security xml
bindings actually allow several ejbs and methods to be mentioned which
just complicates things in this scenario. I also made it so that if
you supply a <method-schedule> for a method of an EJB in xml, then it
is considered an override of the annotation schedule information in
the class for that method. So it is possible to shut off scheduling
for a method with a declaration like so:
<method-schedule>
<ejb-name>MyBean</ejb-name>
<method>
<method-name>runAction</method-name>
<method-params/>
</method>
</method-schedule>
Additionally, I followed standard rules for annotation inheritance in
that overriding a method in a subclass causes the annotations
associated with that method to be "whipped away" unless redeclared in
the overridden method. This matches the rules for all the callback
methods (@PostConstruct, @PreDestroy, @AroundInvoke, @PrePassivate,
@PostActivate). For example:
public class Parent {
@Schedules({
@Schedule(dayOfMonth = "6", month = "2", year = "2009"),
@Schedule(dayOfMonth = "30", month = "3", year = "2009")
})
public void runAction() {
}
}
Had those annotations been meant to be inherited, they would have been
marked with @java.lang.annotation.Inherited.
public class MyBean extends Parent {
/**
* Overriding this method without
* re-annotating it causes it to no longer
* be treated as an @Schedule method
*/
public void runAction() {
}
}
On the deployment side of things, all the sources of data are read in,
the rules are enforced, and the result is that DeploymentInfo now has
a method like so:
public List<ScheduleExpression> getMethodSchedules(Method method);
There'll be one javax.ejb.ScheduleExpression list associated with each
method, or null if there are no schedules for that method.
One little caveat of doing it this way is that ScheduleExpression does
not encapsulate all the data that is present in @Schedule, namely it
isn't possible to specify 'persistence' or 'info'. For the first
iteration we can go without persistence. But perhaps there should in
fact be a 'public boolean persistent' field in ScheduleExpression.
No, that would duplicate functionality in TimerConfig, which allows one
to specify both persistence status and info.
Calendar based timers will be created through
TimerService.createTimer(ScheduleExpression, TimerConfig) (or the
corresponding method in EJBTimerService in the absence of the updated
TimerService interface).
-David
