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/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
