[keycloak-dev] i18n for Logging

[Stian Thorgersen]

Ok, let's just keep debug and trace statements as is then. If WildFly can
get away without codes and internationalization of those so can we.

On 18 January 2016 at 19:52, Stan Silvert <ssilvert at redhat.com> wrote:

> On 1/18/2016 1:23 PM, Stian Thorgersen wrote:
>
>
>
> On 18 January 2016 at 16:45, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 1/18/2016 9:56 AM, Stan Silvert wrote:
>>
>> On 1/18/2016 8:25 AM, Stan Silvert wrote:
>>
>> On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>>
>> Looks good how you've done it.
>>
>> Bill is currently working on re-organizing code, but he's not going to
>> move anything from services. So can you finish up services and send a PR
>> for it? Then you can do the other logging once Bill is completed.
>>
>> Assuming nobody has an objection to the proposed format, I'll go ahead
>> and finish services.
>>
>>
>> Another thing to consider is DEBUG logging.  Do we want to localize debug
>> messages?
>>
>> I grepped the WildFly code.  I could only find a handful of examples
>> where somebody localized a debug message.  Looks like for the most part,
>> their debug messages are not localized.
>>
>
> We barely have any info logging, neither does WildFly. Seems weird to
> treat them differently.
>
> Yes,  from what I've seen so far, most of our logging is ERROR, WARN, or
> DEBUG.  Very little INFO and a tiny bit of TRACE.
>
>
> Is it just internationalization or log codes as well they don't have for
> debug?
>
> Neither.  Except for a couple of places I found, they aren't doing
> anything special with debug messages.
>
> Debug messages can still get logged using the same per-module logger that
> is used for localized logging.  So we can have:
> protected static ServicesLogger logger = ServicesLogger.ROOT_LOGGER;
> ....
> logger.debugv("Client {0} authenticated by {1}", client.getClientId(),
> factory.getId());
>
> These would not be localized and would not be given a message number.  If
> you want them localized with message number you need:
>
> logger.clientAuthenticated(client.getClientId(), factory.getId());
> ...
> @LogMessage(level = DEBUG)
> @Message(id=45, value="Client %s authenticated by %s")
> void clientAuthenticated(String clientId, String factoryId);
>
>
>
>
>
>>
>>
>>
>>
>>
>> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com> wrote:
>>
>>> I've completed a first stab at this using the JBoss logging tools.  Once
>>> merged we will have the ability to do i18n/l10n on our log messages and
>>> also use message numbers.
>>>
>>> Here is the commit to show you how it turns out converting the log
>>> messages in KeycloakApplication:
>>>
>>> https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>>
>>> So, now a message coming from the KeycloakApplication class in the
>>> services module looks like this:
>>>
>>> 15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread Pool
>>> -- 50)* KC-SERVICES0001*: Loading config from
>>> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>>
>>> We need to decide how we want to structure this.  In WildFly, we
>>> typically have one logger per maven module.  If you want to have one logger
>>> per package then you would need to create a new interface in each package,
>>> which gets hairy.
>>>
>>> I do suggest that we prefix all of our messages with "KC-" or something
>>> else that is unique across products.  Also, we should standardize the
>>> "padding" for the message numbers.
>>>
>>> Another possibility is to have all keycloak messages start with
>>> "KEYCLOAK".  This would mean that we would need for each module to reserve
>>> a number range.  There are annotations to enforce this if we want to go
>>> that route.  The downside is that somewhere we need to maintain a
>>> registry.  I think WildFly did this but eventually abandoned it.  Notice
>>> that WildFly messages are like "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>>
>>> BTW, localization works nicely.  Just add a bundle for a new language.
>>> The tool even creates a skeleton properties file for you.
>>>
>>> If you want more details on the i18n framework, see
>>> https://developer.jboss.org/wiki/JBossLoggingTooling.
>>>
>>> Stan
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/8836c015/attachment-0001.html