You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Henrib <hb...@gmail.com> on 2007/11/14 15:13:48 UTC
logging through log4j
I'm in a situation where Solr is embedded in a webapp (ie using solr.jar).
Other modules of this app are using log4j and I'm looking for a way to make
the logging configuration consistent (aka through log4.xml).
Can anyone who solved the same kind of issue share his/her experience?
After much browsing, understanding why commons-logging, sl4j or others are
not solutions for Solr iself, I finally stumbled on
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/
which seems to provide a ready made solution.
Has anyone some experience & comment using it?
Thanks
--
View this message in context: http://www.nabble.com/logging-through-log4j-tf4805241.html#a13747253
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Henrib <hb...@gmail.com>.
I agree, slf4j is a better solution; I was just trying to mitigate the
functional need (hooking log4j) & the strong (op)positions against changing
the logging API, thus the mildly disgusting solr-549 strawman. :-)
David Smiley @MITRE.org wrote:
>
> Whenever I see a project with some home-grown LogManager that provides
> loggers, I am always mildly disgusted no matter how simple it is (no
> disrespect to you, that is my opinion). I believe use of SLF4J will meet
> common goals.
>
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16967768.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by "David Smiley @MITRE.org" <DS...@mitre.org>.
I do sympathize; it does seem wrong, but it's the norm in Java because Sun
screwed up Jdk14 logging. It's not a reflection of the design decisions of
Solr (i.e. your judgement) so please don't feel too bad accepting SLF4J.
~ David
Erik Hatcher wrote:
>
> My main point is philosophical - adding another dependency just for
> logging seems so wrong.
>
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16962888.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
My main point is philosophical - adding another dependency just for
logging seems so wrong.
Pragmatically - I give up.... I won't block an overhaul to Solr's
logging .... I'll just quietly cringe.
Erik
On Apr 29, 2008, at 10:25 AM, David Smiley @MITRE.org wrote:
>
> Whenever I see a project with some home-grown LogManager that provides
> loggers, I am always mildly disgusted no matter how simple it is (no
> disrespect to you, that is my opinion). I believe use of SLF4J
> will meet
> common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
> out-of-the-box ship the slf4j-jdk14.jar (or not but Eric Hatcher
> seems to be
> a fan; but it's really not that important any way). Then, if
> someone (like
> me :-) would like to configure logging with log4j then I am easily
> empowered
> to do so by removing that jar and adding slf4j-log4j.jar. What I
> like about
> sfl4j is that it is the most logging agnostic of logging apis for
> java. In
> theory, JUL is an agnostic choice but for a variety of reasons that
> have
> already been discussed on this list, it isn't.
>
> ~ David Smiley
>
>
> Henrib wrote:
>>
>> I've been fiddling with java.util.logging from jul-to-log4j bridge
>> to the
>> idea of implementing a LogManager.
>> In the latter case there are a lot of deployability caveats, in
>> particular
>> the fact that there is no common way of configuring them between
>> servlet
>> containers. Trying to tame Websphere on this respect for instance
>> seems
>> like a difficult battle.
>> In the former case, the jul-to-log4j bridge suffers - in some
>> environment
>> - from the fact that the LogManager & al may have security
>> restrictions
>> that wont allow manipulating some Logger properties.
>> But in all cases, I miss the log4j deployability that does not
>> require
>> anything but the fact that some classes exist in the jar/war (ie,
>> no need
>> to set something globally in the servlet container or use a JVM wide
>> property).
>>
>> The only solution that I've been able to find is to have Solr
>> cooperate
>> and implement its "own" org.apache.solr.Logger "shim" that behaves
>> like a
>> local LogManager and trigger the implementation switch by using a
>> log4j
>> adapter class; if the adapter class is present (aka loadable), the
>> Loggers
>> are anonymous (j.u.l.Logger.getAnonymousLogger) with one handler that
>> transforms the LogRecord into log4j events. Otherwise, if that
>> class is
>> not present, it just reverts to usual j.u.l logging.
>> The only code change is to use
>> org.apache.solr.logging.Logger.getLogger(...) instead of
>> java.util.logging.Logger.getLogger(...) (37 occurences if I'm not
>> mistaken). There are also 4 new files, only one being dependant on
>> log4j
>> and one class whose presence in the jar/classpath determines the
>> log4j
>> redirection.
>>
>> In general terms, it means a "casual logging" library/application
>> like
>> Solr can use JDK logging (and no external/log4j dependency) and be
>> made
>> log4j "friendly" at a cost of 3 classes and a convention. I'm not
>> sure
>> this is a valid bug/rfe to post and I don't know how to package
>> this as a
>> patch for general consumption (log4j dependency, build.xml & al).
>> Anyway,
>> the "raw" material is attached here for review & comments.
>> http://www.nabble.com/file/p16825364/logging.tar.gz logging.tar.gz
>> Henri
>>
>
> --
> View this message in context: http://www.nabble.com/logging-through-
> log4j-tp13747253p16961288.html
> Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Ryan McKinley <ry...@gmail.com>.
>
> using an alternate logging framework does't make JUL logging go away
> --
> it's still there, it's the 3000lb gorilla in the corner. it may be
> sleeping, but that doesn't mean some code somewhere isn't going to
> wake it
> up at some point -- you might as well acknowledge it and deal with it.
>
> bringing in another gorilla doesn't make the first one go away
>
funny, I see JUL as the gorilla I wish SOLR did not wake up. Nothing
else I have ever worked dared poke him ;)
I hoped SLF4J would let the the gorilla sleep peacefully along with
javax.swing and the other such animals I keep my distance from. I
prefer kittens.
ryan
Re: logging through log4j (or better yet, SLF4J)
Posted by Henrib <hb...@gmail.com>.
Configuring JUL to fit your needs *requires* that you get people in charge
of the container to cooperate.
If you can not, you are screwed no matter what.
Some of us are just not in a position to negotiate with them on this issue.
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p17022227.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Chris Hostetter <ho...@fucit.org>.
: Being able to override the default implementation fortunately allows to
: implement the must-have feature you describe as the "ClassLoader specific
: LogManagerManager", I agree; however, I think it should have been in the
: default implementation. I view this as a major regression from the previous
: de-facto standard (aka log4j).
take this to the logical conclusion: if JUL's LogManager did implicitly
allow configuration per ClassLoader, then in the case of Something like
Solr, where each core constructs a ClassLoader for loading plugins, you
could wind up with a plugin jar mucking up the logging (for it and other
plugins loaded by teh same class loader) and ignoring the LogManager you
choose for Solr.
Security and configuration and flexibility have to start at the root of
the tree and be passed down. the "root application" (servlet
container in our case) needs to say "i'm going to use a LogManager that
allows code i load at runtime to pick it's own LogManager". The converse
is also true, a servlet container needs to be able to say "i'm not going
to allow webapps to log willynilly, all messages must get funneled through
me via a central config." ... it just so happens that the later is the
default.
: There are organisations where IT responsability ends at application
: security/start/stop (the more apps/servers running, the more likely &
: common); people in charge of the application content & usage do monitor
: their logs. In this case, the unified logging pipeline (ala Websphere/JUL
: for instance) is in fact inconvenient (fortunately, WAS also support
: commons/log4j/...).
:
: IT logs are expected to only contain container/services logs and
: applications are highly encouraged (aka expected) to deal with their logging
: needs themselves.
Then the IT people setting this expectation should be providing you the
basic tool you need to satisfy it: a servlet container using a LogManager
that will delegate to a LogManager (or LogManager configuration) per
webapp.
-Hoss
Re: logging through log4j (or better yet, SLF4J)
Posted by Henrib <hb...@gmail.com>.
Erik Hatcher wrote:
>
> It seems to me Sun left it wide open for a thousand implementations
> to flourish, actually. What's to prevent a ClassLoader specific
> LogManagerManager from being put into the mix? Nothing - that's what
> JULI does.
>
Being able to override the default implementation fortunately allows to
implement the must-have feature you describe as the "ClassLoader specific
LogManagerManager", I agree; however, I think it should have been in the
default implementation. I view this as a major regression from the previous
de-facto standard (aka log4j).
Instead of having "one" standard as it should have been, we end up with one
proprietary solution per container trying (or not) to complement it with
some "slightly extended constructs" to cope with configuration.
Erik Hatcher wrote:
>
> Container writers do need to ensure they funnel all of
> their plugged in components to a unified pipeline to be good logging
> citizens.
>
I see a difference between "container plug-ins/core services" where the
unified pipeline allows these to be good logging citizens and applications
where it is almost an hindrance.
There are organisations where IT responsability ends at application
security/start/stop (the more apps/servers running, the more likely &
common); people in charge of the application content & usage do monitor
their logs. In this case, the unified logging pipeline (ala Websphere/JUL
for instance) is in fact inconvenient (fortunately, WAS also support
commons/log4j/...).
IT logs are expected to only contain container/services logs and
applications are highly encouraged (aka expected) to deal with their logging
needs themselves.
If we consider these environments as application colocating/hosting,
container management stops before the application functional boundary.
Logging is a functional aspect, it is a feature of an application and
therefore should not be tied to container management.
As it stands, JDK logging is certainly appropriate & sufficient for the
container & its services but definitely lacks a standard per-application
self-configurability mechanism to cope with these common deployment schemes.
Of course, all of this is moot when you have the luxury of configuring the
container yourself or as you please but also makes the JDK logging choice a
tad elitist.
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16993293.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 30, 2008, at 12:50 PM, Henrib wrote:
>>
>> the rant is on the containers not doing the
>> right thing by incorporating (something like) JULI.
>>
> Containers {w,sh}ould not have to invent specific and proprietary
> if JDK
> logging specified a way to define LogManager per class-loader;
> imho, the
> rant is squarely on Sun
It seems to me Sun left it wide open for a thousand implementations
to flourish, actually. What's to prevent a ClassLoader specific
LogManagerManager from being put into the mix? Nothing - that's what
JULI does. Container writers do need to ensure they funnel all of
their plugged in components to a unified pipeline to be good logging
citizens.
Erik
Re: logging through log4j (or better yet, SLF4J)
Posted by Henrib <hb...@gmail.com>.
Erik Hatcher wrote:
>
> JUL is the substrate that we (Java developers) should be logging to.
> Practically speaking, I'd like the world to look like this:
> App -> JUL -> Log4J adapter
>
Agreed.
Erik Hatcher wrote:
>
> the rant is on the containers not doing the
> right thing by incorporating (something like) JULI.
>
Containers {w,sh}ould not have to invent specific and proprietary if JDK
logging specified a way to define LogManager per class-loader; imho, the
rant is squarely on Sun.
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16987046.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 29, 2008, at 8:00 PM, David Smiley @MITRE.org wrote:
> 2. If you're saying (from another message I responded to) that it's
> the
> container's job to handle the JUL configuration in a flexible
> manner, then
> wouldn't it be reasonable in this scenario to tell the container to
> direct
> JUL to whatever it is I want (log4j in this scenario)?
JUL is the substrate that we (Java developers) should be logging to.
Practically speaking, I'd like the world to look like this:
App -> JUL -> Log4J adapter
Having log4j be the formatters and triggers and such because it's an
open source implementation with all the goodies you need for
practically any need.
I'm with Hoss here - the rant is on the containers not doing the
right thing by incorporating (something like) JULI.
Erik
Re: logging through log4j (or better yet, SLF4J)
Posted by Chris Hostetter <ho...@fucit.org>.
: And Jetty is what WE ship, not just me using it. By definition, the container
: that we ship for our examples doesn't do logging right. How would we expect
: anyone else to?
Jetty, in my opinion, doesn't do JUL logging wrong -- it just doesn't add
any bells and whistles. It defers to whatever LogManager is specified for
the JVM it's running in.
We include Jetty in our releases for the sole, and explicit, reason that
it is a fairly scaled down and simplified container that let's us run a
single instance of the solr webapp in a portable way. We've intentionally
left out a logging.properties file so that the log messages go to the
console for the purpose of seeing what's going on when doing the tutorial.
http://wiki.apache.org/solr/FAQ#head-a8f4473b60bbeeec2acc0aa1c73c67134d30ff5b
> Solr Comes with Jetty, is Jetty the recommended Servlet Container to use
> when running Solr?
>
> The Solr example app has Jetty in it just because at the time we set it
> up, Jetty was the simplest/smallest servlet container we found that
> could be run easily in a cross platform way (ie: "java -jar start.jar").
> That does not imply that Solr runs better under Jetty, or that Jetty is
> only good enough for demos -- it's just that Jetty made our demo setup
> easier.
>
> Users should decide for themselves which Servlet Container they consider
> the easiest/best for their use cases based on their needs/experience.
> For high traffic scenarios, investing time for tuning the servlet
> container can often make a big difference.
-Hoss
Re: logging through log4j (or better yet, SLF4J)
Posted by Grant Ingersoll <gs...@apache.org>.
But that's just it, hardly anything does use JUL. I can't for the
life of me think of a single project that does OTHER than Solr.
And Jetty is what WE ship, not just me using it. By definition, the
container that we ship for our examples doesn't do logging right. How
would we expect anyone else to?
On Apr 29, 2008, at 8:12 PM, Chris Hostetter wrote:
>
> : 2. If you're saying (from another message I responded to) that
> it's the
> : container's job to handle the JUL configuration in a flexible
> manner, then
> : wouldn't it be reasonable in this scenario to tell the container
> to direct
> : JUL to whatever it is I want (log4j in this scenario)?
> : 3. You mentioned logging from some other webapp that userA didn't
> write. If
> : the container is so great at configuring JUL, then as I ask in #2,
> just let
> : the container do it's JUL kung-fu thing.
>
> that's exactly my point: Any application that loads arbitrary code
> specified at runtime (and a servlet container fits this definition)
> need
> to be able to deal with possibility that that code will use JUL, so
> they
> have to deal with it -- servlet containers that don't make it easy to
> configure how you want them to deal with that aren't very good servlet
> containers (in my opinion). If you don't like the way the servlet
> container you are using deals with JUL messages, don't blame the code
> using JUL, blame the servlet container.
>
>
> -Hoss
>
Re: logging through log4j (or better yet, SLF4J)
Posted by Chris Hostetter <ho...@fucit.org>.
: 2. If you're saying (from another message I responded to) that it's the
: container's job to handle the JUL configuration in a flexible manner, then
: wouldn't it be reasonable in this scenario to tell the container to direct
: JUL to whatever it is I want (log4j in this scenario)?
: 3. You mentioned logging from some other webapp that userA didn't write. If
: the container is so great at configuring JUL, then as I ask in #2, just let
: the container do it's JUL kung-fu thing.
that's exactly my point: Any application that loads arbitrary code
specified at runtime (and a servlet container fits this definition) need
to be able to deal with possibility that that code will use JUL, so they
have to deal with it -- servlet containers that don't make it easy to
configure how you want them to deal with that aren't very good servlet
containers (in my opinion). If you don't like the way the servlet
container you are using deals with JUL messages, don't blame the code
using JUL, blame the servlet container.
-Hoss
Re: logging through log4j (or better yet, SLF4J)
Posted by "David Smiley @MITRE.org" <DS...@mitre.org>.
hossman wrote:
>
> : a fan; but it's really not that important any way). Then, if someone
> (like
> : me :-) would like to configure logging with log4j then I am easily
> empowered
> : to do so by removing that jar and adding slf4j-log4j.jar. What I like
> about
>
> This is the part of all the third party logging abstraction arguments i've
> ever heard that I never understand -- if userA ruws webapp wyz.war in
> "CoolioServletContainer then even if wyx.war uses SLF4J, and even
> if userA uses slf4j-log4j.jar because userA want log4j to be the
> underlying logging system, that won't change the fact that unless
> CoolioServletContainer provides an alternate implementation of the
> JUL LogManager, the default implementation is still being loaded by the
> JVM, and some code somewhere (maybe a plugin to wyz.war, maybe another
> webapp in the same servlet container, etc...) might use the JUL APIs to
> log some info -- so userA needs to worry about those messages (or they go
> to STDERR).
>
1. I think it's VERY rare to find utility/library/framework code that logs
to JUL (instead, JCL and increasingly SLF4J are used for such code). Come
to think of it, I don't know of any at all using JUL; though of course
there's got to be some ill-advised project that doesn't know better out
there ;-P So needless to say, I've yet to run into this scenario despite
all the open-source Java software I've encountered over the years.
2. If you're saying (from another message I responded to) that it's the
container's job to handle the JUL configuration in a flexible manner, then
wouldn't it be reasonable in this scenario to tell the container to direct
JUL to whatever it is I want (log4j in this scenario)?
3. You mentioned logging from some other webapp that userA didn't write. If
the container is so great at configuring JUL, then as I ask in #2, just let
the container do it's JUL kung-fu thing.
hossman wrote:
>
> using an alternate logging framework does't make JUL logging go away --
> it's still there, it's the 3000lb gorilla in the corner. it may be
> sleeping, but that doesn't mean some code somewhere isn't going to wake it
> up at some point -- you might as well acknowledge it and deal with it.
>
> bringing in another gorilla doesn't make the first one go away
>
I'm not sure why a gorilla is a suitable analogy for this... but see #2
above any way.
~ David
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16973118.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j (or better yet, SLF4J)
Posted by Chris Hostetter <ho...@fucit.org>.
: a fan; but it's really not that important any way). Then, if someone (like
: me :-) would like to configure logging with log4j then I am easily empowered
: to do so by removing that jar and adding slf4j-log4j.jar. What I like about
This is the part of all the third party logging abstraction arguments i've
ever heard that I never understand -- if userA ruws webapp wyz.war in
"CoolioServletContainer then even if wyx.war uses SLF4J, and even
if userA uses slf4j-log4j.jar because userA want log4j to be the
underlying logging system, that won't change the fact that unless
CoolioServletContainer provides an alternate implementation of the
JUL LogManager, the default implementation is still being loaded by the
JVM, and some code somewhere (maybe a plugin to wyz.war, maybe another
webapp in the same servlet container, etc...) might use the JUL APIs to
log some info -- so userA needs to worry about those messages (or they go
to STDERR).
using an alternate logging framework does't make JUL logging go away --
it's still there, it's the 3000lb gorilla in the corner. it may be
sleeping, but that doesn't mean some code somewhere isn't going to wake it
up at some point -- you might as well acknowledge it and deal with it.
bringing in another gorilla doesn't make the first one go away
-Hoss
Re: logging through log4j (or better yet, SLF4J)
Posted by "David Smiley @MITRE.org" <DS...@mitre.org>.
Whenever I see a project with some home-grown LogManager that provides
loggers, I am always mildly disgusted no matter how simple it is (no
disrespect to you, that is my opinion). I believe use of SLF4J will meet
common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
out-of-the-box ship the slf4j-jdk14.jar (or not but Eric Hatcher seems to be
a fan; but it's really not that important any way). Then, if someone (like
me :-) would like to configure logging with log4j then I am easily empowered
to do so by removing that jar and adding slf4j-log4j.jar. What I like about
sfl4j is that it is the most logging agnostic of logging apis for java. In
theory, JUL is an agnostic choice but for a variety of reasons that have
already been discussed on this list, it isn't.
~ David Smiley
Henrib wrote:
>
> I've been fiddling with java.util.logging from jul-to-log4j bridge to the
> idea of implementing a LogManager.
> In the latter case there are a lot of deployability caveats, in particular
> the fact that there is no common way of configuring them between servlet
> containers. Trying to tame Websphere on this respect for instance seems
> like a difficult battle.
> In the former case, the jul-to-log4j bridge suffers - in some environment
> - from the fact that the LogManager & al may have security restrictions
> that wont allow manipulating some Logger properties.
> But in all cases, I miss the log4j deployability that does not require
> anything but the fact that some classes exist in the jar/war (ie, no need
> to set something globally in the servlet container or use a JVM wide
> property).
>
> The only solution that I've been able to find is to have Solr cooperate
> and implement its "own" org.apache.solr.Logger "shim" that behaves like a
> local LogManager and trigger the implementation switch by using a log4j
> adapter class; if the adapter class is present (aka loadable), the Loggers
> are anonymous (j.u.l.Logger.getAnonymousLogger) with one handler that
> transforms the LogRecord into log4j events. Otherwise, if that class is
> not present, it just reverts to usual j.u.l logging.
> The only code change is to use
> org.apache.solr.logging.Logger.getLogger(...) instead of
> java.util.logging.Logger.getLogger(...) (37 occurences if I'm not
> mistaken). There are also 4 new files, only one being dependant on log4j
> and one class whose presence in the jar/classpath determines the log4j
> redirection.
>
> In general terms, it means a "casual logging" library/application like
> Solr can use JDK logging (and no external/log4j dependency) and be made
> log4j "friendly" at a cost of 3 classes and a convention. I'm not sure
> this is a valid bug/rfe to post and I don't know how to package this as a
> patch for general consumption (log4j dependency, build.xml & al). Anyway,
> the "raw" material is attached here for review & comments.
> http://www.nabble.com/file/p16825364/logging.tar.gz logging.tar.gz
> Henri
>
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16961288.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j
Posted by Henrib <hb...@gmail.com>.
I've been fiddling with java.util.logging from jul-to-log4j bridge to the
idea of implementing a LogManager.
In the latter case there are a lot of deployability caveats, in particular
the fact that there is no common way of configuring them between servlet
containers. Trying to tame Websphere on this respect for instance seems
like a difficult battle.
In the former case, the jul-to-log4j bridge suffers - in some environment -
from the fact that the LogManager & al may have security restrictions that
wont allow manipulating some Logger properties.
But in all cases, I miss the log4j deployability that does not require
anything but the fact that some classes exist in the jar/war (ie, no need to
set something globally in the servlet container or use a JVM wide property).
The only solution that I've been able to find is to have Solr cooperate and
implement its "own" org.apache.solr.Logger "shim" that behaves like a local
LogManager and trigger the implementation switch by using a log4j adapter
class; if the adapter class is present (aka loadable), the Loggers are
anonymous (j.u.l.Logger.getAnonymousLogger) with one handler that transforms
the LogRecord into log4j events. Otherwise, if that class is not present, it
just reverts to usual j.u.l logging.
The only code change is to use org.apache.solr.logging.Logger.getLogger(...)
instead of java.util.logging.Logger.getLogger(...) (37 occurences if I'm not
mistaken). There are also 4 new files, only one being dependant on log4j and
one class whose presence in the jar/classpath determines the log4j
redirection.
In general terms, it means a "casual logging" library/application like Solr
can use JDK logging (and no external/log4j dependency) and be made log4j
"friendly" at a cost of 3 classes and a convention. I'm not sure this is a
valid bug/rfe to post and I don't know how to package this as a patch for
general consumption (log4j dependency, build.xml & al). Anyway, the "raw"
material is attached here for review & comments.
http://www.nabble.com/file/p16825364/logging.tar.gz logging.tar.gz
Henri
--
View this message in context: http://www.nabble.com/logging-through-log4j-tp13747253p16825364.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logging through log4j
Posted by Chris Hostetter <ho...@fucit.org>.
: It's cool to know about the jul-log4j-bridge and I like the way with a
: single method call one can effectively short-circuit j.u.l. by stealing
: its output, but on very quick read it appears there is a potentially
: non-trivial performance penalty from the need to re-multiplex
: everything, and some of the limitations of j.u.l. remain in effect.
i haven't looked at the code for this jul-log4j-bridge, but if anyone
*really* wants to ridge the JDK / log4j gap once and for all there is a
fairly strait forward way to do it that can be as efficient as you want it
to be:
"Implement the JDK Logging API using classes that delegate to Log4J."
The only problems (in my humble opinion) with JDK logging are that:
1) it wsa branded poorly
2) it is both an API and a default implementation all rolled into one
without a well advertised seperation.
3) the default implementation supports only supports a very limited
config syntax.
The JDK logging docs are very clear about the fact that *ANYONE* can
extend the j.u.logging.LogManager class and make it behave anyway they
want -- the java.util.logging.manager system property can be used to pick
an implementation for your JVM at run time -- no one writting an
application *has* to use the j.u.logging.LogManager (or it's default
config file syntax) just because they use a library that uses
a j.u.logging.Logger.
I have never understood why Log4j doesn't provide some class like...
public JavaUtilLoggingManagerFacade extends java.util.logging.LogManager { ... }
-Hoss
Re: logging through log4j
Posted by Ryan McKinley <ry...@gmail.com>.
aaaah, the logging topic. This has come up a few times:
http://www.nabble.com/Changing-Logging-in-Solr-to-Apache-Commons-Logging-tf3484843.html#a9728641
and
http://www.nabble.com/logging---slf4j--tf3366438.html#a9366144
So far, the consensus has been that jdk logging is fine and can be
configured to do whatever you like. This is true for the web-app
context, and true (but annoying) for an embedded context.
I've been working on a solr+wicket interface - (wicket uses slf4j)
Personally, I would like to see solr use slf4j, but understand the
arguments for sticking with jdk logging
ryan
J.J. Larrea wrote:
> Long on my to-do list has been trying to use sl4j as a bridge to escape the horrible limitations of JDK1.4 java.util.logging unfortunately cemented into Solr, enter the fairly peaceful garden of log4j, and avoid the pitfalls of commons-logging's trying to class-load its way into everyone's living-room ("I am *your* logger!") but knocking over the coffee table in the process.
>
> And for my embedded-Solr indexer, I thought converting the logging calls to sl4j's printf-style message formatting might additionally save some sorely needed cycles. So I'm dismayed to hear that sl4j may not be as simple and effective a bridge solution as I had hoped.
>
> It's cool to know about the jul-log4j-bridge and I like the way with a single method call one can effectively short-circuit j.u.l. by stealing its output, but on very quick read it appears there is a potentially non-trivial performance penalty from the need to re-multiplex everything, and some of the limitations of j.u.l. remain in effect.
>
> So count me as another attentive listener if anyone has some experience or at least gossip pro or con either sl4j or the jul-log4j-bridge.
>
> Thanks,
> J.J. Larrea
>
> At 6:13 AM -0800 11/14/07, Henrib wrote:
>> I'm in a situation where Solr is embedded in a webapp (ie using solr.jar).
>> Other modules of this app are using log4j and I'm looking for a way to make
>> the logging configuration consistent (aka through log4.xml).
>> Can anyone who solved the same kind of issue share his/her experience?
>> After much browsing, understanding why commons-logging, sl4j or others are
>> not solutions for Solr iself, I finally stumbled on
>> http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/
>> which seems to provide a ready made solution.
>> Has anyone some experience & comment using it?
>> Thanks
>> --
>> View this message in context: http://www.nabble.com/logging-through-log4j-tf4805241.html#a13747253
>> Sent from the Solr - Dev mailing list archive at Nabble.com.
>
>
Re: logging through log4j
Posted by "J.J. Larrea" <jj...@panix.com>.
Long on my to-do list has been trying to use sl4j as a bridge to escape the horrible limitations of JDK1.4 java.util.logging unfortunately cemented into Solr, enter the fairly peaceful garden of log4j, and avoid the pitfalls of commons-logging's trying to class-load its way into everyone's living-room ("I am *your* logger!") but knocking over the coffee table in the process.
And for my embedded-Solr indexer, I thought converting the logging calls to sl4j's printf-style message formatting might additionally save some sorely needed cycles. So I'm dismayed to hear that sl4j may not be as simple and effective a bridge solution as I had hoped.
It's cool to know about the jul-log4j-bridge and I like the way with a single method call one can effectively short-circuit j.u.l. by stealing its output, but on very quick read it appears there is a potentially non-trivial performance penalty from the need to re-multiplex everything, and some of the limitations of j.u.l. remain in effect.
So count me as another attentive listener if anyone has some experience or at least gossip pro or con either sl4j or the jul-log4j-bridge.
Thanks,
J.J. Larrea
At 6:13 AM -0800 11/14/07, Henrib wrote:
>I'm in a situation where Solr is embedded in a webapp (ie using solr.jar).
>Other modules of this app are using log4j and I'm looking for a way to make
>the logging configuration consistent (aka through log4.xml).
>Can anyone who solved the same kind of issue share his/her experience?
>After much browsing, understanding why commons-logging, sl4j or others are
>not solutions for Solr iself, I finally stumbled on
>http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/
>which seems to provide a ready made solution.
>Has anyone some experience & comment using it?
>Thanks
>--
>View this message in context: http://www.nabble.com/logging-through-log4j-tf4805241.html#a13747253
>Sent from the Solr - Dev mailing list archive at Nabble.com.