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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
