[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2806:
------------------------------------------
Never mind the bit in my previous comment about "read-resource(recursive=true,resolve-expressions=true)". I forgot that the "resolve-expressions" parameter is not supported on an HC, and even if we brought it to some parts of the HC tree (e.g. host subsystems) we wouldn't bring it to these resources.
So, my concern about "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" still applies, but it's quite a bit less of a concern since the specific problem case I could think of isn't real.
> Global domain config for unique GC log file name and path
> ---------------------------------------------------------
>
> Key: WFCORE-2806
> URL: https://issues.jboss.org/browse/WFCORE-2806
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Aaron Ogburn
> Labels: domain-mode
>
> Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members:
> {code}
> <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/>
> {code}
> But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is:
> {code}
> <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/>
> {code}
> But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2806 at 10/19/17 12:27 PM:
---------------------------------------------------------------------
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve-expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.
was (Author: brian.stansberry):
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. -So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve---expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve---expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.-
> Global domain config for unique GC log file name and path
> ---------------------------------------------------------
>
> Key: WFCORE-2806
> URL: https://issues.jboss.org/browse/WFCORE-2806
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Aaron Ogburn
> Labels: domain-mode
>
> Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members:
> {code}
> <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/>
> {code}
> But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is:
> {code}
> <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/>
> {code}
> But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3375) Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
by James Perkins (JIRA)
James Perkins created WFCORE-3375:
-------------------------------------
Summary: Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
Key: WFCORE-3375
URL: https://issues.jboss.org/browse/WFCORE-3375
Project: WildFly Core
Issue Type: Component Upgrade
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
The {{org.jboss.logmanager:jboss-logmanager:2.1.0.Alpha6}} will introduce a new {{CallerClassLoaderLogContextListener}} which needs to be used to ensure that modules don't create loggers on a deployments log context.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2806 at 10/19/17 12:26 PM:
---------------------------------------------------------------------
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. -So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve---expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve---expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.-
was (Author: brian.stansberry):
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. -So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve-expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.-
> Global domain config for unique GC log file name and path
> ---------------------------------------------------------
>
> Key: WFCORE-2806
> URL: https://issues.jboss.org/browse/WFCORE-2806
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Aaron Ogburn
> Labels: domain-mode
>
> Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members:
> {code}
> <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/>
> {code}
> But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is:
> {code}
> <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/>
> {code}
> But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2806 at 10/19/17 12:25 PM:
---------------------------------------------------------------------
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. -So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve-expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.-
was (Author: brian.stansberry):
Possibilities:
1) Where possible use a different expression resolver for these such that the standard ${jboss.server.xxx} properties available on the server are also available to the HC. This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch.
2) A simpler variant of that would be
<option value="-Xloggc:${jboss.domain.servers.dir}/${jboss.special.property.for.server.being.launched}/log/gc.log"/>
That's simpler because now we don't have to worry about all the different standard ${jboss.server.xxx}
properties and the different ways they can be configured. But the user has to understand this special property.
3) Another variant is to use special expression syntax instead of a special property:
<option value="-Xloggc:${jboss.domain.servers.dir}/##server.name##/log/gc.log"/>
But I don't like that at all as it opens up a whole can of worms where now we may need to check for that syntax elsewhere, need new expression resolution logic etc.
The fly in the ointment for all of these is the "This would only work if the expression is being resolved in a context where there is one and only one relevant server, i.e. during server launch" bit. So something like this would not work normally:
/host=master:read-resource(recursive=true,resolve-expressions=true)
Even something more targeted would not work:
/host=master/server-config=server-one/jvm=default:read-resource(recursive=true,resolve-expressions=true)
This is because the read-resource op is generic. And adding a lot of exception logic to it to handle special cases is not likely to be feasible.
> Global domain config for unique GC log file name and path
> ---------------------------------------------------------
>
> Key: WFCORE-2806
> URL: https://issues.jboss.org/browse/WFCORE-2806
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Aaron Ogburn
> Labels: domain-mode
>
> Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members:
> {code}
> <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/>
> {code}
> But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is:
> {code}
> <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/>
> {code}
> But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3374) The property test.level might not be (re)defined in the module's pom
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-3374:
-----------------------------------------
Summary: The property test.level might not be (re)defined in the module's pom
Key: WFCORE-3374
URL: https://issues.jboss.org/browse/WFCORE-3374
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 4.0.0.Alpha1
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Priority: Minor
Getting an exception when instantiating a container:
ava.lang.IllegalArgumentException: Unknown level ""
at org.jboss.logmanager.LogContext.getLevelForName(LogContext.java:203)
This is due to the test.level property not being properly set in the server module pom thus leaving a handler.CONSOLE.level="" in the logging.properties.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3373) Add an HC reload API to DomainLifecycleUtil
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3373:
----------------------------------------
Summary: Add an HC reload API to DomainLifecycleUtil
Key: WFCORE-3373
URL: https://issues.jboss.org/browse/WFCORE-3373
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Priority: Minor
DomainLifecycleUtil includes a number of methods that when combined are the right way to do an HC reload in tests. Effect is we have a number of spots in the domain testsuite where these are being combined. Task here is to work out a useful overall method that can handle the bulk of these cases in 1 go.
Methods are:
executeAwaitConnectionClosed
awaitHostController
awaitServers
A vague thought is to add a "reload" method with a few params that can configure the reload op (admin-only, restart-servers) and determine whether and how long the method should wait for HC reload and whether and how the method should wait for server reload. Use Boolean and Long for params instead of primitives, with null meaning ignore that bit.
See the ServerReload class which has similar utils for standalone servers.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months