On Thu, 2004-05-13 at 01:32, Inger, Matthew wrote:
> The only real issue i have with commons-logging is the
> hardcoded list of loggers that are available, and having
> to include the adapters for those loggers in our programs
> no matter what. It would be nice to have a service provider
> (read d
On Thu, 2004-05-13 at 06:35, Alex Karasulu wrote:
> > From: "Shapira, Yoav" <[EMAIL PROTECTED]>
> >
> >
>
> No I have not but I don't think an extra call is going to make
> or break an application. Again everyone has valid concerns
> about the approach and it may not be the best fit but worth
>
> From: "Shapira, Yoav" <[EMAIL PROTECTED]>
> Date: 2004/05/12 Wed AM 08:45:45 EDT
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Subject: RE: [beanutils] remove dependency on commons-logging
>
> >Just how many of th
Hi,
>Just how many of the 50 first off will be logging? So take this
subclass
Every single one hopefully. Have you benchmarked this IoC logging
approach for performance (versus say a log4j for a given set of
classes)?
Are we making a mountain out of a mole hill? ;)
Yoav
This e-mail, inclu
t: Re: [beanutils] remove dependency on commons-logging
I haven't heard any complaints from the community that commons components
are tied to commons-logging so I'm a bit confused about why we need to
decouple it. We created logging to isolate us from specific logging
packages in the first plac
> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 9:48 PM
> To: Jakarta Commons Developers List
> Subject: RE: [beanutils] remove dependency on commons-logging
>
> On Wed, 2004-05-12 at 13:38, Noel J. Bergman wrote:
On Wed, 2004-05-12 at 13:38, Noel J. Bergman wrote:
> > > Sorry to step in late but has anyone considered the use of a generic
> > > event callback interface for use in monitoring.
>
> > If a library has a couple of major events that it can report, then
> > callbacks are a nice idea.
>
> > Howeve
> -Original Message-
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 6:29 PM
> To: Jakarta Commons Developers List
> Subject: RE: [beanutils] remove dependency on commons-logging
>
> Hi Alex,
>
> On Wed, 2004-05-12 at 09:55,
> > Sorry to step in late but has anyone considered the use of a generic
> > event callback interface for use in monitoring.
> If a library has a couple of major events that it can report, then
> callbacks are a nice idea.
> However I see logging as something *pervasive*. Libraries like log4j
> m
> -Original Message-
> From: matthew.hawthorne [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 6:27 PM
> To: Jakarta Commons Developers List
> Subject: Re: [beanutils] remove dependency on commons-logging
>
> Alex Karasulu wrote:
> > Sorry to
I haven't heard any complaints from the community that commons components
are tied to commons-logging so I'm a bit confused about why we need to
decouple it. We created logging to isolate us from specific logging
packages in the first place. Now we need to decouple from our own
library?
IMO, the
On Wed, 2004-05-12 at 00:53, David Graham wrote:
> I was reluctantly in favor of copying certain Collections classes as a
> temporary solution to removing that dependency but I don't see why we want
> to permanently copy Logging classes to other projects. Commons Logging is
> an abstraction for Lo
Hi Robert,
On Wed, 2004-05-12 at 09:11, robert burrell donkin wrote:
> 1. if we're going to look at logging again, i'd prefer to think about
> making beanutils a little more easy to use in a managed environment.
> this means giving more programmatic control over logging.
Can you give some more
m sort of new to using it so there may be problems with
the approach that I'm unaware of. So far it seems pretty neat.
Cheers,
Alex
-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 5:12 PM
To: Jakarta Commons Developers List
Subject:
On 11 May 2004, at 23:29, Simon Kitching wrote:
The issue you raise in your webpage about wanting to set different
logging behaviours for different instances of some class is simple to
implement with logging:
public void setLog(Log log);
This is equivalent to setting a Monitor with a "generic"
Hi Alex,
On Wed, 2004-05-12 at 09:55, Alex Karasulu wrote:
> Hi,
>
> Sorry to step in late but has anyone considered the use of a generic
> event callback interface for use in monitoring.
If a library has a couple of major events that it can report, then
callbacks are a nice idea.
However I s
Alex Karasulu wrote:
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring. Beanutil classes can
expose a BeanutilsMonitor interface with methods that are called by
the executing code to monitor notable events such as failures and
s
t of new to using it so there may be problems with
the approach that I'm unaware of. So far it seems pretty neat.
Cheers,
Alex
> -Original Message-
> From: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 5:12 PM
> To: Jakarta Commons Developer
1. if we're going to look at logging again, i'd prefer to think about
making beanutils a little more easy to use in a managed environment.
this means giving more programmatic control over logging.
2. (for reasons given in a previous mail) i'd prefer it if this goes
into a branch rather than the
Converting mandatory dependencies to optional is a key
part of solving some of the dilemas with commons. And
yes, some solutions will be different from those we
would adopt in our day jobs.
This solution is neat and simple - if you want logging
for beanutils then add commons-logging to your
classp
David Graham wrote:
I was reluctantly in favor of copying certain Collections classes as a
temporary solution to removing that dependency but I don't see why we want
to permanently copy Logging classes to other projects. Commons Logging is
an abstraction for Log4j and java.util.logging; now we're
I was reluctantly in favor of copying certain Collections classes as a
temporary solution to removing that dependency but I don't see why we want
to permanently copy Logging classes to other projects. Commons Logging is
an abstraction for Log4j and java.util.logging; now we're going to add yet
ano
22 matches
Mail list logo
