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 <[email protected]> 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 <[email protected]>: >>> >>> 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 <[email protected]<mailto: >>>> [email protected]>> 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 <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>>> 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 >
