@Romain
If I need that the async job calls ejbs or make remote calls to e.g. web
services can I then do the following (pseudocode):
public class JobDispatcher {
@Inject
private Job job;
@Inject
private Executor executor; //Executor from TomEE examples...
public boolean submitJob() throws Exception {
//For now just wait for the answer
Future<Boolean> jobFuture = executor.submit(job);
return jobFuture.get();
}
}
public class Job implements Callable<Boolean> {
@Inject
private SomeEJB1 someEJB1;
@Inject
private SomeEJB2 someEJB2;
public Boolean call() throws Exception {
someEJB1.doWork();
someEJB2.doWork();
return true;
}
}
On Mon, Oct 6, 2014 at 10:20 PM, Lars-Fredrik Smedberg <itsme...@gmail.com>
wrote:
>
> On Mon, Oct 6, 2014 at 6:58 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
>> 2014-10-06 18:55 GMT+02:00 John D. Ament <john.d.am...@gmail.com>:
>> > No, not at all.
>> >
>>
>
> As far as I understand I can access @RequestScoped and @ApplicationScoped
> beans when inside an @Asynchronous EJB method call. However only the
> @ApplicationScoped bean will refer to the same scope as the method calling
> the @Asynchronous EJB method right? That was the first question and what I
> meant when saying "allowed"... not to clear but that was it :)
>
> The second was if it did make any sense to pass @RequestScoped and
> @ApplicationScoped beans as parameters to an @Asynchronous EJB method call
> and I don't find any good reason to do that and from your and Romains
> answer I guess there is not...
>
>
>> > The solution Romain gave you would likely work, but may fail in other
>> > containers as what's passed around is a proxy, not necessarily the real
>> > object.
>> >
>>
>> well idea was to compute params before being async. If that's a
>> request scoped bean computation is fast (otherwise there is design
>> issue IMHO). Request scope bean will likely pass some form/request
>> data to the async computation no more, no?
>>
>
> This method is simple and I guess will create the least amount of errors
> when developers that does not know every aspect of EJB and CDI will build
> applications.
>
>
>>
>> > On Mon, Oct 6, 2014 at 12:51 PM, Lars-Fredrik Smedberg <
>> itsme...@gmail.com>
>> > wrote:
>> >
>> >> @John
>> >>
>> >> But isnt @RequestScoped and @ApplicationScoped allowed scopes when
>> running
>> >> in an @Asynchronous EJB method?
>> >>
>> >>
>> >>
>> >> On Mon, Oct 6, 2014 at 5:24 PM, John D. Ament <john.d.am...@gmail.com>
>> >> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I would say no to #2. Thread != RequestScoped. If you want to
>> start a
>> >> > request scope with the thread, DeltaSpike has a CDIControl module
>> that
>> >> can
>> >> > do this for you.
>> >> >
>> >> > John
>> >> >
>> >> > On Mon, Oct 6, 2014 at 11:08 AM, Lars-Fredrik Smedberg <
>> >> itsme...@gmail.com
>> >> > >
>> >> > wrote:
>> >> >
>> >> > > When executing an EJB @Asynchronous method I know that valid CDI
>> scopes
>> >> > are
>> >> > > request and application.
>> >> > >
>> >> > > 1. Since @ApplicationScoped beans are available I assume that its
>> >> better
>> >> > to
>> >> > > inject those in the actual code being executed rather than passing
>> them
>> >> > as
>> >> > > arguments to the @Asynchronous method, correct?
>> >> > > 2. Since the @Asynchronous method starts a new thread any
>> >> @RequestScoped
>> >> > > beans passed in will be recreated right when the first business
>> method
>> >> on
>> >> > > them are called, correct?
>> >> > > 3. The above leaves me (if correct) with choosing between passing a
>> >> > normal
>> >> > > POJO (created with new) or an injected @Dependent scoped CDI
>> Managed
>> >> Bean
>> >> > > to an @Asynchronous EJB method, the choice depends on wether the
>> object
>> >> > > passed needs to inject anything, correct?
>> >> > >
>> >> > > --
>> >> > > Med vänlig hälsning / Best regards
>> >> > >
>> >> > > Lars-Fredrik Smedberg
>> >> > >
>> >> > > STATEMENT OF CONFIDENTIALITY:
>> >> > > The information contained in this electronic message and any
>> >> > > attachments to this message are intended for the exclusive use of
>> the
>> >> > > address(es) and may contain confidential or privileged
>> information. If
>> >> > > you are not the intended recipient, please notify Lars-Fredrik
>> Smedberg
>> >> > > immediately at itsme...@gmail.com, and destroy all copies of this
>> >> > > message and any attachments.
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Med vänlig hälsning / Best regards
>> >>
>> >> Lars-Fredrik Smedberg
>> >>
>> >> STATEMENT OF CONFIDENTIALITY:
>> >> The information contained in this electronic message and any
>> >> attachments to this message are intended for the exclusive use of the
>> >> address(es) and may contain confidential or privileged information. If
>> >> you are not the intended recipient, please notify Lars-Fredrik Smedberg
>> >> immediately at itsme...@gmail.com, and destroy all copies of this
>> >> message and any attachments.
>> >>
>>
>
>
>
> --
> Med vänlig hälsning / Best regards
>
> Lars-Fredrik Smedberg
>
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsme...@gmail.com, and destroy all copies of this
> message and any attachments.
>
--
Med vänlig hälsning / Best regards
Lars-Fredrik Smedberg
STATEMENT OF CONFIDENTIALITY:
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
address(es) and may contain confidential or privileged information. If
you are not the intended recipient, please notify Lars-Fredrik Smedberg
immediately at itsme...@gmail.com, and destroy all copies of this
message and any attachments.
