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
Matt Sgarlata <[EMAIL PROTECTED]> 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 f
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 ea
Matt Sgarlata <[EMAIL PROTECTED]> 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);
> >>
> >>
> >
> >N
Will move the discussion back to your proposal.
Matt Sgarlata <[EMAIL PROTECTED]> 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 Lo
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
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 sig
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. Spec
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
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
10 matches
Mail list logo
