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-t
: 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 prev
: 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 whatev
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 impleme
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
ran
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 incorpo
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.
brin
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 w
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 any
: 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 ment
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 th
: 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 ar
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-grow
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 - addin
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
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 shi
16 matches
Mail list logo
