hi luis, just fyi: the ds-scheduler module [1] is using quartz as a default implementation and provides a proper scope-handling out-of-the-box.
regards, gerhard [1] http://deltaspike.apache.org/documentation/scheduler.html 2018-02-14 10:39 GMT+01:00 Luís Alves <[email protected]>: > Hi Mark, > > Thanks for you answer :) > I guess is this: > https://deltaspike.apache.org/documentation/container- > control.html#_attach_a_requestcontext_to_a_new_thread_in_ee > I've changed my code to not send stuff to async, since is an MDB and I can > control the number of sessions [@ActivationConfigProperty(propertyName = > "maxSession", propertyValue = "10")]. > But it's good to know that I'll have the issue with Quartz jobs and DS > CdiCtrl will solve it :) > > LA > > On Wed, Feb 14, 2018 at 9:16 AM, Mark Struberg <[email protected]> > wrote: > > > That's a problem with the EE7 concurrency-utils. > > It doesn't require the request context to get activated :( > > > > You can work around this with DeltaSpike CdiCtrl or the CDI-2.0 Context > > activator (if you are on an EE 8 server). > > > > LieGrue, > > strub > > > > > Am 13.02.2018 um 15:48 schrieb Luís Alves <[email protected]>: > > > > > > Fun thing...with @RequestScoped I get: > > > > > > 14:32:00,682 ERROR [stderr] (EE-ManagedExecutorService- > default-Thread-3) > > > org.jboss.weld.context.ContextNotActiveException: WELD-001303: No > active > > > contexts for scope type javax.enterprise.context.RequestScoped > > > > > > when running a task inside a ManagedExecutorService. Any ideas? > > > Anyone know how to get the current TX id with wildfly? I this I'm > runin' > > 2 > > > different TX, since the MDB push a task to the ManagedExecutorService I > > > doubt the TX can be propagated. > > > > > > > > > On Tue, Feb 13, 2018 at 12:32 PM, Gerhard Petracek < > [email protected] > > > > > > wrote: > > > > > >> org.apache.deltaspike.jpa.impl.transaction. > > ContainerManagedTransactionStr > > >> ategy > > >> is a 1:1 delegation (without additional logic [1]). > > >> it's mainly useful for shared libs which use > > >> @org.apache.deltaspike.jpa.api.transaction.Transactional, but there > are > > >> applications using CMT (instead of BMT). > > >> > > >> regards, > > >> gerhard > > >> > > >> [1] > > >> https://github.com/apache/deltaspike/blob/master/ > > >> deltaspike/modules/jpa/impl/src/main/java/org/apache/ > > deltaspike/jpa/impl/ > > >> transaction/ContainerManagedTransactionStrategy.java > > >> > > >> > > >> > > >> 2018-02-13 12:58 GMT+01:00 Luís Alves <[email protected]>: > > >> > > >>> I'm avoiding EJBs...currently just for MDB. And I use CMT => > > >>> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction. > > >>> TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction. > > >>> ContainerManagedTransactionStrategy > > >>> > > >>> And now I changed my producer to: > > >>> > > >>> @Produces > > >>> @Default > > >>> *@RequestScoped* > > >>> public EntityManager get() > > >>> { > > >>> return entityManager; > > >>> } > > >>> > > >>> On Tue, Feb 13, 2018 at 11:54 AM, Gerhard Petracek < > > [email protected] > > >>> > > >>> wrote: > > >>> > > >>>> @TransactionScoped beans get destroyed after finishing the outermost > > >>> method > > >>>> (in the callstack) annotated (in-/directly) with > > >>>> @org.apache.deltaspike.jpa. > > >>>> api.transaction.Transactional. > > >>>> > > >>>> in case you are using ejbs and CMT, the container already manages > the > > >>> scope > > >>>> for you (and you just get a proxy-instance anyway - which can be > > >> exposed > > >>> as > > >>>> dependent bean). > > >>>> -> it really depends on the mode you are using. > > >>>> > > >>>> regards, > > >>>> gerhard > > >>>> > > >>>> > > >>>> > > >>>> 2018-02-13 12:31 GMT+01:00 Luís Alves <[email protected]>: > > >>>> > > >>>>> There you use the @RequestScoped....and you present > > >> @TransactionScoped, > > >>>>> which seems exactly what I want but not sure what happens when TX > is > > >>>> marked > > >>>>> as NEVER or SUPPORTS (and none is oppened). > > >>>>> > > >>>>> On Tue, Feb 13, 2018 at 11:15 AM, Gerhard Petracek < > > >>> [email protected] > > >>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> hi luis, > > >>>>>> > > >>>>>> please have a look at [1]. > > >>>>>> > > >>>>>> regards, > > >>>>>> gerhard > > >>>>>> > > >>>>>> [1] http://deltaspike.apache.org/documentation/jpa.html# > Basicusage > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2018-02-13 12:11 GMT+01:00 Luís Alves <[email protected]>: > > >>>>>> > > >>>>>>> Well...I have REST services...so I think RequestScoped EM would > > >> be > > >>>> ok. > > >>>>>>> > > >>>>>>> On Tue, Feb 13, 2018 at 10:55 AM, Thomas Andraschko < > > >>>>>>> [email protected]> wrote: > > >>>>>>> > > >>>>>>>> If an AppScoped EntityManager is the right thing for you, yes. > > >>>>>>>> In my webapplication i mostly use RequestScoped EMs. > > >>>>>>>> > > >>>>>>>> 2018-02-13 11:39 GMT+01:00 Luís Alves <[email protected]>: > > >>>>>>>> > > >>>>>>>>> "An instance of a dependent bean is never shared between > > >>>> *different > > >>>>>>>> clients > > >>>>>>>>> *or different injection points." > > >>>>>>>>> "Beans with scope @Dependent don’t need a proxy object. The > > >>>> client > > >>>>>>> holds > > >>>>>>>> a > > >>>>>>>>> direct reference to its instance." > > >>>>>>>>> > > >>>>>>>>> so...I think I should be OK. > > >>>>>>>>> > > >>>>>>>>> On Tue, Feb 13, 2018 at 10:29 AM, Luís Alves < > > >>>>> [email protected]> > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> So my Service layer is @ApplicationScoped. > > >>>>>>>>>> Since Inject the @Repository into my service layer and is > > >>>>>> @Dependent > > >>>>>>> it > > >>>>>>>>>> will be an @ApplicationScoped. I'm producing my EM like: > > >>>>>>>>>> > > >>>>>>>>>> @ApplicationScoped > > >>>>>>>>>> public class EntityManagerProducerImpl implements > > >>>>>>> EntityManagerProducer > > >>>>>>>>>> { > > >>>>>>>>>> > > >>>>>>>>>> @PersistenceContext(unitName = "unit") > > >>>>>>>>>> private EntityManager entityManager; > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> @Override > > >>>>>>>>>> @Produces > > >>>>>>>>>> @Default > > >>>>>>>>>> public EntityManager get() > > >>>>>>>>>> { > > >>>>>>>>>> return entityManager; > > >>>>>>>>>> } > > >>>>>>>>>> } > > >>>>>>>>>> > > >>>>>>>>>> So...will it work properly? or do I have to mark my EM as > > >>>>>>>> @RequestScoped? > > >>>>>>>>>> > > >>>>>>>>>> LA > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Tue, Feb 13, 2018 at 10:24 AM, Thomas Andraschko < > > >>>>>>>>>> [email protected]> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Hi, > > >>>>>>>>>>> > > >>>>>>>>>>> the default scope is @Dependent but i suggest everyone to > > >>> use > > >>>>>>>>>>> @ApplicationScoped. > > >>>>>>>>>>> The EM will be proxied if you use a NormalScope like > > >>>>>> @RequestScoped, > > >>>>>>>>> .... > > >>>>>>>>>>> > > >>>>>>>>>>> Regards, > > >>>>>>>>>>> Thomas > > >>>>>>>>>>> > > >>>>>>>>>>> 2018-02-13 10:54 GMT+01:00 Luís Alves < > > >>> [email protected] > > >>>>> : > > >>>>>>>>>>> > > >>>>>>>>>>>> Hi, > > >>>>>>>>>>>> > > >>>>>>>>>>>> What is the scope of @Repository? Do you use a similar > > >>>>> approach > > >>>>>> of > > >>>>>>>>>>> Spring? > > >>>>>>>>>>>> @Singleton and proxy the EM? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Regards, > > >>>>>>>>>>>> LA > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
