April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4518) enable undertow access logs to use logging subsystem

by Matt Drees (JIRA)

Matt Drees created WFLY-4518: -------------------------------- Summary: enable undertow access logs to use logging subsystem Key: WFLY-4518 URL: https://issues.jboss.org/browse/WFLY-4518 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 8.2.0.Final Reporter: Matt Drees Assignee: Stuart Douglas The access log mechanism exposed by the undertow subsystem only writes to a file. It cannot be configured to 'write' to the jboss logging subsystem. This would be useful to, for example, use the syslog appender. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3901) Please add the "relative-to" attribute to access-log in undertow

by Carlton Zachary (JIRA)

[ https://issues.jboss.org/browse/WFLY-3901?page=com.atlassian.jira.plugin.... ] Carlton Zachary commented on WFLY-3901: --------------------------------------- Hi Tomaz, Any update on this? Thanks. > Please add the "relative-to" attribute to access-log in undertow > ---------------------------------------------------------------- > > Key: WFLY-3901 > URL: https://issues.jboss.org/browse/WFLY-3901 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Carlton Zachary > Assignee: Tomaz Cerar > > I have been trying to point the "directory" attribute value to a var ${custom.jboss.server.log.dir} to write the access.log to a non-default location, but this diesn't work in undertow. It does work in EAP 6.2 JBoss-web. The custom.jboss.server.log.dir is defined in the "<paths>" in the servers section of the host-slave.xml file. > In JBoss EAP 6.2 with jboss-web the access-log has the "relative-to" attribute, but this is not the case with access-log for undertow in WFLY 8.1. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-640) Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found"

by Brandon Gaisford (JIRA)

[ https://issues.jboss.org/browse/WFCORE-640?page=com.atlassian.jira.plugin... ] Brandon Gaisford commented on WFCORE-640: ----------------------------------------- I'm code complete on this issue and have completed my developer level testing. Looking to start on the unit tests. I posted an email to wildfly-dev regarding the units test to be written... Waiting for some feedback before proceeding. > Bad permissions on properties files when using add-user.bat for results in "JBAS015234: No mgmt-groups.properties files found" > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-640 > URL: https://issues.jboss.org/browse/WFCORE-640 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Windows 7, 32-bit, jdk1.7.0_45 > Reporter: John Lusk > > Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user. > c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat > What type of user do you wish to add? > a) Management User (mgmt-users.properties) > b) Application User (application-users.properties) > (a): a > * Error * > JBAS015234: No mgmt-groups.properties files found. > Press any key to continue . . . > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME% > C:\usr\local\wildfly-8.0.0.Beta1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME% > C:\java\jdk1.7.0_45 > c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME% > C:\usr\local\Maven\3.1.1 > c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version > Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2 > 2-0400) > Maven home: C:\usr\local\Maven\3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > Java home: C:\java\jdk1.7.0_45\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "windows" > c:\usr\local\wildfly-8.0.0.Beta1\bin> -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-642) ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-642?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-642: ----------------------------------------- Example of an issue caused by this: https://gist.github.com/heiko-braun/62097308030d0d4ff423 > ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely > -------------------------------------------------------------------------------------- > > Key: WFCORE-642 > URL: https://issues.jboss.org/browse/WFCORE-642 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.CR1 > > > Getting WFCORE-282 to work surfaces a problem with :read-operation-description handling, which will get invoked in the background by the CLI whenever the user inputs a wildcard read op. > Problem is ReadOperationDescriptionHandler.getDescribedOp, which attempts to deal with cases where there is no resource registration for the target address. It checks if the request is for a wildcard address, and if so it sees if there are concrete registrations for that address, and if so whether they all use the same description. If yes, it provides the description. > This is broken in a couple ways: > 1) It assumes the wildcard applies to the last element in the address, which may not be the case with ops that support wildcard addressing schemes. > 2) It looks vulnerable to problems with proxy resources, particularly the /host=* case on the DC where there can be a normal ConcreteResourceRegistration for the local host=master child, and then ProxyControllerRegistration instances for the various host=slave-x registrations. I suspect this might lead to false results. -- 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 John Mezzetta (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta commented on LOGMGR-120: -------------------------------------- Thanks James! We are give you feedback regarding our performance testing using the solution within the next few days. Regards, John > 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] (JBJCA-1261) Rework pool policies

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1261?page=com.atlassian.jira.plugin... ] Jesper Pedersen reopened JBJCA-1261: ------------------------------------ > Rework pool policies > -------------------- > > Key: JBJCA-1261 > URL: https://issues.jboss.org/browse/JBJCA-1261 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.4.Final > > > Let the pool policy (FIFO/FILO) be defined by its decrementer policy -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1261) Rework pool policies

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1261?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1261. ---------------------------------- Fix Version/s: 1.1.10.Final Resolution: Done > Rework pool policies > -------------------- > > Key: JBJCA-1261 > URL: https://issues.jboss.org/browse/JBJCA-1261 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.10.Final, 1.2.4.Final > > > Let the pool policy (FIFO/FILO) be defined by its decrementer policy -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4448) Batch creates a JdbcJobRepository per deployment where only one global repository should be used

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4448?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-4448: ------------------------------------- The resources to display batch jobs from the console will live on the deployment. In CLI the path is {{/deployment=my.war/subsystem=batch/}}. This is where jobs will be displayed by the job name. {code:title=Example CLI output} [standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=batch:read-resource(include-runtime=true,recursive=true) { "outcome" => "success", "result" => {"job" => {"chunkPartition" => { "instance-count" => 1, "running-executions" => 0, "execution" => {"1" => { "batch-status" => "COMPLETED", "create-time" => "2015-04-14T11:29:39.008-0700", "end-time" => "2015-04-14T11:29:39.033-0700", "exit-status" => "COMPLETED", "instance-id" => 1L, "last-updated-time" => "2015-04-14T11:29:39.033-0700", "start-time" => "2015-04-14T11:29:39.008-0700" }} }}} } {code} If a deployment uses a shared JDBC data source (the only current option) they could see all jobs from all applications using the same data source. The management operations will limit the available jobs to those allowed to be seen by the deployment. We may be able to add that constraint by overriding the {{JobOperator}}. I'm not sure we want to go there at this point though. > Batch creates a JdbcJobRepository per deployment where only one global repository should be used > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4448 > URL: https://issues.jboss.org/browse/WFLY-4448 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > When the batch subsystem is configured to use a JDBC job repository a new {{JdbcJobRepository}} is created for each application deployed. A global {{JdbcJobRepository}} should be used. -- 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 James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- To use this feature set the {{org.jboss.logmanager.useThreadLocalFilter}} system property to {{true}}. In WildFly this would need to be done in the {{standalone.conf(.bat)}} by adding {{-Dorg.jboss.logmanager.useThreadLocalFilter=true}} to the {{JAVA_OPTS}}. Then use {{LogManager.setThreadLocalLogLevel(Filter)}} to set the filter for the thread. To remove the filter pass {{null}} to the setter. > 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] (WFCORE-642) ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-642: --------------------------------------- Summary: ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely Key: WFCORE-642 URL: https://issues.jboss.org/browse/WFCORE-642 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.CR1 Getting WFCORE-282 to work surfaces a problem with :read-operation-description handling, which will get invoked in the background by the CLI whenever the user inputs a wildcard read op. Problem is ReadOperationDescriptionHandler.getDescribedOp, which attempts to deal with cases where there is no resource registration for the target address. It checks if the request is for a wildcard address, and if so it sees if there are concrete registrations for that address, and if so whether they all use the same description. If yes, it provides the description. This is broken in a couple ways: 1) It assumes the wildcard applies to the last element in the address, which may not be the case with ops that support wildcard addressing schemes. 2) It looks vulnerable to problems with proxy resources, particularly the /host=* case on the DC where there can be a normal ConcreteResourceRegistration for the local host=master child, and then ProxyControllerRegistration instances for the various host=slave-x registrations. I suspect this might lead to false results. -- 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