"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
Paul Clapham wrote:There is no merit in using an initialization servlet. That's because life-cycle listeners were added to Java EE several years ago, and that's what you should be using now.
Paul Clapham wrote:As for trouble-shooting, you can certainly use a servlet to modify the log level, but I think it's more common to use JMX to do that sort of thing these days.
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
Thad Humphries wrote:As for changing the log level through JMX, how can that be done? When I run jconsole, I don't see my logger. Must I put something into my listener to have jconsole see my logger? How do I connect jconsole and my app that is using log4j.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:One of the Great Confusions of Our Time. I went round and round and round on this one myself.
I'm out of practice on the topic, but unless I got totally confused, JMX for webapps is not an issue. The webapps must contain the appropriate MBeans, and (IIRC) they have to register them with the JVM in order to be served up, but whether a given MBean belongs to the server or to a deployed app doesn't matter, as (I think!) the MBean "belongs" to the JVM.
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:getRealPath() gives me hives. It isn't guaranteed to return a path at all, and especially if the WAR is unexploded.
Personally, I prefer to store parameters like this as env-entry definitions so that they can be set (overridden) from the Tomcat Context definition and retrieved by the webapp via JNDI.
I definitely would avoid using relative path names - they are extremely untrustworthy in a webapp environment. Most likely, I'd expect a general path value and use a "magic" value such as "*" to indicate use of the internal log4j property definitions.
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
Your mother was a hamster and your father was a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|