[JBoss JIRA] (WFWIP-355) Bootable JAR - scripts in bin folder of the server installation directory are not executable
by Tommaso Borgato (Jira)
[ https://issues.redhat.com/browse/WFWIP-355?page=com.atlassian.jira.plugin... ]
Tommaso Borgato commented on WFWIP-355:
---------------------------------------
[~dlofthouse], [~jdenise] I verified the bug is fixed:
{noformat}
$ ls -ltr /tmp/wildfly-bootable-server17387426269613352428/bin
total 2440
-rw-rw-r--. 1 tborgato tborgato 2269 Sep 15 11:50 vault.bat
-rwxrwxr-x. 1 tborgato tborgato 13022 Sep 15 11:50 standalone.sh
-rw-rw-r--. 1 tborgato tborgato 913 Sep 15 11:50 jboss-cli.ps1
-rwxrwxr-x. 1 tborgato tborgato 792 Sep 15 11:50 common.sh
-rw-rw-r--. 1 tborgato tborgato 2417 Sep 15 11:50 add-user.bat
-rw-rw-r--. 1 tborgato tborgato 1854 Sep 15 11:50 standalone.ps1
-rw-rw-r--. 1 tborgato tborgato 3594 Sep 15 11:50 standalone.conf.ps1
-rw-rw-r--. 1 tborgato tborgato 3244 Sep 15 11:50 standalone.conf
-rw-rw-r--. 1 tborgato tborgato 9947 Sep 15 11:50 standalone.bat
-rwxrwxr-x. 1 tborgato tborgato 2635 Sep 15 11:50 jboss-cli.sh
-rw-rw-r--. 1 tborgato tborgato 1933 Sep 15 11:50 jboss-cli-logging.properties
-rw-rw-r--. 1 tborgato tborgato 3271 Sep 15 11:50 jboss-cli.bat
-rw-rw-r--. 1 tborgato tborgato 1108 Sep 15 11:50 elytron-tool.ps1
-rw-rw-r--. 1 tborgato tborgato 11549 Sep 15 11:50 common.ps1
-rw-rw-r--. 1 tborgato tborgato 1095 Sep 15 11:50 add-user.ps1
-rw-rw-r--. 1 tborgato tborgato 2444 Sep 15 11:50 add-user.properties
-rw-rw-r--. 1 tborgato tborgato 2311512 Sep 15 11:50 wildfly-elytron-tool.jar
-rw-rw-r--. 1 tborgato tborgato 725 Sep 15 11:50 vault.ps1
-rw-rw-r--. 1 tborgato tborgato 3699 Sep 15 11:50 standalone.conf.bat
-rw-rw-r--. 1 tborgato tborgato 49 Sep 15 11:50 product.conf
-rw-rw-r--. 1 tborgato tborgato 3035 Sep 15 11:50 jboss-cli.xml
-rw-rw-r--. 1 tborgato tborgato 1710 Sep 15 11:50 elytron-tool.bat
-rw-rw-r--. 1 tborgato tborgato 823 Sep 15 11:50 common.bat
-rwxrwxr-x. 1 tborgato tborgato 2392 Sep 15 11:50 add-user.sh
-rwxrwxr-x. 1 tborgato tborgato 2362 Sep 15 11:50 vault.sh
-rw-rw-r--. 1 tborgato tborgato 50513 Sep 15 11:50 launcher.jar
{noformat}
> Bootable JAR - scripts in bin folder of the server installation directory are not executable
> --------------------------------------------------------------------------------------------
>
> Key: WFWIP-355
> URL: https://issues.redhat.com/browse/WFWIP-355
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Tommaso Borgato
> Assignee: Jean Francois Denise
> Priority: Major
>
> Related RFE: EAP7-1385
> Scripts in the bin folder of the server's installation directory are not executable;
> If you start the server like the following:
> {noformat}
> java -jar target/default-hollow-jar-bootable.jar --install-dir=/tmp/wildfly-bootable-server-hollow-jar
> {noformat}
> and the look into the bin folder:
> {noformat}
> $ ls -ltr /tmp/wildfly-bootable-server-hollow-jar/bin
> total 1520
> -rw-rw-r--. 1 hudson hudson 2362 Sep 11 10:11 vault.sh
> -rw-rw-r--. 1 hudson hudson 709 Sep 11 10:11 vault.ps1
> -rw-rw-r--. 1 hudson hudson 2269 Sep 11 10:11 vault.bat
> -rw-rw-r--. 1 hudson hudson 823 Sep 11 10:11 common.bat
> -rw-rw-r--. 1 hudson hudson 1933 Sep 11 10:11 jboss-cli-logging.properties
> -rw-rw-r--. 1 hudson hudson 3271 Sep 11 10:11 jboss-cli.bat
> -rw-rw-r--. 1 hudson hudson 792 Sep 11 10:11 common.sh
> -rw-rw-r--. 1 hudson hudson 11549 Sep 11 10:11 common.ps1
> -rw-rw-r--. 1 hudson hudson 893 Sep 11 10:11 jboss-cli.ps1
> -rw-rw-r--. 1 hudson hudson 1793 Sep 11 10:11 elytron-tool.sh
> -rw-rw-r--. 1 hudson hudson 1079 Sep 11 10:11 elytron-tool.ps1
> -rw-rw-r--. 1 hudson hudson 1710 Sep 11 10:11 elytron-tool.bat
> -rw-rw-r--. 1 hudson hudson 2392 Sep 11 10:11 add-user.sh
> -rw-rw-r--. 1 hudson hudson 3035 Sep 11 10:11 jboss-cli.xml
> -rw-rw-r--. 1 hudson hudson 2635 Sep 11 10:11 jboss-cli.sh
> -rw-rw-r--. 1 hudson hudson 1069 Sep 11 10:11 add-user.ps1
> -rw-rw-r--. 1 hudson hudson 2444 Sep 11 10:11 add-user.properties
> -rw-rw-r--. 1 hudson hudson 2417 Sep 11 10:11 add-user.bat
> -rw-rw-r--. 1 hudson hudson 12843 Sep 11 10:11 standalone.sh
> -rw-rw-r--. 1 hudson hudson 1624 Sep 11 10:11 standalone.ps1
> -rw-rw-r--. 1 hudson hudson 3226 Sep 11 10:11 standalone.conf.ps1
> -rw-rw-r--. 1 hudson hudson 3402 Sep 11 10:11 standalone.conf.bat
> -rw-rw-r--. 1 hudson hudson 2965 Sep 11 10:11 standalone.conf
> -rw-rw-r--. 1 hudson hudson 9576 Sep 11 10:11 standalone.bat
> -rw-rw-r--. 1 hudson hudson 49 Sep 11 10:11 product.conf
> -rw-rw-r--. 1 hudson hudson 49721 Sep 11 10:11 launcher.jar
> -rw-rw-r--. 1 hudson hudson 1369074 Sep 11 10:11 wildfly-elytron-tool.jar
> {noformat}
> you can see e.g. jboss-cli.sh is not executable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-356) Operations :check (-live, -ready) not present in embedded and admin-only mode
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFWIP-356?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFWIP-356:
-----------------------------------
This is not a bug.
check, check-live and check-ready are runtime operations and are not present in admin-only mode
{code}
[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:read-operation-description(name=check)
{
"outcome" => "success",
"result" => {
"operation-name" => "check",
"description" => "Check both the liveness and readiness of the application server and its deployments",
"request-properties" => {},
"reply-properties" => {
"type" => OBJECT,
"value-type" => OBJECT
},
"read-only" => false,
"runtime-only" => true
}
}
{code}
When you create an embedded server, it runs in admin-only mode. that's why the operations are not available.
{code}
./bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server
[standalone@embedded /] :read-attribute(name=running-mode)
{
"outcome" => "success",
"result" => "ADMIN_ONLY"
}
{code}
> Operations :check (-live, -ready) not present in embedded and admin-only mode
> -----------------------------------------------------------------------------
>
> Key: WFWIP-356
> URL: https://issues.redhat.com/browse/WFWIP-356
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> microprofile-health-smallrye subsystem operations {{:check}}, {{check-live}}, {{check-ready}} not present in embedded or admin-only mode. Is this expected or we should move this jira to JBEAP bug?
> Admin only mode
> {code}
> :reload(admin-only = true)
> /subsystem=microprofile-health-smallrye:check
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0031: No operation named 'check' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
> "rolled-back" => true
> }
> {code}
> Embedded mode
> {code}
> ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] /subsystem=microprofile-health-smallrye:check-ready
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0031: No operation named 'check-ready' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-356) Operations :check (-live, -ready) not present in embedded and admin-only mode
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-356?page=com.atlassian.jira.plugin... ]
Martin Choma moved WFLY-13867 to WFWIP-356:
-------------------------------------------
Project: WildFly WIP (was: WildFly)
Key: WFWIP-356 (was: WFLY-13867)
Component/s: MP Health
(was: MP Health)
> Operations :check (-live, -ready) not present in embedded and admin-only mode
> -----------------------------------------------------------------------------
>
> Key: WFWIP-356
> URL: https://issues.redhat.com/browse/WFWIP-356
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> microprofile-health-smallrye subsystem operations {{:check}}, {{check-live}}, {{check-ready}} not present in embedded or admin-only mode. Is this expected or we should move this jira to JBEAP bug?
> Admin only mode
> {code}
> :reload(admin-only = true)
> /subsystem=microprofile-health-smallrye:check
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0031: No operation named 'check' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
> "rolled-back" => true
> }
> {code}
> Embedded mode
> {code}
> ./jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] /subsystem=microprofile-health-smallrye:check-ready
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0031: No operation named 'check-ready' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13867) Operations :check (-live, -ready) not present in embedded and admin-only mode
by Martin Choma (Jira)
Martin Choma created WFLY-13867:
-----------------------------------
Summary: Operations :check (-live, -ready) not present in embedded and admin-only mode
Key: WFLY-13867
URL: https://issues.redhat.com/browse/WFLY-13867
Project: WildFly
Issue Type: Bug
Components: MP Health
Reporter: Martin Choma
Assignee: Jeff Mesnil
microprofile-health-smallrye subsystem operations {{:check}}, {{check-live}}, {{check-ready}} not present in embedded or admin-only mode. Is this expected or we should move this jira to JBEAP bug?
Admin only mode
{code}
:reload(admin-only = true)
/subsystem=microprofile-health-smallrye:check
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0031: No operation named 'check' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
"rolled-back" => true
}
{code}
Embedded mode
{code}
./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server
[standalone@embedded /] /subsystem=microprofile-health-smallrye:check-ready
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0031: No operation named 'check-ready' exists at address [(\"subsystem\" => \"microprofile-health-smallrye\")]",
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13866) Several traces created in Jaeger for just one method call
by Fabio Burzigotti (Jira)
Fabio Burzigotti created WFLY-13866:
---------------------------------------
Summary: Several traces created in Jaeger for just one method call
Key: WFLY-13866
URL: https://issues.redhat.com/browse/WFLY-13866
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 21.0.0.Beta1
Reporter: Fabio Burzigotti
Assignee: Emmanuel Hugonnet
Fix For: 21.0.0.Beta1
I am migrating one opentracing/fault-tolerance test from Thorntail TS [1] and I noticed that Wildfly SNAPSHOT is behaving differently with respect to what in the subject.
The test is pretty simple, deploying a REST app which makes use of injected service which in turn leverages microprofile opentracing (via API) and fault-tolerance (via annotations). The test executes the following 2 methods in the given order:
- call {{hello}}, which is synchronous and is throwing an exception, hence failing and gets called again then ending up with the fallback. This generates 1 trace with 4 spans in Jaeger and the behavior is consistent between TT and WildFly
- call {{helloAsync}}, which is asynchronous and is throwing an exception, hence failing and getting called again (asynchronously?) then ending up with the fallback. This generates the following traces in Jaeger:
TT: 1 trace with 4 spans
WildFly: 4 separate traces , i.e. the one for the REST endpoint GET method, two for the {{helloAsync}} calls and one for the fallback.
[1]
https://github.com/rhoar-qe/thorntail-test-suite/tree/master/microprofile...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5584) Retrieving the DMNModel has failed.
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5584?page=com.atlassian.jira.plug... ]
Mario Fusco reassigned DROOLS-5584:
-----------------------------------
Assignee: Mario Fusco (was: Yeser Amer)
> Retrieving the DMNModel has failed.
> -----------------------------------
>
> Key: DROOLS-5584
> URL: https://issues.redhat.com/browse/DROOLS-5584
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.42.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Critical
> Labels: drools-wb
> Fix For: 7.44.0.Final
>
>
> following the Traffic Violation tutorial I got the error. I worked around the issue by closing all , Build the project, and try it again.
> {code:java}
> 10:35:57,461 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-7) Exception thrown: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.: org.drools.scenariosimulation.backend.util.ImpossibleToFindDMNException: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.findDMNModel(DMNSimulationUtils.java:56)
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNModel(DMNSimulationUtils.java:39)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.getDMNModel(DMNTypeServiceImpl.java:98)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.retrieveFactModelTuple(DMNTypeServiceImpl.java:62)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl$Proxy$_$$_WeldClientProxy.retrieveFactModelTuple(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.getFactModelTuple(DMNSimulationSettingsCreationStrategy.java:145)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.createSimulation(DMNSimulationSettingsCreationStrategy.java:58)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder.createSimulation(ScenarioSimulationBuilder.java:41)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl.create(ScenarioSimulationServiceImpl.java:176)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl$Proxy$_$$_WeldClientProxy.create(Unknown Source)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:65)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at deployment.business-central.war//org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at deployment.business-central.war//org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at deployment.business-central.war//org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at deployment.business-central.war//org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at deployment.business-central.war//org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websocket@2.1.0.Final//io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:173)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.1.0.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.core@2.1.0.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 10:36:12,521 ERROR [org.guvnor.common.services.backend.exceptions.ExceptionUtilities] (default task-7) Exception thrown: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.: org.drools.scenariosimulation.backend.util.ImpossibleToFindDMNException: Retrieving the DMNModel has failed. Make sure the used DMN asset does not produce any compilation errors and that the project does not contain multiple DMN assets with the same name and namespace. In addition, check if the reference to the DMN file is correct in the Settings panel. After addressing the issues, build the project again.
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.findDMNModel(DMNSimulationUtils.java:56)
> at deployment.business-central.war//org.drools.scenariosimulation.backend.util.DMNSimulationUtils.extractDMNModel(DMNSimulationUtils.java:39)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.getDMNModel(DMNTypeServiceImpl.java:98)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl.retrieveFactModelTuple(DMNTypeServiceImpl.java:62)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.DMNTypeServiceImpl$Proxy$_$$_WeldClientProxy.retrieveFactModelTuple(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.getFactModelTuple(DMNSimulationSettingsCreationStrategy.java:145)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy.createSimulation(DMNSimulationSettingsCreationStrategy.java:58)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.DMNSimulationSettingsCreationStrategy$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder.createSimulation(ScenarioSimulationBuilder.java:41)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.util.ScenarioSimulationBuilder$Proxy$_$$_WeldClientProxy.createSimulation(Unknown Source)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl.create(ScenarioSimulationServiceImpl.java:176)
> at deployment.business-central.war//org.drools.workbench.screens.scenariosimulation.backend.server.ScenarioSimulationServiceImpl$Proxy$_$$_WeldClientProxy.create(Unknown Source)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.AbstractRPCMethodCallback.invokeMethodFromMessage(AbstractRPCMethodCallback.java:65)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.ValueReplyRPCEndpointCallback.callback(ValueReplyRPCEndpointCallback.java:40)
> at deployment.business-central.war//org.jboss.errai.bus.server.io.RemoteServiceCallback.callback(RemoteServiceCallback.java:54)
> at deployment.business-central.war//org.jboss.errai.cdi.server.CDIExtensionPoints$2.callback(CDIExtensionPoints.java:448)
> at deployment.business-central.war//org.jboss.errai.bus.server.DeliveryPlan.deliver(DeliveryPlan.java:47)
> at deployment.business-central.war//org.jboss.errai.bus.server.ServerMessageBusImpl.sendGlobal(ServerMessageBusImpl.java:297)
> at deployment.business-central.war//org.jboss.errai.bus.server.SimpleDispatcher.dispatchGlobal(SimpleDispatcher.java:46)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:96)
> at deployment.business-central.war//org.jboss.errai.bus.server.service.ErraiServiceImpl.store(ErraiServiceImpl.java:113)
> at deployment.business-central.war//org.jboss.errai.bus.server.servlet.DefaultBlockingServlet.doPost(DefaultBlockingServlet.java:144)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websocket@2.1.0.Final//io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:173)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecureHeadersFilter.doFilter(SecureHeadersFilter.java:110)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at deployment.business-central.war//org.uberfire.ext.security.server.SecurityIntegrationFilter.doFilter(SecurityIntegrationFilter.java:70)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.1.0.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.1.0.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@19.1.0.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.1.0.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.1.0.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
> at io.undertow.core@2.1.0.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13865) Enable switching Galleon pack Maven coordinates for the Galleon layers used in the clustering tests
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13865?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana updated WFLY-13865:
----------------------------------------
Description:
The Galleon layer tests for clustering are using two galleon packs, one to bring in the web-clustering Galleon layer and the full Galleon pack.
This configuration is not properly testing the switching of the Galleon packs under test by the CI Jobs.
The task here is to provide this capability replacing the full one by using the Maven properties passed by the CI Job, e.g:
{code:java}
<feature-pack>
<groupId>${testsuite.ee.galleon.pack.groupId}</groupId>
<artifactId>${testsuite.ee.galleon.pack.artifactId}</artifactId>
<version>${testsuite.ee.galleon.pack.version}</version>
<inherit-configs>false</inherit-configs>
<inherit-packages>false</inherit-packages>
</feature-pack>
{code}
was:
The Galleon layers tests for clustering are using two galleon packs, the one for testing to bring in web-clustering and the full Galleon pack.
This configuration is not properly testing the switching of the Galleon packs under test by the CI Jobs.
The take here is to provide this capability replacing the full one by using the Maven properties passed by the CI Job, e.g:
{code:java}
<feature-pack>
<groupId>${testsuite.ee.galleon.pack.groupId}</groupId>
<artifactId>${testsuite.ee.galleon.pack.artifactId}</artifactId>
<version>${testsuite.ee.galleon.pack.version}</version>
<inherit-configs>false</inherit-configs>
<inherit-packages>false</inherit-packages>
</feature-pack>
{code}
> Enable switching Galleon pack Maven coordinates for the Galleon layers used in the clustering tests
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-13865
> URL: https://issues.redhat.com/browse/WFLY-13865
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The Galleon layer tests for clustering are using two galleon packs, one to bring in the web-clustering Galleon layer and the full Galleon pack.
> This configuration is not properly testing the switching of the Galleon packs under test by the CI Jobs.
> The task here is to provide this capability replacing the full one by using the Maven properties passed by the CI Job, e.g:
> {code:java}
> <feature-pack>
> <groupId>${testsuite.ee.galleon.pack.groupId}</groupId>
> <artifactId>${testsuite.ee.galleon.pack.artifactId}</artifactId>
> <version>${testsuite.ee.galleon.pack.version}</version>
> <inherit-configs>false</inherit-configs>
> <inherit-packages>false</inherit-packages>
> </feature-pack>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months