On Oct 24, 2008, at 3:52 AM, Alex Grönholm wrote:
David Blevins kirjoitti:
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).
Had those annotations been meant to be inherited, they would have
been marked with @java.lang.annotation.Inherited.
I don't think that works for methods. But, right, the annotation data
is not "inherited" by the overriding 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.
that would duplicate functionality in TimerConfig, which allows one
to specify both persistence status and info.
Thanks, I missed that class. In which case we'll want to wrap both
the ScheduleExpression and TimerConfig in an object and return both
from the DeploymentInfo.getMethodSchedule(..) method.
I'll hack something up on that.
-David
