Thanks Oleg,
Appreciate your bunch of random thoughts. We'll probably build a
source code converter utility here and send it along once we're happy
with it.
Fwiw, your luck (or our lack of luck) may have to do with the fact that
we use log4j natively; it's possible and plausible that mixed
I'm not sure it's really any better, but another option might be to
fork(fix) commons-logging. This version could just directly use
log4j(or whatever) instead of relying on the classloader to work it
out. You might then have to replace all instances of the
commons-logging jar in the app
Hi Eric
Personally up to now I have not had too much of a hard time using
commons-logging with Websphere 5.0 and 5.1. Maybe I was just lucky
You may want to fork off the HttpClient 2.0 branch and host it on the
SourceForge, for instance. HttpClient 2.0 is stable and will not be
actively
Answer inline:
-Original Message-
From: Tim Vernum [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 5:38 AM
From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
Configuration is not done by a components, therefore it is
outside the scope of the common-logging package.
use it to
understand to debug their templates.
Have fun,
Paulo Gaspar
-Original Message-
From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 6:21 AM
To: Jakarta Commons Developers List
Subject: Re: Problems with commons-logging
I agree
On Wed, 6 Feb 2002, Paulo Gaspar wrote:
Hey, I am talking about the really minimal log to a file
configuration that any logger supports and drawing the line
after that.
The any logger supports statement is why this proposal is on the
slippery slope. IMHO, the commons-logging API itself
On Wed, 6 Feb 2002, Craig R. McClanahan wrote:
Configuration is a feature of a particular *implementation* of logging.
The implementations we wrap all have their own configuration mechanism.
So does the simple logger implementation that writes to System.out (which
uses system properties).
On Wed, 6 Feb 2002, Tim Vernum wrote:
1) The more you add the more you have to support.
If someone adds code to commons-logging to do basic
configuration, then commons has to support it.
You have to make sure it's not creating security problems.
You have to support it for any future
[EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2002, Tim Vernum wrote:
1) The more you add the more you have to support.
If someone adds code to commons-logging to do basic
configuration, then commons has to support it.
You have to make sure it's not creating security problems.
You have to
- Original Message -
From: Paulo Gaspar [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED];
Morgan Delagrange [EMAIL PROTECTED]
Sent: Wednesday, February 06, 2002 7:16 AM
Subject: RE: Problems with commons-logging
Morgan,
It looks like your reading of my posts
Answer inline:
-Original Message-
From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 7:36 PM
- Original Message -
From: Paulo Gaspar [EMAIL PROTECTED]
Sent: Wednesday, February 06, 2002 7:16 AM
Morgan,
It looks like your reading of
Hi Berin, answer inline:
-Original Message-
From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 6:11 PM
...
[EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2002, Tim Vernum wrote:
In Avalon, we provide the following interface for the LoggerConfiguration:
Hi Craig,
Although Costin defended all the reasons to add a bit of configuration
much better than I would be able to do, there are a couple of options
to consider.
The rest goes inline:
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday,
necessary however, since it does not change the way
components are developed at all.
- Morgan
- Original Message -
From: Tim Vernum [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Sent: Tuesday, February 05, 2002 10:38 PM
Subject: RE: Problems with commons-logging
: RE: Problems with commons-logging
Paulo,
I've seen you mention a couple of times that you consider singletons
dangerous. Would you care to elaborate? Is it because you're
concerned that
people can't write thread-safe code correctly? Or because correct
thread-safe code affects concurrency
Answer inline:
-Original Message-
From: Tim Vernum [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 7:51 AM
To: 'Jakarta Commons Developers List'
Subject: RE: Problems with commons-logging
...
Otherwise we'll still have to code against Log4j APIs ( to set
Donnie Hale wrote:
Paulo,
I've seen you mention a couple of times that you consider singletons
dangerous. Would you care to elaborate? Is it because you're concerned that
people can't write thread-safe code correctly? Or because correct
thread-safe code affects concurrency? Or something
PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 03, 2002 11:50 PM
To: Jakarta Commons Developers List
Subject: Re: Problems with commons-logging
On Sat, 2 Feb 2002, Scott Sanders wrote:
Are you saying that with getInstance(), we should remove it and just
use newLogInstance()? I
PROTECTED]]
Sent: Sunday, February 03, 2002 3:05 AM
To: Jakarta Commons Developers List
Subject: Re: Problems with commons-logging
From: Steve Downey [EMAIL PROTECTED]
The configuration should be done with the logging package
API. A component
is not going to do configuration
On Mon, 4 Feb 2002, Steve Downey wrote:
The case: you have 2 apps you want to keep isolated. Allowing one to
log into the other's log is unacceptable. Classloader tricks are not
allways possible and are extremely error prone ( and I would say -
ineffective, can be tricked ). And the
To: 'Jakarta Commons Developers List'
Subject: RE: Problems with commons-logging
BTW, another issue I just saw:
catch(Throwable) {}
Is it really the intent to catch OutOfMemoryError, and do nothing?
Or, you really want to keep the thread from cleaning up when
thread.stop()
is called
On Sat, 2 Feb 2002, Steve Downey wrote:
- security: getLogNames() and getInstance() are evil and unacceptable.
Both log4j and logkit have solutions that allow safe use in a
Could you elaborate on getInstance()? If the underlying logging packages
First, is the combination of getLogNames()
From: Steve Downey [EMAIL PROTECTED]
The configuration should be done with the logging package API. A component
is not going to do configuration, the application, or the administrator,
is
going to. The components need a uniform way of accessing the logging
system
that the application is
Answer inline:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 03, 2002 11:24 AM
On Sat, 2 Feb 2002, Remy Maucherat wrote:
...
I don't see a problem with getInstance, though. What's the problem ?
Using getInstance, or just
]]
Sent: Sunday, February 03, 2002 9:05 AM
To: Jakarta Commons Developers List
Subject: Re: Problems with commons-logging
From: Steve Downey [EMAIL PROTECTED]
The configuration should be done with the logging package API.
A component
is not going to do configuration, the application
Answer inline:
-Original Message-
From: Scott Sanders [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 03, 2002 2:18 AM
On Sat, Feb 02, 2002 at 08:33:46AM -0800, [EMAIL PROTECTED] wrote:
- security: getLogNames() and getInstance() are evil and unacceptable.
Both log4j and
On Sat, 2 Feb 2002, Scott Sanders wrote:
Are you saying that with getInstance(), we should remove it and just
use newLogInstance()? I am also fine with this, albeit a +0.
It's not a naming issue, but a behavior issue.
The case: you have 2 apps you want to keep isolated. Allowing one to
log
I am -1 on walking the config line. No config. None. This
API intends
to mask all of this and allow a component to just log. The
container
using the component will be required to configure logging.
We are not
trying to replace LogKit/Log4J, we are only trying to replace
]]
Sent: Saturday, February 02, 2002 11:58 PM
To: Jakarta Commons Developers List
Subject: Re: Problems with commons-logging
On 2/2/02 6:12 PM, Paulo Gaspar [EMAIL PROTECTED] wrote:
Some of this issues are addressed in the code I have. Lets see if I
have time next week to take a look at both
29 matches
Mail list logo
