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