April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-548) Changing append on a file handler indicates a reload is required when it should be a runtime change

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-548?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-548: --------------------------------- Summary: Changing append on a file handler indicates a reload is required when it should be a runtime change (was: Changing append on a file handler indicates a reload is required when a restart is required) > Changing append on a file handler indicates a reload is required when it should be a runtime change > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-548 > URL: https://issues.jboss.org/browse/WFCORE-548 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Changing the {{append}} attribute at runtime results in the following output: > {code} > [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=append,value=false) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > A {{reload}} operation does not stop a file from being appended to. Either the behavior needs to change or the {{process-state}} should be "restart-required". > The issue is likely the file name is checked during boot and hasn't changed therefore the it's not set which would cause the stream to the file to be closed and reopened without the append. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-636) Logging operations should resolve runtime values off the operation

by James Perkins (JIRA)

James Perkins created WFCORE-636: ------------------------------------ Summary: Logging operations should resolve runtime values off the operation Key: WFCORE-636 URL: https://issues.jboss.org/browse/WFCORE-636 Project: WildFly Core Issue Type: Task Components: Logging Reporter: James Perkins Assignee: James Perkins Priority: Minor Some logging operations attempt to resolve runtime values from the operation where the updated model from the {{MODEL}} stage should be used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-633) Erroneous name attribute on root-logger after add-handler operation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-633?page=com.atlassian.jira.plugin... ] James Perkins resolved WFCORE-633. ---------------------------------- Resolution: Won't Fix See the comments on https://bugzilla.redhat.com/show_bug.cgi?id=1017881#c12 for the reason this won't be fixed. > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFCORE-633 > URL: https://issues.jboss.org/browse/WFCORE-633 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-635) Require placeholder resources for non-proxy runtime resources

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-635: --------------------------------------- Summary: Require placeholder resources for non-proxy runtime resources Key: WFCORE-635 URL: https://issues.jboss.org/browse/WFCORE-635 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.CR1 ReadResourceHandler has a nullSafeReadResource method that returns a PlaceholderResource for any address whose MRR says it's runtime: https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... That basically allows devs to not bother creating runtime resources, but breaks things where there's an assumption that no resource object will be present when no actual resource exists. See discussion at https://github.com/wildfly/wildfly/pull/6607 This JIRA is to get rid of that behavior, restricting it to, at most, proxy resource cases. See also WFCORE-580 which is a similar problem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-580?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-580: ------------------------------------ Description: Take the following hierarchy: - {code} keystore=xxx alias=yyy certificate-chain=default certificate-chain=x509 {code} keystore is a regular resource with storage=configuration. alias is a regular resource with storage=runtime certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. For the singleton resources however the following method is called: - {code} org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) {code} Within this method the following check takes place: - {code} if (resource != null && resource.hasChildren(childType)) { Set<String> childNames = resource.getChildrenNames(childType); if (element.isWildcard()) { set.addAll(childNames); } else if (childNames.contains(element.getValue())) { set.add(element.getValue()); } {code} Up to this point all is fine, the children the resource claims are available are the only ones added. But further down this happens: - {code} if (!element.isWildcard()) { ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); if (childReg != null && childReg.isRuntimeOnly()) { set.add(element.getValue()); } } {code} So even though the resource was previously checked and missing children excluded they are now added back. The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. >From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. was: Take the following hierarchy: - keystore=xxx alias=yyy certificate-chain=default certificate-chain=x509 keystore is a regular resource with storage=configuration. alias is a regular resource with storage=runtime certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. For the singleton resources however the following method is called: - {code} org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) {code} Within this method the following check takes place: - {code} if (resource != null && resource.hasChildren(childType)) { Set<String> childNames = resource.getChildrenNames(childType); if (element.isWildcard()) { set.addAll(childNames); } else if (childNames.contains(element.getValue())) { set.add(element.getValue()); } {code} Up to this point all is fine, the children the resource claims are available are the only ones added. But further down this happens: - {code} if (!element.isWildcard()) { ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); if (childReg != null && childReg.isRuntimeOnly()) { set.add(element.getValue()); } } {code} So even though the resource was previously checked and missing children excluded they are now added back. The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. >From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. > Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-580 > URL: https://issues.jboss.org/browse/WFCORE-580 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 1.0.0.CR1 > > > Take the following hierarchy: - > {code} > keystore=xxx > alias=yyy > certificate-chain=default > certificate-chain=x509 > {code} > keystore is a regular resource with storage=configuration. > alias is a regular resource with storage=runtime > certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. > So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. > The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. > For the singleton resources however the following method is called: - > {code} > org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) > {code} > Within this method the following check takes place: - > {code} > if (resource != null && resource.hasChildren(childType)) { > Set<String> childNames = resource.getChildrenNames(childType); > if (element.isWildcard()) { > set.addAll(childNames); > } else if (childNames.contains(element.getValue())) { > set.add(element.getValue()); > } > {code} > Up to this point all is fine, the children the resource claims are available are the only ones added. > But further down this happens: - > {code} > if (!element.isWildcard()) { > ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); > if (childReg != null && childReg.isRuntimeOnly()) { > set.add(element.getValue()); > } > } > {code} > So even though the resource was previously checked and missing children excluded they are now added back. > The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. > From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-489?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-489: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/607 (was: https://github.com/wildfly/wildfly-core/pull/428) > The "access-mechanism" field in the active-operation resources is always undefined > ---------------------------------------------------------------------------------- > > Key: WFCORE-489 > URL: https://issues.jboss.org/browse/WFCORE-489 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.CR1 > > > The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: > {code} > ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); > if (accessMechanism != null) { > accessMechanismNode.set(accessMechanismNode.toString()); > } > {code} > It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4473) javax.ejb.ConcurrentAccessTimeoutException does not specify the offending EJB

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4473?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-4473: ------------------------------------ Assignee: Stuart Douglas > javax.ejb.ConcurrentAccessTimeoutException does not specify the offending EJB > ----------------------------------------------------------------------------- > > Key: WFLY-4473 > URL: https://issues.jboss.org/browse/WFLY-4473 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Carlo de Wolf > Assignee: Stuart Douglas > > {noformat} > javax.ejb.ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@75b60094 - could not obtain lock within 5000 MILLISECONDS > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ The proposed solution as given will not likely be accepted, thus it's not worth further analysis. See my comments above regarding how such a feature must be implemented to have acceptable performance characteristics. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2643) Pass the jboss.server.log.dir parameter to the global system properties

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ] James Perkins resolved WFLY-2643. --------------------------------- Resolution: Won't Fix There is a workaround to use the {{-Djboss.server.log.dir}} system property via the command line or via the {{standalone.conf(.bat)}}. I'd rather not make any changes to the scripts if possible as we've had issues with them recently. > Pass the jboss.server.log.dir parameter to the global system properties > ----------------------------------------------------------------------- > > Key: WFLY-2643 > URL: https://issues.jboss.org/browse/WFLY-2643 > Project: WildFly > Issue Type: Enhancement > Components: Logging, Server > Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1 > Environment: All > Reporter: Stian Lund > Priority: Optional > Labels: jbossas, logging, wildfly > > In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for: > {code} > # determine the default log dir, if not set > if [ "x$JBOSS_LOG_DIR" = "x" ]; then > JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log" > fi > {code} > However, this is not actually used to set the value of Java property jboss.server.log.dir. > {code} > -Djboss.home.dir="$JBOSS_HOME" > -Djboss.server.base.dir="$JBOSS_BASE_DIR" > "$SERVER_OPTS" > {code} > (It should be set at the same place) > This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log. > This is a problem for those who want to override the location of the server.log files. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4495) Remove Duplicate Versions and Groupids

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4495: ---------------------------------------- Summary: Remove Duplicate Versions and Groupids Key: WFLY-4495 URL: https://issues.jboss.org/browse/WFLY-4495 Project: WildFly Issue Type: Patch Components: Build System Reporter: Philippe Marschall Assignee: Paul Gier Maven POMs inherit the version and groupId from the parent, there is no need to repeat them. Some POMs currently repeat them while others don't. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015