[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFLY-5966:
-------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
The following modules were fixed or verified as correct (moved from the first list):
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
The following modules were fixed or verified as correct (moved from the first list):
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> The following modules were fixed or verified as correct (moved from the first list):
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11468) EE Security SecurityContext impl without JACC
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-11468:
---------------------------------------
Summary: EE Security SecurityContext impl without JACC
Key: WFLY-11468
URL: https://issues.jboss.org/browse/WFLY-11468
Project: WildFly
Issue Type: Feature Request
Components: Security
Reporter: Darran Lofthouse
The default SecurityContext implementation from Soteria makes use of JACC to obtain the current authenticated identity, this means we need to have an active JACC policy.
A SecurityContext implementation that does not require JACC could be useful.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2316:
--------------------------------
This is bad IMO for multiple reasons:
* I do *not* want to define the ports in multiple locations; the authoritative location for JGroups ports is the JGroups config file. Having to define the same port in multiple files is error-prone and unmaintainable
* A lot of protocols (UDP/TCP, FD_SOCK, STATE_SOCK) do *not* define a static port; the default is 0, which means the OS picks an ephemeral port.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------
In short, this should never happen in Kubernetes.
In my opinion, things like {{FD_SOCK.bind_port=0}} should never be set in containers. In vast majority of the cases, you don't need dynamic ports since with a "Bridged" network setup (which is the default in Kubernetes), you can have multiple containers exposing the same port. The only exception from this rule is a setup with "Host" network setting. In that case, the port clash may occur. However, in most of the cases (Tectonic, OpenShift Online etc), you can not use it.
So just to recap, the "blessed" setup is this:
* You assign a static port for JGroups. It can be anything you want since multiple container can use the same port.
* The next step is to {{EXPOSE}} it in your Dockerfile.
* Finally, you create a Service, which basically exposes a port specified in a Dockerfile for the consumption inside a Kubernetes cluster.
Just to give you an example based on your snippet, a DNS {{SRV}} could look like this (I'm handcrafting this based on a snippet from my previous comment):
{code}
$ dig jgroups.dev.auth.example.com.svc.cluster.local SRV
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.example.com.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16690
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;jgroups.dev.auth.example.com.svc.cluster.local. IN SRV
;; ANSWER SECTION:
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 8888 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.example.com.svc.cluster.local.
;; Query time: 2 msec
;; SERVER: 10.42.3.2#53(10.42.3.2)
;; WHEN: Fri Sep 21 01:45:44 2018
;; MSG SIZE rcvd: 481
{code}
The key point to notice is that all ports are {{8888}}.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11387) IllegalStateException when calling MetricsContextService.stop during shutdown sequence
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11387?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-11387:
---------------------------------------
[~jmesnil] I can still see the issue in latest Wildfly master. It already contain fix - https://github.com/wildfly/wildfly/pull/11873
I've added steps to reproduce. Re-opening.
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11387
> URL: https://issues.jboss.org/browse/WFLY-11387
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 15.0.0.Beta1
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 15.0.0.Final
>
>
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> This doesn't happen regularly, it happened to me like once from 5 shutdowns. I saw the warning 3 times today.
> "not happening always" is because of parallelism in shutdown/boot of WF/EAP
> I did slight misconfiguration on purpose, but not sure if it's related or not
> {code}
> /subsystem=microprofile-metrics-smallrye/:write-attribute(name=exposed-subsystems, value=["batch_jberet"])
> {code}
> Stacktrace is this:
> {code}
> 09:53:23,883 WARN [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000004: Failure during stop of service jboss.extension.metrics.context: java.lang.IllegalStateException
> at org.jboss.as.domain-http-interface@7.0.0.Beta1//org.jboss.as.domain.http.server.ManagementHttpServer.removeContext(ManagementHttpServer.java:234)
> at org.jboss.as.server@7.0.0.Beta1//org.jboss.as.server.mgmt.UndertowHttpManagementService$1.removeContext(UndertowHttpManagementService.java:144)
> at org.wildfly.extension.microprofile.metrics-smallrye@15.0.0.CR1-SNAPSHOT//org.wildfly.extension.microprofile.metrics.MetricsContextService.stop(MetricsContextService.java:131)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1794)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1763)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11387) IllegalStateException when calling MetricsContextService.stop during shutdown sequence
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11387?page=com.atlassian.jira.plugin... ]
Miroslav Novak reopened WFLY-11387:
-----------------------------------
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11387
> URL: https://issues.jboss.org/browse/WFLY-11387
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 15.0.0.Beta1
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 15.0.0.Final
>
>
> IllegalStateException when calling MetricsContextService.stop during shutdown sequence
> This doesn't happen regularly, it happened to me like once from 5 shutdowns. I saw the warning 3 times today.
> "not happening always" is because of parallelism in shutdown/boot of WF/EAP
> I did slight misconfiguration on purpose, but not sure if it's related or not
> {code}
> /subsystem=microprofile-metrics-smallrye/:write-attribute(name=exposed-subsystems, value=["batch_jberet"])
> {code}
> Stacktrace is this:
> {code}
> 09:53:23,883 WARN [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000004: Failure during stop of service jboss.extension.metrics.context: java.lang.IllegalStateException
> at org.jboss.as.domain-http-interface@7.0.0.Beta1//org.jboss.as.domain.http.server.ManagementHttpServer.removeContext(ManagementHttpServer.java:234)
> at org.jboss.as.server@7.0.0.Beta1//org.jboss.as.server.mgmt.UndertowHttpManagementService$1.removeContext(UndertowHttpManagementService.java:144)
> at org.wildfly.extension.microprofile.metrics-smallrye@15.0.0.CR1-SNAPSHOT//org.wildfly.extension.microprofile.metrics.MetricsContextService.stop(MetricsContextService.java:131)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1794)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1763)
> at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months