You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Luís Alves <lu...@gmail.com> on 2018/04/06 16:37:34 UTC
@Observes @Initialized(ApplicationScoped.class) No active contexts
for RequestScoped
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*
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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
> Am 06.04.2018 um 18:37 schrieb Luís Alves <lu...@gmail.com>:
>
> public void init(@Observes @Initialized(ApplicationScoped.class) Object
> init){
This is imo pretty clearly a bug i your container and has nothing to do with DeltaSpike.
Please file a bug in your container.
It might not even have to do with Weld itself but is most probably an integration issue.
LieGrue,
strub
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Indeed you are right. It's only defined to MUST be active for EJBs and asynchronous observer methods.
But funnily not in synchronous CDI bean observers :/
LieGrue,
strub
> Am 09.04.2018 um 14:24 schrieb Martin Kouba <mk...@redhat.com>:
>
> 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 <mk...@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 <mk...@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 <mkouba@redhat.com
>>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
>>>> <ma...@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/spec/1.2/cdi-spec.html#request_context <http://docs.jboss.org/cdi/spec/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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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 <lu...@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 <lu...@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 <jo...@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 <lu...@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 <mk...@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 <mk...@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 <mkouba@redhat.com
> >> > <mailto:
> >> > >>>> mkouba@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 <
> >> > mkouba@redhat.com
> >> > >>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
> >> > >>>> <ma...@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
> >> > >
> >> >
> >>
> >
> >
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by "John D. Ament" <jo...@apache.org>.
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 <lu...@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 <lu...@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 <jo...@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 <lu...@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 <mk...@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 <mk...@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 <mkouba@redhat.com
> >> > <mailto:
> >> > >>>> mkouba@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 <
> >> > mkouba@redhat.com
> >> > >>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
> >> > >>>> <ma...@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
> >> > >
> >> >
> >>
> >
> >
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Luís Alves <lu...@gmail.com>.
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 <lu...@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 <jo...@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 <lu...@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 <mk...@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 <mk...@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 <mkouba@redhat.com
>> > <mailto:
>> > >>>> mkouba@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 <
>> > mkouba@redhat.com
>> > >>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
>> > >>>> <ma...@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
>> > >
>> >
>>
>
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Luís Alves <lu...@gmail.com>.
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 <jo...@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 <lu...@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 <mk...@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 <mk...@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 <mkouba@redhat.com
> > <mailto:
> > >>>> mkouba@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 <
> > mkouba@redhat.com
> > >>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
> > >>>> <ma...@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
> > >
> >
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by "John D. Ament" <jo...@apache.org>.
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 <lu...@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 <mk...@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 <mk...@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 <mkouba@redhat.com
> <mailto:
> >>>> mkouba@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 <
> mkouba@redhat.com
> >>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
> >>>> <ma...@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
> >
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Luís Alves <lu...@gmail.com>.
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 <mk...@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 <mk...@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 <mkouba@redhat.com<mailto:
>>>> mkouba@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 <mkouba@redhat.com
>>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
>>>> <ma...@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
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Martin Kouba <mk...@redhat.com>.
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 <mk...@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 <mk...@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 <mkouba@redhat.com
>>> <ma...@redhat.com> <mailto:mkouba@redhat.com
>>> <ma...@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/spec/1.2/cdi-spec.html#request_context <http://docs.jboss.org/cdi/spec/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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
According to the CDI spec every call to a business method must have the Request Context activated.
And this very observer IS a business method.
LieGrue,
strub
> Am 09.04.2018 um 10:58 schrieb Martin Kouba <mk...@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 <mk...@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 <mkouba@redhat.com
>> <ma...@redhat.com> <mailto:mkouba@redhat.com
>> <ma...@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/spec/1.2/cdi-spec.html#request_context <http://docs.jboss.org/cdi/spec/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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Martin Kouba <mk...@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 <mkouba@redhat.com
> <ma...@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 <mkouba@redhat.com
> <ma...@redhat.com> <mailto:mkouba@redhat.com
> <ma...@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/spec/1.2/cdi-spec.html#request_context <http://docs.jboss.org/cdi/spec/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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Luís Alves <lu...@gmail.com>.
I still didn't tested it...but I was hoping that @Observes
@Initialized(ApplicationScoped.class)
was executed after @PostConstruct
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 <mk...@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 <mkouba@redhat.com <mailto:
>> mkouba@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>
>>
>>
>> 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
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Martin Kouba <mk...@redhat.com>.
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 <mkouba@redhat.com
> <ma...@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>
>
>
> 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
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Luís Alves <lu...@gmail.com>.
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?
Regards,
LA
On Mon, Apr 9, 2018 at 7:56 AM, Martin Kouba <mk...@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
>
>
> 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
>
Re: @Observes @Initialized(ApplicationScoped.class) No active
contexts for RequestScoped
Posted by Martin Kouba <mk...@redhat.com>.
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
> 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