On 12/7/2012 2:01 PM, Marina Vatkina wrote:
> Experts,
>
> GlassFish (RI) throws an exception if Timer any method is executed by a non-EJB. The statement that might cause RI
> behavior is in the section 13.2.6: "timers are local objects"..
>
I don't understand. Section 13.2.6, only says that it must not be passed through a
*remote* interface.
> Do you think the RI is too restrictive or the spec wording should be relaxed?
>
If you are interpreting "local object" to mean local to the specific EJB, then yes,
I believe that that interpretation is too restrictive.
> My vote is yes, because otherwise, instead of just calling Timer.isPersistent() or Timer.getInfo() the caller needs to
> ask an EJB (the Bean Provider) to do so.
>
> thanks,
> -marina
>
> Linda DeMichiel wrote:
>>
>>
>> On 12/4/2012 9:40 AM, Marina Vatkina wrote:
>>>
>>>
>>> Linda DeMichiel wrote:
>>>>
>>>>
>>>> On 12/3/2012 11:03 PM, Marina Vatkina wrote:
>>>>> Experts,
>>>>>
>>>>> Please look at http://java.net/jira/browse/EJB_SPEC-71 - which is a separate issue on Timer.cancel mismatch in the
>>>>> spec.
>>>>>
>>>>> Please let me know, if you think that:
>>>>>
>>>>> a) A timer can be cancelled only by the bean that owns it (as in getAllTimers() rule)
>>>>>
>>>>
>>>> no
>>>>
>>>>> Or
>>>>>
>>>>> b1) A timer can be cancelled by calling Timer.cancel() (i.e. the rule in getAllTimers() should be removed)
>>>>>
>>>>
>>>> yes
>>>>
>>>>> b2) Timer can be cancelled by a non-EJB caller (i.e. the spec should remove references to a bean or a Bean Provider
>>>>> when
>>>>> describing the timer cancellation).
>>>>>
>>>>
>>>> yes
>>>>
>>>>> Depending on the outcome of your vote, I'll update the spec one way or the other.
>>>>>
>>>>
>>>> The spec should not prohibit this, as that would be a backward-incompatible change.
>>>>
>>>> I don't see any reason for encouraging it either, i.e., the language of EJB 3.1 is sufficient.
>>>
>>> The spec says "Timer object [...] allows the bean to cancel the timer" or "the Bean Provider to cancel a timer". So the
>>> spec needs to change to allow b2.
>>>
>>
>> I don't think the spec needs to change anything. What is stated is the obvious intended scenario. However the
>> bean provider can arrange for the timer to be canceled or managed by another object by passing it around.
>>
>>
>>> thanks,
>>> -marina
>>>>
>>>> -Linda
>>>>
>>>>> As a note: GlassFish (RI) allows a non-owning bean (I didn't check a servlet) to cancel a timer by calling its
>>>>> cancel()
>>>>> method.
>>>>>
>>>>>
>>>>> thanks,
>>>>> -marina