You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Sgarlata <sg...@users.sourceforge.net> on 2004/12/12 21:58:38 UTC
Enterprise Logging - API Proposal
To support localized log messages, we only need to introduce one
*optional* interface that will *not* affect any existing functionality.
interface LocalizedLog extends Log { // methods TBD }
Then calling code that wants to make use of localized logging would make
this call:
private static final LocalizedLog log = (LocalizedLog)
LogFactory.getLog(MyClass.class);
And existing code or code that doesn't want to make use of localized
logging stays like this:
private static final Log log = LogFactory.getLog(MyClass.class);
To accomplish this, the LogFactory implementation will be changed to
*always* return a LocalizedLog. If the underlying logging
implementation supports internationalization, log messages will be
internationalized. If not, the LocalizedLog methods will delegate to
the plain old Log methods and log output will display the message keys
unresolved. Clearly if your code is using the LocalizedLog API you will
probably want to chose an implementation that supports localization, but
if you don't that won't cause errors in commons-logging (your log
messages will be written, they just won't be resolved).
This API is based on the following assumptions, which I think we should
all be able to agree on:
(1) Commons-logging should remain a thin bridge to other logging APIs
(2) Some logging APIs already offer localized log messages (e.g. Log4J)
Which in turn implies
(3) Commons-logging will pass through localized logging calls to
underlying logging implementations which support internationalization.
Logging implementations which do not support localization will simply
print out the arguments to the localized logging calls directly, without
any resolution
(4) It is inappropriate for any type of message key resolution to be
implemented in commons-logging. Message key resolution is certainly
important though, and should definitely be implemented somewhere else :)
Matt
Simon Kitching wrote:
>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?
>
>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Enterprise Logging - API Proposal
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
You have me almost convinced :) I still have some lingering
concerns/doubts though...
* 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 <sg...@users.sourceforge.net> 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.
>
>
>
>>Richard Sitze wrote:
>>
>>
>>
>>>Now, were does the *component* developer 'place' this content? I claim
>>>
>>>
>we
>
>
>>>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: 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
Re: Enterprise Logging - API Proposal
Posted by Richard Sitze <rs...@us.ibm.com>.
Matt Sgarlata <sg...@users.sourceforge.net> 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 agree 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.
>
>
> Richard Sitze wrote:
>
> >Now, were does the *component* developer 'place' this content? I claim
we
> >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: 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
Re: Enterprise Logging - API Proposal
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
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
from, but I think it's time for us to agree to disagree :) I think
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...
Richard Sitze wrote:
>Now, were does the *component* developer 'place' this content? I claim we
>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 :)
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Enterprise Logging - API Proposal
Posted by Richard Sitze <rs...@us.ibm.com>.
Matt Sgarlata <sg...@users.sourceforge.net> wrote on 12/13/2004
02:26:41 PM:
>
> >>Then calling code that wants to make use of localized logging would
make
> >>
> >>
> >>this call:
> >>
> >>private static final LocalizedLog log = (LocalizedLog)
> >>LogFactory.getLog(MyClass.class);
> >>
> >>
> >
> >Not sufficient.
> >a) Leaving the existing LogFactory alone allows a minimal
implementation
> >to be obtained, if that is appropriate, for Log. It also allows an
> >EnterpriseLog/LocalizedLog to be obtained.
> >b) Use of an alternate factory, as opposed to type-casts which might
fail,
> >represents a programmatic "contract". It assures the developer that
they
> >*will* get an Enterprise/Localized Log class back. Not something that
may
> >or may not typecase.
> >
> >
> I advocate that the type cast above *never* fail, because LogFactory
> will (in JavaDoc, not in its actual interface) guarantee a LocalizedLog
> will be returned. If the underlying logging implementation doesn't
Reasonable, but overly restrictive. getLog() should be allowed to return
a Log instance only. I understand we have a difference in opinion here.
I'd like to hear other opinions on this. In addition, the proposed
EnterpriseLogFactory.getEnterpriseLog() method takes two parameters:
1. logger [category] name
2. resourceBundleName
Without something identifying the resourceBundle, we have no way to
resolve the messages, or to help the underlying logger implementation
determine how to find these resources.
Could we introduce the 'Log getLog(String name, String
resourceBundleName)' method on the existing Factory? Sure... but if it's
ALWAYS going to return an EntLog, then let's make it contractual and
change the return type to EntLog.... and we're starting down a road that
brought the orginal proposal to introduce this on a subclass:
EntLogFactory.
Matt, I'm not going to claim that the original proposal is "the only way
to do things." I only want to make it clear that the simple solution(s)
have inherent implications that not everyone might agree with, and we must
be aware of them.
> support internationalization, then the messages are just passed through
> unresolved. I will argue why I like this approach below...
> >Not sufficient. Again, commons logging, though minimal, must be
useful.
> >It is trivial work for a wrapper to use the Java tools to do the
message
> >translation. If the translation still fails, then agree: dump the
message
> >directly.
> >
> >We *are* working on an assumption that
> >a) the component using logging *owns* the message resource bundle(s)
> >b) the general "scheme" for accessing/translating fits ONE paradigm,
and
> >said paradigm must be mappable to the target implementation [if
supported
> >directly], or resolved by the wrapper [if not].
> >
> >
> >>(4) It is inappropriate for any type of message key resolution to be
> >>implemented in commons-logging. Message key resolution is certainly
> >>important though, and should definitely be implemented somewhere else
:)
> >>
> >>
> >
> >I argue against this. Please keep the focus on the expected target for
> >making use of commons-logging: component, not hosting
> >application/framework.
> >
> >Note that the message key resolution and message formatting must be
> >directly exposed, the component developer must:
> >
> >a) write the message resources: key / text
> >b) assume and develope to some mechanism that enables translation, or
> >multiple texts per key
> >c) assume some formatting mechanism, and embed formatting directives in
> >the messages
> >
> >No matter the target environment, the extraction and formatting of
these
> >messages must be performed as the component developer has planned.
> >Therefore, for a common I18N logging, we must assume and adopt a
> >"standard" translation and formatting mechanism that all components
would
> >use.
> >
> >Ideally, such a standard would be supported by all, or at least a
> >majority, of the target logger implementations. Also, minimal is
> >prefered. We believe that the mechanisms provided by the JDK core
> >classes, as per the original proposal, satisfy both of these.
> >
> >Is this minimal? depends on your definition of minimal. Do I see any
> >alternatives? No.
> >
> >
> Ah but I do see alternatives : )
>
> First, I'm sure everyone will agree: messages should be parameterizable
> in this standard format shown below.
>
> messageKeyNumberOne=This is an {0} message from {1}
Agreed.
Now, were does the *component* developer 'place' this content? I claim we
need a standard approach for this, based on the 'resource bundle name'
parameters we pass into the
EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName);
>
> So I can plug in "ignorant" and "Matt" or "insightful" and "God", as the
> case may be.
>
> The goal of "standardizing on a format" is satisfied just by what I have
> written previously.
We agree on this point.
> There is no need to specify any mechanisms for
> retrieving the message template based on a key like
> "messageKeyNumberOne". That retrieval could happen through the file
> system or a database or whatever.
We disagree on this point. The *component* developer owns the resource.
The developer has a right to expect that this will be respected by the
hosting environment. Yes, someone might extract the resources from the
component as part of their build, and drop them into a database... one
might imagine that the resourceBundleName would be [part of] a key to
same... that the underlying implementation would know how to work with
this. Doesn't change a thing: the component developer expects the key to
be found, the application developer/packager must know where the source
for these can be found.
> I do think that *falling back* on the
> java.util.ResourceBundle functionality is a valid approach, but we need
> to take account the case when that resolution doesn't work (e.g. - I am
> pulling my resource from a DB instead, but haven't configured that
> yet). If java.util.ResourceBundle fails, we have to be prepared to pass
> unresolved messages straight through to the underlying logging system.
For loggers that support I18N: pass the resourceBundleName, key, and
formatting parameters straight through. No fall back, logger
implementation assumes responsibility.
For loggers that do not support I18N: use the Java tooling to resolve the
key to a message. If this fails, use the key as the message. Format the
message, and pass it onto the logger.
> I'm pretty sure the Commons team will agree that throwing an exception
> is not an option. Commons logging already made the choice that broken
> logging will *never* bring a system to its knees (if someone disputes
> this, please start a new thread).
No argument.
> So if java.util.ResourceBundle fails, I think we have two alternatives:
> A. Pass unresolved messages to the underlying logging implementation if
> the implementation doesn't support internationalization. This is the
> approach I advocated before. I still think it's reasonable because if
> you want internationalization of your log messages, I think you should
> pick a logging implementation that supports it! However, (B) below may
The component owner must be able to "globalize" and instrument their code
for the EnterpriseLog interface without knowledge of what logger is in
effect. They have no control if the host environment will support it
directly or not.
> be a better, more middle-of-the-road alternative:
> B. Define an interface similar to Spring's MessageSource
> (http://www.springframework.
> org/docs/api/org/springframework/context/MessageSource.html)
> interface. That way, people can plug in whatever resource bundle
> implementation they want to use (java.util.ResourcesBundle directly,
> Struts' resource bundle mechanism, Commons Resources, Spring, to name a
> few). This allows you to mix-and-match logging implementations and
> message key resolution implementations.
>
> A is more minimal, B is more functional.
Pluggable is cool.. BUT!! You bring in ComponentA that *depends* on
message resolver MR-A, and componentB that depends on resolver MR-B...
which one do you *plug* in? Or do you plug by component? We've left the
realm of simple, and for no positive reason.
>
> Matt
>
>
> ---------------------------------------------------------------------
> 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
Re: Enterprise Logging - API Proposal
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
>>Then calling code that wants to make use of localized logging would make
>>
>>
>>this call:
>>
>>private static final LocalizedLog log = (LocalizedLog)
>>LogFactory.getLog(MyClass.class);
>>
>>
>
>Not sufficient.
>a) Leaving the existing LogFactory alone allows a minimal implementation
>to be obtained, if that is appropriate, for Log. It also allows an
>EnterpriseLog/LocalizedLog to be obtained.
>b) Use of an alternate factory, as opposed to type-casts which might fail,
>represents a programmatic "contract". It assures the developer that they
>*will* get an Enterprise/Localized Log class back. Not something that may
>or may not typecase.
>
>
I advocate that the type cast above *never* fail, because LogFactory
will (in JavaDoc, not in its actual interface) guarantee a LocalizedLog
will be returned. If the underlying logging implementation doesn't
support internationalization, then the messages are just passed through
unresolved. I will argue why I like this approach below...
>Not sufficient. Again, commons logging, though minimal, must be useful.
>It is trivial work for a wrapper to use the Java tools to do the message
>translation. If the translation still fails, then agree: dump the message
>directly.
>
>We *are* working on an assumption that
>a) the component using logging *owns* the message resource bundle(s)
>b) the general "scheme" for accessing/translating fits ONE paradigm, and
>said paradigm must be mappable to the target implementation [if supported
>directly], or resolved by the wrapper [if not].
>
>
>
>
>>(4) It is inappropriate for any type of message key resolution to be
>>implemented in commons-logging. Message key resolution is certainly
>>important though, and should definitely be implemented somewhere else :)
>>
>>
>
>I argue against this. Please keep the focus on the expected target for
>making use of commons-logging: component, not hosting
>application/framework.
>
>Note that the message key resolution and message formatting must be
>directly exposed, the component developer must:
>
>a) write the message resources: key / text
>b) assume and develope to some mechanism that enables translation, or
>multiple texts per key
>c) assume some formatting mechanism, and embed formatting directives in
>the messages
>
>No matter the target environment, the extraction and formatting of these
>messages must be performed as the component developer has planned.
>Therefore, for a common I18N logging, we must assume and adopt a
>"standard" translation and formatting mechanism that all components would
>use.
>
>Ideally, such a standard would be supported by all, or at least a
>majority, of the target logger implementations. Also, minimal is
>prefered. We believe that the mechanisms provided by the JDK core
>classes, as per the original proposal, satisfy both of these.
>
>Is this minimal? depends on your definition of minimal. Do I see any
>alternatives? No.
>
>
Ah but I do see alternatives : )
First, I'm sure everyone will agree: messages should be parameterizable
in this standard format shown below.
messageKeyNumberOne=This is an {0} message from {1}
So I can plug in "ignorant" and "Matt" or "insightful" and "God", as the
case may be.
The goal of "standardizing on a format" is satisfied just by what I have
written previously. There is no need to specify any mechanisms for
retrieving the message template based on a key like
"messageKeyNumberOne". That retrieval could happen through the file
system or a database or whatever. I do think that *falling back* on the
java.util.ResourceBundle functionality is a valid approach, but we need
to take account the case when that resolution doesn't work (e.g. - I am
pulling my resource from a DB instead, but haven't configured that
yet). If java.util.ResourceBundle fails, we have to be prepared to pass
unresolved messages straight through to the underlying logging system.
I'm pretty sure the Commons team will agree that throwing an exception
is not an option. Commons logging already made the choice that broken
logging will *never* bring a system to its knees (if someone disputes
this, please start a new thread).
So if java.util.ResourceBundle fails, I think we have two alternatives:
A. Pass unresolved messages to the underlying logging implementation if
the implementation doesn't support internationalization. This is the
approach I advocated before. I still think it's reasonable because if
you want internationalization of your log messages, I think you should
pick a logging implementation that supports it! However, (B) below may
be a better, more middle-of-the-road alternative:
B. Define an interface similar to Spring's MessageSource
(http://www.springframework.org/docs/api/org/springframework/context/MessageSource.html)
interface. That way, people can plug in whatever resource bundle
implementation they want to use (java.util.ResourcesBundle directly,
Struts' resource bundle mechanism, Commons Resources, Spring, to name a
few). This allows you to mix-and-match logging implementations and
message key resolution implementations.
A is more minimal, B is more functional.
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Enterprise Logging - API Proposal
Posted by Richard Sitze <rs...@us.ibm.com>.
Will move the discussion back to your proposal.
Matt Sgarlata <sg...@users.sourceforge.net> wrote on 12/12/2004
02:58:38 PM:
> To support localized log messages, we only need to introduce one
> *optional* interface that will *not* affect any existing functionality.
>
> interface LocalizedLog extends Log { // methods TBD }
As per the earlier proposal.
>
> Then calling code that wants to make use of localized logging would make
> this call:
>
> private static final LocalizedLog log = (LocalizedLog)
> LogFactory.getLog(MyClass.class);
Not sufficient.
a) Leaving the existing LogFactory alone allows a minimal implementation
to be obtained, if that is appropriate, for Log. It also allows an
EnterpriseLog/LocalizedLog to be obtained.
b) Use of an alternate factory, as opposed to type-casts which might fail,
represents a programmatic "contract". It assures the developer that they
*will* get an Enterprise/Localized Log class back. Not something that may
or may not typecase.
> And existing code or code that doesn't want to make use of localized
> logging stays like this:
>
> private static final Log log = LogFactory.getLog(MyClass.class);
>
> To accomplish this, the LogFactory implementation will be changed to
> *always* return a LocalizedLog. If the underlying logging
> implementation supports internationalization, log messages will be
> internationalized. If not, the LocalizedLog methods will delegate to
> the plain old Log methods and log output will display the message keys
> unresolved. Clearly if your code is using the LocalizedLog API you will
> probably want to chose an implementation that supports localization, but
> if you don't that won't cause errors in commons-logging (your log
> messages will be written, they just won't be resolved).
>
> This API is based on the following assumptions, which I think we should
> all be able to agree on:
> (1) Commons-logging should remain a thin bridge to other logging APIs
Agreed. That is the intent.
> (2) Some logging APIs already offer localized log messages (e.g. Log4J)
> Which in turn implies
> (3) Commons-logging will pass through localized logging calls to
> underlying logging implementations which support internationalization.
Absolutely
> Logging implementations which do not support localization will simply
> print out the arguments to the localized logging calls directly, without
> any resolution
Not sufficient. Again, commons logging, though minimal, must be useful.
It is trivial work for a wrapper to use the Java tools to do the message
translation. If the translation still fails, then agree: dump the message
directly.
We *are* working on an assumption that
a) the component using logging *owns* the message resource bundle(s)
b) the general "scheme" for accessing/translating fits ONE paradigm, and
said paradigm must be mappable to the target implementation [if supported
directly], or resolved by the wrapper [if not].
> (4) It is inappropriate for any type of message key resolution to be
> implemented in commons-logging. Message key resolution is certainly
> important though, and should definitely be implemented somewhere else :)
I argue against this. Please keep the focus on the expected target for
making use of commons-logging: component, not hosting
application/framework.
Note that the message key resolution and message formatting must be
directly exposed, the component developer must:
a) write the message resources: key / text
b) assume and develope to some mechanism that enables translation, or
multiple texts per key
c) assume some formatting mechanism, and embed formatting directives in
the messages
No matter the target environment, the extraction and formatting of these
messages must be performed as the component developer has planned.
Therefore, for a common I18N logging, we must assume and adopt a
"standard" translation and formatting mechanism that all components would
use.
Ideally, such a standard would be supported by all, or at least a
majority, of the target logger implementations. Also, minimal is
prefered. We believe that the mechanisms provided by the JDK core
classes, as per the original proposal, satisfy both of these.
Is this minimal? depends on your definition of minimal. Do I see any
alternatives? No.
Now, once we've settle on such, it is not a problem [and it is minimal
work] for the wrapper classes to step in to do the translation for those
loggers that don't do it themselves.
>
> Matt
>
> Simon Kitching wrote:
>
> >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?
> >
> >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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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