Marina,
We decided against it because it strayed from POJO/OO principles back
into an over-reliance on proxies.
Cheers,
Reza
On 7/5/2011 7:05 PM, Marina Vatkina wrote:
> Does somebody from the EJB 3.1 EG remember why the original approach
> was abandoned when an EJB could have a regular return type on its
> async method, with a Future return type on the corresponding method on
> an interface?
>
> thanks,
> -marina
>
> Carlo de Wolf wrote:
>> It brings us back to the original problem of the async API: you want
>> the app developer to use Future, but Future is not used in the
>> business interface definition. This makes no real difference for void
>> methods (if you're not interested in exceptions), but other methods
>> should 'return' a Future. Hence the divine() method.
>>
>> Carlo
>>
>> On 07/01/2011 02:38 PM, Pete Muir wrote:
>>> I do agree with Carlo that often it is the client that knows whether
>>> an invocation should be sync or async.
>>>
>>> I also agree with Reza that the proposed syntax is a little obtuse.
>>> Some comments:
>>>
>>> * I don't like the use of static helper methods at all, it's
>>> (a) clunky and
>>> (b) inconsistent with the rest of Java EE
>>> * Where possible the API should avoid having classes in it
>>> * I don't really understand the naming of the methods beyond async()
>>>
>>> public class Async {
>>>
>>> public static<T> T async(T bean);
>>>
>>> public static Future<?> divine();<<< What does divine() mean?
>>>
>>> public static<R> Future<R> divine(R dummyResult);
>>> }
>>>
>>> I would have thought that it is more consistent with the EJB
>>> component model to expose a special JNDI name returning an async or
>>> future wrapped version of the bean. With CDI we could then expose
>>> these as @Asynchronous and just future wrapped options.
>>>
>>> e.g.
>>>
>>> @Inject @Asynchronous SomeBean bean;
>>>
>>> @Inject Future<SomeBean> bean;
>>>
>>> On 30 Jun 2011, at 19:18, Reza Rahman wrote:
>>>
>>>> Personally, I think @Asynchronous is fine (in fact, I think it is
>>>> probably more intuitive than the proposed syntax). The cases are
>>>> very rare that a synchronous method would suddenly be used
>>>> asynchronously without the bean developer's knowledge. It's also
>>>> the case that in order to support things like cancellation, the
>>>> bean would have to be aware that it is being invoked asynchronously.
>>>>
>>>> Cheers,
>>>> Reza
>>>>
>>>>
>>>> On 6/30/2011 1:57 PM, Marina Vatkina wrote:
>>>>> Thanks for asking. The official guideline is to use this list :)
>>>>>
>>>>> -marina
>>>>>
>>>>> Pete Muir wrote:
>>>>>> Where should we discuss this - comments thread? email list?
>>>>>>
>>>>>> Marina, what is the official guideline?
>>>>>>
>>>>>> On 30 Jun 2011, at 09:59, Carlo de Wolf wrote:
>>>>>>
>>>>>>> As I mentioned on the EJB 3.1 EG when we did asynchronous, I
>>>>>>> don't like that it is tied into the bean developer realm.
>>>>>>>
>>>>>>> I've opened up http://java.net/jira/browse/EJB_SPEC-11 as a
>>>>>>> proposed alternative.
>>>>>>> Looking forward to your comments.
>>>>>>>
>>>>>>> Carlo
>>>>>
>>>>> -----
>>>>> No virus found in this message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 10.0.1388 / Virus Database: 1516/3735 - Release Date:
>>>>> 06/30/11
>>>>>
>>>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3746 - Release Date: 07/05/11
>
>