September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9349) Upgrade WildFly Naming Client to 1.0.2.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-9349: --------------------------------- Summary: Upgrade WildFly Naming Client to 1.0.2.Final Key: WFLY-9349 URL: https://issues.jboss.org/browse/WFLY-9349 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 11.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1734) FEEL if in case of otherwise

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1734?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1734: ----------------------------------- Description: Spec says: if FEEL(e 1 ) is true then FEEL(e 2 ) else FEEL(e 3 ) so if I follow the spec, NOT the code, it could happen that FEEL(e1) is: true follows the spec, returns FEEL(e2) false follows the spec, returns FEEL(e3) otherwise if I follow the spec, it should return FEEL(e3), if I follow the code, it's returning null (and an error). The spec takes the position that 'if x then 1 else 2' should always result in either 1 or 2, regardless of x (or the type of x). This makes it easier for users to handle missing data, e.g. if x > 0 then x else 0. was: Spec says: if FEEL(e 1 ) is true then FEEL(e 2 ) else FEEL(e 3 ) so if I follow the spec, NOT the code, it could happen that FEEL(e1) is: true follows the spec, returns FEEL(e2) false follows the spec, returns FEEL(e3) otherwise if I follow the spec, it should return FEEL(e3), if I follow the code, it's returning null (and an error). > FEEL if in case of otherwise > ---------------------------- > > Key: DROOLS-1734 > URL: https://issues.jboss.org/browse/DROOLS-1734 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Spec says: > if FEEL(e 1 ) is true then FEEL(e 2 ) else FEEL(e 3 ) > so if I follow the spec, NOT the code, it could happen that FEEL(e1) is: > true follows the spec, returns FEEL(e2) > false follows the spec, returns FEEL(e3) > otherwise if I follow the spec, it should return FEEL(e3), if I follow the code, it's returning null (and an error). > The spec takes the position that 'if x then 1 else 2' should always > result in either 1 or 2, regardless of x (or the type of x). This > makes it easier for users to handle missing data, e.g. if x > 0 then x > else 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3301) Upgrade JBoss Remoting to 5.0.2.Final

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3301?page=com.atlassian.jira.plugi... ] David Lloyd updated WFCORE-3301: -------------------------------- Fix Version/s: 4.0.0.Alpha1 3.0.3.Final > Upgrade JBoss Remoting to 5.0.2.Final > ------------------------------------- > > Key: WFCORE-3301 > URL: https://issues.jboss.org/browse/WFCORE-3301 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 4.0.0.Alpha1, 3.0.3.Final > > > Fixes an NPE which causes the test suite to hang under some circumstances. Specifically if a shared connection makes use of EXTERNAL auth, it fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1734) FEEL if in case of otherwise

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1734: -------------------------------------- Summary: FEEL if in case of otherwise Key: DROOLS-1734 URL: https://issues.jboss.org/browse/DROOLS-1734 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Spec says: if FEEL(e 1 ) is true then FEEL(e 2 ) else FEEL(e 3 ) so if I follow the spec, NOT the code, it could happen that FEEL(e1) is: true follows the spec, returns FEEL(e2) false follows the spec, returns FEEL(e3) otherwise if I follow the spec, it should return FEEL(e3), if I follow the code, it's returning null (and an error). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3301) Upgrade JBoss Remoting to 5.0.2.Final

by David Lloyd (JIRA)

