[JBoss JIRA] (WFLY-3031) Management audit logging logs parallel boot ops in separate records
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3031?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3031:
-----------------------------------
Summary: Management audit logging logs parallel boot ops in separate records (was: Management audit logging does not log parallel boot ops)
Issue Type: Enhancement (was: Bug)
Fix Version/s: 9.0.0.CR1
(was: 8.0.1.Final)
Description:
The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff.
This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops.
was:
The parallel boot ops (i.e. the subsystem stuff) are not part of the set recorded and logged.
Priority: Major (was: Critical)
I was wrong in my initial report; these actually are logged, just somewhat oddly. I'm not certain we should fix this, but my instinct is we should.
> Management audit logging logs parallel boot ops in separate records
> -------------------------------------------------------------------
>
> Key: WFLY-3031
> URL: https://issues.jboss.org/browse/WFLY-3031
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff.
> This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-1188) allow custom-formatter configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661] from POST to MODIFIED
> allow custom-formatter configuration
> ------------------------------------
>
> Key: WFLY-1188
> URL: https://issues.jboss.org/browse/WFLY-1188
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Aleksandar Kostadinov
> Assignee: James Perkins
> Labels: as7, formatting, logging
> Fix For: 8.0.0.CR1
>
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned LOGMGR-95:
-----------------------------------
Assignee: James Perkins (was: David Lloyd)
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Livingston
> Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3035) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3035?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-50 to WFLY-3035:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-3035 (was: JBEAP-50)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Affects Version/s: 8.0.0.Final
(was: EAP 6.2.0.Final)
Component/s: Domain Management
(was: Domain Management)
Security: Public
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3035
> URL: https://issues.jboss.org/browse/WFLY-3035
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Assignee: Brian Stansberry
> Priority: Minor
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3004) properties are not resolved for arguments of commands handled on the client-side
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3004?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-3004:
------------------------------------
Summary: properties are not resolved for arguments of commands handled on the client-side (was: properties are not resolved in a connect command line within a cli batch file)
Fix Version/s: 8.0.1.Final
I've modified the summary of this issue to describe the issue in general.
That's true, system properties *in argument* value are not resolved for commands handled on the client side, e.g. connect, ls, cd, etc.
> properties are not resolved for arguments of commands handled on the client-side
> --------------------------------------------------------------------------------
>
> Key: WFLY-3004
> URL: https://issues.jboss.org/browse/WFLY-3004
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Final
> Environment: windows 7 and centos 6.4
> Reporter: Gabriele Garuglieri
> Assignee: Alexey Loubyansky
> Fix For: 8.0.1.Final
>
>
> When using cli for batch files using --file and --properties arguments, any property is resolved but for those defined in the connect command line.
> The properties file contains (among the others):
> server.bind.addr = xxxxx
> server.management.port = 9990
> Having:
> connect ${server.bind.addr}
> in the batch file gets
> ERROR [org.jboss.as.cli.CommandContext] Failed to resolve host '${server.bind.addr}': Failed to create URI: Illegal character in authority at index 16: http-remoting://${server.bind.addr}:9990
> Having:
> connect ${server.bind.addr}:${server.management.port}
> gets:
> ERROR [org.jboss.as.cli.CommandContext] The port must be a valid non-negative integer: '${server.bind.addr}:${server.management.
> If i use literal values for the connect command, any other property in the batch is correctly resolved (but that's exactly what i was trying to avoid)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3031) Management audit logging does not log parallel boot ops
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3031?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3031:
----------------------------------------
Definitely. The audit logging config has an attribute to let you enable/disable logging boot ops, but if they are turned on we shouldn't be skipping 3/4 of them.
Logging boot ops lets you see if something unexpected has come in via the config file.
> Management audit logging does not log parallel boot ops
> -------------------------------------------------------
>
> Key: WFLY-3031
> URL: https://issues.jboss.org/browse/WFLY-3031
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 8.0.1.Final
>
>
> The parallel boot ops (i.e. the subsystem stuff) are not part of the set recorded and logged.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2916) getSerlvetPath() truncates path at the first semicolon
by Rossen Stoyanchev (JIRA)
[ https://issues.jboss.org/browse/WFLY-2916?page=com.atlassian.jira.plugin.... ]
Rossen Stoyanchev commented on WFLY-2916:
-----------------------------------------
These are the references I could find in the Servlet 3.1 spec:
Section 3.1:
bq. Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method
Section 12.1:
bq. The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters.
And the Javadoc for getServletPath():
{noformat}
* Returns the part of this request's URL that calls
* the servlet. This path starts with a "/" character
* and includes either the servlet name or a path to
* the servlet, but does not include any extra path
* information or a query string.
{noformat}
It does say path parameters should be removed but it doesn't say the path should be truncated. Truncating makes getServletPath useless.
Since the Servlet API still does not provide any way to find out how a Servlet is mapped, trying to determine the actual path to use for mapping purposes can be tricky and involves checking all of: getRequestUri(0, getServletPath(), and getPathInfo(). Truncation makes this determination even harder.
> getSerlvetPath() truncates path at the first semicolon
> ------------------------------------------------------
>
> Key: WFLY-2916
> URL: https://issues.jboss.org/browse/WFLY-2916
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Rossen Stoyanchev
> Assignee: Stuart Douglas
>
> Given a URL path with path parameters (e.g. "/data/matrixvars;foo=bar1/multiple;foo=bar2"), depending on the Servlet mapping (e.g. with "/" the whole path after the context path is the servlet path), a call to getServletPath() is truncated after the first semicolon (e.g. "/data/matrixvars").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2916) getSerlvetPath() truncates path at the first semicolon
by Rossen Stoyanchev (JIRA)
[ https://issues.jboss.org/browse/WFLY-2916?page=com.atlassian.jira.plugin.... ]
Rossen Stoyanchev edited comment on WFLY-2916 at 2/27/14 11:07 AM:
-------------------------------------------------------------------
These are the references I could find in the Servlet 3.1 spec:
Section 3.1:
bq. Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method
Section 12.1:
bq. The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters.
And the Javadoc for getServletPath():
{noformat}
* Returns the part of this request's URL that calls
* the servlet. This path starts with a "/" character
* and includes either the servlet name or a path to
* the servlet, but does not include any extra path
* information or a query string.
{noformat}
It does say path parameters should be removed but it doesn't say the path should be truncated. Truncating makes getServletPath useless.
Since the Servlet API still does not provide any way to find out how a Servlet is mapped, trying to determine the actual path to use for mapping purposes can be tricky and involves checking all of: getRequestUri(), getServletPath(), and getPathInfo(). Truncation makes this determination even harder.
was (Author: rstoyanchev):
These are the references I could find in the Servlet 3.1 spec:
Section 3.1:
bq. Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method
Section 12.1:
bq. The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters.
And the Javadoc for getServletPath():
{noformat}
* Returns the part of this request's URL that calls
* the servlet. This path starts with a "/" character
* and includes either the servlet name or a path to
* the servlet, but does not include any extra path
* information or a query string.
{noformat}
It does say path parameters should be removed but it doesn't say the path should be truncated. Truncating makes getServletPath useless.
Since the Servlet API still does not provide any way to find out how a Servlet is mapped, trying to determine the actual path to use for mapping purposes can be tricky and involves checking all of: getRequestUri(0, getServletPath(), and getPathInfo(). Truncation makes this determination even harder.
> getSerlvetPath() truncates path at the first semicolon
> ------------------------------------------------------
>
> Key: WFLY-2916
> URL: https://issues.jboss.org/browse/WFLY-2916
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Rossen Stoyanchev
> Assignee: Stuart Douglas
>
> Given a URL path with path parameters (e.g. "/data/matrixvars;foo=bar1/multiple;foo=bar2"), depending on the Servlet mapping (e.g. with "/" the whole path after the context path is the servlet path), a call to getServletPath() is truncated after the first semicolon (e.g. "/data/matrixvars").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months