* LogFactory - I'm not comfortable introducing a new LogFactory so that logging is supported. What happens when the next new logging feature comes along? Then we'd have to have three factories somehow, and it wouldn't be clear where exactly to put the new factory (does it extend LogFactory or EnterpriseLogFactory?) We might even want to consider leaving the current LogFactory alone and leaving message source resolution completely to the underlying logging framework. With this approach, specific LogFactory implementations, e.g. the Log4JLogFactory, might require additional configuration information in the commons-logging.properties file to get logging working if their underlying implementation is clumsy on configuration or requires the ResourceBundle to be passed in on each logging call. (I think this would be needed for Log4J) Hopefully the underlying logging framework supports resource bundle configuration directly (I think JDK 1.4 logging will play nicer in this area).
* Message resolution - You've convinced me. I see the benefits of your approach in that it keeps JCL as small as possible. I guess if someone (e.g. - Matt Sgarlata) *really* wants a custom resource bundle resolution strategy (e.g. - Spring + Log4J), he or she can always subclass an existing LogFactory/Log combo to do the resolution. It's not very exciting, but it keeps JCL as an ultra-thin bridge. I personally would prefer to see "resourceBundleName" renamed "resourceName" or "resourceId", to be clear that we aren't necessarily dealing with a java.util.ResourceBundle but this is of course splitting hairs... either way is fine :)
Matt
Richard Sitze wrote:
Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004 07:05:31 PM:
Ah-hah, I understand our main disconnect now: I'm thinking in terms of configuring logging for an overall application and you're thinking in terms of components. So now at least I understand where you're coming
A step forward... :-)
from, but I think it's time for us to agee to disagree :) I think
Give me time ;-) The proper role and position for commons-logging is up to the individual developer. That said, within the commons-logging development community it is a fundamental premise that commons-logging's mere existence is justified ONLY as an enabler for logging in components that must be developed independently from a single application/framework.
someone said earlier that perhaps part of your proposal would fit better
in Log4J or in some other logging component. In any case, thanks for spending so much time discussing your ideas with me. More comments
below...
If you are developing applications or frameworks, and you want Log4J function, then go use Log4J. End of story, commons-logging has little/no value to you. If your application integrates components that use JCL [Jakarta Commons Logging], then bind JCL to Log4J in your hosting environment, and you are ready to move forward.
weRichard Sitze wrote:
Now, were does the *component* developer 'place' this content? I claim
need a standard approach for this, based on the 'resource bundle name' parameters we pass into the EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName);I think instead of the resourceBundleName we could optionally pass in a MessageSource implementation. That way if internationalization for a component was dependent on a particular implementation, it could be passed in. If no MessageSource was passed in, we could still try java.util.ResourceBundle and the underlying logging implementation. I'm
sure we disagree on this point, but I just wanted to through this idea out there :)
Not a bad idea. With every level of flexibility we gain more complex code. I would resist this at this moment because it either a) introduces a 3rd party dependency on MessageSource, b) introduces yet more code to develope for commons-logging (keep it simple).
In addition, it also requires the user to new up and manage the MessageSource, yet one more ticky-mark on the check-list of new work to do. There is admittedly a balance between "programmer work" and "function". Everyone is going to have their own opinions on where the right place is to strike this balance.
So far, there are proposals for new API's.. but we've tried to keep new Interfaces, and implementations behind them, to a bare minimum (ELog & ELogFactory).
Matt
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
