commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject Re: [VOTE] [logging] Enterprise Logging - API Proposal
Date Mon, 13 Dec 2004 19:00:11 GMT
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 <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
>
>
>  
>


---------------------------------------------------------------------
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