David Lloyd created WFCORE-3301: ----------------------------------- Summary: Upgrade JBoss Remoting to 5.0.2.Final Key: WFCORE-3301 URL: https://issues.jboss.org/browse/WFCORE-3301 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fixes an NPE which causes the test suite to hang under some circumstances. Specifically if a shared connection makes use of EXTERNAL auth, it fails. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3300) configuration-changes doesn't record server stop

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3300?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3300: ------------------------------------------ The domainUUID thing is because the op is executed on a host and never leaves that host. We don't apply a domainUUID to ops that execute on a single process. (The op launches another process, the server, but that process is not a participant in the op.) > configuration-changes doesn't record server stop > ------------------------------------------------ > > Key: WFCORE-3300 > URL: https://issues.jboss.org/browse/WFCORE-3300 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Claudio Miranda > Priority: Minor > > Enable configuration-changes at > {code} > /host=master/subsystem=core-management/service=configuration-changes:add > {code} > server stop is not recorded there > {code} > /host=master/server-config=server-one:stop > {code} > Also, the start operation for a server, doesn't generate a domain-uuid attribute > {code} > { > "operation-date" => "2017-09-15T19:37:50.473Z", > "access-mechanism" => "HTTP", > "remote-address" => "localhost/127.0.0.1", > "outcome" => "success", > "operations" => [{ > "blocking" => false, > "operation" => "start", > "address" => [ > ("host" => "master"), > ("server-config" => "server-three") > ], > "operation-headers" => { > "access-mechanism" => "HTTP", > "caller-type" => "user" > } > }] > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3300) configuration-changes doesn't record server stop

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3300?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3300: ---------------------------------------- Assignee: (was: Brian Stansberry) Anyone looking at this needs to be very very careful. It's minor and we don't want to cause worse problems. The op doesn't end up being recorded because ServerStopHandler doesn't do anything that leads the OperationContext to treat it as a write op. And that's very deliberate; we don't want to do things that may cause the op to block waiting for other ops. See comments in that class for one example. The domainUUID thing I'm not sure about, but be careful too. > configuration-changes doesn't record server stop > ------------------------------------------------ > > Key: WFCORE-3300 > URL: https://issues.jboss.org/browse/WFCORE-3300 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Claudio Miranda > Priority: Minor > > Enable configuration-changes at > {code} > /host=master/subsystem=core-management/service=configuration-changes:add > {code} > server stop is not recorded there > {code} > /host=master/server-config=server-one:stop > {code} > Also, the start operation for a server, doesn't generate a domain-uuid attribute > {code} > { > "operation-date" => "2017-09-15T19:37:50.473Z", > "access-mechanism" => "HTTP", > "remote-address" => "localhost/127.0.0.1", > "outcome" => "success", > "operations" => [{ > "blocking" => false, > "operation" => "start", > "address" => [ > ("host" => "master"), > ("server-config" => "server-three") > ], > "operation-headers" => { > "access-mechanism" => "HTTP", > "caller-type" => "user" > } > }] > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3300) configuration-changes doesn't record server stop

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3300?page=com.atlassian.jira.plugi... ] Claudio Miranda updated WFCORE-3300: ------------------------------------ Description: Enable configuration-changes at {code} /host=master/subsystem=core-management/service=configuration-changes:add {code} server stop is not recorded there {code} /host=master/server-config=server-one:stop {code} Also, the start operation for a server, doesn't generate a domain-uuid attribute {code} { "operation-date" => "2017-09-15T19:37:50.473Z", "access-mechanism" => "HTTP", "remote-address" => "localhost/127.0.0.1", "outcome" => "success", "operations" => [{ "blocking" => false, "operation" => "start", "address" => [ ("host" => "master"), ("server-config" => "server-three") ], "operation-headers" => { "access-mechanism" => "HTTP", "caller-type" => "user" } }] }, {code} was: Enable configuration-changes at /host=master/subsystem=core-management/service=configuration-changes:add server stop is not recorded there /host=master/server-config=server-one:stop Also, the start operation for a server, doesn't generate a domain-uuid attribute { "operation-date" => "2017-09-15T19:37:50.473Z", "access-mechanism" => "HTTP", "remote-address" => "localhost/127.0.0.1", "outcome" => "success", "operations" => [{ "blocking" => false, "operation" => "start", "address" => [ ("host" => "master"), ("server-config" => "server-three") ], "operation-headers" => { "access-mechanism" => "HTTP", "caller-type" => "user" } }] }, > configuration-changes doesn't record server stop > ------------------------------------------------ > > Key: WFCORE-3300 > URL: https://issues.jboss.org/browse/WFCORE-3300 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Claudio Miranda > Assignee: Brian Stansberry > Priority: Minor > > Enable configuration-changes at > {code} > /host=master/subsystem=core-management/service=configuration-changes:add > {code} > server stop is not recorded there > {code} > /host=master/server-config=server-one:stop > {code} > Also, the start operation for a server, doesn't generate a domain-uuid attribute > {code} > { > "operation-date" => "2017-09-15T19:37:50.473Z", > "access-mechanism" => "HTTP", > "remote-address" => "localhost/127.0.0.1", > "outcome" => "success", > "operations" => [{ > "blocking" => false, > "operation" => "start", > "address" => [ > ("host" => "master"), > ("server-config" => "server-three") > ], > "operation-headers" => { > "access-mechanism" => "HTTP", > "caller-type" => "user" > } > }] > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3300) configuration-changes doesn't record server stop

by Claudio Miranda (JIRA)

Claudio Miranda created WFCORE-3300: --------------------------------------- Summary: configuration-changes doesn't record server stop Key: WFCORE-3300 URL: https://issues.jboss.org/browse/WFCORE-3300 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Claudio Miranda Assignee: Brian Stansberry Priority: Minor Enable configuration-changes at /host=master/subsystem=core-management/service=configuration-changes:add server stop is not recorded there /host=master/server-config=server-one:stop Also, the start operation for a server, doesn't generate a domain-uuid attribute { "operation-date" => "2017-09-15T19:37:50.473Z", "access-mechanism" => "HTTP", "remote-address" => "localhost/127.0.0.1", "outcome" => "success", "operations" => [{ "blocking" => false, "operation" => "start", "address" => [ ("host" => "master"), ("server-config" => "server-three") ], "operation-headers" => { "access-mechanism" => "HTTP", "caller-type" => "user" } }] }, -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3299) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3299?page=com.atlassian.jira.plugi... ] Brian Stansberry moved ELY-1350 to WFCORE-3299: ----------------------------------------------- Project: WildFly Core (was: WildFly Elytron) Key: WFCORE-3299 (was: ELY-1350) > Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation. > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3299 > URL: https://issues.jboss.org/browse/WFCORE-3299 > Project: WildFly Core > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > > Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation. > There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS. > *How to reproduce:* > * run powershell and set work directory JBOSS_HOME/bin > * set env variable for custom credential store implementation jar like this: > {code} > $env:ELYTRON_TOOL_ADDONS="C:\custom.jar" > {code} > * run this command > {code} > PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug > Exception encountered executing the command: > java.security.NoSuchAlgorithmException > at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80) > at > org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188 > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81) > {code} > *Suggestion to improve:* > For me works one of these changes in elytron-tool.ps1 script > # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value } > # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 September 2017