[JBoss JIRA] (WFLY-11109) Fix PatterFormatter documentation for host name pattern
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11109?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11109:
---------------------------------
Description:
Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the first segment of the host.
The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
{code:title=Current Output}
org
{code}
{code:title=Expected Output}
developer
{code}
was:
Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the last segment of the host.
The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
{code:title=Current Output}
org
{code}
{code:title=Expected Output}
developer
{code}
> Fix PatterFormatter documentation for host name pattern
> -------------------------------------------------------
>
> Key: WFLY-11109
> URL: https://issues.jboss.org/browse/WFLY-11109
> Project: WildFly
> Issue Type: Task
> Components: Documentation
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the first segment of the host.
> The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
> {code:title=Current Output}
> org
> {code}
> {code:title=Expected Output}
> developer
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-11109) Fix PatterFormatter documentation for host name pattern
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11109?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11109:
---------------------------------
Description:
Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the last segment of the host.
The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
{code:title=Current Output}
org
{code}
{code:title=Expected Output}
developer
{code}
was:
Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the first segment of the host.
The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
{code:title=Current Output}
org
{code}
{code:title=Expected Output}
developer
{code}
> Fix PatterFormatter documentation for host name pattern
> -------------------------------------------------------
>
> Key: WFLY-11109
> URL: https://issues.jboss.org/browse/WFLY-11109
> Project: WildFly
> Issue Type: Task
> Components: Documentation
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> Currently the short host name pattern, {{%h}}, is documented as allowing the a precision argument to be added. This should not be allowed and the short host should only be the last segment of the host.
> The qualified host name pattern, {{%H}}, indicates the precision is done left to right just like a log category or class name. However in general a host name is the opposite direction and thus should be segmented from right to left instead. For example given the host name {{developer.jboss.org}} and a pattern of {{%H\{1\}}}:
> {code:title=Current Output}
> org
> {code}
> {code:title=Expected Output}
> developer
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-4364) Allow management audit logging to write JSON log messages to stdout
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4364?page=com.atlassian.jira.plugi... ]
James Perkins edited comment on WFCORE-4364 at 5/31/19 4:56 PM:
----------------------------------------------------------------
Looking more at the data it's going to have to be fully restructured. The data looks like an object. It's probably going to have to look more like:
{code}
{
"timestamp" : "2019-03-08 13:29:49"
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "8.0.1.CR1-SNAPSHOT",
"user" : "$local",
"domainUUID" : null,
"access" : "NATIVE",
"remote-address" : "localhost/127.0.0.1",
"success" : true,
"opAddress" : "/subsystem=logging/json-formatter=json",
"op" : "remove",
"caller-type" : "user",
"access-mechanism" : "NATIVE"
}
{code}
Note we need to determine what values can end up in the {{operation-headers}} object.
was (Author: jamezp):
Looking more at the data it's going to have to be fully restructured. The date looks like an object. It's probably going to have to look more like:
{code}
{
"timestamp" : "2019-03-08 13:29:49"
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "8.0.1.CR1-SNAPSHOT",
"user" : "$local",
"domainUUID" : null,
"access" : "NATIVE",
"remote-address" : "localhost/127.0.0.1",
"success" : true,
"opAddress" : "/subsystem=logging/json-formatter=json",
"op" : "remove",
"caller-type" : "user",
"access-mechanism" : "NATIVE"
}
{code}
Note we need to determine what values can end up in the {{operation-headers}} object.
> Allow management audit logging to write JSON log messages to stdout
> -------------------------------------------------------------------
>
> Key: WFCORE-4364
> URL: https://issues.jboss.org/browse/WFCORE-4364
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging, Management
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> Management audit logging can already log messages in JSON format. However these can only be written to a file or a syslog server. We need the ability for these messages to be written to {{stdout}}. This is useful for containers like OpenShift which consume the {{stdout}} data to feed to log aggregators.
> Example Output:
> {code}
> 2019-03-08 13:29:49 - {
> "type" : "core",
> "r/o" : false,
> "booting" : false,
> "version" : "8.0.1.CR1-SNAPSHOT",
> "user" : "$local",
> "domainUUID" : null,
> "access" : "NATIVE",
> "remote-address" : "localhost/127.0.0.1",
> "success" : true,
> "ops" : [{
> "address" : [
> {
> "subsystem" : "logging"
> },
> {
> "json-formatter" : "json"
> }
> ],
> "operation" : "remove",
> "operation-headers" : {
> "caller-type" : "user",
> "access-mechanism" : "NATIVE"
> }
> }]
> }
> {code}
> Note for a log aggregator the complex {{ops}} attribute can be an issue. We may need to find a better way to log that. If possibly maybe convert it into a CLI command.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (DROOLS-4089) EvaluatedExpression not well resolved with JIT during race
by vincent palau (Jira)
[ https://issues.jboss.org/browse/DROOLS-4089?page=com.atlassian.jira.plugi... ]
vincent palau commented on DROOLS-4089:
---------------------------------------
Oh yes, Great news :D
I'm not sure about your release cycles.
At each Sprint?
When it will be available on the maven repo?
Thanks a lot for this quick fix!
> EvaluatedExpression not well resolved with JIT during race
> ------------------------------------------------------------
>
> Key: DROOLS-4089
> URL: https://issues.jboss.org/browse/DROOLS-4089
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.20.0.Final, 7.22.0.Final
> Reporter: vincent palau
> Assignee: Mario Fusco
> Priority: Major
> Attachments: debugging-1.png
>
>
> We recently moved from Drools 7.9.0 to 7.20.
> Some errors started appearing in ours tests when calling static methods in LHS drools.
> This started happening when all tests were run simultaneously.
> It seems the mvel JIT compiler kicks in and it incorrectly evaluates the property name:
> A simple call to {noformat}ValidationUtils.isNullOrEmpty(interestedPartyNumber){noformat} ends up with this kind of error:
> {noformat}
> "java.lang.RuntimeException: Unknown property 'nullOrEmpty' on class tech.stage.utils.cwr.model.PublisherRecord"
> {noformat}
> Debugging info:
> Related source-code: https://github.com/kiegroup/drools/blob/7.20.0.Final/drools-core/src/main...
> !debugging-1.png|full!
> 1) is the current evaluated property
> 2) Should be the right property of WriterRecord
> 3) Perhaps the expression which should be executed instead of invocations.get(0)
> We fixed that somehow disabling JIT with {noformat}ConstraintJittingThresholdOption{noformat}
> Is there any chance to this bug fixed?
> Do you need more info?
> Thanks in advance for your support.
> {panel:title=Reproducer}
> https://github.com/vp-stage/evaluatedexpressionandjit
> {panel}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved WFLY-1598.
------------------------------
Resolution: Duplicate Issue
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 17.0.0.Final
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-1598:
----------------------------------
[~jamezp] This is now being tracked via EAP7-1090 and its corresponding community issue, WFCORE-4482. I'm going to close this subtask.
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 17.0.0.Final
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months