October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1402) Release WildFly Elytron 1.2.0.Beta6

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1402: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta6 Key: ELY-1402 URL: https://issues.jboss.org/browse/ELY-1402 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta6 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1401) Release WildFly Elytron 1.1.5.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1401: ------------------------------------- Summary: Release WildFly Elytron 1.1.5.Final Key: ELY-1401 URL: https://issues.jboss.org/browse/ELY-1401 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.5.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3355) logging subsystem should skip if directories can't be listed

by Janine Eichler (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3355?page=com.atlassian.jira.plugi... ] Janine Eichler updated WFCORE-3355: ----------------------------------- Description: Following condition: - a mounted volume within the jboss.log.dir - the mounted volume is an ext filesystem as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... using the cli or mgmt console to read the log is then not possible. it might be good to skip reading those files/directories and continue rather than throwing an error. i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. was: Following condition: - a mounted volume within the jboss.log.dir - the mounted volume is an ext filesystem as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... using the cli or mgmt console to read the log is then not possible. i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. > logging subsystem should skip if directories can't be listed > ------------------------------------------------------------ > > Key: WFCORE-3355 > URL: https://issues.jboss.org/browse/WFCORE-3355 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Affects Versions: 3.0.5.Final > Reporter: Janine Eichler > Assignee: James Perkins > > Following condition: > - a mounted volume within the jboss.log.dir > - the mounted volume is an ext filesystem > as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. > Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... > using the cli or mgmt console to read the log is then not possible. > it might be good to skip reading those files/directories and continue rather than throwing an error. > i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9438) Add stop/start/restart operation to listeners.

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9438?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-9438. ----------------------------- Fix Version/s: 11.0.0.Final Resolution: Done Looks like this was already done in 11. Can you try with 11 CR1 build to verify? > Add stop/start/restart operation to listeners. > ---------------------------------------------- > > Key: WFLY-9438 > URL: https://issues.jboss.org/browse/WFLY-9438 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Robert Blody > Assignee: Stuart Douglas > Priority: Minor > Fix For: 11.0.0.Final > > > We are looking at migrating from Norton security certificates to LetsEncrypt, which gives out free SSL certificates, but they expire in 90 days... > This presents a problem to us. We don't want to have to redeploy the site every 90 days, we want it to contiguously run, and like we're doing with the EAR, we just want to call /redeploy on it, and have it continue operating. > > However, we haven't found a way to reset the HTTP sockets like we can with the EAR. I found this feature request: [WFLY-4321] restart of http connector without restarting whole web container - JBoss Issue Tracker > In it, the developer on the last page recommends to run this command: > /subsystem=undertow/server=default-server/https-listener=https:remove() {allow-resource-service-restart=true} > /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm="UndertowRealm", socket-binding="https") > Removing and re-adding the listener requires a full restart of the Wildfly server. This is just as bad as taking down the server. It would be helpful for consistency to have a stop, stop and restart command attached to listeners as there already exists for deployments. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3355) logging subsystem should skip if directories can't be listed

by Janine Eichler (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3355?page=com.atlassian.jira.plugi... ] Janine Eichler updated WFCORE-3355: ----------------------------------- Description: Following condition: - a mounted volume within the jboss.log.dir - the mounted volume is an ext filesystem as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... using the cli or mgmt console to read the log is then not possible. i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. was: Following condition: - a mounted volume within the jboss.log.dir - the mounted volume is an ext filesystem as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... using the cli or mgmt console to read the log is then not possible. > logging subsystem should skip if directories can't be listed > ------------------------------------------------------------ > > Key: WFCORE-3355 > URL: https://issues.jboss.org/browse/WFCORE-3355 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Affects Versions: 3.0.5.Final > Reporter: Janine Eichler > Assignee: James Perkins > > Following condition: > - a mounted volume within the jboss.log.dir > - the mounted volume is an ext filesystem > as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. > Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... > using the cli or mgmt console to read the log is then not possible. > i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3355) logging subsystem should skip if directories can't be listed

by Janine Eichler (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3355?page=com.atlassian.jira.plugi... ] Janine Eichler updated WFCORE-3355: ----------------------------------- Affects Version/s: (was: 2.1.0.Final) > logging subsystem should skip if directories can't be listed > ------------------------------------------------------------ > > Key: WFCORE-3355 > URL: https://issues.jboss.org/browse/WFCORE-3355 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Affects Versions: 3.0.5.Final > Reporter: Janine Eichler > Assignee: James Perkins > > Following condition: > - a mounted volume within the jboss.log.dir > - the mounted volume is an ext filesystem > as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. > Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... > using the cli or mgmt console to read the log is then not possible. > i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3355) logging subsystem should skip if directories can't be listed

by Janine Eichler (JIRA)

Janine Eichler created WFCORE-3355: -------------------------------------- Summary: logging subsystem should skip if directories can't be listed Key: WFCORE-3355 URL: https://issues.jboss.org/browse/WFCORE-3355 Project: WildFly Core Issue Type: Feature Request Components: Logging Affects Versions: 3.0.5.Final, 2.1.0.Final Reporter: Janine Eichler Assignee: James Perkins Following condition: - a mounted volume within the jboss.log.dir - the mounted volume is an ext filesystem as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... using the cli or mgmt console to read the log is then not possible. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-6823 at 10/12/17 6:44 AM: ------------------------------------------------------------ Source for reference: https://github.com/undertow-io/undertow/blob/7a2a32d7d47ca584566b3f7d05a1... Need to note, when passwords are stored in hashes on the server, there would have to be stored hash for every supported encoding. Just note, in Undertow (EAP) is this supported only by BASIC mechanism - not by DIGEST mechanism, so this would be new feature. was (Author: honza889): Source for reference: https://github.com/undertow-io/undertow/blob/7a2a32d7d47ca584566b3f7d05a1... Just note, in Undertow (EAP) is this supported only by BASIC mechanism - not by DIGEST mechanism, so this would be new feature. > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Dominik Hanak (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Dominik Hanak commented on DROOLS-1692: --------------------------------------- Resolving. Note that optaplanner-persistence-test depends on drools functionality and required changes for jpa test module in order to work. Here is related prq: https://github.com/kiegroup/optaplanner/pull/343 > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Dominik Hanak > Fix For: 7.5.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Dominik Hanak (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Dominik Hanak edited comment on DROOLS-1692 at 10/12/17 6:37 AM: ----------------------------------------------------------------- Resolving. Note that optaplanner-persistence-test depends on drools test functionality and required changes for jpa test module in order to work. Here is related prq: https://github.com/kiegroup/optaplanner/pull/343 was (Author: dhanak): Resolving. Note that optaplanner-persistence-test depends on drools functionality and required changes for jpa test module in order to work. Here is related prq: https://github.com/kiegroup/optaplanner/pull/343 > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Dominik Hanak > Fix For: 7.5.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 October 2017