I think you're dead-on with this new line of thinking. It won't seem like it because now I'm going to spend the rest of this email disagreeing with you, but I'm with you on the big leap you took in your last post; I'm just disagreeing with you on the minor details :) See below...
Simon Kitching wrote:
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.
I don't think that just because *some* bridging attempts fail that *all* bridging attempts must necessarily fail. In the case of localized logging, I think we could quite easily introduce a bridge API.
HOWEVER, at this point there's nothing to bridge! Correct me if I'm wrong, but there are two options for internationalization on the table right now:
1) Log4J
2) ResourceBundles + some other logging implementation (e.g. JDK 1.4 logging or JCL's SimpleLog)
If internationalization becomes a part of most logging APIs and it becomes clear that localized log messages really are needed by many applications, *then* JCL can worry about providing a bridge API. (In other words, if JDK 1.4 logging adds localization features in a future JDK, say JDK 1.6 or 1.7, then JCL can worry about the bridging API.) For now, if you need internationalization, it's not difficult to roll your own abstraction over JCL like this
public class MyStaticLoggerUtils {
public static void info(Log log, String messageKey, Object args[]) {
// code here
}
}So Richard can have his enter/exit methods and I can have my ReloadableResourceBundle from Spring and we can go happily our own ways ;)
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 don't think that introducing advanced features implies that logging *must* break if those advanced features aren't present. I think this could be configurable both at the component level *and* at the application level (i.e. - Component X says "I want Internationalization!" and Application Y is free to say "too bad"). In the case of internationalization, we've already demonstrated that it would be easy to fall back to logging the message codes without any resolution. (For example, I get message code output like this all the time from the JSTL tags implemented by the Taglibs project. Not very cute, but not a huge problem either)
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.
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.
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.
I don't think it's fair to say that applications don't need an abstraction over logging APIs. This is like saying "why code to interfaces and use factories rather than just coding to classes?". Abstractions over specific implementations can be useful at all levels of a system. It's really up to the system's architect to determine where abstractions are appropriate and where they are not. I think it's a little bold to claim that applications never need a logging abstraction and can feel safe in coding directly to a logging implementation. I personally always choose to use JCL; both in components and for applications.
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 *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.
I agree we should ditch EnterpriseLog and my proposal. However, I'd like to reiterate that, as I mentioned above, I don't think that "introducing optional features" implies "system startup failure if optional feature missing"
-1 to *mandatory* configuration for JCL
I agree with you
+1 to keeping JCL as a least-common-denominator logging API that
can be used for commons components.
I agree with you
Regards,
Simon
Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
