August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-82) PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-82?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-82: -------------------------------- Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/136, https://github.com/jboss-logging/jboss-logmanager/pull/137 (was: https://github.com/jboss-logging/jboss-logmanager/pull/136) > PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy > -------------------------------------------------------------------- > > Key: LOGMGR-82 > URL: https://issues.jboss.org/browse/LOGMGR-82 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha3 > > > The rotation tests seem to fail at random days and times. The test {{testPeriodicAndSizeRotate}} needs to be looked at before re-enabling it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-82) PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-82?page=com.atlassian.jira.plugin.... ] James Perkins edited comment on LOGMGR-82 at 8/18/17 2:36 PM: -------------------------------------------------------------- Of course this seems to be failing now. The {{yyyy-MM-dda}} pattern is failing at 11:00 am PDT. {code:title=Full Failure Message} Failed tests: PeriodicSizeRotatingFileHandlerTests.testPeriodicAndSizeRotate:179->testPeriodicAndSizeRotate0:347 Expected NO log rotation, but it happened anyways Handler: yyyy-MM-dda ; Message: yyyy-MM-dd-HH ; testSize=false Checking for log file here: /home/jperkins/projects/jboss/logging/jboss-logmanager/target/logs/rotating-file-handler.log.2017-08-18AM List of log files: rotating-file-handler.log.2017-08-18AM rotating-file-handler.log -- End of listing -- {code} was (Author: jamezp): Of course this seems to be failing now. The {{yyyy-MM-dda}} pattern is failing at 11:00 am PDT. > PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy > -------------------------------------------------------------------- > > Key: LOGMGR-82 > URL: https://issues.jboss.org/browse/LOGMGR-82 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha3 > > > The rotation tests seem to fail at random days and times. The test {{testPeriodicAndSizeRotate}} needs to be looked at before re-enabling it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-82) PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-82?page=com.atlassian.jira.plugin.... ] James Perkins reopened LOGMGR-82: --------------------------------- Of course this seems to be failing now. The {{yyyy-MM-dda}} pattern is failing at 11:00 am PDT. > PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy > -------------------------------------------------------------------- > > Key: LOGMGR-82 > URL: https://issues.jboss.org/browse/LOGMGR-82 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha3 > > > The rotation tests seem to fail at random days and times. The test {{testPeriodicAndSizeRotate}} needs to be looked at before re-enabling it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-115) Writing the configuration file should handle properties with null values

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-115?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-115: -------------------------------------- The other option would be to have the {{setPropertyValueString()}} not allow for {{null}} values. This would likely be the best option which would require {{removeProperty()}} is used. > Writing the configuration file should handle properties with null values > ------------------------------------------------------------------------ > > Key: LOGMGR-115 > URL: https://issues.jboss.org/browse/LOGMGR-115 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Priority: Minor > > Currently in the configuration API if a property is set to {{null}} an NPE occurs during the write and is swallowed. The idea was the {{removeProperty()}} should be used in the API. We should though check for {{null}} values and either not write the value or leave the value blank and have the reader for the configuration assume a value of 0 length is {{null}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-115) Writing the configuration file should handle properties with null values

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-115?page=com.atlassian.jira.plugin... ] James Perkins edited comment on LOGMGR-115 at 8/18/17 2:06 PM: --------------------------------------------------------------- The other option would be to have the {{setPropertyValueString()}} not allow for {{null}} values. This would likely be the best option which would require {{removeProperty()}} is used. Something like: {code:java} public void setPropertyValueString(final String propertyName, final String value) throws IllegalArgumentException { if (isRemoved()) { throw new IllegalArgumentException(String.format("Cannot set property \"%s\" on %s \"%s\" (removed)", propertyName, getDescription(), getName())); } if (propertyName == null) { throw new IllegalArgumentException("propertyName is null"); } if (value == null) { throw new IllegalArgumentException(String.format("The value cannot be null for property %1$s, " + "use removeProperty(\"%1$s\") to remove the property", propertyName)); } setPropertyValueExpression(propertyName, ValueExpression.STRING_RESOLVER.resolve(value)); } {code} was (Author: jamezp): The other option would be to have the {{setPropertyValueString()}} not allow for {{null}} values. This would likely be the best option which would require {{removeProperty()}} is used. > Writing the configuration file should handle properties with null values > ------------------------------------------------------------------------ > > Key: LOGMGR-115 > URL: https://issues.jboss.org/browse/LOGMGR-115 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Priority: Minor > > Currently in the configuration API if a property is set to {{null}} an NPE occurs during the write and is swallowed. The idea was the {{removeProperty()}} should be used in the API. We should though check for {{null}} values and either not write the value or leave the value blank and have the reader for the configuration assume a value of 0 length is {{null}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3200) permissions.xml is not parsed if -Dorg.jboss.server.bootstrap.maxThreads is explicitly set

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3200: ---------------------------------------- Summary: permissions.xml is not parsed if -Dorg.jboss.server.bootstrap.maxThreads is explicitly set Key: WFCORE-3200 URL: https://issues.jboss.org/browse/WFCORE-3200 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 3.0.0.Beta31 Environment: Reproduced on both Windows and RedHat machines. Reporter: Marius Ani Assignee: jaikiran pai If -Dorg.jboss.server.bootstrap.maxThreads is explictily set in Wildfly, then, the permissions.xml file is not even parsed when the application is deployed. Debugging the Wildfly 8.2.0 source code revealed the problem in org.jboss.as.server.ServerService#addService:218 {code:java} if (configuration.getServerEnvironment().isAllowModelControllerExecutor()) { serviceBuilder.addDependency(Services.JBOSS_SERVER_EXECUTOR, ExecutorService.class, service.getExecutorServiceInjector()); } {code} The org.jboss.as.server.ServerEnvironment#allowModelControllerExecutor property is set to true if -Dorg.jboss.server.bootstrap.maxThreads was set. The above 'if' seems a little strange because a default value for maxThreads is always set in org.jboss.as.server.ServerEnvironment#getBootstrapMaxThreads even when the -Dorg.jboss.server.bootstrap.maxThreads property was not specified. This may also cause other things to not work properly when -Dorg.jboss.server.bootstrap.maxThreads is set. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1335) In a continuation required situation create the scope if it doesn't already exist

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1335?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1335. ----------------------------------- Resolution: Done > In a continuation required situation create the scope if it doesn't already exist > --------------------------------------------------------------------------------- > > Key: ELY-1335 > URL: https://issues.jboss.org/browse/ELY-1335 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Final, 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1338) Update FileAuditEndpoint to assemble byte[] outside of the synchronized block.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1338?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1338: ---------------------------------- Fix Version/s: 1.2.0.Beta1 > Update FileAuditEndpoint to assemble byte[] outside of the synchronized block. > ------------------------------------------------------------------------------ > > Key: ELY-1338 > URL: https://issues.jboss.org/browse/ELY-1338 > Project: WildFly Elytron > Issue Type: Bug > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Final, 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1338) Update FileAuditEndpoint to assemble byte[] outside of the synchronized block.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1338?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1338. ----------------------------------- Resolution: Done > Update FileAuditEndpoint to assemble byte[] outside of the synchronized block. > ------------------------------------------------------------------------------ > > Key: ELY-1338 > URL: https://issues.jboss.org/browse/ELY-1338 > Project: WildFly Elytron > Issue Type: Bug > Components: Audit > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Final, 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1337) Bootclassloader defined services lead to NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1337?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1337: ---------------------------------- Fix Version/s: 1.1.0.Final 1.2.0.Beta1 > Bootclassloader defined services lead to NPE > -------------------------------------------- > > Key: ELY-1337 > URL: https://issues.jboss.org/browse/ELY-1337 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jason Greene > Assignee: Jason Greene > Fix For: 1.1.0.Final, 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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