I am using Log4j to Log my application.
Previously i was actually initializing the logs in my jsp_init() i.e. in each jsp and servlets.
Now, i think that i should actually initialize the Log once the application starts i.e. inside ContextListener.
But i am not really aware about the performance issue here? Can anyone please explain me jsp_init vs ContextListener in terms of performance.
Actually i am taking out the configuration of Log4j from the properties file , and then i am initializing the object of the Log inside my jsp_init(), which i think i should be doing inside the servlet contextListener and then setting the attribute of the Log object that can be used inside the jsp and servlets for debugging and info statements.
No, you should not initialize logging in each and every JSP.
A relatively clean way to initialize logging is to create what I call a "null servlet", which is a servlet which has an init() method but no GET/POST handlers. Configure logging in the init() method, and make the servlet itself auto-start and be the first servlet to start. Everyone else can pick up from there.
You don't actually have to make a discrete servlet for this purpose as long as you already have something similar that you can add the log config process to. Just keep the design clean.
Customer surveys are for companies who didn't pay proper attention to begin with.
Tim Holloway wrote:No, you should not initialize logging in each and every JSP.
A relatively clean way to initialize logging is to create what I call a "null servlet", which is a servlet which has an init() method but no GET/POST handlers. Configure logging in the init() method, and make the servlet itself auto-start and be the first servlet to start. Everyone else can pick up from there.
You don't actually have to make a discrete servlet for this purpose as long as you already have something similar that you can add the log config process to. Just keep the design clean.
Can i not use Context Listener instead of this "Null Servlet" ?
Personally, I prefer to avoid adding listeners and other esoterica unless they're actually essential. If I can use basic building blocks, it's usually simpler, more understandable, and less likely to break unexpectedly when a new and improved standard comes out.
From a performance point of view, however, consider this: listeners are called continually. I mean, their name says it - they listen. However an init() method is only run once. So from a strictly performance point of view, a listener isn't the optimal choice. You definitely don't want to re-init logging each time the listener kicks off, and even though the overhead for checking so you only run the first time is fairly small, it's still overhead. In addition to the overhead of setting up and calling the listener (assuming you didn't need the listener for other purposes, too).
Tim Holloway wrote:Personally, I prefer to avoid adding listeners and other esoterica unless they're actually essential. If I can use basic building blocks, it's usually simpler, more understandable, and less likely to break unexpectedly when a new and improved standard comes out.
I'm going to have to respectfully but completely disagree with Tim here. "Null servlets" for initialization were a hack to perform initialization prior to the introduction of context listeners. A context listener is now the correct way to perform one-time initialization at context start.
From a performance point of view, however, consider this: listeners are called continually. I mean, their name says it - they listen
The methods of a context listener are called exactly once -- one at startup, and one at shutdown. They are not called continuously.
In addition to the overhead of setting up and calling the listener (assuming you didn't need the listener for other purposes, too).
Any such overhead would be no different than establishing a servlet for the same purpose.
Tim Holloway wrote:Personally, I prefer to avoid adding listeners and other esoterica unless they're actually essential. If I can use basic building blocks, it's usually simpler, more understandable, and less likely to break unexpectedly when a new and improved standard comes out.
From a performance point of view, however, consider this: listeners are called continually. I mean, their name says it - they listen. However an init() method is only run once. So from a strictly performance point of view, a listener isn't the optimal choice. You definitely don't want to re-init logging each time the listener kicks off, and even though the overhead for checking so you only run the first time is fairly small, it's still overhead. In addition to the overhead of setting up and calling the listener (assuming you didn't need the listener for other purposes, too).
Thanks for your quick reply Tim , really appreciate your response.
I think i will be creating a null servlet now and avoid the use of jsp_init() in all my JSP's.
While implementing null servlet, i have found that their was not significant improvement in the performance time as compared to the
ServletContext Listeners
Also i think the initialization is needed only once , hence i will agree with Bear and go for the servletContextListener
Bear Bibeault wrote:I'm going to have to respectfully but completely disagree with Tim here. "Null servlets" for initialization were a hack to perform initialization prior to the introduction of context listeners. A context listener is now the correct way to perform one-time initialization at context start.
I agree that it is the correct and preferred mechanism, but there are enough applications out there using load-on-startup servlets for bootstrap configuration that it is still worth knowing but better not to create any more, in my opinion ;)
manish sahni wrote:While implementing null servlet, i have found that their was not significant improvement in the performance time as compared to the
ServletContext Listeners
Of course there isn't. That's because...
the initialization is needed only once
It's also quite likely because initializing logging only takes a couple of microseconds anyway.
hack to perform initialization prior to the introduction of context listeners. A context listener is now the correct way to perform one-time initialization at context start.
Though I might agree with you Context Listener is the correct way to use, in what way using log4j initialization servlet impact on performance! Obviously, we are talking about server start-up here. Is that the time taken for server start-up with log4j initialization servlet take more time than using Context Listener? If so, I really wouldn't mind sparing few milliseconds as this is not a problem at the request serving time.
I would very very surprised if there were any significant performance impact one way or the other. There difference comes down to that one way is an old-fashioned hack, the other is the conventional and intended mechanism.
Bear Bibeault wrote:I would very very surprised if there were any significant performance impact one way or the other. There difference comes down to that one way is an old-fashioned hack, the other is the conventional and intended mechanism.
Well, I prefer the term "kludge" for that kind of stuff. A "kludge" in my dictionary is something that works, but isn't the ideal approach. Hacks - as my current signature asserts - are in my view crude, nasty solutions to a problem and they tend to be breakable. Although refinements may come into the JEE standard that may require a distinction to be made between the time the servlet context is set up and the time the first servlet inits, whatever happens will be predictable and logical. Not to mention vendor-independent. That's because all the players are performing their roles in accordance to strict specs outlined by the standard. Hacks make their own standards. And suffer thereby.
Nevertheless, I'd forgotten about the addition of the servlet CONTEXT listener and was confusing it with one of the busier listeners. I don't do that stuff often enough these days to remember.
I think I'd have to vote for using the ContextListener for a reason other than sheer performance, however. That being that (presumably, not having RTFM'ed), the context listener event fires before the first servlet inits. And it's preferable to get logging configured as early as possible so that ALL aspects of the app log properly.
There is a case where I might consider doing a non-null version of the log setup servlet - that would be if the servlet provided GET/POST methods to alter logging while the app was running. Although depending on circumstances, I might pair it with a context listener even then.
What this mainly points out to me, however, is how impoverished we've become with the implosion of the trade magazines. I get Linux Journal in dead tree form every month. Not because I can't get it online, but because it has a different reading style. As a tangible collection of articles, I'm less likely to seek-and-find and more likely to browse, and to be well-rounded I like to be presented with literature on stuff that I'm not using now but may need someday and on events in the trade and in the state of the art. Having a medium that's not tied to the distractions of the computer helps a lot, too. Case in point: Hopefully someone would have written up something on context listeners and uses for them that I'd remember, as opposed to having heard about them in passing maybe 5 years ago and forgetting them. I'm always getting little hints like that from the LJ articles.
Tim Holloway wrote:Well, I prefer the term "kludge" for that kind of stuff. A "kludge" in my dictionary is something that works, but isn't the ideal approach.
0
