If you're on CDI 2.0 you can add it yourself if you want (via annotation - @ActivateRequestContext). However, sounds like you're on WF 10.1, so you'd have to programmatically register it.
On Mon, Apr 9, 2018 at 8:41 AM Luís Alves <luisalve...@gmail.com> wrote: > It partially worked on @PostConstruct :), my colleague is having some issue > with the TX. I'm working from home today, so I can only have a clear look > tomorrow. > @Transactional is allowed on @PostConstruct, right? Does the method has to > be public for @Transactional be intercepted? > > I dunno what the spec says...but would be nice to have the @RequestContext > at the @Observes @Initialized(ApplicationScoped.class). > > LA > > On Mon, Apr 9, 2018 at 1:24 PM, Martin Kouba <mko...@redhat.com> wrote: > > > Dne 9.4.2018 v 14:20 Mark Struberg napsal(a): > > > >> According to the CDI spec every call to a business method must have the > >> Request Context activated. > >> > > > > Mark, this is very wrong! Which part of the spec dou you refer? > > > > > > > > And this very observer IS a business method. > >> > >> LieGrue, > >> strub > >> > >> > >> Am 09.04.2018 um 10:58 schrieb Martin Kouba <mko...@redhat.com>: > >>> > >>> Dne 9.4.2018 v 10:36 Luís Alves napsal(a): > >>> > >>>> I still didn't tested it...but I was hoping that @Observes > >>>> @Initialized(ApplicationScoped.class) was executed after > >>>> @PostConstruct > >>>> > >>> > >>> It is, but the request context is destroyed after the @PostConstruct > >>> callback completes (if it did not already exist before the > @PostConstruct > >>> callback was invoked). > >>> > >>> 1st: @PostConstruct > >>>> 2nd: public void init(@Observes @Initialized(ApplicationScoped.class) > >>>> Object init) > >>>> isn't this the case? Why on @PostConstruct we have scope and not at > >>>> @Observes @Initialized(ApplicationScoped.class)? - @Inject(ed) beans > >>>> are available here > >>>> LA > >>>> On Mon, Apr 9, 2018 at 8:44 AM, Martin Kouba <mko...@redhat.com > <mailto: > >>>> mko...@redhat.com>> wrote: > >>>> Dne 9.4.2018 v 09:33 Luís Alves napsal(a): > >>>> Thanks for you answers. > >>>> Before I left we tried with @TransactionScoped and got the > same > >>>> exception. > >>>> With the ContextControl ctxCtrl = > >>>> BeanProvider.getContextualReference(ContextControl.class); it > >>>> worked, but it seems a huge workaround. > >>>> @MKouba: thanks for your proposed solution. I'll will try as > >>>> soon as my colleague arrive, since the code his on his > machine. > >>>> Btw, we use wildfly-10.1.0.Final, if this is a bug can you > open > >>>> a bug? > >>>> It does not seem to be a bug. > >>>> Regards, > >>>> LA > >>>> On Mon, Apr 9, 2018 at 7:56 AM, Martin Kouba < > mko...@redhat.com > >>>> <mailto:mko...@redhat.com> <mailto:mko...@redhat.com > >>>> <mailto:mko...@redhat.com>>> wrote: > >>>> Dne 6.4.2018 v 18:37 Luís Alves napsal(a): > >>>> Hello, > >>>> I'm getting: > >>>> Caused by: java.lang.RuntimeException: > >>>> org.jboss.weld.context.ContextNotActiveException: > >>>> WELD-001303: > >>>> No active > >>>> contexts for scope type > >>>> javax.enterprise.context.RequestScoped > >>>> On bootstrap: > >>>> @ApplicationScoped > >>>> public class BootConfig > >>>> { > >>>> @Inject > >>>> private Logger logger; > >>>> @Inject > >>>> private ConfigRepo configRepo ; > >>>> public void init(@Observes > >>>> @Initialized(ApplicationScoped.class) Object > >>>> init){ > >>>> *//There's no Request Scope here* > >>>> Hm, there is no guarantee that a request context is > active > >>>> at this > >>>> point, i.e. during notification of this observer method. > >>>> However, you could put the logic in a @PostConstruct > >>>> callback of > >>>> BootConfig (request context must be active during > >>>> @PostConstruct > >>>> callback of any bean). > >>>> See also > >>>> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_ > >>>> context > >>>> <http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_ > >>>> context> > >>>> <http://docs.jboss.org/cdi/spe > >>>> c/1.2/cdi-spec.html#request_context <http://docs.jboss.org/cdi/spe > >>>> c/1.2/cdi-spec.html#request_context>> > >>>> Config c = > configRepo.findByKey("my.key"); > >>>> //.... > >>>> } > >>>> } > >>>> @Repository > >>>> public abstract class ConfigRepo extends > >>>> AbstractEntityRepository<Config, > >>>> Long> > >>>> { > >>>> private static final QConfig c= QConfig.config; > >>>> public Stop findByKey(final String key) > >>>> { > >>>> return new > >>>> JPAQuery<Stop>(*entityManager()*).from(c) > >>>> .where(c.key.eq(key)) > >>>> .fetchFirst(); > >>>> } > >>>> @ApplicationScoped > >>>> public class EntityManagerProducerImpl implements > >>>> EntityManagerProducer > >>>> { > >>>> @PersistenceContext(unitName = "my-unit") > >>>> private EntityManager entityManager; > >>>> @Produces > >>>> * @RequestScoped* > >>>> public EntityManager get() > >>>> { > >>>> return entityManager; > >>>> } > >>>> public void dispose(@Disposes @Default > >>>> EntityManager > >>>> entityManager) > >>>> { > >>>> if (entityManager.isOpen()) > >>>> { > >>>> entityManager.close(); > >>>> } > >>>> } > >>>> } > >>>> From the documentation you propose to use * > >>>> @RequestScoped* > >>>> entityManager...so...what is wrong with this > >>>> architecture? > >>>> I can switch to @TransactionScoped and then annotate > >>>> the init > >>>> method with > >>>> @Transactional...I suppose it will work...but maybe > is > >>>> not the > >>>> proper > >>>> approach. > >>>> Regards, > >>>> LA > >>>> -- Martin Kouba > >>>> Senior Software Engineer > >>>> Red Hat, Czech Republic > >>>> -- Martin Kouba > >>>> Senior Software Engineer > >>>> Red Hat, Czech Republic > >>>> > >>> > >>> -- > >>> Martin Kouba > >>> Senior Software Engineer > >>> Red Hat, Czech Republic > >>> > >> > >> > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > >
