February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9771) SingletonPartitionTestCase.testSingletonService fails intermittently

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9771?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-9771: -------------------------------------- It may just be that the timeout is not sufficent > SingletonPartitionTestCase.testSingletonService fails intermittently > -------------------------------------------------------------------- > > Key: WFLY-9771 > URL: https://issues.jboss.org/browse/WFLY-9771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Stuart Douglas > Assignee: Paul Ferraro > > e.g. https://ci.wildfly.org/viewLog.html?buildId=88100&buildTypeId=WF_PullRequ... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9771) SingletonPartitionTestCase.testSingletonService fails intermittently

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-9771: ------------------------------------ Summary: SingletonPartitionTestCase.testSingletonService fails intermittently Key: WFLY-9771 URL: https://issues.jboss.org/browse/WFLY-9771 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Stuart Douglas Assignee: Paul Ferraro e.g. https://ci.wildfly.org/viewLog.html?buildId=88100&buildTypeId=WF_PullRequ... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2273) [DMN Editor] Contextual selection - Hover state

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2273?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2273: -------------------------------- QE Status: VERIFIED (was: ON_QA) > [DMN Editor] Contextual selection - Hover state > ----------------------------------------------- > > Key: DROOLS-2273 > URL: https://issues.jboss.org/browse/DROOLS-2273 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Elements within a logic table that offer contextual actions will present a hover state on focus. Examples of elements that might offer actions include: Rows, cells, columns, table… Or in context terms: Rules, Inputs/Outputs, Context row, etc -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3581) Graceful shutdown via sigterm cannot be resumed

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3581?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-3581: ------------------------------------- Well, from my understanding, the process can choose what to do if it receives SIGTERM signal and handle this properly. Thus, I think it is feasible to behave exactly the same as we behave in case graceful shutdown is performed via CLI operation. Neverthless, I don't consider this as a 'standard' situation or 'standard customer use case'. I raised this as we should try to behave consistently when it comes to the graceful shutdown. > Graceful shutdown via sigterm cannot be resumed > ----------------------------------------------- > > Key: WFCORE-3581 > URL: https://issues.jboss.org/browse/WFCORE-3581 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Jan Stourac > Assignee: Brian Stansberry > Attachments: long-running-servlet.war > > > When server is sent SIGTERM signal to perform graceful shutdown just at the moment it is crunching a long-time running request, it cannot be resumed anymore with the :resume() CLI operation. > See server output (NOTE: NPE in server log is probably caused by this WFCORE-3572.): > {code} > 17:47:30,141 INFO [org.jboss.qa.management.web.resources.HeavyProcessingServlet] (default task-1) Started request processing > 17:47:34,367 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0211: Suspending server with 10000 ms timeout. > 17:47:34,368 INFO [org.jboss.as.ejb3] (Thread-2) WFLYEJB0493: EJB subsystem suspension complete > 17:47:36,022 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0212: Resuming server > 17:47:36,023 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal > 17:47:36,034 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 70) WFLYUT0022: Unregistered web context: '/long-running-servlet' from server 'default-server' > 17:47:36,050 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 17:47:36,055 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0019: Host default-host stopping > 17:47:36,058 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 17:47:36,067 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException > at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72) > at org.xnio.XnioWorker$1.run(XnioWorker.java:138) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979) > at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755) > at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393) > at java.lang.Thread.run(Thread.java:748) > 17:47:36,070 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 69) WFLYCLINF0003: Stopped client-mappings cache from ejb container > 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow HTTPS listener https suspending > 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending > 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to 127.0.0.1:8443 > 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 > 17:47:36,087 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment long-running-servlet.war (runtime-name: long-running-servlet.war) in 61ms > 17:47:36,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0004: Undertow 1.4.22.Final stopping > {code} > This is server output in case that graceful shutdown is called via :shutdown(timeout=<time>) CLI operation: > {code} > 17:46:34,064 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container > 17:46:34,184 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: '/long-running-servlet' for server 'default-server' > 17:46:34,194 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "long-running-servlet.war" (runtime-name : "long-running-servlet.war") > 17:46:34,249 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server > 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Beta1-SNAPSHOT) started in 2915ms - Started 396 of 607 services (333 services are lazy, passive or on-demand) > 17:46:36,122 INFO [org.jboss.qa.management.web.resources.HeavyProcessingServlet] (default task-1) Started request processing > 17:46:39,998 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server with 10000 ms timeout. > 17:46:40,000 INFO [org.jboss.as.ejb3] (management-handler-thread - 1) WFLYEJB0493: EJB subsystem suspension complete > 17:46:42,197 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0212: Resuming server > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3576) deployment is not accessible in runtime when deployed with runtime-name not using .war extension

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3576?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-3576: ----------------------------------- For the existing subsystems and their DeploymentUnitProcessor, it's required. Otherwise, deployment is skipped if deployment type can't be recognized e.g. [JBossWebParsingDeploymentProcessor.java|https://github.com/wildfly/wildfl...] and [BeansXmlProcessor.java|https://github.com/wildfly/wildfly/blob/4f626b06b8...] I believe this "skip" is by design as it always gives other DeploymentUnitProcessor a chance to parse the deployment file. For any possible Extension and its own implementation of DeploymentUnitProcessor, this is not mandatory. > deployment is not accessible in runtime when deployed with runtime-name not using .war extension > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-3576 > URL: https://issues.jboss.org/browse/WFCORE-3576 > Project: WildFly Core > Issue Type: Enhancement > Components: Deployment Scanner, Domain Management > Affects Versions: 4.0.0.Alpha9 > Reporter: Jan Stourac > Assignee: Chao Wang > > According to the folowing [blog-post|https://developer.jboss.org/thread/221251], when using custom --name or --runtime-name for deployment, the file extension (.war, .jar, .ear,...) need to be included so server can distinguish type of deployment somehow. > Currently there is no such check - when I try to deploy any .war app using either web-console or CLI with my custom '\-\-runtime-name' and/or '\-\-name' without .war suffix, server does not complain anyhow: > {code} > deploy --runtime-name=alice --name=bob /tmp/eve.war > {code} > Message in server log: > {code} > 17:30:48,469 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "bob" (runtime-name: "alice") > 17:30:48,499 INFO [org.jboss.as.server] (management-handler-thread - 6) WFLYSRV0010: Deployed "bob" (runtime-name : "alice") > {code} > Although, when I try to access content of the war app via URL, I get only {{404 Not found}} HTTP response. Also I cannot see any deployment content when browsing via CLI: > {code} > /deployment=bob/subsystem=undertow/... > {code} > Even when I raise logging level to DEBUG, I can see no suspicious messages that deployed app has not been completely deployed. > If such suffix is required, we need to inform user about it. We need to update description text for '\-\-name' and '\-\-runtime-name' atributes of deploy command in CLI (see {{deploy --help}}). Also when no such suffix is provided (and/or we fail to distinguish type of deployment in a different way) we need to print error message that deploy operation was not completely successful so customer is aware of it right-away. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3576) deployment is not accessible in runtime when deployed with runtime-name not using .war extension

by Jan Stourac (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3576?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-3576: ------------------------------------- If the file extension is not required for the deployment, why it fails to be used then? Is that because some internal logic fails to determine deployment type? Allright, then maybe we should not enforce the file extension in the name of the file, although we need to inform user if we fail to determine type of the deployment which, as a result, then cannot be used/accessed. > deployment is not accessible in runtime when deployed with runtime-name not using .war extension > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-3576 > URL: https://issues.jboss.org/browse/WFCORE-3576 > Project: WildFly Core > Issue Type: Enhancement > Components: Deployment Scanner, Domain Management > Affects Versions: 4.0.0.Alpha9 > Reporter: Jan Stourac > Assignee: Chao Wang > > According to the folowing [blog-post|https://developer.jboss.org/thread/221251], when using custom --name or --runtime-name for deployment, the file extension (.war, .jar, .ear,...) need to be included so server can distinguish type of deployment somehow. > Currently there is no such check - when I try to deploy any .war app using either web-console or CLI with my custom '\-\-runtime-name' and/or '\-\-name' without .war suffix, server does not complain anyhow: > {code} > deploy --runtime-name=alice --name=bob /tmp/eve.war > {code} > Message in server log: > {code} > 17:30:48,469 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "bob" (runtime-name: "alice") > 17:30:48,499 INFO [org.jboss.as.server] (management-handler-thread - 6) WFLYSRV0010: Deployed "bob" (runtime-name : "alice") > {code} > Although, when I try to access content of the war app via URL, I get only {{404 Not found}} HTTP response. Also I cannot see any deployment content when browsing via CLI: > {code} > /deployment=bob/subsystem=undertow/... > {code} > Even when I raise logging level to DEBUG, I can see no suspicious messages that deployed app has not been completely deployed. > If such suffix is required, we need to inform user about it. We need to update description text for '\-\-name' and '\-\-runtime-name' atributes of deploy command in CLI (see {{deploy --help}}). Also when no such suffix is provided (and/or we fail to distinguish type of deployment in a different way) we need to print error message that deploy operation was not completely successful so customer is aware of it right-away. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-35) Support hardcoded versions in copy-artifact

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-35?page=com.atlassian.jira.plugin... ] Stuart Douglas resolved WFBUILD-35. ----------------------------------- Resolution: Done This should be resolved by the changes in WFBUILD-34. This adds consistent handling of maven coordinates, so now hard coded versions should be usable anywhere. > Support hardcoded versions in copy-artifact > ------------------------------------------- > > Key: WFBUILD-35 > URL: https://issues.jboss.org/browse/WFBUILD-35 > Project: WildFly Build Tools > Issue Type: Enhancement > Reporter: Guillaume Smet > Assignee: Guillaume Smet > Fix For: 1.2.8.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-35) Support hardcoded versions in copy-artifact

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-35?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFBUILD-35: ---------------------------------- Fix Version/s: 1.2.8.Final (was: 1.2.7.Final) > Support hardcoded versions in copy-artifact > ------------------------------------------- > > Key: WFBUILD-35 > URL: https://issues.jboss.org/browse/WFBUILD-35 > Project: WildFly Build Tools > Issue Type: Enhancement > Reporter: Guillaume Smet > Assignee: Guillaume Smet > Fix For: 1.2.8.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-34) Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-34?page=com.atlassian.jira.plugin... ] Stuart Douglas updated WFBUILD-34: ---------------------------------- Fix Version/s: 1.2.8.Final > Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere > ------------------------------------------------------------------------------- > > Key: WFBUILD-34 > URL: https://issues.jboss.org/browse/WFBUILD-34 > Project: WildFly Build Tools > Issue Type: Enhancement > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 1.2.8.Final > > > This both a usability issue and a feature request. > On the usability side, the artifact formats in module.xml files vs. in feature-pack-build.xml files are not the same: > * `{{groupId:artifactId\[:version\[:classifier]]}}` in module.xml files > * `{{groupId:artifactId\[:type\[:classifier]]}}` in feature-pack-build.xml files > The missing feature is the impossibility to define type/extension in module.xml files and the impossibility to had code version in feature-pack-build.xml files > The current proposal is to use the same {{groupId:artifactId\[:type\[:classifier\[:version]]]}} format in both kinds of files. > The proposal is backwards incompatible for module.xml files. But given that the support for hardcoded versions in module.xml files was added just 11 days ago, this will probably impact just a few users. > I am not sure what artifact format is used by JBoss modules. Maybe `{{groupId:artifactId\[:version\[:classifier]]}}` is taken from there? > WDYT [~swd847]? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-34) Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-34?page=com.atlassian.jira.plugin... ] Stuart Douglas resolved WFBUILD-34. ----------------------------------- Assignee: Stuart Douglas (was: Peter Palaga) Resolution: Done > Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere > ------------------------------------------------------------------------------- > > Key: WFBUILD-34 > URL: https://issues.jboss.org/browse/WFBUILD-34 > Project: WildFly Build Tools > Issue Type: Enhancement > Reporter: Peter Palaga > Assignee: Stuart Douglas > Fix For: 1.2.8.Final > > > This both a usability issue and a feature request. > On the usability side, the artifact formats in module.xml files vs. in feature-pack-build.xml files are not the same: > * `{{groupId:artifactId\[:version\[:classifier]]}}` in module.xml files > * `{{groupId:artifactId\[:type\[:classifier]]}}` in feature-pack-build.xml files > The missing feature is the impossibility to define type/extension in module.xml files and the impossibility to had code version in feature-pack-build.xml files > The current proposal is to use the same {{groupId:artifactId\[:type\[:classifier\[:version]]]}} format in both kinds of files. > The proposal is backwards incompatible for module.xml files. But given that the support for hardcoded versions in module.xml files was added just 11 days ago, this will probably impact just a few users. > I am not sure what artifact format is used by JBoss modules. Maybe `{{groupId:artifactId\[:version\[:classifier]]}}` is taken from there? > WDYT [~swd847]? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018