[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza edited comment on WFLY-14284 at 1/21/21 7:30 AM:
---------------------------------------------------------------------------
Yesterday I did one more test on this scenario (on Wildfly 18.0.1 too) in order to try to understand what is the root cause of this problem.
After change de log category of "com.arjuna" to INFO I get some more detail I would share with you. It is on atchment [^server(transaction).log]
I would like know wich kind of authentication following trace refers? Maybe could be the cause of server doesn't stops.
{code:java}
23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed at org.wildfly.http-client.transaction@1.0.16.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:210) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:206) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)Caused by: java.lang.SecurityException: WFHTTP000008: Authentication failed at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$0(HttpTargetContext.java:196) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:134) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$1(HttpTargetContext.java:191) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1145) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:201) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348) at java.base/java.lang.Thread.run(Thread.java:834)
{code}
was (Author: JIRAUSER147207):
Yesterday I did one more test on this scenario in order to try to understand what is the root cause of this problem.
After change de log category of "com.arjuna" to INFO I get some more detail I would share with you. It is on atchment [^server(transaction).log]
I would like know wich kind of authentication following trace refers? Maybe could be the cause of server doesn't stops.
{code:java}
23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed at org.wildfly.http-client.transaction@1.0.16.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:210) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:206) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)Caused by: java.lang.SecurityException: WFHTTP000008: Authentication failed at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$0(HttpTargetContext.java:196) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:134) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$1(HttpTargetContext.java:191) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1145) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:201) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348) at java.base/java.lang.Thread.run(Thread.java:834)
{code}
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza updated WFLY-14284:
---------------------------------------------
Affects Version/s: 18.0.1.Final
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza updated WFLY-14284:
---------------------------------------------
Attachment: ejb-configs.sh
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
If could help too I attatched some related configurations with [^ejb-configs.sh]
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
Yesterday I did one more test on this scenario in order to try to understand what is the root cause of this problem.
After change de log category of "com.arjuna" to INFO I get some more detail I would share with you. It is on atchment [^server(transaction).log]
I would like know wich kind of authentication following trace refers? Maybe could be the cause of server doesn't stops.
{code:java}
23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed23:58:03,985 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed at org.wildfly.http-client.transaction@1.0.16.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:210) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:206) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)Caused by: java.lang.SecurityException: WFHTTP000008: Authentication failed at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$0(HttpTargetContext.java:196) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:134) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$1(HttpTargetContext.java:191) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1145) at org.jboss.xnio@3.7.3.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125) at org.wildfly.http-client.common@1.0.16.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:201) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348) at java.base/java.lang.Thread.run(Thread.java:834)
{code}
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza updated WFLY-14284:
---------------------------------------------
Attachment: server(transaction).log
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14302) WARN java.lang.NoClassDefFoundError: Failed to link javax/servlet/jsp/tagext/TagSupport
by Josep Jiménez (Jira)
[ https://issues.redhat.com/browse/WFLY-14302?page=com.atlassian.jira.plugi... ]
Josep Jiménez commented on WFLY-14302:
--------------------------------------
Hi Richard,
This issue is about the environment. I have checked demo project on Linux Centos 8 an JDK 11 open source and it's running correctly.
When we have tried to run app, the compiling source was 59.0 and the execution environment was 57.0. The error was "NoClassDefFoundError", but problem was version actually.
Thanks
> WARN java.lang.NoClassDefFoundError: Failed to link javax/servlet/jsp/tagext/TagSupport
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-14302
> URL: https://issues.redhat.com/browse/WFLY-14302
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 22.0.0.Final
> Reporter: Josep Jiménez
> Assignee: Richard Opalka
> Priority: Major
> Attachments: demo.zip, page1.png, page2.png, screeenshot-2.png, screenshot-1.png, server.log
>
>
> Over V16 and V21 the same project run correctly.
> The project uses javax.servlet.jsp.tagext.TagSupport
> During the deploiment shows this WARN the same times number of TagLib are defined on two tld's files of project.
> 11:52:58,637 WARN [org.jboss.modules.define] (MSC service thread 1-8) Failed to define class webui.tags.framework.BPlanSelector in Module "deployment.Awebpfcw2-1.0.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link webui/tags/framework/BPlanSelector (Module "deployment.Awebpfcw2-1.0.war" from Service Module Loader): javax/servlet/jsp/tagext/TagSupport11:52:58,637 WARN [org.jboss.modules.define] (MSC service thread 1-8) Failed to define class webui.tags.framework.BPlanSelector in Module "deployment.Awebpfcw2-1.0.war" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link webui/tags/framework/BPlanSelector (Module "deployment.Awebpfcw2-1.0.war" from Service Module Loader): javax/servlet/jsp/tagext/TagSupport at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1095) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126) at org.jboss.modules.Module.loadModuleClass(Module.java:753) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:468) at org.jboss.as.ee@22.0.0.Final//org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:21) at org.jboss.as.ee@22.0.0.Final//org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:14) at org.jboss.as.ee@22.0.0.Final//org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:84) at org.jboss.as.ee@22.0.0.Final//org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77) at org.jboss.as.server@14.0.0.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182) at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.base/java.lang.Thread.run(Thread.java:832)
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14287) NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable
by Radoslav Ivanov (Jira)
[ https://issues.redhat.com/browse/WFLY-14287?page=com.atlassian.jira.plugi... ]
Radoslav Ivanov edited comment on WFLY-14287 at 1/20/21 11:26 PM:
------------------------------------------------------------------
[~brian.stansberry], thanks for the reply and detailed explanation. I pretty well understand those about foodprint, independence, compatibility, etc. So I will understand if you reject changes.
Anyway, I would like to share some food for thought in a scenario and hopefully we can find a solution for it in the future. Let say we have a critical CVE (CVE-2020-28052 in bouncycastle). It is tricky to update the duplicate module only and not the private one for no newer WildFly (WF) reasons, esp. if there is a security exposure for sure. Furthermore, sometimes, for security reasons WF users may take the risk to depend on only one private module so they can update it (after some regression testing) instead of running on private vulnerable along with another updated version of bouncycastle.
was (Author: rady66):
[~brian.stansberry], thanks for the reply and detailed explanation. I pretty well understand those about foodprint, independence, compatibility, etc. So I will understand if you reject changes.
Anyway, I would like to share some food for thought in a scenario and hopefully we can find a solution for it in the future. Let say we have a critical CVE (CVE-2020-28052 in bouncycastle). It is tricky to update the duplicate module only and not the private one for no newer WildFly (WF) reasons, esp. if there is a security exposure for sure. Furthermore, sometimes, for security reasons WF users may take the risk to depend on a private module and update it (after some regression testing) instead of running on vulnerable along with another updated version of bouncycastle.
> NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14287
> URL: https://issues.redhat.com/browse/WFLY-14287
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 21.0.1.Final
> Reporter: Radoslav Ivanov
> Assignee: Sudeshna Sur
> Priority: Major
>
> Could you please add missing dependencies in Bouncycastle modules?
> Problem (we got):
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList (Module "org.bouncycastle.bcpg" version 1.66.00.0 from local module loader @1d1f7216 (finder: local module finder @423e4cbb (roots: /data/avoka/transact/manager/server/modules,/data/avoka/transact/manager/server/modules/system/layers/base))): org/bouncycastle/util/Iterable
> {code}
>
> Solution (adding dependency from bcpg to bcprov modules solves the issue):
> {code:java}
> modules\system\layers\base\org\bouncycastle\bcpg\main\module.xml{code}
> {code:java}
> <dependencies>
> <module name="org.bouncycastle.bcprov" export="true" services="export"/>
> </dependencies>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14287) NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable
by Radoslav Ivanov (Jira)
[ https://issues.redhat.com/browse/WFLY-14287?page=com.atlassian.jira.plugi... ]
Radoslav Ivanov edited comment on WFLY-14287 at 1/20/21 11:24 PM:
------------------------------------------------------------------
[~brian.stansberry], thanks for the reply and detailed explanation. I pretty well understand those about foodprint, independence, compatibility, etc. So I will understand if you reject changes.
Anyway, I would like to share some food for thought in a scenario and hopefully we can find a solution for it in the future. Let say we have a critical CVE (CVE-2020-28052 in bouncycastle). It is tricky to update the duplicate module only and not the private one for no newer WildFly (WF) reasons, esp. if there is a security exposure for sure. Furthermore, sometimes, for security reasons WF users may take the risk to depend on a private module and update it (after some regression testing) instead of running on vulnerable along with another updated version of bouncycastle.
was (Author: rady66):
[~brian.stansberry], thanks for the reply and detailed explanation. I pretty well understand those about foodprint, independence, compatibility, etc. So I will understand if you reject changes.
Anyway, I would like to share some food for thought in a scenario and hopefully we can find a solution for it in the future. Let say we have a critical CVE (CVE-2020-28052 in bouncycastle). It is tricky to update the duplicate module only and not the private one for no newer WildFly (WF) reasons. Sometimes, for security reasons WF users may take the risk to depend on a private module and update it (after some regression testing) instead of running on vulnerable along with another updated version of bouncycastle.
> NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14287
> URL: https://issues.redhat.com/browse/WFLY-14287
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 21.0.1.Final
> Reporter: Radoslav Ivanov
> Assignee: Sudeshna Sur
> Priority: Major
>
> Could you please add missing dependencies in Bouncycastle modules?
> Problem (we got):
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList (Module "org.bouncycastle.bcpg" version 1.66.00.0 from local module loader @1d1f7216 (finder: local module finder @423e4cbb (roots: /data/avoka/transact/manager/server/modules,/data/avoka/transact/manager/server/modules/system/layers/base))): org/bouncycastle/util/Iterable
> {code}
>
> Solution (adding dependency from bcpg to bcprov modules solves the issue):
> {code:java}
> modules\system\layers\base\org\bouncycastle\bcpg\main\module.xml{code}
> {code:java}
> <dependencies>
> <module name="org.bouncycastle.bcprov" export="true" services="export"/>
> </dependencies>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months