[SHIRO-820] - Fix Log4j2 logs format

[ksilisk]

When using the utility, I noticed that the logs were displayed incorrectly.
I found a similar problem in Jira, but I think the [INFO ] output is correct, but the space after it is a consequence of incorrect logger settings, which I corrected.
Also update log message.

JIRA issue https://issues.apache.org/jira/browse/SHIRO-820

Following this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [SHIRO-XXX] - Fixes bug in SessionManager,
  where you replace SHIRO-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• If you have a group of commits related to the same change, please squash your commits into one and force push your branch using git rebase -i.
• Committers: Make sure a milestone is set on the PR

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
In this case, just format the pull request title like [DOC] - Add javadoc in SessionManager.

If this is your first contribution, you have to read the Contribution Guidelines

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement
if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[bmarwell]

Interesting. looking at this, the old hasher CLI tool just gave the hash as the output. Now, we get an additional [INFO ] prefix. For parsing, leaving out the prefix would be beneficial.

Then, the -5level is probably to align output nicely:

[DEBUG] message
[INFO ] hash: …
[WARN ] a warning
[ERROR] an error

That said, I'd prefer to rather change the pattern in log4j.xml to just %msg%n for compatibility and leave the LOG.info statement as-is for easier parsing. Interesting. looking at this, the old hasher CLI tool just gave the hash as the output. Now, we get an additional [INFO ] prefix. For parsing, leaving out the prefix would be beneficial.

Then, the -5level is probably to align output nicely:

[DEBUG] message
[INFO ] hash: …
[WARN ] a warning
[ERROR] an error

That said, I'd prefer to rather change the pattern in log4j.xml to just %msg%n for compatibility and leave the LOG.info statement as-is for easier parsing.

[ksilisk]

Interesting. looking at this, the old hasher CLI tool just gave the hash as the output. Now, we get an additional [INFO ] prefix. For parsing, leaving out the prefix would be beneficial.

Then, the -5level is probably to align output nicely:

[DEBUG] message
[INFO ] hash: …
[WARN ] a warning
[ERROR] an error

That said, I'd prefer to rather change the pattern in log4j.xml to just %msg%n for compatibility and leave the LOG.info statement as-is for easier parsing. Interesting. looking at this, the old hasher CLI tool just gave the hash as the output. Now, we get an additional [INFO ] prefix. For parsing, leaving out the prefix would be beneficial.

Then, the -5level is probably to align output nicely:

[DEBUG] message
[INFO ] hash: …
[WARN ] a warning
[ERROR] an error

That said, I'd prefer to rather change the pattern in log4j.xml to just %msg%n for compatibility and leave the LOG.info statement as-is for easier parsing.

Thanks for the answer @bmarwell!

No, before this the hash output looked like this

[INFO ] some_hash

In my opinion, the presence of a prefix is actually not correct, as was described in the SHIRO-820 issue.

I think that the best solution would be to display the hash in System.out without any prefix.
Then that will solve SHIRO-820.

In this case, there is no need to change the log4j2.xml
Just change LOG.info to System.out.println

If you agree with my decision, I'm ready to correct it.

[lprimak]

fixed as per @bmarwell

fixed as per Benjamin's changes

[lprimak]

Thank you @ksilisk for your contribution!