logging revisited...

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

logging revisited...

Ryan McKinley
While I'm on a roll tossing stuff out there....

Since SOLR-560, solr depends on SLF4j as the logging interface.  
However since we also depend on HttpClient we *also* depend on commons-
logging.  This is a strange.  Our maven artifacts now depend on two  
logging frameworks!

However the good folks at SLF4j have a nice solution -- a drop in  
replacement for commons-logging that uses slf4j.

HttpClient discussed switching to SLF4j for version 4.  They decided  
not to because the slfj4 drop-in replacement gives their users even  
more options.  In Droids we had the same discussion, and now use  
commons-logging API.

So, with that in mind I think we should consider using the commons-
logging API and shipping the .war file with the slf4j drop in  
replacement.  The behavior will be identical and their will be one  
fewer libraries.  The loss is the potential to use some of slf4j's  
more advanced logging features, but I don't see us taking advantage of  
that anyway.

ryan









Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Erik Hatcher
LOL!


On Dec 4, 2008, at 4:43 PM, Ryan McKinley wrote:

> While I'm on a roll tossing stuff out there....
>
> Since SOLR-560, solr depends on SLF4j as the logging interface.  
> However since we also depend on HttpClient we *also* depend on  
> commons-logging.  This is a strange.  Our maven artifacts now depend  
> on two logging frameworks!
>
> However the good folks at SLF4j have a nice solution -- a drop in  
> replacement for commons-logging that uses slf4j.
>
> HttpClient discussed switching to SLF4j for version 4.  They decided  
> not to because the slfj4 drop-in replacement gives their users even  
> more options.  In Droids we had the same discussion, and now use  
> commons-logging API.
>
> So, with that in mind I think we should consider using the commons-
> logging API and shipping the .war file with the slf4j drop in  
> replacement.  The behavior will be identical and their will be one  
> fewer libraries.  The loss is the potential to use some of slf4j's  
> more advanced logging features, but I don't see us taking advantage  
> of that anyway.
>
> ryan
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

hossman
In reply to this post by Ryan McKinley

: Subject: logging revisited...

I'm starting to think Ryan woke up today and asked himself "what's the
best way to screw with Hoss on his day off when he's only casually
skimming email?"

: So, with that in mind I think we should consider using the commons-logging API
: and shipping the .war file with the slf4j drop in replacement.  The behavior
: will be identical and their will be one fewer libraries.  The loss is the
: potential to use some of slf4j's more advanced logging features, but I don't
: see us taking advantage of that anyway.

so if i'm understanding your suggestion correctly:

1) we change all of the logging calls in solr to compile against the
commons-logging API.
2) we do *not* ship with the commons-logging api.
3) we ship with an slf4j provided jar that implements the commons-logging
api, funnels the log messages through slf4j and uses java.util.logging as
it's output by default.
4) people who want to configure solr logging via some other favorite
logging framework (log4j, etc...) can still add another magic slf4j jar to
make slf4j write to their framework of choice instead of
java.util.logging.

...do i have that correctly?

I feel dirty just thinking about this.

I think i may just abstain from any and all current or future discussions
or decisions about logging.  I'm really not that old, but I feel like I
age 5 years every time the topic comes up.



-Hoss

Reply | Threaded
Open this post in threaded view
|

RE: logging revisited...

Will Johnson-2
In reply to this post by Ryan McKinley
To a certain extent SLF4j makes this decision a fairly small one, namely
what API do you want to code to inside SOLR and what jars do you want to
ship as a part of the distribution.  It doesn't really matter if you pick
commons-logging, log4j or slf4j; all have drop in replacements via SLF4j.
They also have one for java.util.logging however it requires custom code to
activate since you can't replace java.* classes.  End users get to do pretty
much whatever they want as far as logging goes if you use SLF4j.

SLF4j has also updated their 'legacy' page since the last time I looked
which was the ~last time this came up:

http://www.slf4j.org/legacy.html

We choose to code against slf4j APIs as it seemed like it was where things
were going (including solr) and gave us and our customers the ability to
switch to something else with minimal effort.  We also ship log4j+config
jars by default because it had the richest config/appender set at the time
however the logback project seems like it might be catching up.  (good thing
we can switch with no code changes)

- will



-----Original Message-----
From: Ryan McKinley [mailto:[hidden email]]
Sent: Thursday, December 04, 2008 4:44 PM
To: [hidden email]
Subject: logging revisited...

While I'm on a roll tossing stuff out there....

Since SOLR-560, solr depends on SLF4j as the logging interface.  
However since we also depend on HttpClient we *also* depend on commons-
logging.  This is a strange.  Our maven artifacts now depend on two  
logging frameworks!

However the good folks at SLF4j have a nice solution -- a drop in  
replacement for commons-logging that uses slf4j.

HttpClient discussed switching to SLF4j for version 4.  They decided  
not to because the slfj4 drop-in replacement gives their users even  
more options.  In Droids we had the same discussion, and now use  
commons-logging API.

