August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13751) Make control of testsuite/layers deletion of provisioned servers configurable via -D

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13751: --------------------------------------- Summary: Make control of testsuite/layers deletion of provisioned servers configurable via -D Key: WFLY-13751 URL: https://issues.redhat.com/browse/WFLY-13751 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry The testsuite/layers tests delete all the provisioned servers when done, which is generally good as these would take up a ton of disk space otherwise. But sometimes during development it's nice to leave these behind to inspect their content. So allow control this behavior via a maven property. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5078) remoting layer defines no dependencies

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5078?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5078: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > remoting layer defines no dependencies > -------------------------------------- > > Key: WFCORE-5078 > URL: https://issues.redhat.com/browse/WFCORE-5078 > Project: WildFly Core > Issue Type: Bug > Components: Build System, Remoting > Affects Versions: 13.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > The remoting layer depends upon legacy security realms but this dependency is not defined. > The layer named "remoting" should be updated to reference an elytron sasl-authentication-factory and the layer should depend upon the elytron layer. > There should be a second layer "legacy-remoting" which references the ApplicationRealm security realm and also this layer should have a dependency on the layer "application-security-realm". -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5076) remoting http-connector silently accepts invalid security-realm

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5076?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5076: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > remoting http-connector silently accepts invalid security-realm > --------------------------------------------------------------- > > Key: WFCORE-5076 > URL: https://issues.redhat.com/browse/WFCORE-5076 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > If the remoting subsystem is changed to the following: > {code:xml} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/> > </subsystem> > {code} > The server starts without error, however attempting to establish a connection fails. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200 > {code} > Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5033) Move org.wildfly.security:wildfly-elytron-jacc into it's own module

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5033?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5033: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > Move org.wildfly.security:wildfly-elytron-jacc into it's own module > ------------------------------------------------------------------- > > Key: WFCORE-5033 > URL: https://issues.redhat.com/browse/WFCORE-5033 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > Long term it will be desirable for JACC to be within it's own subsystem so it's inclusion can be controlled using layers, however there may be an intermediate step where we split JACC out from the Elytron project so will want to bring it in ideally in it's own module. > The classes within this module have never been public API so we are free to refactor as needed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5084) Why does the elytron layer bring in access control?

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5084?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5084: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > Why does the elytron layer bring in access control? > --------------------------------------------------- > > Key: WFCORE-5084 > URL: https://issues.redhat.com/browse/WFCORE-5084 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > The following shows the set of changes created by adding the elytron layer to a provisioned server: > https://gist.github.com/darranl/68f4a3d60560dae9a9225ec1a0e35a9f/revisions > This includes the following: > {code:xml} > <management> > <access-control provider="simple"> > <role-mapping> > <role name="SuperUser"> > <include> > <user name="$local"/> > </include> > </role> > </role-mapping> > </access-control> > </management> > {code} > Shouldn't this section be added if any form of authenticated management is added instead? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5082) Add a new "legacy-remoting" layer.

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5082?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5082: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > Add a new "legacy-remoting" layer. > ---------------------------------- > > Key: WFCORE-5082 > URL: https://issues.redhat.com/browse/WFCORE-5082 > Project: WildFly Core > Issue Type: Task > Components: Build System, Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > This layer should make use of legacy security realms for authentication and depend on the layer "management-security-realm" to ensure it is present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) The management layer should make it more obvious it is unsecured

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5079: -------------------------------- Fix Version/s: 13.0.0.Beta5 (was: 13.0.0.Beta4) > The management layer should make it more obvious it is unsecured > ---------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-11808?page=com.atlassian.jira.plugi... ] Cheng Fang reassigned WFLY-11808: --------------------------------- Assignee: Michal Petrov (was: Cheng Fang) > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.redhat.com/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Michal Petrov > Priority: Major > Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-11808?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-11808: ----------------------------------- name space context is more related to batch envrionment than to job operator. So I think {{BatchEnvironmentService}} is probably a better place to handle name space context selection. Maybe compare the current thread's name space context with the deployment one, and switch if differ. > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.redhat.com/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11808) Unable to do jndi lookup when starting batch job from web console

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-11808?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFLY-11808: -------------------------------------- [~cfang], would [this|https://github.com/michpetrov/wildfly/commit/2698ccfe38fe5fee2e7e905...] work? I thought the namingContext would be harder to retrieve but we can put it into the jobOperator. > Unable to do jndi lookup when starting batch job from web console > ----------------------------------------------------------------- > > Key: WFLY-11808 > URL: https://issues.redhat.com/browse/WFLY-11808 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 16.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: Default Task Thread.png, External Management Request Thread.png, Screen Shot 2019-03-04 at 10.38.47 PM.png > > > when starting a batch job from web console, jndi lookup inside the application's batch artifacts failed with NameNotFoundException. When the same job is started by the application, the lookups all go well. Need to check if the naming context is properly propagated when starting job from the web console. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 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 August 2020