DO NOT REPLY [Bug 51588] Change access modifiers in AccessLogValve to make it easier to extend
https://issues.apache.org/bugzilla/show_bug.cgi?id=51588 --- Comment #1 from Konstantin Kolinko 2011-07-30 12:18:47 UTC --- Are those new fields specific for your environment? Maybe you can propose them to be added to AccessLogValve? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51588] Change access modifiers in AccessLogValve to make it easier to extend
https://issues.apache.org/bugzilla/show_bug.cgi?id=51588 --- Comment #2 from Rod 2011-07-30 12:49:30 UTC --- I want to add a %f and %F as possible options in the custom log pattern to log IP address and name safely extracted from the X-Forwarded-For header with a fallback to HttpServletRequest.getRemoteAddr(). Just to back up and clarify my original bug report in case it wasn't clear (now that I re-read it I think I could have been clearer): At the bottom of org.apache.catalina.valves.AccessLogValve, the last two private methods are: private AccessLogElement createAccessLogElement(char pattern) and private AccessLogElement createAccessLogElement(String header, char pattern) If you want to add another 'field' to the custom log format pattern by subclassing AccessLogValve then you have to go up to the 3rd last method: protected AccessLogElement[] createLogElements() but unfortunately it contains a lot of good logic that would have to be either completely copied or duplicated in some way. Overriding one or both of the two private methods lets you simply plug in your addition and not replace any of the functionality of the original AccessLogValve. This is the same for both the version 6 and 7 sources. So my suggestions is simply to replace 'private' with 'protected' in the last 2 methods in AccessLogValve. Of course I'd love the new options to be added to the Catalina core but I suspected that they may be slightly peripheral? Perhaps not. I've just finished writing up the details for anyone else that may have a use for this functionality at: http://rod.vagg.org/2011/07/handling-x-forwarded-for-in-java-and-tomcat/ If you think this would be useful to integrate into Catalina then I'd be more than happy to refactor it all into AccessLogValve (it uses an additional utility class as it is now) and post a patch here; please let me know what you think about that option. I think changing those access modifiers would be useful in either case by the way. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51588] Change access modifiers in AccessLogValve to make it easier to extend
https://issues.apache.org/bugzilla/show_bug.cgi?id=51588
--- Comment #3 from Konstantin Kolinko 2011-07-30
13:41:54 UTC ---
Note, that
1. Parsing of X-Forwarded-For is already implemented in Tomcat 7 in
RemoteIpValve and RemoteIpFilter. RemoteIpValve was backported to Tomcat 6,
though maybe not all features of it.
2. AccessLogValve in Tomcat 7 can use request attributes that are set by
RemoteIpValve if you set AccessLogValve.requestAttributesEnabled property to
true.
3. You can set any attribute on the request object (even in the Valve itself)
and reference it later as %{xxx}r
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1152463 - /tomcat/trunk/webapps/docs/class-loader-howto.xml
Author: kkolinko Date: Sat Jul 30 13:57:51 2011 New Revision: 1152463 URL: http://svn.apache.org/viewvc?rev=1152463&view=rev Log: Improve class loading documentation Improve documentation about $CATALINA_HOME/endorsed. Modified: tomcat/trunk/webapps/docs/class-loader-howto.xml Modified: tomcat/trunk/webapps/docs/class-loader-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/class-loader-howto.xml?rev=1152463&r1=1152462&r2=1152463&view=diff == --- tomcat/trunk/webapps/docs/class-loader-howto.xml (original) +++ tomcat/trunk/webapps/docs/class-loader-howto.xml Sat Jul 30 13:57:51 2011 @@ -195,29 +195,31 @@ loading looks in the following repositor - + -Among many other changes, the JavaSE 5 release packages the JAXP APIs, and -a version of Apache Xerces, inside the JRE. This has impacts on applications -that wish to use their own XML parser. +Starting with Java 1.4 a copy of JAXP APIs and an XML parser are packed +inside the JRE. This has impacts on applications that wish to use their own +XML parser. -In previous versions of Tomcat, you could simply replace the XML parser -in the $CATALINA_HOME/common/lib directory to change the parser +In old versions of Tomcat, you could simply replace the XML parser +in the Tomcat libraries directory to change the parser used by all web applications. However, this technique will not be effective -when you are running on JSE 5, because the usual class loader delegation -process will always choose the implementation inside the JDK in preference -to this one. - -JDK 1.5 supports a mechanism called the "Endorsed Standards Override -Mechanism" to allow replacement of APIs created outside of the JCP (i.e. -DOM and SAX from W3C). It can also be used to update the XML parser +when you are running modern versions of Java, because the usual class loader +delegation process will always choose the implementation inside the JDK in +preference to this one. + +Java supports a mechanism called the "Endorsed Standards Override +Mechanism" to allow replacement of APIs created outside of the JCP +(i.e. DOM and SAX from W3C). It can also be used to update the XML parser implementation. For more information, see: http://download.oracle.com/javase/1.5.0/docs/guide/standards/index.html";> http://download.oracle.com/javase/1.5.0/docs/guide/standards/index.html. Tomcat utilizes this mechanism by including the system property setting -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS in the -command line that starts the container. +command line that starts the container. The default value of this option is +$CATALINA_HOME/endorsed. This endorsed directory is not +created by default. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1152466 - in /tomcat/tc6.0.x/trunk/webapps/docs: changelog.xml class-loader-howto.xml
Author: kkolinko Date: Sat Jul 30 14:06:33 2011 New Revision: 1152466 URL: http://svn.apache.org/viewvc?rev=1152466&view=rev Log: Improve class loading documentation Backport documentation changes from Tomcat 7. CTR: Docs - Changed formatting and rewrote some phrases - Documented tomcat-juli.jar and commons-daemon.jar - Documented the peculiarities of tomcat-juli.jar handling in TC6 (vs. TC7). - Mention both CATALINA_HOME and CATALINA_BASE. - Improve documentation about $CATALINA_HOME/endorsed. Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=1152466&r1=1152465&r2=1152466&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Sat Jul 30 14:06:33 2011 @@ -325,6 +325,9 @@ system property name for changing the name of the SSO session cookie. (markt) + +Improve class loading documentation. (kkolinko) + Modified: tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml?rev=1152466&r1=1152465&r2=1152466&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/class-loader-howto.xml Sat Jul 30 14:06:33 2011 @@ -36,22 +36,23 @@ -Like many server applications, Tomcat 6 installs a variety of class loaders +Like many server applications, Tomcat installs a variety of class loaders (that is, classes that implement java.lang.ClassLoader) to allow different portions of the container, and the web applications running on the container, to have access to different repositories of available classes and resources. This mechanism is used to provide the functionality defined in the -Servlet Specification, version 2.4 -- in particular, Sections 9.4 and 9.6. +Servlet Specification, version 2.4 — in particular, Sections 9.4 +and 9.6. -In a J2SE 2 (that is, J2SE 1.2 or later) environment, class loaders are +In a Java environment, class loaders are arranged in a parent-child tree. Normally, when a class loader is asked to load a particular class or resource, it delegates the request to a parent class loader first, and then looks in its own repositories only if the parent -class loader(s) cannot find the requested class or resource. The model for -web application class loaders differs slightly from this, as discussed below, -but the main principles are the same. +class loader(s) cannot find the requested class or resource. Note, that the +model for web application class loaders differs slightly from this, +as discussed below, but the main principles are the same. -When Tomcat 6 is started, it creates a set of class loaders that are +When Tomcat is started, it creates a set of class loaders that are organized into the following parent-child relationships, where the parent class loader is above the child class loader: @@ -76,67 +77,101 @@ the following section. As indicated in the diagram above, Tomcat 6 creates the following class loaders as it is initialized: -Bootstrap - This class loader contains the basic runtime -classes provided by the Java Virtual Machine, plus any classes from JAR -files present in the System Extensions directory -($JAVA_HOME/jre/lib/ext). NOTE - Some JVMs may +Bootstrap — This class loader contains the basic +runtime classes provided by the Java Virtual Machine, plus any classes from +JAR files present in the System Extensions directory +($JAVA_HOME/jre/lib/ext). Note: some JVMs may implement this as more than one class loader, or it may not be visible -(as a class loader) at all. -System - This class loader is normally initialized from -the contents of the CLASSPATH environment variable. All such -classes are visible to both Tomcat internal classes, and to web -applications. However, the standard Tomcat 6 startup scripts +(as a class loader) at all. +System — This class loader is normally initialized +from the contents of the CLASSPATH environment variable. All +such classes are visible to both Tomcat internal classes, and to web +applications. However, the standard Tomcat startup scripts ($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat) totally ignore the contents of the CLASSPATH environment variable itself, and instead build the System class loader from the following repositories: + -$CATALINA_HOME/bin/bootstrap.jar - Contains the main() method -that is used to initialize the Tomcat 6 server, an
DO NOT REPLY [Bug 51580] Severe error deploying WAR application (ExpandWar error)
https://issues.apache.org/bugzilla/show_bug.cgi?id=51580 --- Comment #4 from Konstantin Kolinko 2011-07-30 14:32:59 UTC --- Zip uses platform default encoding to encode file names. JAR uses UTF-8. java.lang.NullPointerException at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:407) at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:138) It looks as if InputStream reference in ExpandWar#expand(InputStream, File) was null. That is an earlier call to jarFile.getInputStream(jarEntry) on ExpandWar.java:135 returned null. The Javadoc for JarFile#getInputStream(ZipEntry) does not say that it can return null. I would have expected a ZipException here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
