[JBoss JIRA] (WFLY-6485) add JPA dependency in subdeployments to avoid NPE
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6485?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6485:
------------------------------------
Great catch [~mkouba]! I like your version of the fix better. I verified that the unit test and test case both pass with your suggested fix.
> add JPA dependency in subdeployments to avoid NPE
> --------------------------------------------------
>
> Key: WFLY-6485
> URL: https://issues.jboss.org/browse/WFLY-6485
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> WeldDeploymentProcessor only processes top level deployments (subdeployments are skipped). This means that subdeployments that CDI inject a persistence unit/context, will not add a dependency on the JPA PersistenceUnitService. As a result, the PersistenceUnitService is referenced before it is started (which leads to PersistenceUnitService.entityManagerFactory being null).
> We should avoid the following NPE by ensuring that dependencies on the JPA persistence unit are added for all sub-deployments.
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:91)
> at org.jboss.as.jpa.container.AbstractEntityManager.find(AbstractEntityManager.java:212)
> {quote}
> Potential fix is at [https://github.com/scottmarlow/wildfly/tree/jpaNPE]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6485) add JPA dependency in subdeployments to avoid NPE
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6485?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6485:
------------------------------------
Hi [~mkouba], I'll try that.
> add JPA dependency in subdeployments to avoid NPE
> --------------------------------------------------
>
> Key: WFLY-6485
> URL: https://issues.jboss.org/browse/WFLY-6485
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> WeldDeploymentProcessor only processes top level deployments (subdeployments are skipped). This means that subdeployments that CDI inject a persistence unit/context, will not add a dependency on the JPA PersistenceUnitService. As a result, the PersistenceUnitService is referenced before it is started (which leads to PersistenceUnitService.entityManagerFactory being null).
> We should avoid the following NPE by ensuring that dependencies on the JPA persistence unit are added for all sub-deployments.
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:91)
> at org.jboss.as.jpa.container.AbstractEntityManager.find(AbstractEntityManager.java:212)
> {quote}
> Potential fix is at [https://github.com/scottmarlow/wildfly/tree/jpaNPE]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-4146) Cache add operation should automatically create its child resources
by Maxim Karavaev (JIRA)
[ https://issues.jboss.org/browse/WFLY-4146?page=com.atlassian.jira.plugin.... ]
Maxim Karavaev commented on WFLY-4146:
--------------------------------------
Dear Paul,
I need your help, please. I've spent two days to clarify, why my WildFly9 Infinispan configuration stop working in WildFly10.
I just uses a cache with a custom store configuration. Cache configured through the jboss-cli like this:
{code}
/profile=full-ha/subsystem=infinispan/cache-container=cacheContainer:add()
/profile=full-ha/subsystem=infinispan/cache-container=cacheContainer/transport=TRANSPORT:add(lock-timeout=60000)
/profile=full-ha/subsystem=infinispan/cache-container=cacheContainer/replicated-cache=test:add(mode=ASYNC)
/profile=full-ha/subsystem=infinispan/cache-container=cacheContainer/replicated-cache=test/store=STORE:add(class=org.infinispan.persistence.sifs.configuration.SoftIndexFileStoreConfigurationBuilder,passivation=false,preload=false,purge=false,properties={dataLocation=${jboss.server.data.dir}/infinispan/container/testData,indexLocation=${jboss.server.data.dir}/infinispan/container/testIndex})
{code}
Ok, I read your comments and changed scripts accordingly. Nothing changed.
I know, that to start my Infinispan container in WF9 I need to inject CacheContainer instance inside the EJB container and after that, I can use CacheContainer.getCache("test") to get access to a properly configured cache instance.
{code:java}
@Singleton
@Startup
public class CacheAccessBean {
@Resource(lookup = "java:jboss/infinispan/container/cacheContainer")
private CacheContainer cc;
@PostConstruct
public void init() {
Cache cache = cc.getCache("test");
...
}
{code}
This is not work in WilfFly10. As I can see, CacheContainer injected into the EJB container without named configuration "test", so the invocation of CacheContainer.getCache("test") returns default cache. Injection of the Cache instance itself by the JNDI link like "java:jboss/infinispan/container/cacheContainer/test" didn't work in WL9 and here too.
What did I wrong? Is there any special trick to start Cache service with the defined configuration?
> Cache add operation should automatically create its child resources
> -------------------------------------------------------------------
>
> Key: WFLY-4146
> URL: https://issues.jboss.org/browse/WFLY-4146
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Alpha6
>
>
> There is effectively no difference between the behavior of a cache that does not contain a given child resource (e.g. transaction, locking, etc) and one that contains the child resource, but with default attribute values.
> Consequently, the cache add operation should automatically create these resources (and the cache remove operation should automatically remove them). We can treat the child add operations as no-ops, and the child remove operations as a series of undefine-attribute operations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month