Saturday, June 18, 2016 12:43 AM
> To: Commons Developers List
> Subject: Re: [crypto] Logging dependency
>
> Hello Dapeng,
>
> Sun, Dapeng schrieb am Mi., 15. Juni 2016 um
> 11:22 Uhr:
>
> > Thank all for your input!
> >
> > I will try to remove the log depend
t...@apache.org]
Sent: Saturday, June 18, 2016 12:43 AM
To: Commons Developers List
Subject: Re: [crypto] Logging dependency
Hello Dapeng,
Sun, Dapeng schrieb am Mi., 15. Juni 2016 um
11:22 Uhr:
> Thank all for your input!
>
> I will try to remove the log dependence.
>
> About
u...@vafer.org]
> Sent: Saturday, June 11, 2016 6:44 PM
> To: Commons Developers List
> Subject: Re: [crypto] Logging dependency
>
> On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers
> wrote:
>
> >
> > > On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote:
> > >
lto:tcu...@vafer.org]
Sent: Saturday, June 11, 2016 6:44 PM
To: Commons Developers List
Subject: Re: [crypto] Logging dependency
On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers
wrote:
>
> > On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote:
> >
> >> Matt, there is a big
On Sat, Jun 11, 2016 at 7:34 AM, Ralph Goers
wrote:
>
> > On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote:
> >
> >> Matt, there is a big difference between printing the stack trace and
> >> walking it to find the info. printing it on every debug call would be
> >> insane.
> >>
> >
> > Why would
I still think crypto should do no logging at all, but propagate errors
using exceptions. Higher level application code may catch those exceptions
and implement the desired recovery routines:
- show a message to the user
- Add the problem to an admin dash board
- try a different crypto provider
- .
On 11 June 2016 at 06:34, Ralph Goers wrote:
>
>> On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote:
>>
>>> Matt, there is a big difference between printing the stack trace and
>>> walking it to find the info. printing it on every debug call would be
>>> insane.
>>>
>>
>> Why would anyone want to
> On Jun 10, 2016, at 2:56 PM, Torsten Curdt wrote:
>
>> Matt, there is a big difference between printing the stack trace and
>> walking it to find the info. printing it on every debug call would be
>> insane.
>>
>
> Why would anyone want to do that?
>
> https://docs.oracle.com/javase/7/docs/
>
> > As a side note: I personally think libraries should return errors - not
> log
> > them. The error logging should happen in the app - not the library. If
> you
> > have to log errors in the framework there is a good chance your API is
> not
> > how it should be.
> >
>
> That's not a good answe
> Now we are getting way off topic, but I would argue that a message that
> contains no specific context information would still be a good message.
> There is nothing wrong with a debug message of logger.debug(“User: {},
> userId); as this contains all the context information you need to determine
> Matt, there is a big difference between printing the stack trace and
> walking it to find the info. printing it on every debug call would be
> insane.
>
Why would anyone want to do that?
https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html
And how do you think the loggin
>
> > Exactly. It's so simple and it doesn't introduce any deps.
> > Whether that's goal one can align with is another matter.
> > But it means no logging framework discussions anymore ;)
>
> The disadvantage of this approach is that you loose the location
> information - every log event will come
On Fri, Jun 10, 2016 at 3:55 AM, Torsten Curdt wrote:
> >
> > But I guarantee that there will be other discussions:
> > Wouldn't you add an "error" method to "Console"?
> > And there we go again...
>
>
> Not quite the same discussions though.
> And I was just saying: it works for me.
>
> As a s
Now we are getting way off topic, but I would argue that a message that
contains no specific context information would still be a good message. There
is nothing wrong with a debug message of logger.debug(“User: {}, userId); as
this contains all the context information you need to determine where
In any case, if the message String does not give sufficient context to
be able to understand where the message originated, then arguably it's
not a very good message.
On 10 June 2016 at 16:34, Matt Sicker wrote:
> Oh, I didn't even notice the printStackTrace() part until now. Good point.
>
> On 1
Oh, I didn't even notice the printStackTrace() part until now. Good point.
On 10 June 2016 at 10:23, Ralph Goers wrote:
> Matt, there is a big difference between printing the stack trace and
> walking it to find the info. printing it on every debug call would be
> insane.
>
> Ralph
>
> > On Jun
Matt, there is a big difference between printing the stack trace and walking it
to find the info. printing it on every debug call would be insane.
Ralph
> On Jun 10, 2016, at 8:09 AM, Matt Sicker wrote:
>
> Without Java 9, that's pretty much the only way to get the caller line
> number and oth
Without Java 9, that's pretty much the only way to get the caller line
number and other metadata besides the caller class.
On 10 June 2016 at 09:44, Jochen Wiedmann wrote:
> On Fri, Jun 10, 2016 at 4:02 PM, sebb wrote:
>
> > Depends on what the implementation does.
> >
> > For example:
> >
> >
On Fri, Jun 10, 2016 at 4:02 PM, sebb wrote:
> Depends on what the implementation does.
>
> For example:
>
> @Override
> void debug( String message ){
> new Throwable(message).printStackTrace();
> }
Even a dumb application developer like me would at least like to see a
*bit* of performace. :
On 10 June 2016 at 13:39, Ralph Goers wrote:
>
>> On Jun 10, 2016, at 3:34 AM, Torsten Curdt wrote:
>>
>> On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote:
>>
>>> On 10 June 2016 at 10:46, Gilles wrote:
Hi.
On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>
> FWIW
>>>
> On Jun 10, 2016, at 3:34 AM, Torsten Curdt wrote:
>
> On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote:
>
>> On 10 June 2016 at 10:46, Gilles wrote:
>>> Hi.
>>>
>>> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
FWIW
I am not a fan of libraries and frameworks ju
On Fri, 10 Jun 2016 12:55:18 +0200, Torsten Curdt wrote:
But I guarantee that there will be other discussions:
Wouldn't you add an "error" method to "Console"?
And there we go again...
Not quite the same discussions though.
And I was just saying: it works for me.
As a side note: I personal
I can get on board with that model I suppose. What we talked about long ago
was an event listener model for knowing what's going on internally with a
library. These events could be delivered asynchronously from the calls
coming from an application.
On Fri, Jun 10, 2016 at 7:03 AM sebb wrote:
> On
On 10 June 2016 at 11:55, Torsten Curdt wrote:
>>
>> But I guarantee that there will be other discussions:
>> Wouldn't you add an "error" method to "Console"?
>> And there we go again...
>
>
> Not quite the same discussions though.
> And I was just saying: it works for me.
>
> As a side note: I
>
> But I guarantee that there will be other discussions:
> Wouldn't you add an "error" method to "Console"?
> And there we go again...
Not quite the same discussions though.
And I was just saying: it works for me.
As a side note: I personally think libraries should return errors - not log
the
On Fri, 10 Jun 2016 12:34:10 +0200, Torsten Curdt wrote:
On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote:
On 10 June 2016 at 10:46, Gilles
wrote:
> Hi.
>
> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>>
>> FWIW
>>
>> I am not a fan of libraries and frameworks just logging away
any
On Fri, Jun 10, 2016 at 12:14 PM, sebb wrote:
> On 10 June 2016 at 10:46, Gilles wrote:
> > Hi.
> >
> > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
> >>
> >> FWIW
> >>
> >> I am not a fan of libraries and frameworks just logging away anyway.
> >>
> >> What I usually do this days:
>
On 10 June 2016 at 10:46, Gilles wrote:
> Hi.
>
> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>>
>> FWIW
>>
>> I am not a fan of libraries and frameworks just logging away anyway.
>>
>> What I usually do this days:
>> Have an interface in the library itself. Along the lines of
>>
>>
Hi.
On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
FWIW
I am not a fan of libraries and frameworks just logging away anyway.
What I usually do this days:
Have an interface in the library itself. Along the lines of
public interface Console {
void debug( String message );
FWIW
I am not a fan of libraries and frameworks just logging away anyway.
What I usually do this days:
Have an interface in the library itself. Along the lines of
public interface Console {
void debug( String message );
}
and then have the user of the library pass in an implemen
I'll check it out. The printf sounds nice
On Thu, Jun 9, 2016 at 7:18 PM Ralph Goers
wrote:
>
> > On Jun 9, 2016, at 3:55 PM, James Carman
> wrote:
> >
> > On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote:
> >
> >> There is a huge list of advantages to using log4j-api over slf4j-api
> >> nowada
> On Jun 9, 2016, at 3:55 PM, James Carman wrote:
>
> On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote:
>
>> There is a huge list of advantages to using log4j-api over slf4j-api
>> nowadays, plus I do prefer to use Apache dependencies in Apache projects
>> unless the competition is clearly bet
On Thu, Jun 9, 2016 at 2:19 PM Matt Sicker wrote:
> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat in
On Thu, Jun 9, 2016 at 11:19 AM, Matt Sicker wrote:
> There is a huge list of advantages to using log4j-api over slf4j-api
> nowadays, plus I do prefer to use Apache dependencies in Apache projects
> unless the competition is clearly better for the use case (like using Jetty
> instead of Tomcat i
There is a huge list of advantages to using log4j-api over slf4j-api
nowadays, plus I do prefer to use Apache dependencies in Apache projects
unless the competition is clearly better for the use case (like using Jetty
instead of Tomcat in Karaf due to OSGi support). Also, using log4j-api
works fine
On Mon, Jun 6, 2016 at 10:01 PM Gary Gregory wrote:
> Hi All:
>
> IMO. if [crypto] is to have a dependency on a logging framework, it should
> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
> pair with any number of implementations: Log4j's own Core, JUL, SLF4J, and
> s
els.net
>
> -Original Message-
> From: Gary Gregory
> To: Commons Developers List
> Sent: Mi., 08 Juni 2016 0:48
> Subject: Re: [crypto] Logging dependency
>
> Log4j 2 provides minimal support for v1 properties file, and its not
> documented yet beyond the code i
Here we have been arguing about whether to move to Java 7 (or 8) or not and you
are saying users need to stick with Log4j 1. Wow. Log4j 1.2 is still at Java
1.2, so it can’t even use java.util.concurrent.
The Logging PMC officially announced EOL for Log4j last August [1]. But in
reality it rea
I'd be a little worried about switching to log4j 2. Two of the main
targets of this library when it was proposed were Spark and Hadoop,
both of which do not use log4j 2; you might be able to configure them
too, but Spark at least has functionality built on top of log4j 1.2,
and I'm not sure how wel
On Jun 7, 2016 9:07 AM, "sebb" wrote:
>
> On 7 June 2016 at 16:42, Benedikt Ritter wrote:
> > Hello Gary,
> >
> > Gary Gregory schrieb am Di., 7. Juni 2016 um
> > 04:01 Uhr:
> >
> >> Hi All:
> >>
> >> IMO. if [crypto] is to have a dependency on a logging framework, it
should
> >> be Log4j 2, not
hing)
>
>Gruss
>Bernd
>--
>http://bernd.eckenfels.net
>
>-Original Message-
>From: Gary Gregory
>To: Commons Developers List
>Sent: Mi., 08 Juni 2016 0:48
>Subject: Re: [crypto] Logging dependency
>
>Log4j 2 provides minimal support for v1 properties fi
Juni 2016 0:48
Subject: Re: [crypto] Logging dependency
Log4j 2 provides minimal support for v1 properties file, and its not
documented yet beyond the code itself. Log4j 2 does support the Log4j 1 API
though, which is the most important level of compatibility.
You make it sound like some folks will
Log4j 2 provides minimal support for v1 properties file, and its not
documented yet beyond the code itself. Log4j 2 does support the Log4j 1 API
though, which is the most important level of compatibility.
You make it sound like some folks will not adopt a new library and API
because of the format
No library depends on (or should depend on) log4j 1.x as it ties you to
log4j 1.x. Most projects have been using commons-logging or slf4j, but
commons-logging has been superseded by log4j 2.x. Which logging library is
actually used for configuration and the actual logging should be left to
the end
Could you please elaborate on the argument for not logging at all? As a
potential user of commons-crypto, I'll be reluctant to use it if it
doesn't provide adequate diagnostic logging when something goes wrong.
Regarding the choice of Log4J 2, this is also something that could prevent
uptake. Fo
On 7 June 2016 at 16:42, Benedikt Ritter wrote:
> Hello Gary,
>
> Gary Gregory schrieb am Di., 7. Juni 2016 um
> 04:01 Uhr:
>
>> Hi All:
>>
>> IMO. if [crypto] is to have a dependency on a logging framework, it should
>> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
>>
Hello Gary,
Gary Gregory schrieb am Di., 7. Juni 2016 um
04:01 Uhr:
> Hi All:
>
> IMO. if [crypto] is to have a dependency on a logging framework, it should
> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can
> pair with any number of implementations: Log4j's own Core, JU
47 matches
Mail list logo
