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.
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.
<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.
>
> 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
10:57:47
> >PM:
> >
> >
> >
> >>Hi Richard,
> >>
> >>The class javadoc for the EnterpriseLog class states:
> >>
> >>Please note that a specific implementation of Commons Logging can
choose
> >>to support either the simple logging interface (represented by [EMAIL
> >>PROTECTED]
> >>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?
> >>
> >>
> >
> >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:
> >
> >1. Fall back is "ok", BUT - we *MUST* log an error/info/warning message
on
> >this event, so that there is a clear understanding that something is
not
> >as it should be. The "silent fail & fallback" of the current JCL has
to
> >go.
> >
> >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
cannot
> >>be found. This is quite in contradiction to the log4j logging
approach,
> >>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]
