[JBoss JIRA] (WFLY-12676) memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12676?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12676:
--------------------------------
Summary: memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment (was: org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment)
> memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12676
> URL: https://issues.jboss.org/browse/WFLY-12676
> Project: WildFly
> Issue Type: Task
> Components: JCA
> Affects Versions: 18.0.0.Final
> Reporter: Scott Marlow
> Assignee: Stefano Maestri
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
> Attachments: 2lc.jar, java_pid12802.0001.zip, jcaleakmarlow.txt
>
>
> As part of looking at [WFLY-12671], I found that org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is leaking the application classloader (after undeployment) via org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory originalTCCL being kept after undeployment.
> See attached jcaleakmarlow.txt (also attached to [WFLY-12671]), which shows the leak.
> I tried waiting a few minutes after undeployment and the leak was still there. I also tried an even simpler app (2lc.jar) and still there is a leak. I also attached the heapdump (java_pid12802.0001.zip)
> To recreate:
> * Deploy simple (no app code will be executed) 2lc.jar app.
> * Undeploy by doing "rm 2lc.jar.deployed" in wildfly/standalone/deployments
> * Look at memory with MAT or other memory leak tool.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFCORE-4592) WildFly Core doesn't compile on Open JDK 14 anymore
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4592?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFCORE-4592:
----------------------------------------
We can support JDK14 and beyond [~brian.stansberry] [~dlofthouse]
as it is possible to workaround this issue.
ATM just java.security.acl package was removed from JDK14.
It is possible to put this missing package to some separate folder or jar archive and
pass "-patch-module" and "-add-exports" flag to compiler and VM.
The following command line is working workaround for this issue:
$ORACLE_JDK14_EA/bin/java --patch-module java.base=/home/opalka/java.base-patch --add-exports java.base/java.security.acl=ALL-UNNAMED Test
where java.base-patch folder contains missing java.security.acl package and its classes
> WildFly Core doesn't compile on Open JDK 14 anymore
> ---------------------------------------------------
>
> Key: WFCORE-4592
> URL: https://issues.jboss.org/browse/WFCORE-4592
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Environment: Since Open JDK 14 EA build 8 including
> Reporter: Richard Opalka
> Priority: Major
>
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /home/opalka/git/redhat/wildfly-core/domain-management/src/main/java/org/jboss/as/domain/management/security/JaasCallbackHandler.java:[224,51] cannot access java.security.acl.Group
> class file for java.security.acl.Group not found
> [INFO] 1 error
> [INFO] -------------------------------------------------------------
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12666) JPA jipijapa use optional dependencies instead of modifying the system module
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12666?page=com.atlassian.jira.plugin... ]
Scott Marlow resolved WFLY-12666.
---------------------------------
Resolution: Rejected
[~bmaxwell] please reopen if you come up with an alternative approach that doesn't include a user module.
> JPA jipijapa use optional dependencies instead of modifying the system module
> -----------------------------------------------------------------------------
>
> Key: WFLY-12666
> URL: https://issues.jboss.org/browse/WFLY-12666
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Scott Marlow
> Priority: Major
> Attachments: WFLY-12666-overlay.zip
>
>
> As per [1] it requires modifying the modules under system/layers/base, these are system modules which users really should not modify. When applying patches it will complain because the module has been modified.
> It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml
> modules/system/layers/base/org/eclipse/persistence/main/module.xml
> It looks like this almost works with just adding the optional dependency, except there is an exception where it looks like the classloader may not be set correctly for some reason when the module is split into 2.
> {code}
> <module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.5">
> ...
> <module name="org.eclipse.persistence.impl" optional="true" services="import"/>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="org.eclipse.persistence.impl">
> <resources>
> <!-- you want this jar to be loaded from the system module as it can be packaged potentially
> <resource-root path="jipijapa-eclipselink-7.3.0.Beta-redhat-00001.jar"/>
> -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**"/>
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="org.antlr"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> <module name="org.eclipse.persistence"/> <!-- to see jipijapa-eclipse-link if necessary -->
> </dependencies>
> </module>
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Object: com.jboss.examples.jpa.model.User@4fbcb157 is not a known Entity type.
> at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at com.jboss.examples.jpa.TestSingleton.test(TestSingleton.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
> {code}
> [1] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12666) JPA jipijapa use optional dependencies instead of modifying the system module
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12666?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-12666:
-------------------------------------
{quote}
WildFly should not ship modules outside of modules/system/layers/base.
{quote}
Including an optional user module for EclipseLink, is part of the [WFLY-12666] proposal. Guess we need to reject this jira.
> JPA jipijapa use optional dependencies instead of modifying the system module
> -----------------------------------------------------------------------------
>
> Key: WFLY-12666
> URL: https://issues.jboss.org/browse/WFLY-12666
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Scott Marlow
> Priority: Major
> Attachments: WFLY-12666-overlay.zip
>
>
> As per [1] it requires modifying the modules under system/layers/base, these are system modules which users really should not modify. When applying patches it will complain because the module has been modified.
> It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml
> modules/system/layers/base/org/eclipse/persistence/main/module.xml
> It looks like this almost works with just adding the optional dependency, except there is an exception where it looks like the classloader may not be set correctly for some reason when the module is split into 2.
> {code}
> <module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.5">
> ...
> <module name="org.eclipse.persistence.impl" optional="true" services="import"/>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="org.eclipse.persistence.impl">
> <resources>
> <!-- you want this jar to be loaded from the system module as it can be packaged potentially
> <resource-root path="jipijapa-eclipselink-7.3.0.Beta-redhat-00001.jar"/>
> -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**"/>
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="org.antlr"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> <module name="org.eclipse.persistence"/> <!-- to see jipijapa-eclipse-link if necessary -->
> </dependencies>
> </module>
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Object: com.jboss.examples.jpa.model.User@4fbcb157 is not a known Entity type.
> at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at com.jboss.examples.jpa.TestSingleton.test(TestSingleton.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
> {code}
> [1] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-4625:
--------------------------------------
Comment: was deleted
(was: [~danielezonca] Yes definitely if something is wrong with the Background data the user should be informed. Is this more of a system error or a user error - how do they resolve it? )
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screenshot from 2019-10-16 16-42-25.png, Screenshot from 2019-10-16 16-44-18.png, background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4625:
-------------------------------------------
[~danielezonca] Yes definitely if something is wrong with the Background data the user should be informed. Is this more of a system error or a user error - how do they resolve it?
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screenshot from 2019-10-16 16-42-25.png, Screenshot from 2019-10-16 16-44-18.png, background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-4625:
--------------------------------------
Comment: was deleted
(was: [~danielezonca] So the user should go to the alerts or the background tab to get more info? Or both? )
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screenshot from 2019-10-16 16-42-25.png, Screenshot from 2019-10-16 16-44-18.png, background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12666) JPA jipijapa use optional dependencies instead of modifying the system module
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12666?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12666:
-----------------------------------------
[~smarlow]
{quote}
Or perhaps we could consider moving modules/system/layers/base/org/eclipse/persistence/main/module.xml to modules/org/eclipse/eclipselink/main/module.xml.
{quote}
WildFly should not ship modules outside of modules/system/layers/base.
I also don't think moving the module would prevent patch conflict problems. If it did it would be because moving the module prevents it being patched, which is not good.
> JPA jipijapa use optional dependencies instead of modifying the system module
> -----------------------------------------------------------------------------
>
> Key: WFLY-12666
> URL: https://issues.jboss.org/browse/WFLY-12666
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 18.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Scott Marlow
> Priority: Major
> Attachments: WFLY-12666-overlay.zip
>
>
> As per [1] it requires modifying the modules under system/layers/base, these are system modules which users really should not modify. When applying patches it will complain because the module has been modified.
> It would be better if these modules depended on an optional module which would not exist unless the user configured this. So for example a user could create modules/org/eclipse/persistence/impl/main/module.xml
> modules/system/layers/base/org/eclipse/persistence/main/module.xml
> It looks like this almost works with just adding the optional dependency, except there is an exception where it looks like the classloader may not be set correctly for some reason when the module is split into 2.
> {code}
> <module name="org.eclipse.persistence" xmlns="urn:jboss:module:1.5">
> ...
> <module name="org.eclipse.persistence.impl" optional="true" services="import"/>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="org.eclipse.persistence.impl">
> <resources>
> <!-- you want this jar to be loaded from the system module as it can be packaged potentially
> <resource-root path="jipijapa-eclipselink-7.3.0.Beta-redhat-00001.jar"/>
> -->
> <resource-root path="eclipselink.jar">
> <filter>
> <exclude path="javax/**"/>
> </filter>
> </resource-root>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.annotation.api"/>
> <module name="javax.enterprise.api"/>
> <module name="javax.persistence.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.validation.api"/>
> <module name="javax.xml.bind.api"/>
> <module name="org.antlr"/>
> <module name="org.dom4j"/>
> <module name="org.jboss.as.jpa.spi"/>
> <module name="org.jboss.logging"/>
> <module name="org.jboss.vfs"/>
> <module name="org.eclipse.persistence"/> <!-- to see jipijapa-eclipse-link if necessary -->
> </dependencies>
> </module>
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Object: com.jboss.examples.jpa.model.User@4fbcb157 is not a known Entity type.
> at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4326)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:596)
> at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:580)
> at com.jboss.examples.jpa.TestSingleton.test(TestSingleton.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:126)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:112)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:112)
> {code}
> [1] https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months