]
James Perkins commented on LOGTOOL-132:
---------------------------------------
I think I'm just going break compatibility and remove the previous properties which
allowed the generated implementation to work with 3.0.x. For compiling I'll throw an
exception if the correct minimum version of {{jboss-logging}} isn't used. I think it
will just make it easier. Keeping the compatibility is likely just going to complicated
the generated code and we should really leave it very simple as the goal is shrinking the
metaspace size.
I seem to have this working well locally. There are few main issues left:
# There was a way for a default locale, LOGTOOL-116, to be set. Given the same
implementation is used for all languages we need to away to determine which locale should
be used for translated messages vs fallback messages.
# We need to figure out how we fallback from {{fr_CA}} to {{fr}} if both properties files
exist
# Performance testing needs to be done.
One kind of interesting thing, and something I'll look at in more depth, is while the
implementations seem to be down about 50% in metaspace size the total only seems down
about 1%.
Support low-metaspace bundles/classes
-------------------------------------
Key: LOGTOOL-132
URL:
https://issues.jboss.org/browse/LOGTOOL-132
Project: Log Tool
Issue Type: Enhancement
Reporter: David Lloyd
Priority: Critical
Metaspace is at a premium in the application server environment, and the number one
consumer is presently generated log classes.
Introduce a leaner variation on generated classes with the following requirements:
* The generated class must be {{final}}
* The generated class must contain no message strings
* The generated class must accept both a {{Logger}} and a {{Locale}}, and load its
resources from a file based on that information
* The usage of Java 8's locale lookup functionality should be considered, to support
language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
Here are some implementation ideas:
* Option 1: The resource files contain only messages, one per line, loaded directly into
a {{String[]}} instance field in the implementation class; each logging method uses a
hard-coded array index to access its message
** A key advantage is that the implementation class is very small, and consumes very
little metaspace; also, it is fast, requiring only an array lookup to acquire the string
** A disadvantage is, any change to the message set invalidates all the locale files,
which must then be regenerated
** Also, each locale file must contain all messages, unless a fallback mechanism is used
(e.g. an empty line signifies that the string should come from the parent locale)
* Option 2: The resource files contain key-value pairs, with the key being equal to the
method name
** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit
more easily from parent locales
** Disadvantage: the added overhead of mapping lines to methods (for example, using a
switch statement to map method names to fixed indexes, or loading the messages into a hash
table e.g. {{HashMap}}) will fill metaspace or impact performance, or both