Simon Kitching <[EMAIL PROTECTED]> wrote on 12/25/2004 06:25:51 PM: > On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote: > > In my last message, I failed to emphasize the brittleness of the > > "break into interfaces" hypothesis. Even if at a high-level of > > abstraction two APIs perform the same task, this does not mean that > > they can be abstracted away by a thin facade (or bridge). For example, > > all the attempts made at bridging X.25 and TCP/IP, both well defined > > and stable protocols, have failed miserably, even if both stacks > > supposedly fit into layers 1-4 of the 7 layer OSI network model. > > I quite agree with this. > > And I don't think the approach of providing multiple optional interfaces > in commons-logging to support "advanced" features that various logging > libraries implement is useful either. As I've written in previous > emails, I do *not* like the idea of an application failing to start > because an appropriate logging implementation is not present. > > I think commons-logging should be a *simple* API that abstracts only the > *basic* functionality of logging. The current API is fine; log strings > at various priority levels to a single named category. Any reasonable > log implementation will be able to provide a sane mapping for these > concepts. > > But I don't think it is worth trying to extend JCL much beyond this. As > Ceki says, logging libraries can provide widely varying features and it > is not productive to try to map these to portable APIs.
Agreed in general, but there are some directions that are reasonable to follow. i18n is one. > JCL does a very useful job for jakarta-commons libraries: provide a > means for the commons libraries to implement logging without enforcing a > logging implementation on the larger app which uses the library. Note > that the kind of log messages generated by commons components are of > course implementation-related and are therefore aimed at the *developer* > not the user. For this reason, i18n support is not terribly useful for > commons component logging. Not true. In particular, the Message level API's [fatal, error, warn, info] may be targeted towards either end users, or [international] developers using the component. In either case, i18n is useful. For example, HTTPSender reflects an edge component to which customers are directly exposed. Failure to open ports, dropped socket connections... any socket, TCP/IP, or HTTP error is of interest to the end user, not just the developer using HTTPSender. Clearly, the developer would very much prefer that the users *resolve* these problems [in their native languages] rather than have the user contact the developer. And the component developer would prefer that the app developer understand how/if the API's are being misused, again in their natural language if possible. There is a need for i18n logging, and IBM's recognition of this need is much broader than *my* immediately daily chores. I'm just a spokeman here folks: the proposal is submitted on behalf of IBM, not IBM WebSphere [J2EE]. IBM and many other global companies are involved with a number of open source projects. Internationalization IS becoming more and more important for our customers. And our customers using open source are your customers. The IBM community also feels *strongly* that we must NOT fragment the logging community any further than it already is, strong alignment with JCL is necessary. > However I'm not convinced that for *applications* (rather than > libraries) it is sensible to use JCL at all; why not just pick a > concrete logging implementation and use that? You get all the necessary > features, and apps can deploy whatever logging implementation they want. Agree 100%. NO question. This is fundamental to JCL's goals. > The only awkward situation is container frameworks like J2EE. In this > case, you may want logging to be redirected to the container's logging > implementation so that logging from all apps within the framework is > treated consistently. I can see some kind of common API cabable of > generating i18n messages being useful here. > > After all the discussion on logging recently, I'm coming to the > conclusion that Richard's original proposed features (i18n, discovery > changes) should *not* be included in JCL. None of these features help > commons components with their logging requirements, and these features Disagree strongly. And I believe there are others would also disagree. > *are* going to make JCL significantly more complex and controversial. It > would be better to start a separate project. If this project can > successfully resolve the issues then maybe it could be merged back in to > JCL. > > To summarize, my (non-binding) votes are: > -1 to adding extra *optional* features to JCL that fail if the > "discovered" logging implementation doesn't suport them. This > includes Richard's EnterpriseLog class, and Matt Scarlata's > proposals too. > -1 to *mandatory* configuration for JCL > +1 to keeping JCL as a least-common-denominator logging API that > can be used for commons components. > > Regards, > > Simon > > > --------------------------------------------------------------------- > 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]
