On 11.07.2011 13:19, Konstantin Kolinko wrote: > 2011/6/23 Rainer Jung <rainer.j...@kippdata.de>: >> Since OneLineFormatter now uses the DateFormatCache util class, and to >> prevent any dependency of juli form other packages that util class sits >> in juli, what do we think about using it also in AccessLogValve? >> >> At the moment the valve has a local copy as an inner class. Of course a >> dependency on juli is OK, because we have it most of the time for >> logging, but it is a bit strange, that this time it is for a utility >> class. What do you think about directly using the juli DateFormatCache >> in the AccessLogValve? Overall I think the benefits of having the code >> only once outweigh the strangeness of that kind of dependency. >> >> And yes, I removed a small generalization form the class when including >> it in juli, which I would thean add back to make the same class work for >> both uses. >> > > I think it is OK. > Most of catalina classes already have dependency on > "org.apache.juli.logging.Log", so the dependency between jars already > does exist, as you noted.
OK, especially the AccessLogValve already uses juli. > Things to watch for while implementing this: > 1) The class should be present in both copies of tomcat-juli.jar: the > one provided in the default distribution and in the one provided as an > extra. > 2) SecurityManager policies for tomcat-juli.jar do differ vs. other > Tomcat code. If the helper class tries to read some system properties, > such rules have to be added to the security policy file. > > I think 1) and 2) are already OK for this specific case. I am > mentioning them here just as a reminder. Thanks! Will check after implementing. I will postpone this refactoring - using a common class for juli and AccessLogValve - after 7.0.19 to allow for more testing. There's no real problem here at the moment, just optimization. The localization issue you noted for the AccessLogValve is not a problem for juli, because the log files are expected to be written in the default locale. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
