Thinking more about it...
The scopes that we can safely support will be:
a) Scope.Component (which is redundant as the result of getTimers()
would be the same as getAllTimers(Scope.Component)
b) Scope.Module
c) Scope.Application (which most of the experts didn't think we should
support)
The rest of possible scopes (Cluster or Instance) if outside of the 3
scopes above, pose a security risk...
Another option would be to start with a no-arg getAllTimers, which will
default to (b) Scope.Module, and add Scopes when they are available.
-marina
Antonio Goncalves wrote:
> Well, I think this should belong to javax.naming really. A bit tough
> to get it in Java SE but it's just an enum of what already exists in
> JNDI (expect if we use Strings getAllTimers("app") but I don't like it)
>
> Antonio
>
> On Mon, Jun 25, 2012 at 10:00 PM, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Which package/spec will Scope belong to? We don't want to define
> it in javax.ejb, correct?
>
> thanks,
> -marina
>
> Antonio Goncalves wrote:
>
> Instead of choosing between 1a & 1b, why don't we pass a scope
> as a parameter ? We have the JNDI scopes that we could mimic :
> comp, module, application, global... So why not having
> getAllTimers(Scope.Module) or getAllTimers(Scope.Application)
> ? If Java EE 7 is (at last) mentioning clustering in the spec,
> why not having an extra Cluster scope ?
> getAllTimers(Scope.Cluster) would return all the timers across
> the cluster.
> Antonio
>
> On Fri, Jun 22, 2012 at 3:48 PM, Jean-Louis MONTEIRO
> <jeanouii_at_gmail.com <mailto:jeanouii_at_gmail.com>
> <mailto:jeanouii_at_gmail.com <mailto:jeanouii_at_gmail.com>>> wrote:
>
> Marina,
>
> Yes, that is definitely useful.
> Being able to cancel a set of Timer spread on a cluster i don't
> necessary started, looks dangerous to me at first glance.
>
> That's why I choose 3b. Then, it means that it's just for
> information purpose if I don't own the Timer.
>
> Jean-Louis
>
>
>
> 2012/6/20 Marina Vatkina <marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>
> <mailto:marina.vatkina_at_oracle.com
> <mailto:marina.vatkina_at_oracle.com>>>
>
>
> Returning to this item...
>
>
> Florent and Jean-Louis,
>
> Did you miss my question: "You chose 3b, so do you
> think that
> the new API is useful even if it is for information
> purpose only"?
>
>
> Experts, we still have an almost even split between 3a
> and 3b,
> so please cast your votes (if you don't think the new
> API is
> useful, please say so as well).
>
> thanks,
> -marina
>
>
> Marina Vatkina wrote:
>
> We have 2 votes for 3a and 2 votes for 3b.
>
> Those of you who didn't vote, please do so.
>
> Florent, Jean-Louis, (you chose 3b) do you still think
> that the new API is useful? What would in your
> opinion the
> caller be able to do with the timers returned by
> this API?
>
> thanks,
> -marina
>
> Florent BENOIT wrote:
>
> 1a
> 2b
> 3b
>
> Regards,
>
> Florent
>
> On 04/18/2012 11:01 PM, Marina Vatkina wrote:
>
> Experts,
>
> Do you think it is useful to add a method
> to the
> TimerService - getAllTimers() - (see
> http://java.net/jira/browse/EJB_SPEC-47)
> that will
> allow to get a collection of all active
> timers in
> this application?
>
> If you think it is useful, which options
> should be
> supported:
>
> 1. Scope
> a) All timers in the same EJB module
> b) All timers in the same application (EAR
> file)
>
> 2. Runtime:
> a) Timers from 1a or 1b running on the same
> server
> instance
> b) Timers from 1a or 1b running on any
> instance in
> the cluster
>
> 3. Cancelation:
> a) Timers returned by this method can be
> canceled
> by the caller (i.e. even if it doesn't own
> the timer)
> b) Only the bean that owns a timer can
> cancel it.
>
> If you think there is no need for the new API,
> please say so.
>
> Best,
> -marina
>
>
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG
> <http://www.parisjug.org>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>