See http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html. We are providing a service definition in META-INF/services/javax.servlet.ServiceContainerInitializer. Once that is found the servlet container is supposed to invoke the initializer. However there are some problems with this as there is no guaranteed order for running them. I suppose the ServletContext could be inspected to look for a setting to disable it. Perhaps if there is no log4j configuration file we could also ignore it.
One thing I really don’t like is that the initializer also throws an error if it finds a manually configured servlet context listener. To me, this is exactly backwards. If the servlet context listener is configured that should take precedence over the initializer. Ralph On Jan 18, 2014, at 10:54 AM, Gary Gregory <[email protected]> wrote: > On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <[email protected]> > wrote: > I’ve always had reservations about the servlet 3.0 automatic configuration > because if the log4j jar is present it can’t be disabled or be modified by > the end user. We’ve had some issues with Spring initialization and now > LOG4J2-452 reinforces that. I would propose that if we want to keep it that > we move the minimum amount required into its own jar so that users have a > choice as to whether it is automatically initialized. > > Am I the only one who feels this way? Frankly, this and one other issue I > plan to work on this weekend are the only things I see as blockers for a GA > release. > > For me, the fewer jars, the better. Can't this be configured somehow without > having to do more jar juggling? > > Gary > > > Ralph > > On Jan 17, 2014, at 8:25 PM, Nick Williams <[email protected]> > wrote: > >> Filter initialization is one of the last things to happen in web app >> startup. The ServletContainerInitializer sets the threads logger context so >> that web app startup procedures can use it. The filter's init() method >> clears it near the end of startup so that it doesn't bleed into another web >> app. >> >> Then, on web apps shutdown, destruction of filters is one of the first >> things to happen. The filter's destroy() sets the logger context so that the >> web app shutdown procedures can use it. >> >> Nick >> >> On Jan 17, 2014, at 10:17 PM, Matt Sicker wrote: >> >>> Now I'm not sure if I'm interpreting this correctly, but init() clears the >>> current thread's logger context, and destroy() sets it. What's up with >>> this? Especially since it just gets set and cleared in the doFilter() bit. >>> >>> -- >>> Matt Sicker <[email protected]> >> > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