So, with that in mind I think we should consider using the commons-
logging API and shipping the .war file with the slf4j drop in  
replacement.  The behavior will be identical and their will be one  
fewer libraries.  The loss is the potential to use some of slf4j's  
more advanced logging features, but I don't see us taking advantage of  
that anyway.

ryan










Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Ryan McKinley
In reply to this post by hossman

On Dec 4, 2008, at 5:55 PM, Chris Hostetter wrote:

>
> : Subject: logging revisited...
>
> I'm starting to think Ryan woke up today and asked himself "what's the
> best way to screw with Hoss on his day off when he's only casually
> skimming email?"

If I knew you had the day off, I would ask about moving to jdk 1.6!


>
> : So, with that in mind I think we should consider using the commons-
> logging API
> : and shipping the .war file with the slf4j drop in replacement.  
> The behavior
> : will be identical and their will be one fewer libraries.  The loss  
> is the
> : potential to use some of slf4j's more advanced logging features,  
> but I don't
> : see us taking advantage of that anyway.
>
> so if i'm understanding your suggestion correctly:
>
> 1) we change all of the logging calls in solr to compile against the
> commons-logging API.
> 2) we do *not* ship with the commons-logging api.
> 3) we ship with an slf4j provided jar that implements the commons-
> logging
> api, funnels the log messages through slf4j and uses  
> java.util.logging as
> it's output by default.
> 4) people who want to configure solr logging via some other favorite
> logging framework (log4j, etc...) can still add another magic slf4j  
> jar to
> make slf4j write to their framework of choice instead of
> java.util.logging.
>
> ...do i have that correctly?
>
> I feel dirty just thinking about this.

I'm afraid so, but I'll describe it differently so it does not sound  
as crazy.

1. We compile everything against the commons-logging API (JCL)

2. We ship the .war file with a JCL implementation that behaves  
identical to solr-1.3.  Currently the best option is: jcl-over-
slf4j.jar + slf4j-jdk14.

3. Anyone using the solr.jar could use JCL or SLF4j magic


>
> I think i may just abstain from any and all current or future  
> discussions
> or decisions about logging.  I'm really not that old, but I feel  
> like I
> age 5 years every time the topic comes up.
>


I would have left well enough alone, but I am working with maven  
dependencies now and the duplicate logging frameworks feels a bit  
odd.  I am happy with any choice here, but figured I should bring it  
up before it is 'cooked' in to an official release.

I am happily to stuff the genie back in the bottle, but i don't think  
that puts years back in the bank.

ryan

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

hossman

: If I knew you had the day off, I would ask about moving to jdk 1.6!

Ryan: I may not know where you live, and i may not know what you look
like, but if you insist on goading me like this i will dedicate myself to
answering those questions so i can come to your house and hurt you.

: > I feel dirty just thinking about this.
:
: I'm afraid so, but I'll describe it differently so it does not sound as crazy.

No, no ... you missunderstood.  It didn't actually sound crazy to me,
that's why i felt dirty.

here's my question though: if the slf4j guys have such great support for
implementing the commons-logging api (jcl-over-slf4j.jar right?) then why
do we need to change any code in solr?  

using your three bullet points: can't we skip #1, and just do #2
and then #3 still applies?

: 1. We compile everything against the commons-logging API (JCL)
:
: 2. We ship the .war file with a JCL implementation that behaves identical to
: solr-1.3.  Currently the best option is: jcl-over-slf4j.jar + slf4j-jdk14.
:
: 3. Anyone using the solr.jar could use JCL or SLF4j magic



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Ryan McKinley

On Dec 9, 2008, at 12:39 AM, Chris Hostetter wrote:

>
> : If I knew you had the day off, I would ask about moving to jdk 1.6!
>
> Ryan: I may not know where you live, and i may not know what you look
> like, but if you insist on goading me like this i will dedicate  
> myself to
> answering those questions so i can come to your house and hurt you.
>

game on!


> : > I feel dirty just thinking about this.
> :
> : I'm afraid so, but I'll describe it differently so it does not  
> sound as crazy.
>
> No, no ... you missunderstood.  It didn't actually sound crazy to me,
> that's why i felt dirty.
>
> here's my question though: if the slf4j guys have such great support  
> for
> implementing the commons-logging api (jcl-over-slf4j.jar right?)  
> then why
> do we need to change any code in solr?
>
> using your three bullet points: can't we skip #1, and just do #2
> and then #3 still applies?
>

I'm not sure I follow...  To be clear, the behavior in either case  
will be the same.  The question is just about what logging  
dependencies are required for solr.   Since we are forced to depend on  
the commons-logging api, it might make sense to just use that api.

I am totally happy to leave things as they are -- I like the slf4j API  
and it seems to be getting more popular.  (lucene java is even  
considering using it)

We can make this thread go away by not replying :)

ryan

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Grant Ingersoll-2
In reply to this post by Ryan McKinley
I'm not sure I follow.  We're going to switch to commons-logging, but  
one that was written by the SLF4J people?

On Dec 4, 2008, at 4:43 PM, Ryan McKinley wrote:

