Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM: > > On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote: > > > Good comments, thanks. > > > > > > Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 05:34:58 PM: > > > >> Sorry to come in on this late. I just read the archives after Ceki > >> posted a link on log4j-dev. > >> > >> First, I agree Enterprise is a poor name. I tend to think in terms of > > > > Back to the issue of names, assuming we don't play some of the other > > games > > mentioned above, other name suggestions are welcome. > > > > I wasn't terribly concerned about the eventual class names. More try > to make the observation that the major tension is between the intended > audience for the message not the scope of the system. A debug or trace > level message in a handheld app has more in common with a trace level > message in a enterprise system than either has with a "out of stock" > warning in either system. > > > > >> diagnostic versus administrative logging. Diagnostic logging intended > >> to diagnose an issue where log requests are generally discarded > >> (unless > >> actively researching a problem) and fluency with internal program > >> structure and with the human language used in the implementation is > >> assumed. Logger names based on class names would be appropriate here > >> since the audience is likely familiar with the code base. > > > > Agreed. > > > > JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL > > debug, trace] logging which I believe equates to what you term > > "diagnostic > > logging". We do *not* propose to 'internationalize' these... I would > > resist such efforts. > > > >> > >> Administrative logging (in lack of a better term, but at least it is > >> better than Enterprise) are messages intended for a difference > >> audience > >> where knowledge of internal program structure and the human language > >> of > >> the implementation is not given. These difference audiences have > >> resulted in different API on some platforms, for example, Windows has > >> OutputDebugString (for diagnostic messages) and the Event log methods > >> for administrative messages. Logger names here would likely be > >> business process related. > > > > Reasonable, not sure if your intention is to relate this type of > > logging > > to the "message level" logging of JCL [fatal, error, warn, info]. > > I don't think that was my intention. Platform provided diagnostic > logging, like Win32 OutputDebugString, may be very simplistic and > provide no support for prioritization, persistence, or > internationalization. Platform provided administrative logging, like > the NT event log, would likely support some of those. Both a > diagnostic and a administrative system may have a concept of a WARN > severity, however the business significance of a WARN severity may be > orders of magnitude different depending on the context. I would not > think it common that, for example, inventory messages would switch from > using a diagnostic to an administrative type API based on message > severity.
As you pointed out earlier, much of this depends on how the logger is used. Class category names for code logging, other "application category" logger names for the other would be a reasonable approach. However, for our stated *GOAL*, JCL's primary purpose is for instrumenting components that are expected to plug into larger applications/frameworks. It's not clear to me what it means to start instrumenting such components for "administrative" or "application" level logging events. Not to say it couldn't be done. This is a "best-practice" issue for the most part... something for the users guide. If there are specific issues to be addressed by the API's, please raise them? Examples? It's not clear to me what course of action you advocate. > > > >> There are a couple of issues with the resource bundle proposals that I > >> have seen previously. I haven't had time to review those presented > >> here so they may or may not apply. > >> > >> Resource bundle approaches are sufficiently demanding of developers > >> that they will likely substantially reduce the density of diagnostic > >> messages if only a resource bundle approach is available. What are our (simple) options. Again remember that we expect to be a thin-wrapper over existing log implementations. > >> > >> Using the locale settings of the user or system is likely > >> inappropriate > >> for diagnostic messages. A diagnostician reviewing log files or > >> receiving networked log messages should not be forced to read log > >> messages in the user's native language. A worse case scenario would > >> be > >> a internationalized web site log where the language in the log file > >> was > >> constantly changing. > > > > Agreed. Again, the current proposal does not provide I18N enabled > > logging > > for JCL debug or trace methods. > > If I was a diagnostician looking at a log, I would want all the > diagnostic messages, whether they be ERROR or TRACE to be in my > preferred language not that of a user or web site visitor. Turning on > debug or trace messages would likely only occur after I narrow the > problem down by looking at higher level. > > By not having I18N debug or trace messages, you are basically saying > that those levels don't exist for messages that need to be > internationalized. You seem to be arguing against [pervious statements in your original post], and against [your new statements. What is your point? > If I was using a logging system to report, say > employee status to a store manager, an employee arriving or leaving > might be assigned an INFO status, i. e. lowest severity that is > typically reported. If I was trying to diagnose a drop in > productivity, I might want to be able to configure that I should get > DEBUG severity events, like door swipes or cash register logins and I > would still want these in my preferred language. Then the designer must be aware of the distinction between trace level logging, as intended for application debugging, and for message level logging. Everything you describe is message level logging. I think I'm starting to see where you are going with this... and would start by arguing that "independent pluggable components" are not necessarily the right place to start making assumptions of this sort, or even the right place to be logging this level of information. > > > >> A log request may need to be rendered for more than one locale. For > >> example, a log request may result in email messages send to multiple > >> recipients each in an appropriate language. > >> > >> A diagnostic log may be transmitted to a location where the resource > >> bundles are not available. If it still is resource based at that > >> point, you would require a specialized reader which would need to be > >> kept in sync as new messages were added. > >> > >> Discarded diagnostic messages need to be very low cost. > >> Administrative > >> messages are vastly less frequent, are rarely discarded and can be > >> fairly expensive. > > > > Agreed. > > > > That a single log request can be rendered for more than one locale > would either require having a localizable object passing through the > logging dispatch system, being able to translate the log request at the > appender or some other approach internal to the logging system. > Constructing a message using resource bundles and passing a rendered > message on to log4j logging would not accomplish that goal. We do not desire to pass on the rendered message, unless the underlying logger offers us no alternative. We desire to pass the messageID and parameters directly to the Logger, to be handled as it would. Again, I'm not sure what changes/problems you are arguing for? > > > >> An approach that I've found to work fairly well without requiring API > >> modifications is the use of a localizing layout. > >> http://www.mail-archive.com/log4j-user@logging.apache.org/ > >> msg00479.html) describe the use of such a layout in a project using > >> log4net. If you were careful on how you constructed your messages > >> (for > >> example, start with fixed content instead of variable content, did not > >> allow your conversions to be affected by the default locale), you > >> could > >> create a fairly efficient localization mechanism by having a layout > >> that would match the "generic" message and transform it into an > >> appropriate localized content based on an external document containing > >> regex patterns and substitutions. > > > > This is much to complex for the casual user. To repeat earlier > > comment, > > it is *critical* to put JCL in it's proper role: "enablement" for > > logging > > by pluggable "components". These [sometimes small] components need to > > be > > plugged into something more complex [your application/framework] that > > provides the real logger. It is not acceptable that each component > > tries > > to architect into itself something of the scale you appear to be > > proposing > > I was suggesting that a smart layout or appender can perform > localization without adding any additional architecture or making any > modifications to log4j and JCL. Log4J is not the only logger out there. There are multitudes of loggers that we would prefer to hand the messageID and parameters to. This allows the messages to be distributed to the different handlers, as I think you suggest earlier, and translated to a multitude of different locales if necessary. > > > > Much of what you appear to be describing can be managed as follows: > > > > a. Take the I18N enabled EnterpriseLog [or whatever you call it] > > API's, and map them to your own EnterpriseLog implementation. > > > > b. Manage the "magic" as-per your application environment in your > > custom EnterpriseLog impl. > > I'm not sure what you are trying to say. I'm saying you can always develop your own customized Log implementation wrappers, and plug them in. > > > >> > >> Some of advantages of this approach: no API change is necessary, > >> diagnostic messages are still trivial to add and fast to process, each > >> appender may have a different locale, localization has no cost for > >> discarded messages, generic language (typically english) messages are > >> available for messages that have not been translated (and likely most > >> diagnostic messages would not be), does not require customized > >> readers. > > > > It is reasonable to attempt to "standardize" a general "enablement" for > > I18N on the API level. Sure, you can roll your own. Sure, each > > component > > could roll it's own... Sure, we can duplicate this endlessly. Let's > > standardize this now. > > > > As long as this effort is only trying to define an abstraction layer to > unify existing practice and implementations, I'm okay with it. If it > is trying to "standardize" an API before implementations are available > and without consultation with major implementations like the Logging > Services Project, then I would be concerned. From reading the thread, > I'm not sure what the effort is trying to do. We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the existing JCL is of paramount importance. We are NOT trying to standardize on some "other" API within the industry, but rather to evolve an existing standard with new function. The API's are based *functionally* on JSR-47 and other logging implementations. It's fair to say that there is more than a little experience being brought to bear on this effort within the Jakarta community. > >> The primary disadvantage is that is it not straightforward to ensure > >> that all the messages of concern have translations and that messages > >> that are to be localized should be designed so that they are easily > >> matched and parsed. > > > > Any best-practices and suggestions you would like to offer on this > > matter > > [examples would probably be valuable] would be a welcome addition to > > the > > users-guide. > > > > > Internationalization has been a sporadic topic of discussion in the > log4j and derivatives' mailing lists, but doesn't appear to be a major > concern in our user base. I think a localizing layout would be a nice It's a concern to SOME user bases, and we have requirements. We believe that there is benefit for manifesting them in the open source community. When Log4J supports localized messages, with I'm sure all sorts of interesting features under the covers, components written to JCL will be ready to migrate to that. Meanwhile, the loggers that already support it, in varying degrees, will be better supported by JCL. > addition to log4j or derivatives and would allow existing applications > using log4j (whether natively or using JCL) to incrementally localize > their logging. I've got a release of log4cxx to nurse through and a > decent number of other tasks in my queue, but may be able to put > something together in the next few weeks. I'll report back if and when > it becomes available. However, I'll probably rely on Ceki to follow > this activity for the log4j and just assume that he is watching out for > log4cxx and log4net since anything that gets imposed on log4j > eventually will get imposed on us. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
