Richard Sitze wrote:
Matt, I think you are jumping the gun here. It is way to premature to vote on your proposal, if for no other reason then there is a preexisting proposal on the table.Hi Richard, I'm apologize; I'm not trying to push aside your (excellent) proposal. It obviously has significant merit, given the amount of discussion that has taken place thus far. However, I believe your proposal is just too big to get a wholesale +1 from everyone. I'm trying to add some organization to the wonderful collective brainstorm that has taken place on this list over the past few days by narrowing the focus to just one small aspect of your proposal. The barrage of posts regarding your proposal has slowed down, so to me the brainstorming is over and we need to start building a consensus so that we can actually do something :) There is still much to be decided, and many more votes that will need to take place before a 1.1 or 2.0 or whatever release.
That said, I would like to point out that your proposal is, on the surface, very much in line with the original proposal. Specifically - naming aside - EnterpriseLog is intended to extend Log, just as your LocalizedLog does. If that is your 'key point', then there is nothing new here.There are several points in the API proposal I brought up before:
1) LocalizedLog/EnterpriseLog extends Log (as you mention above)
2) There will *not* be an EnterpriseLogFactory. The LogFactory interface will remain unchanged.
3) LogFactory's behavior will be changed so that it always returns an LocalizedLog/EnterpriseLog. Logging implementations which do not support internationalization will just pass through calls on a LocalizedLog to the underlying Log with no resource bundle resolution taking place
This is a pretty big difference. It's saying that the portion of section A.2 below will NOT be true, since the guarantees will be up to the underlying logging implementation and will not be guaranteed by commons-logging
Ensure that component has an assurance that the
message will be translated/formatted as expected: - ALL message translation must be done using
the standard java.util.ResourceBundle class,
or functional equivalent. - ALL message formatting must be done using
the standard java.text.MessageFormat class,
or functional equivalent. - Bind a ResourceBundleName to an EnterpriseLog
instance. - Expects that the named ResourceBundle is
available to the logger.
Matt
<ras>
Matt Sgarlata <[EMAIL PROTECTED]> wrote on 12/13/2004 12:11:30 PM:
The API I proposed yesterday circumvents this problem and allows us to add whatever methods we need for internationalization while not breaking
backwards compatability. Instead of adding methods to the Log interface, we introduce a new interface, called "LocalizedLog". The key
is that the Log and LogFactory APIs can remain unchanged and yet still allow us to introduce this new functionality.10:57:47
Since no one's voiced any concerns with my proposal, why don't we go ahead and put it to a vote? I'm not a committer, but here's my +1 (and I am willing to contribute code to make this happen). We can vote on other changes separately (e.g. - add equivalent to FINER, perhaps ENTER and EXIT)
-------------------------------------------------------------------- [ ] +1 I support this API proposal and am willing to help [ ] +0 I support this API proposal but am unable to help [ ] -0 I do not support this API proposal [ ] -1 I do not support this API proposal, and here are my reasons --------------------------------------------------------------------
Matt
Richard Sitze wrote:
Interesting point Simon.. more below
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/10/2004
choosePM:
Hi Richard,
The class javadoc for the EnterpriseLog class states:
Please note that a specific implementation of Commons Logging can
onto support either the simple logging interface (represented by [EMAIL PROTECTED]As you noted below, the desired behavior is that logging will always succeed. If I recall correctly, the current JCL will fall back to a SimpleLogger if it cannot locate an explicitly configured Log implementation. Two points worth considering on this topic:
Log}) or the advanced logging interface (represented by this
interface). A user of a Common Logging implementation that supports
only the simple logging interface will not be able to instantiate a
<code>EnterpriseLog</code>.
Given the following code:
if ((day == saturday) || (day == sunday)) { EnterpriseLog log = EnterpriseLogFactory.getLog(...); log.error("This code doesn't work on weekends"); }
are you proposing that this code will run fine all week, then suddenly throw a runtime error on saturday if the underlying log implementation does not support "enterprise" logging?
1. Fall back is "ok", BUT - we *MUST* log an error/info/warning message
notthis event, so that there is a clear understanding that something is
toas it should be. The "silent fail & fallback" of the current JCL has
cannotgo.
2. A "simple" EnterpriseLog implementation must be made available, to allow the behavior you describe below.
While this example is a bit contrived, I can certainly envisage an app put together with modules, one of which uses "enterprise" logging, and is only invoked under some conditions...
Incidentally, it looks like JCL itself will throw an exception on
startup if an explicit log implementation is specified (eg via system
properties or commons-logging.properties) but that implementation
approach,be found. This is quite in contradiction to the log4j logging
which is that an app should *never* fail just because logging fails. I prefer the log4j philosophy myself...
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]
--------------------------------------------------------------------- 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]
