Curt Arnold <[EMAIL PROTECTED]> wrote on 12/18/2004 02:52:02 PM: > > On Dec 18, 2004, at 12:24 PM, Richard Sitze wrote: > > > > 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. > > > > I was trying to give examples that the localized messages are not > needed because the system is "enterprise" level or because the message > is significant, but due to the audience and nature of the message.
Agreed > Enterprise level systems may have more messages that need to be > localized, but that doesn't mean that non-enterprise level systems > would not benefit. Agreed > log4j and JSR-47 was designed and optimized for diagnostic logging, > however they can be applied effectively for administrative logging. > However when they do, there are some aspects (like localization) that > may be lacking. However if I was designed a system that needed > configurable routing of administrative messages, then I could do worse > than using log4j or JSR-47 and working within their constraints or > evolving them. Fair enough, but always remember to keep our primary goals in mind. > > >>>> 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. > > > > Depends on the requirements. All I have to go on is what was in the > thread and there didn't seem to be a huge amount of elaboration. The requirements are all on the thread [archive], original post. There is probably a lot of historical discussion that establishes context, in the JCL community. Elaboration is coming through discussion, thank you for your comments. > If the requirement is to support localization of logging messages, then > there are multiple ways of attacking that problem. If the requirement > is to provide a facade to mimic JSR-47's resource bundle approach, then > that is very achievable, however I think it is likely to not be a > deeply satisfactory solution to localizing logging messages without > some accomodation in the implementations. The requirement is to enable localization of logging messages via a facade that maps to JSR-47 or other loggers that support localization underneath. Ideally to pass the localization info straight through to underlying implementations that support. > > > You seem to be arguing against [pervious statements in your original > > post], and against [your new statements. What is your point? > > > > I am trying to say that the severity of the message is independent of > the intended audience of the message and the need for localization. > You can have an ERROR message targeted to a diagnostician that should > be locale-neutral and a DEBUG message targeted to an administrator that > needs to be localized. Ok, I can understand this... but would counter that a) you design to what the API's support. b) remember the target use: components. The primary purpose of trace level info is going to be diagnostic, and the intended audience would be the developer(s). Balance is key, there is no one right answer. > > > > >> 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. > > I was trying to provide reasonable use case sub-INFO severity message > would need localization. > > The primary requirements that drove log4j were diagnostic logging > requirements and localization was not a significant design concern. > Developers have applied in many uses, like administrative logging, that > weren't in the initial set of requirements. The questions is if these > two types of "logging" are incompatible and need two distinct API's or > if one API can acceptably handle both. Remember our users: component developers. Admin logging is application/framework... much higher level I would think. > If you are saying that log4j and JCL should ignore requirements from > people who are using it for administrative logging, then were are the > requirements for localization coming. > > >>> > >> > >> 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? > > > > That is effectively issuing an architectural ultimatum to the logging > implementations: be able to pass resource bundles and parameters > through your processing pipeline or appear to be a second class > implementation of Jakarta Commons Logging. If this is making > architectural demands, it would be right to have the implementors > feedback. No demands are being issued. I do see your point. Implementors are free to jump in. > > 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. > > > > No, but it is a significant one and is also under the ASF. It would be > a undesirable if Jakarta Common Logging makes architectural demands > that log4j can't accept, especially if a reasonable compromise could be > achieved. I'm listening. I don't understand what you are proposing yet. Examples? > > 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. > > > > Again, I'm coming into this late. Is there a requirements doc of some > sort other than what was in this thread, have there been any votes, > anything in CVS, any timeline? No. Just the first note on the thread. No votes, we are opening discussion. Folks, we have to start somewhere... and this is it. > >> 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. > > I wasn't discounting the validity of the concern and it has been an > interest of mine. I was stating that log4j is immature in this area > since it hasn't been a major concern of our user community. > > > > > > Meanwhile, the loggers that already support it, in varying degrees, > > will > > be better supported by JCL. > > > > Any list of reference implementations? JSR-47 is the first to come to mind. > > --------------------------------------------------------------------- > 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]
