David Blevins kirjoitti:
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.
I think we could do with a less complicated solution. As it stands, I
have to reflectively scan the bean class for methods and then call
DeploymentInfo.getMethodSchedule() on each to see if the method has any
schedules on it. CoreDeploymentInfo has a map of method ->
ScheduleExpression, but there is no way to retrieve that. I will also
need the persistent and info properties, so why don't you just give me a
map of method -> ScheduleInfo[] and let me worry about building
ScheduleExpressions and TimerConfigs? This is somewhat blocking my
development so it'd be appreciated if you could do that in the near future.
-David
