8:17 a.m.
Hi,
can someone enlighten me on how to configure the logging at the moment?
For an issue I am working on I wanted to increase the log level to debug
in the hibernate-core module of master.
As always I went to log4.properties and started to edit it. Needless to
say that nothing happened. First I thought
something must be wrong with the IDE setup, but it turned out the same
from the command line build :(
At some stage while growing more and more frustrated I remembered that
there is talk and work in progress for changing
the logging. I finally checked the logging dependencies where I found:
slf4j_simple: 'org.slf4j:slf4j-simple:' + slf4jVersion,
jcl_slf4j: 'org.slf4j:jcl-over-slf4j:' + slf4jVersion,
jcl_api:
'commons-logging:commons-logging-api:99.0-does-not-exist',
jcl:
'commons-logging:commons-logging:99.0-does-not-exist',
So I take it that we are not using log4j anymore, but how do I configure
logging now? And why do we still have the
log4j.properties files checked in, if they are obsolete?
--Hardy
8:54 a.m.
Calm down chief...
I wanted to try the simple sl4fj backend as a means to alleviate the logging
configuration files. Does it meet all of our needs? Dunno, thats kind of the
idea of "try". If it does not, feel free to switch tests back to rely on
log4j. My main concern here was the requirement to remember to revert
log4j.properties changes prior to committing. But there are potentially other
means to achieve that that I want to look at (going back to the notion of a
"local/properties" directory added to the test classpaths like i did in the
old ant builds).
On Thursday, November 11, 2010, at 08:17 am, Hardy Ferentschik wrote:
Hi,
can someone enlighten me on how to configure the logging at the moment?
For an issue I am working on I wanted to increase the log level to debug
in the hibernate-core module of master.
As always I went to log4.properties and started to edit it. Needless to
say that nothing happened. First I thought
something must be wrong with the IDE setup, but it turned out the same
from the command line build :(
At some stage while growing more and more frustrated I remembered that
there is talk and work in progress for changing
the logging. I finally checked the logging dependencies where I found:
slf4j_simple: 'org.slf4j:slf4j-simple:' + slf4jVersion,
jcl_slf4j: 'org.slf4j:jcl-over-slf4j:' + slf4jVersion,
jcl_api:
'commons-logging:commons-logging-api:99.0-does-not-exist',
jcl:
'commons-logging:commons-logging:99.0-does-not-exist',
So I take it that we are not using log4j anymore, but how do I configure
logging now? And why do we still have the
log4j.properties files checked in, if they are obsolete?
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
9:38 a.m.
I wanted to try the simple sl4fj backend as a means to alleviate the
logging configuration files.
Fair enough. A heads up would have been nice though, especially with the
log4j.properties files still around.
Does it meet all of our needs? Dunno, thats kind of the
idea of "try".
If I understand the documentation
(http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html)
correctly it just logs info messages. Personally, I find myself quite
often turning on
debug logging.
My main concern here was the requirement to remember to revert
log4j.properties changes prior to committing.
Is this really such a big issue? What's the harm if someone accidentally
checks in his logging settings?
--Hardy
9:55 a.m.
On Thursday, November 11, 2010, at 09:38 am, Hardy Ferentschik wrote:
If I understand the documentation
(http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html)
correctly it just logs info messages. Personally, I find myself quite
often turning on
debug logging.
Yep, again it was a temporary thing in my mind. I prefer the
"local/properties" approach longer term. Then we can use the log4j binding
and pick up log4j.properties from classpath via local/properties. The idea is
that local/ is named in .gitignore.
Is this really such a big issue? What's the harm if someone
accidentally
checks in his logging settings?
Long(er) build times. Bloated Hudson workspaces. I guess thats it. Are you
going to watch for this? And contact the committer to revert it when it does
happen? The point is its an unecessary situation anyway.
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
7:12 a.m.
On Thu, 11 Nov 2010 16:55:27 +0100, Steve Ebersole <steve(a)hibernate.org>
wrote:
> Is this really such a big issue? What's the harm if someone
accidentally
> checks in his logging settings?
Long(er) build times. Bloated Hudson workspaces. I guess thats it.
Are you going to watch for this? And contact the committer to revert it
when it does happen? The point is its an unecessary situation anyway.
Bloated Hudson workspaces!? That's lame ;-)
Longer build times can be annoying, but it's just a matter of reverting
back to
log level info in this case.
How often does it really happen anyways? And I think any one of us can
change it back
as soon as he discovers the change.
--Hardy
7:59 a.m.
Well we will agree to disagree. Having a file under source control that you
fully expect to change locally on every machine for various circumstances is
lame imo.
On Friday, November 12, 2010, at 07:12 am, Hardy Ferentschik wrote:
On Thu, 11 Nov 2010 16:55:27 +0100, Steve Ebersole
<steve(a)hibernate.org>
wrote:
>> Is this really such a big issue? What's the harm if someone accidentally
>> checks in his logging settings?
>
> Long(er) build times. Bloated Hudson workspaces. I guess thats it.
> Are you going to watch for this? And contact the committer to revert it
> when it does happen? The point is its an unecessary situation anyway.
Bloated Hudson workspaces!? That's lame ;-)
Longer build times can be annoying, but it's just a matter of reverting
back to
log level info in this case.
How often does it really happen anyways? And I think any one of us can
change it back
as soon as he discovers the change.
--Hardy
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5145
days inactive
5146
days old
6 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Steve Ebersole