[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated REMJMX-166:
--------------------------------
Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/43, https://github.com/jbossas/remoting-jmx/pull/42
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: REMJMX-160.jar, REMJMX-166.jar
>
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated REMJMX-166:
--------------------------------
Attachment: REMJMX-166.jar
REMJMX-160.jar
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: REMJMX-160.jar, REMJMX-166.jar
>
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5113) Do not compile exec model classes in RAM
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5113?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5113:
---------------------------------
Description:
Currently executable model classes are compiled in RAM
at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
was:
Currently executable model classes are compiled in RAM
at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Do not compile exec model classes in RAM
> ----------------------------------------
>
> Key: DROOLS-5113
> URL: https://issues.redhat.com/browse/DROOLS-5113
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently executable model classes are compiled in RAM
> at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
> This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
> mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
> Probably we could start bringing the benchmark code into Drools so that we can debug it with idea (in JMH you can't) with the OpenJDK source code attached
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5113) Do not compile exec model classes in RAM
by Luca Molteni (Jira)
Luca Molteni created DROOLS-5113:
------------------------------------
Summary: Do not compile exec model classes in RAM
Key: DROOLS-5113
URL: https://issues.redhat.com/browse/DROOLS-5113
Project: Drools
Issue Type: Enhancement
Components: executable model
Reporter: Luca Molteni
Assignee: Luca Molteni
Currently executable model classes are compiled in RAM
at org.drools.compiler.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
at org.drools.modelcompiler.builder.CanonicalModelKieProject.writeProjectOutput(CanonicalModelKieProject.java:81)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:285)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:247)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:204)
This kie-benchmark fails when running with 10000 rules with the exec model and the lambda externalization activated
mvn clean install -DskipTests=true && java -jar ./target/drools-benchmarks.jar -jvmArgs "-Xms10000m -Xmx10000m -Ddrools.externaliseCanonicalModelLambda=true -XX:+UseG1GC -XX:MetaspaceSize=1000m -XX:MaxMetaspaceSize=1000m -XX:+PrintGCDetails -Xloggc:/tmp/g1-dedup-metaspace4-maxpause.log" -foe true -rf csv -rff results.csv org.drools.benchmarks.turtle.buildtime.BuildKieBaseFromContainerBenchmark
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5056) [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5056?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5056:
-----------------------------------
Sprint: 2020 Week 07-09 (from Feb 10)
> [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned
> -------------------------------------------------------------------------------
>
> Key: DROOLS-5056
> URL: https://issues.redhat.com/browse/DROOLS-5056
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: issue.mp4, taxRate.dmn
>
>
> Sometimes the nodes inside the Decision Service are positioned outside from the Decision Service when the .DMN is saved an open again.
> I was unable to map exact when this happen, but I noticed that this happens depending on the changes you do in the position and size of the Decision Service and its inner nodes.
> I recorded a video with 2 minutes when the issue happens in the last seconds.
> As it can be notice it takes lots of trials to reproduce the issue.
> Also I was unable to reproduce the issue in the Business Central, so I'm not sure if it is related to DMN Editor in VS Code or DMN Editor itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by David Lloyd (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
David Lloyd commented on REMJMX-166:
------------------------------------
The problematic change was this line:
{code:java}
+ group.setDaemon(true);
{code}
This causes the effect described in the bug. The fix is to delete this line.
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13173) Some layers have dependency on unsecure management
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-13173:
-------------------------------------------
Summary: Some layers have dependency on unsecure management
Key: WFLY-13173
URL: https://issues.redhat.com/browse/WFLY-13173
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
The layers defined in servlet/ee/wildfly galleon feature-packs should depend on secure-management instead of management.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13172) health-microprofile layer
by Jean Francois Denise (Jira)
Jean Francois Denise created WFLY-13172:
-------------------------------------------
Summary: health-microprofile layer
Key: WFLY-13172
URL: https://issues.redhat.com/browse/WFLY-13172
Project: WildFly
Issue Type: Enhancement
Components: Build System
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
The only way to provision an health feature is to provision observability. Having a dedicated health layer would align with other microservice layers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Ronald Sigal commented on WFLY-11566:
-------------------------------------
Hi everyone,
Sorry for the delay. Looking at the definitions of ElementType and ConstraintLocationKind, I see that they seem to be very similar, though not exactly the same.
The point of all of that code in SimpleViolationsContainer.compareConstraintViolation() was to verify that two ConstraintViolations were the same. I don't remember offhand why I had to do all of that field by field, but apparently I did. All I can say from the RESTEasy perspective is that if the two tests - getElementType() and getConstraintLocationKind() - are the same and interchangeable, then I don't think there is a problem.
-Ron
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months