You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by David Weinrich <dw...@home.com> on 2001/01/13 08:34:27 UTC
AccessLogUtil and minor patch to AccessLogValve
Time for another installment of the AccessLogUtil, this time the parser is
( nearly ) done and handles most of the possible entries that the apache
mod_log_config does are present ( including filtering an entry based on
status code and parameters to a particular entry type ). The docs for that
module are at:
http://httpd.apache.org/docs/mod/mod_log_config.html
The stuff that I have questions about or haven't implemented yet are as
follows:
%...c: Connection status when response is completed.
'X' = connection aborted before the response completed.
'+' = connection may be kept alive after the response is
sent.
'-' = connection will be closed after the response is sent.
Notes:
* I'm not sure exactly where I would grab the connection aborted
case from ( mostly this was a low priority item, I will dig
through the code and try to locate that a little later ).
%...{FOOBAR}e: The contents of the environment variable FOOBAR
and
%...{Foobar}n: The contents of note "Foobar" from another module.
and
%...P: The process ID of the child that serviced the request.
Notes:
* I don't know these are meaningful/useful in this particular
environment.
%...{Foobar}o: The contents of Foobar: header line(s) in the reply.
Notes:
* This is present *but* response headers that are set internally
( Content-Length and Content-Type are two I ran up against so
far ) aren't yet available. I can fix this in the parser if these
two are the only response headers that get snagged by this.
%...s: Status. For requests that got internally redirected,
this is the status of the *original* request ---
%...>s for the last.
Notes:
* Not sure exactly what the > would mean in this particular
environment, if I'm reading it correctly this is done by
default the way this is implemented but I don't think I am
reading this correctly.
%...{format}t: The time, in the form given by format, which should
be in strftime(3) format. (potentially localized)
Notes:
* For now this actually would take a java.text.SimpleDateFormat
style format. If needed I might be able to parse strtime
formats too but...one thing at a time. I've also added a
shortcut ISO for ISO style timestamp output
"yyyy-MM-dd HH:mm:ss (+|-)offset".
%...T: The time taken to serve the request, in seconds.
Notes:
* Not implemented yet, I'm still trying to figure out a clean
or sane way to do this. So far it looks like the most
straightforward way I've looked at would be to have the
calling valve invoke a 'beforeResponse()' and
'afterResponse()' method but that seems like something of
an ugly solution.
%...v: The canonical ServerName of the server serving the request.
%...V: The server name according to the UseCanonicalName setting.
Notes:
* Is this distinction meaningful in this environment? Right now
the values returned are identical.
I hope this is a fairly useful utility class, the next steps I will
probably take include:
1) Test and retest the parser.
2) Hopefully clarify the items included above and fix.
3) Add additional items available in tomcat but not in mod_log_config.
4) Add a second configuration method that allows the client of this class
to add arbitrary items by name and store a foreign name for that item
( mostly useful for JDBCAccessLog ).
In addition I have some minimal syslog client code sitting around
gathering dust, I know one or two people have requested syslog logs
and access logs. If someone wants I can clean this code up and create
a org.apache.catalina.logger.SyslogLogger class.
One last note: while looking around in AccessLogValve I noticed a
peculiarity in the way the first file opened always lacked the date
stamp. The patch for that is attached.
Thanks for your patience ( this email is a bit lengthy I know ), again any
ideas/critiques/pointers are more than welcome.
David Weinrich
Re: Patches and TC 4.1
Posted by Remy Maucherat <re...@apache.org>.
> Remy Maucherat wrote:
> I have an issue with 4.1 code (fresh from CVS) at the moment -- the JSP
examples
> do not run correctly. That is, any JSP page that references a bean class
that
> is loaded from WEB-INF/classes or WEB-INF/lib fails to find that class.
The classpath generation for Jasper was broken. It should be fixed now.
> > I'd like to make a few proposals :
> > - Move the org.apache.naming package and subpackages, which is part of
the
> > Catalina subproject right now, and make it an independent Tomcat
subproject.
> > - Do the same for the org.apache.catalina.util package (and rename it
> > org.apache.tomcat.util).
> >
>
> By this, do you mean make them separate top-level subdirectories under
> jakarta-tomcat-4.1?
Yes.
> If so, I'm +1.
Ok, I'll make the changes next week.
Remy
Re: Patches and TC 4.1
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:
> > David Weinrich wrote:
> >
> > Now that it's an Apache project, I am +1 for using it ... both here, and
> as an
> > implementation of org.apache.catalina.Logger for the general purpose
> logging
> > that goes on inside Catalina.
>
> +1.
> Will it be required to build ?
>
If we agree to use it (log4j) to implement standard functionality, then it
will. If we use it only for optional stuff, we could make the build scripts
smart enough to recognize this and not compile the optional features, although
IMHO this is *much* more confusing to users who expect a binary distribution to
be "complete".
>
> > I will be examining your patches (and Kief's work on session persistence)
> over
> > the weekend -- look for some commits and/or questions later on.
>
> I was planning to do that, but as I already have a number of items in my
> tasklist it would have taken a while before I applied them.
>
> TC 4.1 should be running fine again. There are no known issues (even with
> WebDAV) except an unimplemented call in the ServletContext.
> The "old" Resources are now gone and replaced with JNDI DirContext. After a
> few adjustements are made, the DefaultServlet / WebdavServlet should be able
> to serve resources from any DirContext implementation (of course, if the
> result of a lookup isn't the special wrapper type Resource or an input
> stream, the string representation of the object will be served, which isn't
> that useful).
>
I have an issue with 4.1 code (fresh from CVS) at the moment -- the JSP examples
do not run correctly. That is, any JSP page that references a bean class that
is loaded from WEB-INF/classes or WEB-INF/lib fails to find that class.
>
> The JARs which are in the /WEB-INF/lib directory in the webapp are still
> loaded from the filesystem, which may or may not be a problem. Classes in
> /WEB-INF/classes are correctly loaded through URLs. I know why this happen,
> and there's no easy way around. One solution I found is providing a more
> complete classloader for the webapps. I'll try to do that, see how good or
> bad it turns out, and commit it if it works ok (it will be called
> WebappClassLoader).
>
> I'll probably do some clenup work in DefaultServlet and WebdavServlet next,
> as the algorithms could be made more efficient (they were adapted for the
> Resources' naming conventions, which were not the same as the JNDI naming
> conventions).
>
> I'd like to make a few proposals :
> - Move the org.apache.naming package and subpackages, which is part of the
> Catalina subproject right now, and make it an independent Tomcat subproject.
> - Do the same for the org.apache.catalina.util package (and rename it
> org.apache.tomcat.util).
>
By this, do you mean make them separate top-level subdirectories under
jakarta-tomcat-4.1? If so, I'm +1.
>
> Remy
>
Craig
Patches and TC 4.1
Posted by Remy Maucherat <re...@apache.org>.
> David Weinrich wrote:
>
> Now that it's an Apache project, I am +1 for using it ... both here, and
as an
> implementation of org.apache.catalina.Logger for the general purpose
logging
> that goes on inside Catalina.
+1.
Will it be required to build ?
> I will be examining your patches (and Kief's work on session persistence)
over
> the weekend -- look for some commits and/or questions later on.
I was planning to do that, but as I already have a number of items in my
tasklist it would have taken a while before I applied them.
TC 4.1 should be running fine again. There are no known issues (even with
WebDAV) except an unimplemented call in the ServletContext.
The "old" Resources are now gone and replaced with JNDI DirContext. After a
few adjustements are made, the DefaultServlet / WebdavServlet should be able
to serve resources from any DirContext implementation (of course, if the
result of a lookup isn't the special wrapper type Resource or an input
stream, the string representation of the object will be served, which isn't
that useful).
The JARs which are in the /WEB-INF/lib directory in the webapp are still
loaded from the filesystem, which may or may not be a problem. Classes in
/WEB-INF/classes are correctly loaded through URLs. I know why this happen,
and there's no easy way around. One solution I found is providing a more
complete classloader for the webapps. I'll try to do that, see how good or
bad it turns out, and commit it if it works ok (it will be called
WebappClassLoader).
I'll probably do some clenup work in DefaultServlet and WebdavServlet next,
as the algorithms could be made more efficient (they were adapted for the
Resources' naming conventions, which were not the same as the JNDI naming
conventions).
I'd like to make a few proposals :
- Move the org.apache.naming package and subpackages, which is part of the
Catalina subproject right now, and make it an independent Tomcat subproject.
- Do the same for the org.apache.catalina.util package (and rename it
org.apache.tomcat.util).
Remy
Re: AccessLogUtil and minor patch to AccessLogValve
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
David Weinrich wrote:
> In diving through the documentation I found for log4j, and hitting the
> website I noticed...it is now part of the jakarta project (yay!). Seems like
> this would be a (much much much) better idea than my mostly-untested syslog
> code for an addition to the logger classes, any thoughts on this?
>
Now that it's an Apache project, I am +1 for using it ... both here, and as an
implementation of org.apache.catalina.Logger for the general purpose logging
that goes on inside Catalina.
I will be examining your patches (and Kief's work on session persistence) over
the weekend -- look for some commits and/or questions later on.
>
> David Weinrich
>
Craig McClanahan
Re: AccessLogUtil and minor patch to AccessLogValve
Posted by Jon Stevens <jo...@latchkey.com>.
on 1/12/01 11:52 PM, "David Weinrich" <dw...@home.com> wrote:
> In diving through the documentation I found for log4j, and hitting the
> website I noticed...it is now part of the jakarta project (yay!). Seems like
> this would be a (much much much) better idea than my mostly-untested syslog
> code for an addition to the logger classes, any thoughts on this?
>
> David Weinrich
+1. Use log4j.
-jon
--
Honk if you love peace and quiet.
Re: AccessLogUtil and minor patch to AccessLogValve
Posted by David Weinrich <dw...@home.com>.
In diving through the documentation I found for log4j, and hitting the
website I noticed...it is now part of the jakarta project (yay!). Seems like
this would be a (much much much) better idea than my mostly-untested syslog
code for an addition to the logger classes, any thoughts on this?
David Weinrich