You better not use an injected EntityManager at all afaik. This is perfectly 
non portably.If you know that you will stick with JBoss then it might work. Not 
sure. On most servers I'd rather inject the EntityManagerFactory and then 
createEM + Dispose it.
If you use @Inject EntityManager throughout your app (and not @PersistenceUnit 
in your EJBs) then it will work perfectly fine.

Btw, back to the original discussion: Simply implement your logic in the 
@PostConstruct instead of the @Observes Initialized(ApplicationScoped.class). 
Because in @PostConstruct methods the request Context MUST be active!
LieGrue,strub
 

    On Wednesday, 11 April 2018, 19:58:50 CEST, John D. Ament 
<johndam...@apache.org> wrote:  
 
 You should not have a disposer method in your case, since you're using a
container managed entity manager (using @PersistenceContext for injection)

On Wed, Apr 11, 2018 at 4:24 AM Luís Alves <luisalve...@gmail.com> wrote:

> The error that I mention earlier was this one:
>
> ERROR [org.jboss.weld.Bean] (DefaultQuartzScheduler_Worker-1) WELD-000019:
> Error destroying an
> instance
> *org.jboss.as.jpa.container.TransactionScopedEntityManager*@4f7d201d
> of Producer Method [EntityManager]
> with qualifiers [@Default @Any] declared as [[BackedAnnotatedMethod]
> @Produces @Default
> @RequestScoped public my.package.config.EntityManagerProducerImpl.get()]
>
>
> It's caused by the dispose method
>
> @ApplicationScoped
> public class EntityManagerProducerImpl implements EntityManagerProducer
> {
>
>    @PersistenceContext(unitName = "my-unit")
>    private EntityManager entityManager;
>
>    @Override
>    @Produces
>    @Default
>    @RequestScoped
>    public EntityManager get()
>    {
>        return entityManager;
>    }
>
>
>
>
>
>
>
> *    public void closeEntityManager(@Disposes @Default EntityManager em)
> {        if (em.isOpen())        {            em.close();        }    }*
>
> }
>
> When I remove it, it works fine. I think since I use
>
> globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy=org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy
> the EM is closed by the container, but not 100% sure.
> Should I have a dispose or not?
>
> Regards,
> LA
>
> On Mon, Apr 9, 2018 at 3:50 PM, Luís Alves <luisalve...@gmail.com> wrote:
>
> > 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 <johndam...@apache.org>
> > 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 <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
> >> > >
> >> >
> >>
> >
> >
>  

Reply via email to