It might be interesting to see how Eclipse and Jetty play together. Gary
On Sat, Jan 18, 2014 at 5:07 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > Well, I’ve always had issues with mixing the servlet spec and OSGi. > Having OSGi run in the servlet container is just awkward, and I don’t know > how of anybody really running the servlet container inside of OSGi. I know > the latest versions of JBoss are doing something OSGi-like, but I’m not > aware that it provides real OSGi support. > > The servlet spec doesn’t really give us anywhere else to hook into other > than a filter or initializer. Hooking above that and you have to create a > custom implementation for each container - if it allows that. > > Ralph > > > On Jan 18, 2014, at 1:56 PM, Matt Sicker <boa...@gmail.com> wrote: > > Guys, I've been reading a little bit about OSGi lately, and that seems > like the perfect use case when combined with servlet 3.0. The thing is, > making minimal JARs is a lot like making bundles. > > The issue I see with async servlets, though, is how to manage the thread > local logger context when an async servlet can have multiple threads. The > most trivial way to make the proper logger context available _somewhere_ is > using request attributes or the servlet context attributes (which is > already being used to hold the initializer which holds the logger context > anyway). That's the thing, though. With multiple threads in a single web > app instance, it's hard to manage state for all those threads without being > higher up in the food chain. I don't think implementing this as a filter is > the best way to go for servlet 3.0. > > > On 18 January 2014 15:19, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> I was hoping to start the GA release sooner than that. >> >> If the servlet context initializer is disabled then the listener should >> still be allowed. >> >> Ralph >> >> On Jan 18, 2014, at 11:38 AM, Nicholas Williams < >> nicho...@nicholaswilliams.net> wrote: >> >> Yes. Next weekend I plan on adding a Servlet context parameter that >> allows the user to disable starting Log4j automatically. That should allow >> us to keep everything in one JAR while supporting both sides of the >> argument. >> >> Nick >> >> Sent from my iPhone, so please forgive brief replies and frequent typos >> >> On Jan 18, 2014, at 10:54, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ralph.go...@dslextreme.com >> > 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 < >>> nicho...@nicholaswilliams.net> 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 <boa...@gmail.com> >>> >>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > Matt Sicker <boa...@gmail.com> > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
