Hi Ceki (and anyone else interested in this discussion),
See comments below...
At 03:36 PM 1/9/2005 +0100, you wrote: > >Hi Jake, > >Just to make sure I understand correctly, >"org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello]" >is name of the logger that TC uses for directing messages generated by >servlets in the web-application "hello" when they invoke the log(String) >method defined in javax.servlet.ServletConfig. Is that correct? >
Yes
>The logger named >"org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello]" is >NOT used for any other purpose. Is that correct? >
Not true. I've seen results of serialization/deserialization of objects in the webapp's session come out there. And that is for the "info" level. We can't presume that there aren't also "warn" and "error" levels used as well, now or in the future. So it is both for Tomcat's logging purposes and servletContext.log().
Keep in mind that, previously, Tomcat defined its own loggers using a <Logger> entry in server.xml or a context configuration file (which is specific to a particular webapp). Information about the context would go there including, like I said before, info messages about serialization and such and error messages such as exception thrown by the application and caught, not by the webapp but, by Tomcat. And, of course, calls to servletContext.log would go there as well. And, of course, this is the idea of the ServletContextLogAppender, to hook the webapp's internal logging transparently into the app's logging system, thereby allowing the server admin to determine where the log file goes. Given that the webapp cannot assume the ability to access the file system of the server it is running on, either within the webapp (which would assume running from a directory which is never guaranteed) or outside it (I think Oracle's AppServer has the webapp running from the database or something weird like that, so I'm not sure if any File IO could be counted on to work there), the ServletContextLogAppender's ability to allow the server admin to determine the log file is a very useful feature. Plus it simply keeps all logging for the app together in one spot.
The fact that Tomcat now uses commons-logging along with server admin's choice of logging implementation shouldn't change the expected behavior of logging to the log file designated for that servlet context by the server admin. Having that logger hijacked by another logger repository surely changes this expected behavior.
>If the above two statements are true, since the >"o.a.c.c.CB.[Catalina].[localhost].[/hello]" logger belongs to the >hello web-application, then having logs generated by that logger go to >hello's logger repository makes perfect sense. I'd be much less happy had >they went to the default logger repository. >
Since both of those statements aren't correct, I think we have a problem here that we have to deal with instead of trying to rationalize it until it isn't a problem anymore.
The fact is, the current behavior renders the ServletContextLogAppender, which used to work perfectly well with the webapp using Log4j-1.2.8 + ContextJNDISelector and the server using its internal <Logger> scheme, useless. And, worse, it both renders any use of servletContext.log() and Tomcat internal use the designated webapp logger useless when the expectation is that it be output to the appender defined in the server's log4j.xml. To say something like "well, if they used a decent logging system (Log4j), then their expectation would have been different, therefore our behavior is correct and their's is not" is not a constructive or satisfying answer. There is an expectation which needs to be met and log4j isn't meeting it right now.
More below...
>More below. > >At 06:54 PM 1/8/2005, Jacob Kjome wrote: > >>Ok, a little more info. >> >>Looks like the ServletContextLogAppender actually is working. In my other >>webapp that I was testing, the console appender was attached to the <root> >>logger with a level of "warn", so I wasn't seeing any output there. But, >>sure enough, the output of logger >>org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello] is >>going to the "hello" logger repository. Take a look at my logging output >>below.... >> >> >>HELLO INFO [http-8080-Processor24] wombat.HelloServlet - Servlet loaded >>HELLO INFO [http-8080-Processor24] >>org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello] - >>[INFO ][cessor24]: wombat.HelloServlet - Servlet loaded >>HELLO INFO [http-8080-Processor24] wombat.HelloServlet - About to say >>hello to bork >>HELLO INFO [http-8080-Processor24] >>org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello] - >>[INFO ][cessor24]: wombat.HelloServlet - About to say >>hello to bork >> >> >>Of course, the logger named >>org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/hello] >>should be going to the default logger repository. At least that's the >>idea. It goes through servletContext.log() and should show up in the log >>file designated for the "hello" context in the server's log4j.xml. The >>point is to be able to log to file without the webapp ever having >>knowledge about where that file exists. > >The logs are generated by the webapp. So they are owned by whomever owns >the webappp, not the server admin. I mean if the webapp owner does not >invoke ServletConfig.log() there won't be any logs in the first place. If >the server admin does not allow the webapp to access files and denies her >to log on the localhost, then that's a different problem. >
I think you are missing the point. Sure, application logging is generated by the webapp. However, it is an explicit choice by the webapp developer to use any given appender, and if they use the ServletContextLogAppender, they've made a decision, by proxy (and documentation), to use servletContext.log(). So, yes, there will most definitely be logs "in the first place".
Additionally, the point of this is to ease configuration and administration. Yes, denial of access to the file system is a different problem and can be dealt with externally to this discussion. The reason I brought it up at all is that it is one of the benefits of the ServletContextLogAppender. I have access to the file system on my own box, yet I use the ServletContextLogAppender anyway, because then I never have to configure a separate log file and for any given webapp, I can send the webapp's logging to wherever I want at the server level without ever having to modify the configuration in the webapp itself. Whether you decide you would use the functionality yourself is beside the point, which is where I suspect some of your consternation with this lies.
>>That is up to the server admin. And, of course, webapps don't necessarily >>have access to the file system except for the servlet-spec-defined temp >>directory designated by the server, but that's for temporary usage, not >>for stuff that should be persisted like a log file. >> >>Is there any way around this? As you'll notice when you test the "hello" >>app, when the webapp is configured with the hello-log4j.xml file, all the >>Log4j internal logging get logged in the "hello" logger repository as >>well. Maybe that part isn't so bad, > >Bad? Isn't it great? That's the whole point of the separation exercise. :-) >
Yes, you're definitely right about this part. I wasn't thinking clearly here and take back what I said about the Log4j internal logging stuff. If a webapp is being configured, then Log4j internal logging should go to that webapp's logger repository.
>>but server classes that are meant to only be part of the default logger >>repository need to be kept out of other logger repositories. > >>Is it possible to avoid this, though? How would these loggers be >>differentiated and/or pegged to a particular logger repository? >> >>Do we need some sort of syntax in config files that reserves certain >>groups of loggers for a particular repository? For instance, in my >>log4j.xml in common/classes, maybe I would reserve org.apache.tomcat and >>org.apache.catalina, org.apache.coyote, and org.apache.log4j loggers and >>their children to be part of the repository using that configuration file >>only. Just a shot in the dark. Thoughts? > >If org.apache.tomcat, org.apache.catalina use log4j, then their loggers >will automatically be in the default repository. I'd be very interested in >pursuing this discussion with concrete examples other than that of >ServletConfig.log(). >
I don't have another example at the moment, but the way you state your response here, it is as if you have written off the servletContext.log() stuff as being of little to no importance, especially after rationalizing the issue away as I described above. I think this is a chink in the chain of the repository selector concept and ought to be solved in a way that allows expected behavior to, well...., work as expected.
The default logger repository seems to me to be a special case in repository selection since it is sort of the master repository in respect to it being the only repository, the fallback for applications that don't take configuration steps to put themselves in a separate logger repository, and/or the logger repository of the master application (the application server) which manages child applications (webapps and such). The fact that there is a master/child relationship between the server and its webapp's suggests that Log4j should probably respect this relationship. The only immediate solution I can think of is defining some way to peg certain loggers to the default logger repository (there really shouldn't be collisions between two non-default logger repositories, so this only concerns the default logger repository). In fact, allowing Log4j to default to the current behavior ought to satisfy you and allowing different behavior after explicit configuration ought to satisfy everyone else (including me).
What do you think? Anyone else want to weigh in?
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
