Thanks John.
DS allows to programmatically activate the scope (Container Control
Module).
Not sure if it works the same way of @ActivateRequestContext.
Nevertheless it's seems a workaround. I must agree with Struberg, it should
be activated, unless there's some good reason it can't be activated in the
observer.

LA

On Mon, Apr 9, 2018 at 3:39 PM, John D. Ament <[email protected]> wrote:

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

Reply via email to