: 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 mentioned logging from some other webapp that userA didn't write. If : the container is so great at configuring JUL, then as I ask in #2, just let : the container do it's JUL kung-fu thing.
that's exactly my point: Any application that loads arbitrary code specified at runtime (and a servlet container fits this definition) need to be able to deal with possibility that that code will use JUL, so they have to deal with it -- servlet containers that don't make it easy to configure how you want them to deal with that aren't very good servlet containers (in my opinion). If you don't like the way the servlet container you are using deals with JUL messages, don't blame the code using JUL, blame the servlet container. -Hoss
