commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [VOTE] [logging] Enterprise Logging - API Proposal
Date Mon, 13 Dec 2004 18:44:54 GMT
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 <sgarlatm@users.sourceforge.net> 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 <s_kitching@paradise.net.nz> 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 {@link
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >> 
> >>
> >
> >*******************************************
> >Richard A. Sitze
> >IBM WebSphere WebServices Development
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> > 
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message