[
https://issues.apache.org/jira/browse/ADFFACES-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer updated ADFFACES-441:
--------------------------------
Resolution: Fixed
Fix Version/s: 1.0.1-incubating-core-SNAPSHOT
Assignee: Jeanne Waldman
Status: Resolved (was: Patch Available)
Fixed.
> Adding localization to logging message and exception
> ----------------------------------------------------
>
> Key: ADFFACES-441
> URL: https://issues.apache.org/jira/browse/ADFFACES-441
> Project: MyFaces ADF-Faces
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.1-incubating-core-SNAPSHOT
> Environment: Generic
> Reporter: jijun wang
> Assigned To: Jeanne Waldman
> Fix For: 1.0.1-incubating-core-SNAPSHOT
>
> Attachments: trinidad.zip, trinidad2.zip, trinidad2b.zip,
> trinidad3a.zip, trinidad3b.zip
>
>
> Proposal:
> 1) use resource bundle for logging message in java files above fine level so
> those message could be localized;
> 2) localize part/all exception in java files with resource bundle
> Benefit:
> More information in local language accessible for people in tech support,
> operation, deployment, field application etc whose software uses trinidad code
> Details:
> Trinidad-api and trinidad-impl will have their own LoggerBundle.xrts where
> message to be localized is defined. A LoggerUtils class will be added as a
> decorator in each project. LoggerUtils.createTrinidadLogger will return a
> TrinidadLogger instance with appropriate resource bundle attached. Message
> localization in logging is thus available from java logging by inheritance.
> Localization in exception message is achieved by passing localized message to
> exception. For both logging and exception, server locale will be used. This
> might create inconsistency for exception when client locale and server locale
> are different. Since an exception not captured would show both on server
> logger and client browser, using server locale is more practical.
> Open Issues:
> 1) Current API in TrinidadLogger is not enough to handle logging that
> contains message, message parameters and throwable. e.g
> _LOG.warning("Unable to instantiate converterClass:" + converterName, e);
> would become:
> _LOG.warning("UNABLE_INSTANTIATE_CONVERTERCLASS", converterName, e); or
> _LOG.logp(Level.WARNING, ..."UNABLE_INSTANTIATE_CONVERTERCLASS",
> converterName, e)
> But we neither warning() nor logp() has API that would take (...String
> message, Object parm, throwable e) as signature. Should we add API or use 2
> logging statements?
> _LOG.warning("Unable to instantiate converterClass:" + converterName;
> _LOG.warning(e);
> 2) Should LoggerUtils provide some methods like public static String
> getMessage(TrinidadLogger logger, String key (, Object params([])?)?) to
> retrieve localized string from resource bundle(parameter substitution could
> also be done in the method). The alternative is to use
> TrinidadLogger.getResourceBundle.getString(key) to retrieve localized
> message(in this case no parameter substitution or we don't localize exception
> message that carries parameters)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
