For those of you that feel very strongly about swapping out logging
frameworks, give AOP (such as AspectJ) a try to hook the logging. I
suspect it'd be possible to write a few AOP rules that would swap it
out nicely.
Erik
On Apr 2, 2007, at 5:43 PM, Chris Hostetter wrote:
: But Solr will in most cases run together with other applications
in a
: webcontainer. So Solr is not really a stand-alone application in
that sense.
: As other here have pointed out, they have same problems of having to
: support different logging configurations.
I would disagree with saying "most cases", and the problems other
people
have refered to are some people who are doing fairly novel things with
Solr embeded in their aplications - those same people (definitely
Ken, i
think i saw a reply to this effect from Ryan) also point out that when
using Solr as a webapp, their servlet takes care of the disjoint
logging
framework issues for them.
: completely independent of other applications, as it would be rather
: pointless to have a search server running "stand-alone". Sure you
can
: integrate Solr with other software not even written in java, but
still
: many people will integrate it with other java applications
running in
: the same webcontainer.
i would *strenously* disagree with you there ... i have have talked
with
lots of people running Solr and i don't know anyone running it in
the same
JVM as another application in a production situation.
: Of course your are right, JDK logging can be configured in other
ways,
: what I wanted to point out is that JDK logging is configured per VM
: which is less flexible than for example Log4J (correct me if I'm
wrong).
There's a differnece between configuring it per JRE installation
and per
JVM process instance ... even in the later case, the "major" servlet
containers already take care of letting you have seperate
configuration
per webapp/WAR.
: So you are suggesting that I write my own wrapper for the JDK
logging,
: but as I see it this is what Commons-logging is about, having a
wrapper
: to use different logging frameworks.
No, that comment was more generally about why I don't understand the
appeal of moving towards a third party logging abstraction now that a
logging abstraction already exists in the core langauge -- I
suspect that
Ultimately my main point is that all Servlet Containers already
*have* to
deal with JDK logging -- it is 100% safe to use, we don't have to
worry
about dependencies, or classpath issues; the Container takes care
of all
that. Further: many servlet containers *also* make dealing with
code that uses multiple logging frameworks painless and
configurable in a
singlurar way -- they are already solving that problem for
applications
in general, so we don't really need to go out of our way to do
anything
special for Solr.
-Hoss
