[JBoss JIRA] (DROOLS-3515) [DMN Designer] Validation: Validate button should compile the DMN file and report issues
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3515?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3515:
-----------------------------------
Sprint: 2019 Week 23-25
> [DMN Designer] Validation: Validate button should compile the DMN file and report issues
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-3515
> URL: https://issues.jboss.org/browse/DROOLS-3515
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Thomas Mantegazzi
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: image-2019-01-14-09-24-07-415.png, image-2019-01-14-09-25-01-777.png, image-2019-01-14-09-25-16-907.png
>
>
> The "validate" button at the top does nit seem to be validating feel expressions:
> !image-2019-01-14-09-24-07-415.png|thumbnail!
> The input of this Decision is a "person" object:
> !image-2019-01-14-09-25-01-777.png|thumbnail!
> and this is the DRG:
> !image-2019-01-14-09-25-16-907.png|thumbnail!
> The validation should say that this literal expression is not valid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4160) Enable DRL codegen by default, rename config properties
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4160?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-4160:
-----------------------------------
Description:
enable model generation by default.
contextually rename properties as follows:
- `kogito.codegen.rules` : boolean -- enable codegen for rules. Defaults to null, meaning that codegen is enabled iff DRLs are found
- `kogito.codegen.processes` : boolean -- enable codegen for processes. Defaults to null, meaning that codegen is enabled iff BPMNs are founds
- `kogito.sources.keep` : boolean -- keep DRL files in the generated artifact. Defaults to false.
- `kogito.di.enabled` : boolean -- generate dependency injection annotation. Defaults to true.
was:
enable model generation by default.
contextually rename properties as follows:
{code}
@Parameter(property = "kogito.codegen.rules", defaultValue = "null") // defaults to true iff DRLs are present
private Boolean generateRules;
@Parameter(property = "kogito.codegen.processes", defaultValue = "null") // defaults to true iff BPMN are present
private Boolean generateProcesses;
@Parameter(property = "kogito.sources.keep", defaultValue = "false") // substitutes generateModel=WITHDRL
private boolean keepSources;
@Parameter(property = "kogito.di.enabled", defaultValue = "true")
private boolean dependencyInjection;
{code}
> Enable DRL codegen by default, rename config properties
> -------------------------------------------------------
>
> Key: DROOLS-4160
> URL: https://issues.jboss.org/browse/DROOLS-4160
> Project: Drools
> Issue Type: Task
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core, kogito, submarine
> Fix For: 8.0.0.Final
>
>
> enable model generation by default.
> contextually rename properties as follows:
> - `kogito.codegen.rules` : boolean -- enable codegen for rules. Defaults to null, meaning that codegen is enabled iff DRLs are found
> - `kogito.codegen.processes` : boolean -- enable codegen for processes. Defaults to null, meaning that codegen is enabled iff BPMNs are founds
> - `kogito.sources.keep` : boolean -- keep DRL files in the generated artifact. Defaults to false.
> - `kogito.di.enabled` : boolean -- generate dependency injection annotation. Defaults to true.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4519) Slave Host Controller deployment repository is cleaned after a full deployment replacement
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4519?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-4519:
---------------------------------
Description:
In domain mode, there is a cleanup task that removes obsolete content from the deployment repository of each process (DC, slave HC, and servers). By default, this task is executed every five minutes.
The task checks if there is any content to be marked as obsolete, if there is, it is marked and deleted on the next task execution.
Deployment content is considerate obsolete in a slave HC if there are no references to it, that means if there is no server group that has this deployment configured.
The issue here is the deployment handler that replaces the deployment content in a slave is not adding a reference to the new content if there are affected server groups.
The consequence is the cleanup task could delete the slave HC content. If this occurs when the servers are starting, the servers could fail to start with the following error:
{noformat}
2019-06-12 08:51:32,813 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "test-application.war")]) - failure description: "WFLYSRV0137: No deployment content with hash b1fb3b872b3490bbdbd152bd082791b1f170397d is available in the deployment content repository for deployment 'test-application.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
2019-06-12 08:51:32,817 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
2019-06-12 08:51:32,833 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 17.0.0.Final-SNAPSHOT (WildFly Core 9.0.1.Final-SNAPSHOT) stopped in 5ms
{noformat}
The issue is difficult to hit because it is the server who requests the required files to the slave HC. In order to reproduce it, there must be a coincidence when the server has requested a deployment file to its HC, the HC already has this file in its deployment repository marked as obsolete and, before send it to the server, the cleanup task removes it.
was:
In domain mode, there is a cleanup task that removes obsolete content from the deployment repository of each process (DC, slave HC, and servers). By default, this task is executed every five minutes.
The task checks if there is any content to be marked as obsolete, if there is, it is marked and deleted on the next task execution.
Deployment content is considerate obsolete in a slave HC if there are no references to it, that means if there is no server group that has this deployment configured.
The issue here is the deployment handler that replaces the deployment content in a slave is not adding a reference to the new content if there are affected server groups.
The consequence is the cleanup task could delete the slave HC content. If this occurs when the servers are starting, the servers could fail to start with the following error:
{noformat}
019-06-12 08:51:32,813 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "test-application.war")]) - failure description: "WFLYSRV0137: No deployment content with hash b1fb3b872b3490bbdbd152bd082791b1f170397d is available in the deployment content repository for deployment 'test-application.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
2019-06-12 08:51:32,817 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
2019-06-12 08:51:32,833 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 17.0.0.Final-SNAPSHOT (WildFly Core 9.0.1.Final-SNAPSHOT) stopped in 5ms
{noformat}
The issue is difficult to hit because it is the server who requests the required files to the slave HC. In order to reproduce it, there must be a coincidence when the server has requested a deployment file to its HC, the HC already has this file in its deployment repository marked as obsolete and, before send it to the server, the cleanup task removes it.
> Slave Host Controller deployment repository is cleaned after a full deployment replacement
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-4519
> URL: https://issues.jboss.org/browse/WFCORE-4519
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 9.0.1.Final
> Environment: Domain mode, slave HC with deployments in its server groups
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> In domain mode, there is a cleanup task that removes obsolete content from the deployment repository of each process (DC, slave HC, and servers). By default, this task is executed every five minutes.
> The task checks if there is any content to be marked as obsolete, if there is, it is marked and deleted on the next task execution.
> Deployment content is considerate obsolete in a slave HC if there are no references to it, that means if there is no server group that has this deployment configured.
> The issue here is the deployment handler that replaces the deployment content in a slave is not adding a reference to the new content if there are affected server groups.
> The consequence is the cleanup task could delete the slave HC content. If this occurs when the servers are starting, the servers could fail to start with the following error:
> {noformat}
> 2019-06-12 08:51:32,813 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "test-application.war")]) - failure description: "WFLYSRV0137: No deployment content with hash b1fb3b872b3490bbdbd152bd082791b1f170397d is available in the deployment content repository for deployment 'test-application.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 2019-06-12 08:51:32,817 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 2019-06-12 08:51:32,833 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Full 17.0.0.Final-SNAPSHOT (WildFly Core 9.0.1.Final-SNAPSHOT) stopped in 5ms
> {noformat}
> The issue is difficult to hit because it is the server who requests the required files to the slave HC. In order to reproduce it, there must be a coincidence when the server has requested a deployment file to its HC, the HC already has this file in its deployment repository marked as obsolete and, before send it to the server, the cleanup task removes it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4155) [DMN Designer] Placeholder doesn't fit a column
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4155?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4155:
--------------------------------
Description:
If user included a *PMML* model into a DMN diagram, then he has possibility to define PMML function invocation. Grid for such invocation contains placeholders saying that document and model needs to be specified. The issue is placeholders doesn't column width and thus are not readable. See the attached picture.
h3. Acceptance test
- Function column width, resizeable (/)
- Change Expression type to Function (/)
- Change Function Type (FEEL / JAVA / PMML) (/)
- Undo function column width resize (/)
- Decision > Context > Function column width, resizeable (/)
- BKM > Function column width, resizeable (x) DROOLS-4165
was:
If user included a *PMML* model into a DMN diagram, then he has possibility to define PMML function invocation. Grid for such invocation contains placeholders saying that document and model needs to be specified. The issue is placeholders doesn't column width and thus are not readable. See the attached picture.
h3. Acceptance test
- Function column width, resizeable (/)
- Change Expression type to Function (/)
- Change Function Type (FEEL / JAVA / PMML) (/)
- Undo function column width resize (/)
- Decision > Context > Function column width, resizeable (/)
- BKM > Function column width, resizeable (x)
> [DMN Designer] Placeholder doesn't fit a column
> -----------------------------------------------
>
> Key: DROOLS-4155
> URL: https://issues.jboss.org/browse/DROOLS-4155
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: bkm-function-width.webm, placeholder.png
>
>
> If user included a *PMML* model into a DMN diagram, then he has possibility to define PMML function invocation. Grid for such invocation contains placeholders saying that document and model needs to be specified. The issue is placeholders doesn't column width and thus are not readable. See the attached picture.
> h3. Acceptance test
> - Function column width, resizeable (/)
> - Change Expression type to Function (/)
> - Change Function Type (FEEL / JAVA / PMML) (/)
> - Undo function column width resize (/)
> - Decision > Context > Function column width, resizeable (/)
> - BKM > Function column width, resizeable (x) DROOLS-4165
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-4165) [DMN Designer] BKM Function column width
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4165:
-----------------------------------
Summary: [DMN Designer] BKM Function column width
Key: DROOLS-4165
URL: https://issues.jboss.org/browse/DROOLS-4165
Project: Drools
Issue Type: Bug
Components: DMN Editor
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: bkm-function-width.webm
BKM Function column width is not preserved between reopening the DMN diagram. For more details see the attached video.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
[~mkopecky] thanks.
This issue is apparently more complex (WELD-2584 ) so I assume that the work/discussion would move there for now.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/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
> 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.12.1#712002)
7 years, 1 month