May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-149) Failures in 'resolve-expression" op appear in server log

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-149: ------------------------------------ Fix Version/s: 2.2.0.CR1 > Failures in 'resolve-expression" op appear in server log > -------------------------------------------------------- > > Key: WFCORE-149 > URL: https://issues.jboss.org/browse/WFCORE-149 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > I happened to notice this in a server log: > 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" > That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. > A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. > Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1346) extension remove reports sucess even if the extension does not exist

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1346?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1346: ------------------------------------- Fix Version/s: 2.2.0.CR1 > extension remove reports sucess even if the extension does not exist > -------------------------------------------------------------------- > > Key: WFCORE-1346 > URL: https://issues.jboss.org/browse/WFCORE-1346 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Stuart Douglas > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > e.g.: > [standalone@localhost:9999 /] /extension=garbage:remove > {"outcome" => "success"} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1348) Specify filesystem rights for deployment content

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1348?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1348: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Specify filesystem rights for deployment content > ------------------------------------------------ > > Key: WFCORE-1348 > URL: https://issues.jboss.org/browse/WFCORE-1348 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Currently when we add a content to the ContentRepository we are using Files.createTempFile whitout specifying the file attributes. On GNU/Linux this may create a file with only read write rights for the user (and not the group or other). We should change that as this could lead to some strange errors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1439) Allow for testsuite to pass on French OS

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1439?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1439: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Allow for testsuite to pass on French OS > ---------------------------------------- > > Key: WFCORE-1439 > URL: https://issues.jboss.org/browse/WFCORE-1439 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.1.0.CR1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > Some tests are checking failure message or exception message as if the Locale is always English. Fixing those -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1376) Update the module cli command help text

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1376?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1376: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Update the module cli command help text > --------------------------------------- > > Key: WFCORE-1376 > URL: https://issues.jboss.org/browse/WFCORE-1376 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > The help text from the module CLI command is still referencing AS7 and doesn't explicitly specify that the command is local only. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1380) service.bat fails when wildfly folder path contains spaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1380?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1380: ------------------------------------- Fix Version/s: 2.2.0.CR1 > service.bat fails when wildfly folder path contains spaces > ---------------------------------------------------------- > > Key: WFCORE-1380 > URL: https://issues.jboss.org/browse/WFCORE-1380 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Andrea Scarpino > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > service.bat does not work when Wildfly is run from Program Files (x86) > {noformat} > C:\Program Files (x86)\wildfly-9.0.0.Final\bin\service>service.bat install > Using the X86-64bit version of prunsrv > \wildfly-9.0.0.Final\domain\log non atteso. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1260: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Capability resolution complaints on admin-only slave HCs not connected to the master > ------------------------------------------------------------------------------------ > > Key: WFCORE-1260 > URL: https://issues.jboss.org/browse/WFCORE-1260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.5.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log > Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config: > {code} > bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1 > {code} > The boot is fine: > {code} > [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand) > {code} > However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC: > {code} > [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {code} > The HC's log: > {code} > [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available: > [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability. > [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability. > {code} > The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references. > But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config. > This is a general case that needs to be accounted for in the capability resolution logic. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1430) Deployment scanner logs ERROR when server is shutting down

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1430?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1430: ------------------------------------- Fix Version/s: 2.2.0.CR1 > Deployment scanner logs ERROR when server is shutting down > ---------------------------------------------------------- > > Key: WFCORE-1430 > URL: https://issues.jboss.org/browse/WFCORE-1430 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 2.1.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: ehsavoie Hugonnet > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > It happens time to time that deployment scanner can throw and log error [1] when server is shutting down. > It's in case of clean startup and clean shutdown when error messages should not be shown. I can hit it when unbounding a datasource takes a bit longer and scan of deployment scanner hits that time. > [1] > {code} > ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /mnt/hudson_workspace/workspace/eap-70-jbossts-crashrec-tests-mssql2014/90fac01f/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/deployments threw Exception: java.lang.RuntimeException: WFLYDS0036: Deployment model operation failed. WFLYCTL0271: Operation cancelled > at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:83) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1614) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1398) RemotingHttpUpgradeService.SERVICE_NAME has a superfluous space

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1398?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1398: ------------------------------------- Fix Version/s: 2.2.0.CR1 > RemotingHttpUpgradeService.SERVICE_NAME has a superfluous space > --------------------------------------------------------------- > > Key: WFCORE-1398 > URL: https://issues.jboss.org/browse/WFCORE-1398 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > public static final ServiceName UPGRADE_SERVICE_NAME = ServiceName.JBOSS.append("remoting ", "remoting-http-upgrade-service"); > Note the space in "remoting " -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-683) ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-683?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-683: ------------------------------------ Fix Version/s: 2.2.0.CR1 > ListModuleRootsHandler and ModuleLocationHandler don't handle PrivilegedActionException properly > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-683 > URL: https://issues.jboss.org/browse/WFCORE-683 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Yeray Santana Borges > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > > The two inner class OSHs in ModuleLoadingResourceDefinition don't deal with exceptions properly. They invoke AccessController.doPrivileged and then deal with any PrivilegedActionException by rethrowing as OperationFailedException. > OperationFailedException represents a client mistake and is handled as such (e.g. isn't logged in the server log.) It shouldn't be thrown here unless the PrivilegedActionException.getCause() value is itself an OFE. Otherwise, the OSHs should throw a RuntimeException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 May 2016