> While I'm on a roll tossing stuff out there....
>
> Since SOLR-560, solr depends on SLF4j as the logging interface.  
> However since we also depend on HttpClient we *also* depend on  
> commons-logging.  This is a strange.  Our maven artifacts now depend  
> on two logging frameworks!
>
> However the good folks at SLF4j have a nice solution -- a drop in  
> replacement for commons-logging that uses slf4j.
>
> HttpClient discussed switching to SLF4j for version 4.  They decided  
> not to because the slfj4 drop-in replacement gives their users even  
> more options.  In Droids we had the same discussion, and now use  
> commons-logging API.
>
> So, with that in mind I think we should consider using the commons-
> logging API and shipping the .war file with the slf4j drop in  
> replacement.  The behavior will be identical and their will be one  
> fewer libraries.  The loss is the potential to use some of slf4j's  
> more advanced logging features, but I don't see us taking advantage  
> of that anyway.
>
> ryan
>
>
>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Ryan McKinley
The suggestion is to compile against the commons-loggging *API*, but  
use an SLF4j implementation in the .war file.  The net result is  
identical behavior and one fewer dependency.

However, lets wait to see what happens with:
http://www.nabble.com/Java-logging-in-Lucene-td20859711.html
(Hoss, i swear i had nothing to do with starting that thread)

ryan


On Dec 9, 2008, at 7:12 AM, Grant Ingersoll wrote:

> I'm not sure I follow.  We're going to switch to commons-logging,  
> but one that was written by the SLF4J people?
>
> On Dec 4, 2008, at 4:43 PM, Ryan McKinley wrote:
>
>> While I'm on a roll tossing stuff out there....
>>
>> Since SOLR-560, solr depends on SLF4j as the logging interface.  
>> However since we also depend on HttpClient we *also* depend on  
>> commons-logging.  This is a strange.  Our maven artifacts now  
>> depend on two logging frameworks!
>>
>> However the good folks at SLF4j have a nice solution -- a drop in  
>> replacement for commons-logging that uses slf4j.
>>
>> HttpClient discussed switching to SLF4j for version 4.  They  
>> decided not to because the slfj4 drop-in replacement gives their  
>> users even more options.  In Droids we had the same discussion, and  
>> now use commons-logging API.
>>
>> So, with that in mind I think we should consider using the commons-
>> logging API and shipping the .war file with the slf4j drop in  
>> replacement.  The behavior will be identical and their will be one  
>> fewer libraries.  The loss is the potential to use some of slf4j's  
>> more advanced logging features, but I don't see us taking advantage  
>> of that anyway.
>>
>> ryan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

hossman
In reply to this post by Ryan McKinley

: > Ryan: I may not know where you live, and i may not know what you look
: > like, but if you insist on goading me like this i will dedicate myself to
: > answering those questions so i can come to your house and hurt you.

: game on!

In case anyone is concerned for Ryan's safety: i'm only kidding (for now)

: > here's my question though: if the slf4j guys have such great support for
: > implementing the commons-logging api (jcl-over-slf4j.jar right?) then why
: > do we need to change any code in solr?
: >
: > using your three bullet points: can't we skip #1, and just do #2
: > and then #3 still applies?

: I'm not sure I follow...  To be clear, the behavior in either case will be the
: same.  The question is just about what logging dependencies are required for
: solr.   Since we are forced to depend on the commons-logging api, it might
: make sense to just use that api.

by "forced to depend on the commons-logging api" you mean we indirectly
depend on it because httpclient right?  there's not much we can do about
that.  


: I am totally happy to leave things as they are -- I like the slf4j API and it
: seems to be getting more popular.  (lucene java is even considering using it)

i like your idea of shipping the jcl-over-slf4j.jar in the solr.war ... at
least that way all of the httpclient log messages get piped to JUL the
same way as all the solr log messages; and anyone who uses slf4j to change
the output "pipeline" to go to some other logging implementation only has
to do it once, and doesn't need to add jcl-over-slf4j.jar to get
consistent logging.

but i don't think changing the api Solr compiles against to
commons-logging makes sense -- not since we're already using the
least common denominator API (slf4j)

We could add a new dependency tomorow that uses log4j, and ship with
log4j-over-slf4j.jar; but would we then change the debate to whether the
Solr code should use the commons API or the log4j API or the slf4j API?
... why bother when it's all going to go through slf4j anyway?


-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: logging revisited...

Ryan McKinley
>
> but i don't think changing the api Solr compiles against to
> commons-logging makes sense -- not since we're already using the
> least common denominator API (slf4j)
>

sounds good.  I agree.


> We could add a new dependency tomorow that uses log4j, and ship with
> log4j-over-slf4j.jar; but would we then change the debate to whether  
> the
> Solr code should use the commons API or the log4j API or the slf4j  
> API?
> ... why bother when it's all going to go through slf4j anyway?
>

great.  as is, our .war ships with jcl-over-slf4j-1.5.5.jar

so I think we can put this discussion permanently in the bag.

ryan