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