September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8549) Create Externalizers, @Immutable and general session replication/failover quickstart

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-8549?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8549: ----------------------------------- Issue Type: Enhancement (was: Task) I'm changing this to Enhancement. Sounds like it is, and since it's prioritized as Critical I'd like it to be clear when looking at Blocker/Critical issues in JIRA that this is an RFE, not some sort of correction. > Create Externalizers, @Immutable and general session replication/failover quickstart > ------------------------------------------------------------------------------------ > > Key: WFLY-8549 > URL: https://issues.jboss.org/browse/WFLY-8549 > Project: WildFly > Issue Type: Enhancement > Components: Clustering, Quickstarts > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: Awaiting Volunteers > > > Demonstrate the marshalling mechanism via implementations of {{org.wildfly.clustering.marshalling.Externalizer}} in conjunction with general session replication. > To demonstrate externalizers, we can demonstrate with non-serializable objects > For @ Immutable we can take 2 classes, one is immutable, one not, we can demonstrate getting attribute and mutating object vs get attribute, mutate, subsequent requests won't see mutation on failover – set attribute must be used. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8523) Create CommandDispatcher Quickstart

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-8523?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-8523: ----------------------------------- Issue Type: Enhancement (was: Task) I'm changing this to Enhancement. Sounds like it is, and since it's prioritized as Critical I'd like it to be clear when looking at Blocker/Critical issues in JIRA that this is an RFE, not some sort of correction. > Create CommandDispatcher Quickstart > ----------------------------------- > > Key: WFLY-8523 > URL: https://issues.jboss.org/browse/WFLY-8523 > Project: WildFly > Issue Type: Enhancement > Components: Clustering, Quickstarts > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > Demonstrate public clustering API which facilitates remote command execution on the cluster in package {{org.wildfly.clustering.dispatcher}}. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12304) Upgrade Apache Artemis from 2.9.0 to 2.10.0

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12304?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12304: ----------------------------------------- Per comments on WFLY-10968 this may incorporate the fix for that one, so I've linked them. > Upgrade Apache Artemis from 2.9.0 to 2.10.0 > ------------------------------------------- > > Key: WFLY-12304 > URL: https://issues.jboss.org/browse/WFLY-12304 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Martin Stefanko > Assignee: Emmanuel Hugonnet > Priority: Blocker > Labels: blocker-WF18, downstream_dependency > > Upgrade Apache Artemis from 2.9.0.Final to 2.10.0.Final. > Due to HA issue with Apache Artemis 2.10.0 this may not be the final version upgrade -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12297) Jakarta EE 8 Certification for WildFly

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12297?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12297: ------------------------------------ Priority: Blocker (was: Critical) > Jakarta EE 8 Certification for WildFly > -------------------------------------- > > Key: WFLY-12297 > URL: https://issues.jboss.org/browse/WFLY-12297 > Project: WildFly > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Blocker > Fix For: 18.0.0.Final > > > Certify WildFly 18 as Jakarta EE 8 compatible. Publish the certification results on https://github.com/wildfly/certifications -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4631) Create tests for Elytron syslog reconnect attempts

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4631?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-4631: ------------------------------------------ [~jamezp] WFLY-12558 seems conceptually related to this. > Create tests for Elytron syslog reconnect attempts > -------------------------------------------------- > > Key: WFCORE-4631 > URL: https://issues.jboss.org/browse/WFCORE-4631 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 10.0.0.Final > > > WFCORE-4394 currently has some tests which will be disabled for this. It's likely some integration tests will need to be done instead of unit tests. ELY-1864 is going to change the way the reconnect attempts are done resulting in the current unit tests failing. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12558) Intermittent failures in TCPSyslogAuditLogTestCase

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12558?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12558: ----------------------------------------- I "rejected" my pull request because I consider it more along the lines of an @Ignore commit than a fix; i.e. it's a workaround to avoid CI noise. If this had been failing for a long time I might feel differently but it only started doing this 2-3 weeks ago. Without objection I'll merge the PR though if it passes another CI round without showing this failure, as we need to avoid CI noise this week. > Intermittent failures in TCPSyslogAuditLogTestCase > -------------------------------------------------- > > Key: WFLY-12558 > URL: https://issues.jboss.org/browse/WFLY-12558 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Priority: Major > > 5 tests in TCPSyslogAuditLogTestCase are frequently failing since late August: > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > Initial failure has this in the server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("syslog-audit-log" => "TCPSyslogAuditLogTestCase") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.TCPSyslogAuditLogTestCase" => "WFLYELY00004: Unable to start the service. > Caused by: java.io.IOException: ELY12001: The maximum reconnect attempts value of 0 was reached. The syslog endpoint will be shutdown."}} > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4666) Implement a non-user standalone.sh extension mechanism

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4666?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4666: ------------------------------------- Description: We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution. What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container developers also don't want to maintain their own variant of standalone.sh but need to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file. A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and, if present, source it after standalone.conf. Perhaps a standalone.conf.pre as well. (Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh. [~luck3y] FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean. [~jamezp] [~jmesnil] FYI. This is not urgent; just something I was thinking about after helping with some user issues with our image launch. was: We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution. What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container also doesn't want to maintain their own variant of standalone.sh but needs to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file. A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and if present, source it after standalone.conf. Perhaps a standalone.conf.pre as well. (Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh. [~luck3y] FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean. > Implement a non-user standalone.sh extension mechanism > ------------------------------------------------------ > > Key: WFCORE-4666 > URL: https://issues.jboss.org/browse/WFCORE-4666 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Brian Stansberry > Priority: Major > > We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution. > What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container developers also don't want to maintain their own variant of standalone.sh but need to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file. > A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and, if present, source it after standalone.conf. Perhaps a standalone.conf.pre as well. > (Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh. > [~luck3y] FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean. > [~jamezp] [~jmesnil] FYI. > This is not urgent; just something I was thinking about after helping with some user issues with our image launch. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4666) Implement a non-user standalone.sh extension mechanism

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4666: ---------------------------------------- Summary: Implement a non-user standalone.sh extension mechanism Key: WFCORE-4666 URL: https://issues.jboss.org/browse/WFCORE-4666 Project: WildFly Core Issue Type: Enhancement Components: Scripts Reporter: Brian Stansberry We have a reasonable architecture for how standalone.sh works: standalone.sh itself is not meant to be touched and has a lot of complex logic, and then standalone.conf is for users to manipulate as they wish to set up env vars. The standalone.conf is sourced early in the standalone.sh execution. What's missing is a hook for non-user extensions to the standalone.conf concept. Primary use case being cloud containers where the container also doesn't want to maintain their own variant of standalone.sh but needs to do env var manipulation before the main script logic runs. Right now images are handling this by shipping their own standalone.conf with a bunch of content appended, but that has the effect of making the file no longer a 'user' file. A possible simple way to improve this is to have standalone.sh look for a 'standalone.conf.post' file and if present, source it after standalone.conf. Perhaps a standalone.conf.pre as well. (Tangent: I think our stock standalone.conf/bat etc should have a leading comment section explaining the "API" of standalone.sh, i.e. what are the env vars that standalone.sh will process that the user may wish to manipulate in standalone.sh. [~luck3y] FYI and input. Whether this is a good idea in our images is a good thing to discuss; i.e. whether easing end-user manipulation is something desirable. The basic design is users should not do that, and instead they should use the various cloud-specific env vars processed by the image logic to manipulate the server launch. And I think that's fine/correct. I just don't like the way that image logic is implemented by having the image build append logic to standalone.conf. That's conceptually unclean. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12558) Intermittent failures in TCPSyslogAuditLogTestCase

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12558?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-12558: ----------------------------------------- [~jamezp] may also know a little more but some of the fixes for audit logging could be in the next core tag - not sure if all our fixes made it to WildFly yet. > Intermittent failures in TCPSyslogAuditLogTestCase > -------------------------------------------------- > > Key: WFLY-12558 > URL: https://issues.jboss.org/browse/WFLY-12558 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Darran Lofthouse > Priority: Major > > 5 tests in TCPSyslogAuditLogTestCase are frequently failing since late August: > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > Initial failure has this in the server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("syslog-audit-log" => "TCPSyslogAuditLogTestCase") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.TCPSyslogAuditLogTestCase" => "WFLYELY00004: Unable to start the service. > Caused by: java.io.IOException: ELY12001: The maximum reconnect attempts value of 0 was reached. The syslog endpoint will be shutdown."}} > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12559) Upgrade jboss-ejb-api_3.2_spec to 2.0.0.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12559: ------------------------------------- Summary: Upgrade jboss-ejb-api_3.2_spec to 2.0.0.Final Key: WFLY-12559 URL: https://issues.jboss.org/browse/WFLY-12559 Project: WildFly Issue Type: Sub-task Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 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 2019