December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-394) Allow MechanismConfiguration and MechanismRealmConfiguration to override the RealmMapper

by Farah Juma (JIRA)

Farah Juma created ELY-394: ------------------------------ Summary: Allow MechanismConfiguration and MechanismRealmConfiguration to override the RealmMapper Key: ELY-394 URL: https://issues.jboss.org/browse/ELY-394 Project: WildFly Elytron Issue Type: Task Components: API / SPI Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1213) Graceful shutdown is interfering with the 'kill' and 'destroy' operations

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1213: ---------------------------------------- Summary: Graceful shutdown is interfering with the 'kill' and 'destroy' operations Key: WFCORE-1213 URL: https://issues.jboss.org/browse/WFCORE-1213 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.0.4.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.0.5.Final The 'kill' and 'destroy' operations on the HC are meant to force shutdown of misbehaving servers. But the graceful shutdown work ([1]) has introduced a management op into the mix. I believe that should be removed, as its not the intent of these operations to try and be graceful; the regular 'stop' ops are for that. When experimenting with how domains react to OOME servers as part of my WFCORE-378 work I'm seeing 'kill' and 'destroy' no longer function because the OOME on the server means the graceful shutdown management op hangs. [1] https://github.com/wildfly/wildfly-core/commit/6e95b5#diff-ecdfa997cd57af... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5842) Upgrade google guava from 18 to 19

by Frank Langelage (JIRA)

Frank Langelage created WFLY-5842: ------------------------------------- Summary: Upgrade google guava from 18 to 19 Key: WFLY-5842 URL: https://issues.jboss.org/browse/WFLY-5842 Project: WildFly Issue Type: Component Upgrade Affects Versions: 10.0.0.CR5 Reporter: Frank Langelage Assignee: Jason Greene Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1212: ------------------------------------------ BTW, I confirmed with Jason that the reason this doesn't end up polluting the dists we publish to repository.jboss.org is that the command that he uses pushes to nexus is: mvn clean deploy -DskipTests -DallTests -Drelease So any previous pollution is cleaned and tests are skipped preventing new pollution. > TestModule does not clean up after itself properly > -------------------------------------------------- > > Key: WFCORE-1212 > URL: https://issues.jboss.org/browse/WFCORE-1212 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Brian Stansberry > Assignee: Ken Wills > > TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs. > The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. > I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. > Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-1212: ----------------------------------- Reproducible in wildfy with: mvn test -pl testsuite/integration/basic -Dts.basic -Dtest=org.jboss.as.test.integration.weld.modules.deployment.StaticModuleToDeploymentVisibilityEarTest > TestModule does not clean up after itself properly > -------------------------------------------------- > > Key: WFCORE-1212 > URL: https://issues.jboss.org/browse/WFCORE-1212 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Brian Stansberry > Assignee: Ken Wills > > TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs. > The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. > I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. > Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5832) Implement journal-pool-files on messaging integration

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFLY-5832?page=com.atlassian.jira.plugin.... ] Clebert Suconic commented on WFLY-5832: --------------------------------------- the correct name for the parameter I chose was journal-pool-files... I did this to match with journal-min-files, so we will have: journal-min-files journal-pool-files > Implement journal-pool-files on messaging integration > ----------------------------------------------------- > > Key: WFLY-5832 > URL: https://issues.jboss.org/browse/WFLY-5832 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Clebert Suconic > Assignee: Jeff Mesnil > > We have recently added a new parameter for the file pool size on the journal. > it's the number we willl shrink back to after journal files have been released. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5832) Implement journal-pool-files on messaging integration

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFLY-5832?page=com.atlassian.jira.plugin.... ] Clebert Suconic updated WFLY-5832: ---------------------------------- Summary: Implement journal-pool-files on messaging integration (was: Implement journal-pool-size on messaging integration) > Implement journal-pool-files on messaging integration > ----------------------------------------------------- > > Key: WFLY-5832 > URL: https://issues.jboss.org/browse/WFLY-5832 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Clebert Suconic > Assignee: Jeff Mesnil > > We have recently added a new parameter for the file pool size on the journal. > it's the number we willl shrink back to after journal files have been released. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5832) Implement journal-pool-size on messaging integration

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFLY-5832?page=com.atlassian.jira.plugin.... ] Clebert Suconic commented on WFLY-5832: --------------------------------------- This was done upstream as part of https://github.com/apache/activemq-artemis/commit/351bcfc9f98e353e4e2e419... > Implement journal-pool-size on messaging integration > ---------------------------------------------------- > > Key: WFLY-5832 > URL: https://issues.jboss.org/browse/WFLY-5832 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Clebert Suconic > Assignee: Jeff Mesnil > > We have recently added a new parameter for the file pool size on the journal. > it's the number we willl shrink back to after journal files have been released. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ] Ken Wills reassigned WFCORE-1212: --------------------------------- Assignee: Ken Wills > TestModule does not clean up after itself properly > -------------------------------------------------- > > Key: WFCORE-1212 > URL: https://issues.jboss.org/browse/WFCORE-1212 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Brian Stansberry > Assignee: Ken Wills > > TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs. > The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. > I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. > Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1212) TestModule does not clean up after itself properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1212?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1212: ------------------------------------- Description: TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs. The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. was: TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the from the dir above 'main' and below, leaving behind intermediate dirs. The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. > TestModule does not clean up after itself properly > -------------------------------------------------- > > Key: WFCORE-1212 > URL: https://issues.jboss.org/browse/WFCORE-1212 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.4.Final > Reporter: Brian Stansberry > > TestModule.create() calls mkdirs() to create its filesystem structure, but remove() only removes the dir above 'main' and below, leaving behind intermediate dirs. > The result of this is if you run the full testsuite with -Dts.basic, the dist/target/wildflyxxx/modules dir ends up with child dir 'test' in addition to the proper 'system'. > I'm not sure why this spurious dir doesn't end up in the final dists we publish. Perhaps its just luck due to the release process not running the testsuite when the final build with the 'deploy' target is invoked. I know my process for releasing WildFly Core doesn't re-run tests in that step. > Once remove() does its current work it should walk up the filesystem tree until it gets to the file returned by getModulesDir(). For each level in the tree it should check if that file is a dir with no children and if it is it should remove the dir. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 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 December 2015