[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-116:
---------------------------------------
I'm scheduling this for 2.1 as we probably should update JBoss Logging too and allow a locale to be passed to the log methods.
> Locale is not used in the actual string format.
> -----------------------------------------------
>
> Key: LOGTOOL-116
> URL: https://issues.jboss.org/browse/LOGTOOL-116
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-116:
----------------------------------
Fix Version/s: (was: 2.0.2.Final)
> Locale is not used in the actual string format.
> -----------------------------------------------
>
> Key: LOGTOOL-116
> URL: https://issues.jboss.org/browse/LOGTOOL-116
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Assignee: James Perkins
> Priority: Minor
> Fix For: 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-113) Source files without license headers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-113?page=com.atlassian.jira.plugi... ]
James Perkins reassigned LOGTOOL-113:
-------------------------------------
Assignee: James Perkins
Resolution: Done
> Source files without license headers
> ------------------------------------
>
> Key: LOGTOOL-113
> URL: https://issues.jboss.org/browse/LOGTOOL-113
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: gil cattaneo
> Assignee: James Perkins
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> Hi
> The following source files are without license headers:
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformMessages.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformTest.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/ValidLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/util/VersionComparatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/MessageFormatValidatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/StringFormatValidatorTest.java
> only in the 1.2 branch:
> ./processor/src/main/java/org/jboss/logging/processor/apt/AbstractMessageObjectType.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLoggerTest.java
> Please, confirm the licensing of code and/or content/s, and add license headers.
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging...
> these files still report the old LGPL license header:
> ./processor/src/main/java/org/jboss/logging/processor/util/TranslationHelper.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/GeneratedSourceAnalysisTest.java
> only in the 1.2 branch:
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LoggerVerificationTest.java
> Thanks in advance
> Regards
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-113) Source files without license headers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-113?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-113:
----------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logging-tools/pull/51, https://github.com/jboss-logging/jboss-logging-tools/pull/52 (was: https://github.com/jboss-logging/jboss-logging-tools/pull/51)
> Source files without license headers
> ------------------------------------
>
> Key: LOGTOOL-113
> URL: https://issues.jboss.org/browse/LOGTOOL-113
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: gil cattaneo
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> Hi
> The following source files are without license headers:
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformMessages.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformTest.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/ValidLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/util/VersionComparatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/MessageFormatValidatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/StringFormatValidatorTest.java
> only in the 1.2 branch:
> ./processor/src/main/java/org/jboss/logging/processor/apt/AbstractMessageObjectType.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLoggerTest.java
> Please, confirm the licensing of code and/or content/s, and add license headers.
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging...
> these files still report the old LGPL license header:
> ./processor/src/main/java/org/jboss/logging/processor/util/TranslationHelper.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/GeneratedSourceAnalysisTest.java
> only in the 1.2 branch:
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LoggerVerificationTest.java
> Thanks in advance
> Regards
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-113) Source files without license headers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-113?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-113:
----------------------------------
Fix Version/s: 2.0.2.Final
2.1.0.Alpha1
> Source files without license headers
> ------------------------------------
>
> Key: LOGTOOL-113
> URL: https://issues.jboss.org/browse/LOGTOOL-113
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: gil cattaneo
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> Hi
> The following source files are without license headers:
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformMessages.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/TransformTest.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/ValidLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/util/VersionComparatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/MessageFormatValidatorTest.java
> ./processor/src/test/java/org/jboss/logging/processor/validation/StringFormatValidatorTest.java
> only in the 1.2 branch:
> ./processor/src/main/java/org/jboss/logging/processor/apt/AbstractMessageObjectType.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLoggerTest.java
> Please, confirm the licensing of code and/or content/s, and add license headers.
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging...
> these files still report the old LGPL license header:
> ./processor/src/main/java/org/jboss/logging/processor/util/TranslationHelper.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/GeneratedSourceAnalysisTest.java
> only in the 1.2 branch:
> ./processor/src/test/java/org/jboss/logging/processor/generated/LegacyLogger.java
> ./processor/src/test/java/org/jboss/logging/processor/generated/LoggerVerificationTest.java
> Thanks in advance
> Regards
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
James Perkins resolved LOGTOOL-104.
-----------------------------------
Assignee: James Perkins
Resolution: Done
This should be fixed with the JDeparser upgrade in LOGTOOL-118
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
> Assignee: James Perkins
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-57) Transition to enabling mechanisms to be 'managed' in server environment.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-57?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-57:
--------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.1.0.CR1)
> Transition to enabling mechanisms to be 'managed' in server environment.
> ------------------------------------------------------------------------
>
> Key: ELY-57
> URL: https://issues.jboss.org/browse/ELY-57
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Darran Lofthouse
> Fix For: 2.0.0.Alpha1
>
>
> For some mechanisms there is a fair amount of initialisation that needs to be performed each time the mechanism is used, e.g. for GSSAPI we have GSSName instances, GSSCredential instances etc...
> The existing convention for SASL mechanisms is that this initialisation occurs when the mechanism is instantiated which is at the time the relevant SaslServerFactory or SaslClientFactory is called. This convention really fits with the mechanisms being used in a JSE environment but once we move to a managed environment we are not so constrained.
> A few options: -
> - Provide a way a mechanism can cache something it has created so if called again it can re-use it.
> - Provide access to a factory / inject certain resources.
> - Make the mechanism fully managed in the server, when create is called the bulk of initialisation would have already occurred and what is returned handles the bare minimum state related to an authentication attemp (client or server side).
> One additional comment if we do consider something like this, some mechanisms may have items cached that once cached would never change for the lifetime of the process - for others we may have additional timeouts to consider such as Kerberos ticket expiration which may mean we want to regenerate cached resources at certain points.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-116:
----------------------------------
Fix Version/s: 2.0.2.Final
2.1.0.Alpha1
> Locale is not used in the actual string format.
> -----------------------------------------------
>
> Key: LOGTOOL-116
> URL: https://issues.jboss.org/browse/LOGTOOL-116
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 2.0.2.Final, 2.1.0.Alpha1
>
>
> The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this:
> {code}
> protected Locale getLoggingLocale() {
> return Locale.ROOT;
> }
> {code}
> Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following:
> * Locale.CANADA - for "en_CA"
> * Locale.CANADA_FRENCH - for "fr_CA"
> * Locale.CHINESE - for "zh"
> * Locale.ENGLISH - for "en"
> * Locale.FRANCE - for "fr_FR"
> * Locale.FRENCH - for "fr"
> * Locale.GERMAN - for "de"
> * Locale.GERMANY - for "de_DE"
> * Locale.ITALIAN - for "it"
> * Locale.ITALY - for "it_IT"
> * Locale.JAPAN - for "ja_JP"
> * Locale.JAPANESE - for "ja"
> * Locale.KOREA - for "ko_KR"
> * Locale.KOREAN - for "ko"
> * Locale.SIMPLIFIED_CHINESE - for "zh_CN"
> * Locale.TRADITIONAL_CHINESE - for "zh_TW"
> * Locale.UK - for "en_GB"
> * Locale.US - for "en_US"
> If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this:
> {code}
> private static final Locale LOCALE = new Locale("hu");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU");
> // or...
> private static final Locale LOCALE = new Locale("hu", "HU", "technl");
> // ...and then...
> @Override
> protected Locale getLoggingLocale() {
> return LOCALE;
> }
> {code}
> Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this:
> {code}
> final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str()));
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months