Re: Too few fatal log ststements
Thanks! All of you :) Now I have much more understanding about tomcat logging. Thanks a lot! On Mon, Aug 11, 2014 at 7:26 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Sangeeta, > > On 8/11/14, 5:41 AM, sangeeta lal wrote: > > Actually I have data for other log levels also. Debug =600 statements, > > error=400 statements, trace =90 statements etc. > > I would usually expect in a typical project that there would be more > TRACE logging statements than anything else. On the other hand, DEBUG > tends to be the default log level used by most developers that I observe. > > There are likely many DEBUG statements in Tomcat's code that perhaps > should be TRACE statements. > > 400 ERROR versus 600 DEBUG seems like an awfully large number of ERROR > statements, but that may simply be evidence that most errors are > properly-logged while there is less DEBUG logging than average. > > > I am just curious, what could be the possible reason for having such few > > "fatal" statements. Can you give your opinion about this? > > There aren't too many things that ate truly /fatal/ to Tomcat. If we can > read config files, mostly everything is okay. One might consider that > failing to bind to a port is a fatal error, but Tomcat can start up > "successfully" even if no connectors can start properly. This is because > connectors can be configured on the fly, etc. and, in embedded contexts, > the state of the container can change from within and therefore zero > live connectors is no cause for alarm. > > Most errors don't take-down the container/JVM, so they aren't considered > fatal. > > I wouldn't expect to see very many FATAL log messages in any product, > really: the truly fatal things happen at the JVM level and would end up > emitting a message to stdout and possibly bringing-down the JVM entirely > (e.g. segmentation fault). > > If you have some /suggestions/ for what conditions might be fatal, we > might be able to comment on those specifically. But, we aren't going to > re-evaluate every component in Tomcat for logging to satisfy your > academic curiosity about logging practices in the Tomcat source. > > -chris > > -- Regards... Sangeeta Assistant Professor CSE Department @JIIT Noida
[GUMP@vmgump]: Project tomcat-trunk-test-nio2 (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test-nio2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 23 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test-nio2 : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-nio2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-NIO2 -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-NIO2/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-nio2/gump_work/build_tomcat-trunk_tomcat-trunk-test-nio2.html Work Name: build_tomcat-trunk_tomcat-trunk-test-nio2 (Type: Build) Work ended in a state of : Failed Elapsed: 24 mins 33 secs Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.12-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.2-SNAPSHOT.jar -Dtest.reports=output/logs-NIO2 -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140812-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/P20140317-1600/ecj-P20140317-1600.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20140812.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140812-native-src.tar.gz -Dtest.temp=output/test-tmp-NIO2 -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl/dest-20140812/bi n/openssl -Dexecute.test.apr=false -Dexecute.test.bio=false -Dexecute.test.nio2=true -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/public/workspace/hamcrest/hamcrest-java/build/hamcrest-core-20140812.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-trunk/
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/357 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1617365 Blamelist: Build succeeded! sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617386 - /tomcat/trunk/webapps/docs/changelog.xml
Author: kkolinko Date: Tue Aug 12 00:12:07 2014 New Revision: 1617386 URL: http://svn.apache.org/r1617386 Log: Correct a typo Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1617386&r1=1617385&r2=1617386&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Aug 12 00:12:07 2014 @@ -125,7 +125,7 @@ when necessary. (markt) -Add simple caching for calls to StandardRoot.getResoucres() +Add simple caching for calls to StandardRoot.getResources() in the new (for 8.0.x) resources implementation. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-234) Tomcat8 Maven Plugin
[ https://issues.apache.org/jira/browse/MTOMCAT-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093526#comment-14093526 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-234: Hi, I started a branch here https://svn.apache.org/repos/asf/tomcat/maven-plugin/branches/tc8.x/ This is also available in github if you want to participate with pull requests :-) ( https://github.com/apache/tomcat-maven-plugin ) ATM I don't have a lot of time for that :-( Any help will be appreciate!! > Tomcat8 Maven Plugin > > > Key: MTOMCAT-234 > URL: https://issues.apache.org/jira/browse/MTOMCAT-234 > Project: Apache Tomcat Maven Plugin > Issue Type: Dependency upgrade >Affects Versions: 2.0, 2.1, 2.2 > Environment: Maven 3.1, Tomcat8.0RC1, Oracle JDK7u25 >Reporter: Petr Novak >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Blocker > Fix For: 3.0 > > > Please provide initial version of Tomcat8 Maven Plugin. > I tried the recommendations in > http://tomcat.10.x6.nabble.com/Tomcat-8-Tomcat-Maven-Plugin-2-2-Tomcat8-Maven-Plugin-td4995858.html#none > but the guideline > http://tomcat.apache.org/maven-plugin-trunk/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html > does not work for Tomcat8 . > The problem is in changed Tomcat 8 API, the maven throws folloving exception: > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:142) > ... 20 more > by: java.lang.NoSuchMethodError: > org.apache.catalina.startup.Tomcat.setDefaultRealm(Lorg/apache/catalina/Realm;)V > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:999) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:514) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > ... 20 more > The method setDefaultRealm is deprecated in Tomcat7 and was removed in > Tomcat8 as described in documentation: > http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html#setDefaultRealm(org.apache.catalina.Realm) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617383 - /tomcat/trunk/bin/setclasspath.bat
Author: kkolinko Date: Mon Aug 11 23:37:57 2014 New Revision: 1617383 URL: http://svn.apache.org/r1617383 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 Review of r1617362. Correct a copy-paste in condition. Modified: tomcat/trunk/bin/setclasspath.bat Modified: tomcat/trunk/bin/setclasspath.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/setclasspath.bat?rev=1617383&r1=1617382&r2=1617383&view=diff == --- tomcat/trunk/bin/setclasspath.bat (original) +++ tomcat/trunk/bin/setclasspath.bat Mon Aug 11 23:37:57 2014 @@ -80,7 +80,7 @@ set _RUNJAVA="%JRE_HOME%\bin\java" rem Don't override _RUNJDB if the user has set it previously rem Also note the quoting as JAVA_HOME may contain spaces. -if not "%_RUNJAVA%" == "" goto gotRunJdb +if not "%_RUNJDB%" == "" goto gotRunJdb set _RUNJDB="%JAVA_HOME%\bin\jdb" :gotRunJdb - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1615697 - in /tomcat/trunk: java/org/apache/catalina/servlets/DefaultServlet.java webapps/docs/changelog.xml
2014-08-04 21:22 GMT+04:00 :
> Author: markt
> Date: Mon Aug 4 17:22:01 2014
> New Revision: 1615697
>
> URL: http://svn.apache.org/r1615697
> Log:
> When the gzip option is enabled for the DefaultServlet ensure that a suitable
> Vary header is returned for resources that might be returned directly in
> compressed form.
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
> tomcat/trunk/webapps/docs/changelog.xml
>
> Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1615697&r1=1615696&r2=1615697&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Mon
> Aug 4 17:22:01 2014
> @@ -799,16 +799,15 @@ public class DefaultServlet extends Http
>
> // Serve a gzipped version of the file if present
> boolean usingGzippedVersion = false;
> -if (gzip &&
> -resource.isFile() &&
> -!included &&
1). I do get why "!included" check was moved to the place below. I
think it should not be moved.
I think that "included" flag does not depend on "accept-encoding"
value sent by user.
2). There may already be a Vary header in the response.
RFC 7230 Chapter 3.2.2. Field Order
[quote]
A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
[/quote]
The well-known exception referenced above is "Set-Cookie" header.
RFC 7231 Chapter 7.1.4. Vary
defines the field as
Vary = "*" / 1#field-name
so it is an alternative between "*" versus a list of values, so the
above requirement for allowing multiple headers is not met.
3) The code may check response.isCommitted(). (In other words, that
addHeader("Content-Encoding", "gzip")
call has been successful).
Best regards,
Konstantin Kolinko
> -!path.endsWith(".gz") &&
> -checkIfGzip(request)) {
> +if (gzip && resource.isFile() && !path.endsWith(".gz")) {
> WebResource gzipResource = resources.getResource(path + ".gz");
> if (gzipResource.exists() && gzipResource.isFile()) {
> -response.addHeader("Content-Encoding", "gzip");
> -resource = gzipResource;
> -usingGzippedVersion = true;
> +response.addHeader("Vary", "accept-encoding");
> +if (!included && checkIfGzip(request)) {
> +response.addHeader("Content-Encoding", "gzip");
> +resource = gzipResource;
> +usingGzippedVersion = true;
> +}
> }
> }
>
>
> Modified: tomcat/trunk/webapps/docs/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1615697&r1=1615696&r2=1615697&view=diff
> ==
> --- tomcat/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/trunk/webapps/docs/changelog.xml Mon Aug 4 17:22:01 2014
> @@ -80,6 +80,12 @@
> and it need not be fatal when the Realm starts. Based on a patch by
> Cédric Couralet. (markt)
>
> +
> +When the gzip option is enabled for the
> +DefaultServlet ensure that a suitable Vary
> +header is returned for resources that might be returned directly in
> +compressed form.
> +
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot exception in ASF Buildbot on tomcat-trunk
The Buildbot has detected a build exception on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/356 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1617359 Blamelist: BUILD FAILED: exception upload_2 sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/355 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1617355 Blamelist: fhanik BUILD FAILED: failed compile_1 sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617375 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Aug 11 21:57:23 2014 New Revision: 1617375 URL: http://svn.apache.org/r1617375 Log: Fix typo Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1617375&r1=1617374&r2=1617375&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Aug 11 21:57:23 2014 @@ -54,7 +54,8 @@ PATCHES PROPOSED TO BACKPORT: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 Add the ability for users to define their own values for _RUNJAVA and _RUNJBD. Based on a patch by Neeme Praks. - http://svn.apache.org/r1617364 + http://svn.apache.org/r1617364 (the actual fix) + http://svn.apache.org/r1617374 (fix typo in changelog) +1: markt -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617374 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Author: markt Date: Mon Aug 11 21:56:35 2014 New Revision: 1617374 URL: http://svn.apache.org/r1617374 Log: Fix typo Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1617374&r1=1617373&r2=1617374&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Aug 11 21:56:35 2014 @@ -137,7 +137,7 @@ 56829: Add the ability for users to define their own values -for _RUNJAVA and _RUNJBD. Based on a patch by +for _RUNJAVA and _RUNJDB. Based on a patch by Neeme Praks. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617373 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Mon Aug 11 21:55:35 2014 New Revision: 1617373 URL: http://svn.apache.org/r1617373 Log: Fix typo Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1617373&r1=1617372&r2=1617373&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Mon Aug 11 21:55:35 2014 @@ -211,7 +211,7 @@ 56829: Add the ability for users to define their own values -for _RUNJAVA and _RUNJBD. Based on a patch by +for _RUNJAVA and _RUNJDB. Based on a patch by Neeme Praks. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1615725 - in /tomcat/tc7.0.x/trunk: ./ res/tomcat.nsi webapps/docs/changelog.xml
2014-08-04 22:43 GMT+04:00 : > Author: markt > Date: Mon Aug 4 18:43:42 2014 > New Revision: 1615725 > > URL: http://svn.apache.org/r1615725 > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56788 > Display the full version in the list of installed applications when installed > via the Windows installer package. Patch provided by Alexandre Garnier. > > Modified: > tomcat/tc7.0.x/trunk/ (props changed) > tomcat/tc7.0.x/trunk/res/tomcat.nsi > tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml > > Propchange: tomcat/tc7.0.x/trunk/ > -- > Merged /tomcat/trunk:r1615724 > > Modified: tomcat/tc7.0.x/trunk/res/tomcat.nsi > URL: > http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/res/tomcat.nsi?rev=1615725&r1=1615724&r2=1615725&view=diff > == > --- tomcat/tc7.0.x/trunk/res/tomcat.nsi (original) > +++ tomcat/tc7.0.x/trunk/res/tomcat.nsi Mon Aug 4 18:43:42 2014 > @@ -345,6 +345,8 @@ Section -post >WriteRegStr HKLM > "Software\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat > @VERSION_MAJOR_MINOR@ $TomcatServiceName" \ > "DisplayName" "Apache Tomcat @VERSION_MAJOR_MINOR@ > $TomcatServiceName (remove only)" >WriteRegStr HKLM > "Software\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat > @VERSION_MAJOR_MINOR@ $TomcatServiceName" \ > + "DisplayVersion" @VERSION@ I think the value shall be in double quotes, "@VERSION@" > + WriteRegStr HKLM > "Software\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat > @VERSION_MAJOR_MINOR@ $TomcatServiceName" \ > "DisplayIcon" "$\"$INSTDIR\tomcat.ico$\"" >WriteRegStr HKLM > "Software\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat > @VERSION_MAJOR_MINOR@ $TomcatServiceName" \ > "UninstallString" "$\"$INSTDIR\Uninstall.exe$\" > -ServiceName=$\"$TomcatServiceName$\"" > > Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml > URL: > http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1615725&r1=1615724&r2=1615725&view=diff > == > --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) > +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Aug 4 18:43:42 2014 > @@ -105,6 +105,15 @@ > > > > + > + > + > +56788: Display the full version in the list of installed > +applications when installed via the Windows installer package. Patch > +provided by Alexandre Garnier. (markt) > + > + > + > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/207 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1617364 Blamelist: markt BUILD FAILED: failed compile sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1617362 - in /tomcat/trunk: bin/setclasspath.bat bin/setclasspath.sh webapps/docs/changelog.xml
2014-08-12 1:29 GMT+04:00 : > Author: markt > Date: Mon Aug 11 21:29:47 2014 > New Revision: 1617362 > > URL: http://svn.apache.org/r1617362 > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 > Add the ability for users to define their own values for _RUNJAVA and > _RUNJBD. Based on a patch by Neeme Praks. 1. A typo, s/_RUNJBD/_RUNJDB/ in changelog.xml, > Modified: > tomcat/trunk/bin/setclasspath.bat > tomcat/trunk/bin/setclasspath.sh > tomcat/trunk/webapps/docs/changelog.xml > > Modified: tomcat/trunk/bin/setclasspath.bat > URL: > http://svn.apache.org/viewvc/tomcat/trunk/bin/setclasspath.bat?rev=1617362&r1=1617361&r2=1617362&view=diff > == > --- tomcat/trunk/bin/setclasspath.bat (original) > +++ tomcat/trunk/bin/setclasspath.bat Mon Aug 11 21:29:47 2014 > @@ -71,11 +71,18 @@ rem Set the default -Djava.endorsed.dirs > set "JAVA_ENDORSED_DIRS=%CATALINA_HOME%\endorsed" > :gotEndorseddir > > +rem Don't override _RUNJAVA if the user has set it previously > +if not "%_RUNJAVA%" == "" goto gotRunJava > rem Set standard command for invoking Java. > rem Note that NT requires a window name argument when using start. > rem Also note the quoting as JAVA_HOME may contain spaces. > set _RUNJAVA="%JRE_HOME%\bin\java" > +:gotRunJava > + > +rem Don't override _RUNJDB if the user has set it previously > +if not "%_RUNJAVA%" == "" goto gotRunJdb 2. The above line should s/_RUNJAVA/_RUNJDB" > set _RUNJDB="%JAVA_HOME%\bin\jdb" > +:gotRunJdb > > goto end > (...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56828] Cluster setup stopped working after 3 months in production
https://issues.apache.org/bugzilla/show_bug.cgi?id=56828 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Thomas --- I don't see any evidence of a Tomcat bug here. There are lots of possibile causes for a cluster node failing to respond and Bugzilla is not the place to explore those. Neither is Bugzilla the place to discuss cluster configuration options or to have configuration reviewed. Please move this to the users mailing list. -- 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
[Bug 56829] do not override _RUNJAVA and _RUNJDB environment variables if already defined
https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 --- Comment #1 from Mark Thomas --- Fixed in 8.0.x for 8.0.11 onwards and in 7.0.x for 7.0.56 onwards. I modified the patch slightly so setclasspath.sh handled java and jdb separately. The modified patch has been proposed for 6.0.x. -- 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: r1617367 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Mon Aug 11 21:34:10 2014 New Revision: 1617367 URL: http://svn.apache.org/r1617367 Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1617367&r1=1617366&r2=1617367&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Aug 11 21:34:10 2014 @@ -51,6 +51,13 @@ PATCHES PROPOSED TO BACKPORT: +1: kkolinko -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 + Add the ability for users to define their own values for _RUNJAVA and _RUNJBD. + Based on a patch by Neeme Praks. + http://svn.apache.org/r1617364 + +1: markt + -1: + PATCHES/ISSUES THAT ARE STALLED: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617365 - /tomcat/trunk/bin/setclasspath.bat
Author: markt Date: Mon Aug 11 21:33:05 2014 New Revision: 1617365 URL: http://svn.apache.org/r1617365 Log: Improve comments Modified: tomcat/trunk/bin/setclasspath.bat Modified: tomcat/trunk/bin/setclasspath.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/setclasspath.bat?rev=1617365&r1=1617364&r2=1617365&view=diff == --- tomcat/trunk/bin/setclasspath.bat (original) +++ tomcat/trunk/bin/setclasspath.bat Mon Aug 11 21:33:05 2014 @@ -74,12 +74,12 @@ set "JAVA_ENDORSED_DIRS=%CATALINA_HOME%\ rem Don't override _RUNJAVA if the user has set it previously if not "%_RUNJAVA%" == "" goto gotRunJava rem Set standard command for invoking Java. -rem Note that NT requires a window name argument when using start. -rem Also note the quoting as JAVA_HOME may contain spaces. +rem Also note the quoting as JRE_HOME may contain spaces. set _RUNJAVA="%JRE_HOME%\bin\java" :gotRunJava rem Don't override _RUNJDB if the user has set it previously +rem Also note the quoting as JAVA_HOME may contain spaces. if not "%_RUNJAVA%" == "" goto gotRunJdb set _RUNJDB="%JAVA_HOME%\bin\jdb" :gotRunJdb - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617364 - in /tomcat/tc7.0.x/trunk: ./ bin/setclasspath.bat bin/setclasspath.sh webapps/docs/changelog.xml
Author: markt Date: Mon Aug 11 21:31:45 2014 New Revision: 1617364 URL: http://svn.apache.org/r1617364 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 Add the ability for users to define their own values for _RUNJAVA and _RUNJBD. Based on a patch by Neeme Praks. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/bin/setclasspath.bat tomcat/tc7.0.x/trunk/bin/setclasspath.sh tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1617362 Modified: tomcat/tc7.0.x/trunk/bin/setclasspath.bat URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/bin/setclasspath.bat?rev=1617364&r1=1617363&r2=1617364&view=diff == --- tomcat/tc7.0.x/trunk/bin/setclasspath.bat (original) +++ tomcat/tc7.0.x/trunk/bin/setclasspath.bat Mon Aug 11 21:31:45 2014 @@ -71,11 +71,18 @@ rem Set the default -Djava.endorsed.dirs set "JAVA_ENDORSED_DIRS=%CATALINA_HOME%\endorsed" :gotEndorseddir +rem Don't override _RUNJAVA if the user has set it previously +if not "%_RUNJAVA%" == "" goto gotRunJava rem Set standard command for invoking Java. rem Note that NT requires a window name argument when using start. rem Also note the quoting as JAVA_HOME may contain spaces. set _RUNJAVA="%JRE_HOME%\bin\java" +:gotRunJava + +rem Don't override _RUNJDB if the user has set it previously +if not "%_RUNJAVA%" == "" goto gotRunJdb set _RUNJDB="%JAVA_HOME%\bin\jdb" +:gotRunJdb goto end Modified: tomcat/tc7.0.x/trunk/bin/setclasspath.sh URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/bin/setclasspath.sh?rev=1617364&r1=1617363&r2=1617364&view=diff == --- tomcat/tc7.0.x/trunk/bin/setclasspath.sh (original) +++ tomcat/tc7.0.x/trunk/bin/setclasspath.sh Mon Aug 11 21:31:45 2014 @@ -83,8 +83,12 @@ if [ -z "$JAVA_ENDORSED_DIRS" ]; then JAVA_ENDORSED_DIRS="$CATALINA_HOME"/endorsed fi -# Set standard commands for invoking Java. -_RUNJAVA="$JRE_HOME"/bin/java -if [ "$os400" != "true" ]; then - _RUNJDB="$JAVA_HOME"/bin/jdb +# Set standard commands for invoking Java, if not already set. +if [ -z "$_RUNJAVA" ]; then + _RUNJAVA="$JRE_HOME"/bin/java fi +if [ "$os400" != "true" ]; then + if [ -z "$_RUNJDB" ]; then +_RUNJDB="$JAVA_HOME"/bin/jdb + fi +fi \ No newline at end of file Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1617364&r1=1617363&r2=1617364&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Aug 11 21:31:45 2014 @@ -135,6 +135,11 @@ applications when installed via the Windows installer package. Patch provided by Alexandre Garnier. (markt) + +56829: Add the ability for users to define their own values +for _RUNJAVA and _RUNJBD. Based on a patch by +Neeme Praks. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617362 - in /tomcat/trunk: bin/setclasspath.bat bin/setclasspath.sh webapps/docs/changelog.xml
Author: markt Date: Mon Aug 11 21:29:47 2014 New Revision: 1617362 URL: http://svn.apache.org/r1617362 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56829 Add the ability for users to define their own values for _RUNJAVA and _RUNJBD. Based on a patch by Neeme Praks. Modified: tomcat/trunk/bin/setclasspath.bat tomcat/trunk/bin/setclasspath.sh tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/bin/setclasspath.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/setclasspath.bat?rev=1617362&r1=1617361&r2=1617362&view=diff == --- tomcat/trunk/bin/setclasspath.bat (original) +++ tomcat/trunk/bin/setclasspath.bat Mon Aug 11 21:29:47 2014 @@ -71,11 +71,18 @@ rem Set the default -Djava.endorsed.dirs set "JAVA_ENDORSED_DIRS=%CATALINA_HOME%\endorsed" :gotEndorseddir +rem Don't override _RUNJAVA if the user has set it previously +if not "%_RUNJAVA%" == "" goto gotRunJava rem Set standard command for invoking Java. rem Note that NT requires a window name argument when using start. rem Also note the quoting as JAVA_HOME may contain spaces. set _RUNJAVA="%JRE_HOME%\bin\java" +:gotRunJava + +rem Don't override _RUNJDB if the user has set it previously +if not "%_RUNJAVA%" == "" goto gotRunJdb set _RUNJDB="%JAVA_HOME%\bin\jdb" +:gotRunJdb goto end Modified: tomcat/trunk/bin/setclasspath.sh URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/setclasspath.sh?rev=1617362&r1=1617361&r2=1617362&view=diff == --- tomcat/trunk/bin/setclasspath.sh (original) +++ tomcat/trunk/bin/setclasspath.sh Mon Aug 11 21:29:47 2014 @@ -83,8 +83,12 @@ if [ -z "$JAVA_ENDORSED_DIRS" ]; then JAVA_ENDORSED_DIRS="$CATALINA_HOME"/endorsed fi -# Set standard commands for invoking Java. -_RUNJAVA="$JRE_HOME"/bin/java -if [ "$os400" != "true" ]; then - _RUNJDB="$JAVA_HOME"/bin/jdb +# Set standard commands for invoking Java, if not already set. +if [ -z "$_RUNJAVA" ]; then + _RUNJAVA="$JRE_HOME"/bin/java fi +if [ "$os400" != "true" ]; then + if [ -z "$_RUNJDB" ]; then +_RUNJDB="$JAVA_HOME"/bin/jdb + fi +fi \ No newline at end of file Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1617362&r1=1617361&r2=1617362&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Mon Aug 11 21:29:47 2014 @@ -209,6 +209,11 @@ applications when installed via the Windows installer package. Patch provided by Alexandre Garnier. (markt) + +56829: Add the ability for users to define their own values +for _RUNJAVA and _RUNJBD. Based on a patch by +Neeme Praks. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1617359 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
On 11/08/2014 22:14, Konstantin Kolinko wrote:
> 2014-08-12 0:38 GMT+04:00 :
>> Author: markt
>> Date: Mon Aug 11 20:38:18 2014
>> New Revision: 1617359
>>
>> URL: http://svn.apache.org/r1617359
>> Log:
>> Silence some unnecessary nags
>>
>> Modified:
>>
>> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
>>
>> Modified:
>> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java?rev=1617359&r1=1617358&r2=1617359&view=diff
>> ==
>> ---
>> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
>> (original)
>> +++
>> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
>> Mon Aug 11 20:38:18 2014
>> @@ -52,6 +52,7 @@ public class StatementFinalizer extends
>> return statement;
>> }
>>
>> +@SuppressWarnings("null") // st is not null when used
>
> Where it is used?
boolean shallClose = false;
try {
shallClose = st!=null && (!st.isClosed());
if (shallClose) {
st.close(); <=== Possible NPE warning
The IDE doesn't tale account of the lines above that mean st.close()
only ever gets called when st is non-null.
> What guarantees that WeakReference to that Statement does not return
> null?
Not relevant.
> Where is that hard reference that prevents the statement from
> being garbage collected?
Also not relevant.
> With the current code I think ws.getStatement() can return null.
No one is disagreeing with you.
> I am starting to think that we do not need a WeakReference for a
> Statement, but a usual hard reference would work better.
I haven't looked at the code other than the three lines above which were
enough to convince me that the IDE warning was a false positive.
> (Just saying, without digging into the code. The relevant questions are
> - Can it be that the only hard reference to Statement object are in user's
> code?
> - If yes, then what happens if user clears those references and allows
> the Statement to be GC'ed? Are java.sql.Statement implementations
> expected to implement finalize() method that calls close() on them?
> )
None of those points seem relevant to my commit. I haven't dug deeper to
look at the wider code. I was just looking at the IDE warning.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1617359 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
2014-08-12 0:38 GMT+04:00 :
> Author: markt
> Date: Mon Aug 11 20:38:18 2014
> New Revision: 1617359
>
> URL: http://svn.apache.org/r1617359
> Log:
> Silence some unnecessary nags
>
> Modified:
>
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
>
> Modified:
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java?rev=1617359&r1=1617358&r2=1617359&view=diff
> ==
> ---
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> (original)
> +++
> tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
> Mon Aug 11 20:38:18 2014
> @@ -52,6 +52,7 @@ public class StatementFinalizer extends
> return statement;
> }
>
> +@SuppressWarnings("null") // st is not null when used
Where it is used?
What guarantees that WeakReference to that Statement does not return
null? Where is that hard reference that prevents the statement from
being garbage collected?
With the current code I think ws.getStatement() can return null.
I am starting to think that we do not need a WeakReference for a
Statement, but a usual hard reference would work better.
(Just saying, without digging into the code. The relevant questions are
- Can it be that the only hard reference to Statement object are in user's code?
- If yes, then what happens if user clears those references and allows
the Statement to be GC'ed? Are java.sql.Statement implementations
expected to implement finalize() method that calls close() on them?
)
> @Override
> public void closeInvoked() {
> while (statements.size()>0) {
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617359 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Author: markt
Date: Mon Aug 11 20:38:18 2014
New Revision: 1617359
URL: http://svn.apache.org/r1617359
Log:
Silence some unnecessary nags
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java?rev=1617359&r1=1617358&r2=1617359&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Mon Aug 11 20:38:18 2014
@@ -52,6 +52,7 @@ public class StatementFinalizer extends
return statement;
}
+@SuppressWarnings("null") // st is not null when used
@Override
public void closeInvoked() {
while (statements.size()>0) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56831] javax.faces.application.ViewExpiredException thrown for applications which contextRoot contains dash
https://issues.apache.org/bugzilla/show_bug.cgi?id=56831 --- Comment #6 from Konstantin Kolinko --- 1) Guessing with a crystal ball I think ViewExpiredException means that you rely on cookies for session management and the session cookie has not been sent by the browser. 2) The RF-13731 issue mentioned that behaviour differs between browsers. (Firefox has the issue, Chrome does not). Is that true? Why are you not mentioning it? I am experimenting with the following configuration: - current Tomcat 7.0.x (~7.0.55) - Using the default examples webapp renamed to "ex-amples" - Firefox 31.0 - I am using built-in Network tool in Firefox to inspect HTTP headers of requests and responses (Tools menu > Web development > Network). The scenario is as following: 1. Access SessionExample page as [1] http://localhost:8080/ex%2Damples/servlets/servlet/SessionExample 2. I observe the following: 1) Firefox displays the URL in address bar as http://localhost:8080/ex-amples/servlets/servlet/SessionExample 2) Tomcat sends the following header: Set-Cookie: JSESSIONID=727BF492DC0D245BD0AD2D749EB1BD6D; Path=/ex-amples/; HttpOnly 3. If I access [1] again in either of the following ways: a) copy-pasting the above URL into the address bar b) refreshing the page (pressing F5 key on keyboard or clicking green reload button in the address bar) Firefox does not send Cookie header with the request. 4. If I go to address bar and press 'Enter' (Ctrl+L, Enter), Firefox uses '-' character in the request and sends Cookie header with the request. 1). The browser behaviour seems odd to me, but to properly judge it one has to look into applicable specifications and test with other browsers. It might be a browser bug. It might be different interpretation of a specification. Does the behaviour differ between browsers? 2). A well-known recommendation for web application authors is to apply HttpServletResponse.encodeURL() to their URLs. That is to ensure that their applications that require sessions can operate with browsers that do not support cookies. -- 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
[Bug 56831] javax.faces.application.ViewExpiredException thrown for applications which contextRoot contains dash
https://issues.apache.org/bugzilla/show_bug.cgi?id=56831 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Thomas --- I can confim that this is not a Tomcat bug. The issue is triggered by HttpServletRequest.getContextPath() returning "/simple%2dapp" rather than "/simple-app". I have confirmed this by: 1. Confirming I can reproduce the issue using the provided steps. 2. Using a debugger, change the return value of getContextPath() from "/simple%2dapp" to "/simple-app" and confirming that the exception no longer occurs. The Javadoc for getContextPath() [1] is clear. The container does NOT decode this method. The simplest fix is probably for RichFaces to use ServletContext.getContextPath() That you don't see this bug on other containers suggests that those containers are not following the specification for HttpServletRequest.getContextPath(). [1] http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getContextPath%28%29 -- 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: r1617355 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Author: fhanik
Date: Mon Aug 11 19:57:22 2014
New Revision: 1617355
URL: http://svn.apache.org/r1617355
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56318
The weak reference is for the statement itself.
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java?rev=1617355&r1=1617354&r2=1617355&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
Mon Aug 11 19:57:22 2014
@@ -37,7 +37,7 @@ import org.apache.tomcat.jdbc.pool.Poole
public class StatementFinalizer extends AbstractCreateStatementInterceptor {
private static final Log log = LogFactory.getLog(StatementFinalizer.class);
-protected List> statements = new
LinkedList<>();
+protected List statements = new LinkedList<>();
private boolean logCreationStack = false;
@@ -45,7 +45,7 @@ public class StatementFinalizer extends
public Object createStatement(Object proxy, Method method, Object[] args,
Object statement, long time) {
try {
if (statement instanceof Statement)
-statements.add(new WeakReference<>(new
StatementEntry((Statement)statement)));
+statements.add(new StatementEntry((Statement)statement));
}catch (ClassCastException x) {
//ignore this one
}
@@ -55,13 +55,13 @@ public class StatementFinalizer extends
@Override
public void closeInvoked() {
while (statements.size()>0) {
-WeakReference ws = statements.remove(0);
-StatementEntry st = ws.get();
+StatementEntry ws = statements.remove(0);
+Statement st = ws.getStatement();
boolean shallClose = false;
try {
-shallClose = st!=null && (!st.getStatement().isClosed());
+shallClose = st!=null && (!st.isClosed());
if (shallClose) {
-st.getStatement().close();
+st.close();
}
} catch (Exception ignore) {
if (log.isDebugEnabled()) {
@@ -69,7 +69,7 @@ public class StatementFinalizer extends
}
} finally {
if (logCreationStack && shallClose) {
-log.warn("Statement created, but was not closed at:",
st.getAllocationStack());
+log.warn("Statement created, but was not closed at:",
ws.getAllocationStack());
}
}
}
@@ -92,18 +92,18 @@ public class StatementFinalizer extends
}
protected class StatementEntry {
-private Statement statement;
- private Throwable allocationStack;
+private WeakReference statement;
+private Throwable allocationStack;
public StatementEntry(Statement statement) {
-this.statement = statement;
+this.statement = new WeakReference<>(statement);
if (logCreationStack) {
this.allocationStack = new Throwable();
}
}
public Statement getStatement() {
-return statement;
+return statement.get();
}
public Throwable getAllocationStack() {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56831] javax.faces.application.ViewExpiredException thrown for applications which contextRoot contains dash
https://issues.apache.org/bugzilla/show_bug.cgi?id=56831 --- Comment #4 from Mark Thomas --- That you only see this bug on Tomcat could mean that Tomcat is following a strict interpretation of the spec whereas other containers are being more lenient. Given that you know the application far better than the Tomcat developers, it makies things a lot simpler if the bug is presented in the form: - the attached app calls method X with parameters Y - as per the Servlet/JSP/EL/WebSocket/HTTP/etc. spec, Tomcat should return A but instead returns B rather than the Tomcat developers having to dig their way through an app they have no knowledge of to try and work out which API call (that might be returning a completely valid result) is causing the problem. It isn't that we aren't going to look into this bug - I'm going to start on it now - but you could really help move things along by providing a more specific bug report than "The attached app throws an expception when I do this." -- 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
[Bug 56828] Cluster setup stopped working after 3 months in production
https://issues.apache.org/bugzilla/show_bug.cgi?id=56828 --- Comment #4 from KS --- Planning to optimize cluster config as below, for now : Kindly provide your comments on the same. NEW= = -- 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
Re: Too few fatal log ststements
Sangeeta, On 8/11/14, 5:41 AM, sangeeta lal wrote: > Actually I have data for other log levels also. Debug =600 statements, > error=400 statements, trace =90 statements etc. I would usually expect in a typical project that there would be more TRACE logging statements than anything else. On the other hand, DEBUG tends to be the default log level used by most developers that I observe. There are likely many DEBUG statements in Tomcat's code that perhaps should be TRACE statements. 400 ERROR versus 600 DEBUG seems like an awfully large number of ERROR statements, but that may simply be evidence that most errors are properly-logged while there is less DEBUG logging than average. > I am just curious, what could be the possible reason for having such few > "fatal" statements. Can you give your opinion about this? There aren't too many things that ate truly /fatal/ to Tomcat. If we can read config files, mostly everything is okay. One might consider that failing to bind to a port is a fatal error, but Tomcat can start up "successfully" even if no connectors can start properly. This is because connectors can be configured on the fly, etc. and, in embedded contexts, the state of the container can change from within and therefore zero live connectors is no cause for alarm. Most errors don't take-down the container/JVM, so they aren't considered fatal. I wouldn't expect to see very many FATAL log messages in any product, really: the truly fatal things happen at the JVM level and would end up emitting a message to stdout and possibly bringing-down the JVM entirely (e.g. segmentation fault). If you have some /suggestions/ for what conditions might be fatal, we might be able to comment on those specifically. But, we aren't going to re-evaluate every component in Tomcat for logging to satisfy your academic curiosity about logging practices in the Tomcat source. -chris signature.asc Description: OpenPGP digital signature
buildbot exception in ASF Buildbot on tomcat-trunk
The Buildbot has detected a build exception on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/354 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1617266 Blamelist: markt BUILD FAILED: exception upload_2 sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Eclipse JAR dependency
On 10/08/2014 14:24, Konstantin Kolinko wrote: > 2014-08-08 21:12 GMT+04:00 Mark Thomas : >> 3. We will not normally update Tomcat's dependency on JDT until the >>'small' JAR is available in Maven Central. > I disagree (-0, not a stopper) with 3., as this procedure lacks > explicit step that triggers upload of "small" jar. > > Currently the incentive for the upload is our having started to use > the new version. There is no incentive other than that, as I think no > other project besides us uses the jar. > > Essentially we have to announce that we want to update the dependency > and wait for a volunteer to notice the announcement. Ah. That makes things more problematic, especially if they wait for the pom to be updated and start to fail before they start their update process. > I think that the procedure is > 1) update build.properties.default and IDE project files > 2) post a heads-up notice on dev/users and wait a few days > 3) update POM (using the fallback options) It is going to be a while before we need to update this again. I suspect there will have to be a little bit of trial and error until we find the smoothest process. It would help if we knew who was currently uploading the JDT jar then we could ping them directly (unless they are already watching the dev list). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56838] Performance drop when using XML
https://issues.apache.org/bugzilla/show_bug.cgi?id=56838 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Mark Thomas --- Resolving as WONTFIX since the bulk of the delay is caused by other optimisations that aren't going to be reverted. -- 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: r1617266 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Mon Aug 11 12:31:23 2014 New Revision: 1617266 URL: http://svn.apache.org/r1617266 Log: Update change log Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1617266&r1=1617265&r2=1617266&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Mon Aug 11 12:31:23 2014 @@ -124,6 +124,10 @@ processing is correctly transferred back to a genuine container thread when necessary. (markt) + +Add simple caching for calls to StandardRoot.getResoucres() +in the new (for 8.0.x) resources implementation. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1617265 - in /tomcat/trunk/java/org/apache/catalina/webresources: Cache.java CachedResource.java StandardRoot.java
Author: markt
Date: Mon Aug 11 12:29:43 2014
New Revision: 1617265
URL: http://svn.apache.org/r1617265
Log:
Add simple caching support for calls to getResources()
Modified:
tomcat/trunk/java/org/apache/catalina/webresources/Cache.java
tomcat/trunk/java/org/apache/catalina/webresources/CachedResource.java
tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
Modified: tomcat/trunk/java/org/apache/catalina/webresources/Cache.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/Cache.java?rev=1617265&r1=1617264&r2=1617265&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/webresources/Cache.java (original)
+++ tomcat/trunk/java/org/apache/catalina/webresources/Cache.java Mon Aug 11
12:29:43 2014
@@ -67,7 +67,7 @@ public class Cache {
CachedResource cacheEntry = resourceCache.get(path);
-if (cacheEntry != null &&
!cacheEntry.validate(useClassLoaderResources)) {
+if (cacheEntry != null &&
!cacheEntry.validateResource(useClassLoaderResources)) {
removeCacheEntry(path);
cacheEntry = null;
}
@@ -85,7 +85,7 @@ public class Cache {
if (cacheEntry == null) {
// newCacheEntry was inserted into the cache - validate it
cacheEntry = newCacheEntry;
-cacheEntry.validate(useClassLoaderResources);
+cacheEntry.validateResource(useClassLoaderResources);
// Even if the resource content larger than objectMaxSizeBytes
// there is still benefit in caching the resource metadata
@@ -112,7 +112,7 @@ public class Cache {
} else {
// Another thread added the entry to the cache
// Make sure it is validated
-cacheEntry.validate(useClassLoaderResources);
+cacheEntry.validateResource(useClassLoaderResources);
}
} else {
hitCount.incrementAndGet();
@@ -121,6 +121,66 @@ public class Cache {
return cacheEntry;
}
+protected WebResource[] getResources(String path, boolean
useClassLoaderResources) {
+lookupCount.incrementAndGet();
+
+// Don't call noCache(path) since the class loader only caches
+// individual resources. Therefore, always cache collections here
+
+CachedResource cacheEntry = resourceCache.get(path);
+
+if (cacheEntry != null &&
!cacheEntry.validateResources(useClassLoaderResources)) {
+removeCacheEntry(path);
+cacheEntry = null;
+}
+
+if (cacheEntry == null) {
+// Local copy to ensure consistency
+int objectMaxSizeBytes = getObjectMaxSizeBytes();
+CachedResource newCacheEntry =
+new CachedResource(this, root, path, getTtl(),
objectMaxSizeBytes);
+
+// Concurrent callers will end up with the same CachedResource
+// instance
+cacheEntry = resourceCache.putIfAbsent(path, newCacheEntry);
+
+if (cacheEntry == null) {
+// newCacheEntry was inserted into the cache - validate it
+cacheEntry = newCacheEntry;
+cacheEntry.validateResources(useClassLoaderResources);
+
+// Content will not be cached but we still need metadata size
+long delta = cacheEntry.getSize();
+size.addAndGet(delta);
+
+if (size.get() > maxSize) {
+// Process resources unordered for speed. Trades cache
+// efficiency (younger entries may be evicted before older
+// ones) for speed since this is on the critical path for
+// request processing
+long targetSize =
+maxSize * (100 - TARGET_FREE_PERCENT_GET) / 100;
+long newSize = evict(
+targetSize, resourceCache.values().iterator());
+if (newSize > maxSize) {
+// Unable to create sufficient space for this resource
+// Remove it from the cache
+removeCacheEntry(path);
+log.warn(sm.getString("cache.addFail", path));
+}
+}
+} else {
+// Another thread added the entry to the cache
+// Make sure it is validated
+cacheEntry.validateResources(useClassLoaderResources);
+}
+} else {
+hitCount.incrementAndGet();
+}
+
+return cacheEntry.getWebResources();
+}
+
protected void backgroundProcess() {
// Create an ordered set of all cached resources with the least
recently
// used first. This is a background process so we can afford to
[Bug 56838] Performance drop when using XML
https://issues.apache.org/bugzilla/show_bug.cgi?id=56838 --- Comment #3 from Mark Thomas --- Having spent some time digging into this, the bulk of the delay is related to class loading. The text case triggers an attempt to load the same class for every iteration. The bulk of the performance difference between 7.0.x and 8.0.x is as a result of different optimisations (e.g. r1539992 ) being applied to 8.0.x when compared to 7.0.x. While the web app class loader could be optimised for this test case, it would be at the expense of more common cases. In this case it would be better for the application to retain a simple pool of XML objects and reuse them as required. There are a few changes (such as caching the call to getResources()) that will shave a few % off the 8.0.x time and are also generally useful. I'll look at making those changes shortly but they aren't going to be sufficient to enable 8.0.x to handle this particular case as well as 7.0.x does. Overall, I think this is going to be resolved as WONTFIX. -- 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
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/352 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1617234 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56831] javax.faces.application.ViewExpiredException thrown for applications which contextRoot contains dash
https://issues.apache.org/bugzilla/show_bug.cgi?id=56831 --- Comment #3 from Juraj Huska --- Hello, thanks for quick response. IMHO it is a Tomcat bug because it is the only servlet container/application container I am able to reproduce this issue on. It works on e.g. JBoss AS 7.1.1.Final or Wildfly 8.1.0.Final. Additionally, I managed to reproduce it without Tomcat manager as well. The key to reproduce it is to access the JSF app (localhost:8080/simple-app) from a link with following code: simple-app The issue is occurring only when href attribute contains dash as a URL encoded character. -- 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: r1617242 - /tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Author: markt
Date: Mon Aug 11 10:39:20 2014
New Revision: 1617242
URL: http://svn.apache.org/r1617242
Log:
This can get called a lot and this appears to be marginally faster
Modified:
tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=1617242&r1=1617241&r2=1617242&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Mon Aug
11 10:39:20 2014
@@ -2501,8 +2501,8 @@ public class WebappClassLoader extends U
private String binaryNameToPath(String binaryName, boolean
withLeadingSlash) {
-StringBuilder path = new StringBuilder(
-1 + binaryName.length() + CLASS_FILE_SUFFIX.length());
+// 1 for leading '/', 6 for ".class"
+StringBuilder path = new StringBuilder(7 + binaryName.length());
if (withLeadingSlash) {
path.append('/');
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Too few fatal log ststements
On 11/08/2014 10:41, sangeeta lal wrote: > Hi Mark, > > Actually I have data for other log levels also. Debug =600 statements, > error=400 statements, trace =90 statements etc. > > I am just curious, what could be the possible reason for having such few > "fatal" statements. Can you give your opinion about this? You seem to be missing the point. Your claim that there are "too few" fatal statements is based on an assumption that there is a "correct" number of fatal statements. You have not provided any basis for your assumption of the correct number of log statements therefore it is impossible for anyone to explain why Tomcat has a different number. Mark > > Thanks! for reply. > > > On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas wrote: > >> On 11/08/2014 09:14, sangeeta lal wrote: >>> Hello Team, >>> >>> >>> I am sangeeta PhD scholar and Researcher working in the are of mining >>> software repositories. >>> >>> Currently I am working on the *tomcat *platform. I am parsing the code of >>> tomcat (version 8) and I discovered that there are only *"10-11" >> log.fatal >>> statement.* >>> >>> I am just curious, is it normal? >> >> That depends on your definition of normal. >> >>> and why is it so? >> >> Because that this how the Tomcat developers wrote the code. >> >>> Why there so few*log.fatal *statements? >> >> That questions assumes that Tomcat has fewer than the normal number of >> fatal log statements. As per my comment above, that depends on how >> normal is defined. >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Too few fatal log ststements
Hi, On Mon, Aug 11, 2014 at 11:45 AM, Leon Rosenberg wrote: > maybe tomcat is just so robust, that nothing is fatal to it ;-) > Leon > > > On Mon, Aug 11, 2014 at 11:41 AM, sangeeta lal > wrote: > > > Hi Mark, > > > > Actually I have data for other log levels also. Debug =600 statements, > > error=400 statements, trace =90 statements etc. > > > > I am just curious, what could be the possible reason for having such few > > "fatal" statements. Can you give your opinion about this? > It seems you don't know what is the purpose of the log messages. Fatal log level is used to indicate that there is a such a problem that Tomcat cannot even start, e.g. some configuration issue. Error level is used to indicate that there is a serious problem but Tomcat can still work, e.g. some request failed somehow and all its resources will be released, but Tomcat will continue serving more requests. Debug and Trace log levels are used for debugging. Usually they are not enabled. > > > > Thanks! for reply. > > > > > > On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas wrote: > > > > > On 11/08/2014 09:14, sangeeta lal wrote: > > > > Hello Team, > > > > > > > > > > > > I am sangeeta PhD scholar and Researcher working in the are of mining > > > > software repositories. > > > > > > > > Currently I am working on the *tomcat *platform. I am parsing the > code > > of > > > > tomcat (version 8) and I discovered that there are only *"10-11" > > > log.fatal > > > > statement.* > > > > > > > > I am just curious, is it normal? > > > > > > That depends on your definition of normal. > > > > > > > and why is it so? > > > > > > Because that this how the Tomcat developers wrote the code. > > > > > > > Why there so few*log.fatal *statements? > > > > > > That questions assumes that Tomcat has fewer than the normal number of > > > fatal log statements. As per my comment above, that depends on how > > > normal is defined. > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > -- > > Regards... > > Sangeeta > > Assistant Professor > > CSE Department @JIIT Noida > > >
Re: Too few fatal log ststements
Okay! This means its because of requirement specification of Tomcat. On Mon, Aug 11, 2014 at 3:15 PM, Leon Rosenberg wrote: > maybe tomcat is just so robust, that nothing is fatal to it ;-) > Leon > > > On Mon, Aug 11, 2014 at 11:41 AM, sangeeta lal > wrote: > > > Hi Mark, > > > > Actually I have data for other log levels also. Debug =600 statements, > > error=400 statements, trace =90 statements etc. > > > > I am just curious, what could be the possible reason for having such few > > "fatal" statements. Can you give your opinion about this? > > > > Thanks! for reply. > > > > > > On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas wrote: > > > > > On 11/08/2014 09:14, sangeeta lal wrote: > > > > Hello Team, > > > > > > > > > > > > I am sangeeta PhD scholar and Researcher working in the are of mining > > > > software repositories. > > > > > > > > Currently I am working on the *tomcat *platform. I am parsing the > code > > of > > > > tomcat (version 8) and I discovered that there are only *"10-11" > > > log.fatal > > > > statement.* > > > > > > > > I am just curious, is it normal? > > > > > > That depends on your definition of normal. > > > > > > > and why is it so? > > > > > > Because that this how the Tomcat developers wrote the code. > > > > > > > Why there so few*log.fatal *statements? > > > > > > That questions assumes that Tomcat has fewer than the normal number of > > > fatal log statements. As per my comment above, that depends on how > > > normal is defined. > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > > > > -- > > Regards... > > Sangeeta > > Assistant Professor > > CSE Department @JIIT Noida > > > -- Regards... Sangeeta Assistant Professor CSE Department @JIIT Noida
[jira] [Commented] (MTOMCAT-234) Tomcat8 Maven Plugin
[ https://issues.apache.org/jira/browse/MTOMCAT-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092625#comment-14092625 ] Xavier Dury commented on MTOMCAT-234: - Do you think there's any chance of progress on this issue now that Tomcat 8 is considered stable (8.0.9)? Thanks. > Tomcat8 Maven Plugin > > > Key: MTOMCAT-234 > URL: https://issues.apache.org/jira/browse/MTOMCAT-234 > Project: Apache Tomcat Maven Plugin > Issue Type: Dependency upgrade >Affects Versions: 2.0, 2.1, 2.2 > Environment: Maven 3.1, Tomcat8.0RC1, Oracle JDK7u25 >Reporter: Petr Novak >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Blocker > Fix For: 3.0 > > > Please provide initial version of Tomcat8 Maven Plugin. > I tried the recommendations in > http://tomcat.10.x6.nabble.com/Tomcat-8-Tomcat-Maven-Plugin-2-2-Tomcat8-Maven-Plugin-td4995858.html#none > but the guideline > http://tomcat.apache.org/maven-plugin-trunk/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html > does not work for Tomcat8 . > The problem is in changed Tomcat 8 API, the maven throws folloving exception: > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:142) > ... 20 more > by: java.lang.NoSuchMethodError: > org.apache.catalina.startup.Tomcat.setDefaultRealm(Lorg/apache/catalina/Realm;)V > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:999) > at > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:514) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > ... 20 more > The method setDefaultRealm is deprecated in Tomcat7 and was removed in > Tomcat8 as described in documentation: > http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html#setDefaultRealm(org.apache.catalina.Realm) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Too few fatal log ststements
maybe tomcat is just so robust, that nothing is fatal to it ;-) Leon On Mon, Aug 11, 2014 at 11:41 AM, sangeeta lal wrote: > Hi Mark, > > Actually I have data for other log levels also. Debug =600 statements, > error=400 statements, trace =90 statements etc. > > I am just curious, what could be the possible reason for having such few > "fatal" statements. Can you give your opinion about this? > > Thanks! for reply. > > > On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas wrote: > > > On 11/08/2014 09:14, sangeeta lal wrote: > > > Hello Team, > > > > > > > > > I am sangeeta PhD scholar and Researcher working in the are of mining > > > software repositories. > > > > > > Currently I am working on the *tomcat *platform. I am parsing the code > of > > > tomcat (version 8) and I discovered that there are only *"10-11" > > log.fatal > > > statement.* > > > > > > I am just curious, is it normal? > > > > That depends on your definition of normal. > > > > > and why is it so? > > > > Because that this how the Tomcat developers wrote the code. > > > > > Why there so few*log.fatal *statements? > > > > That questions assumes that Tomcat has fewer than the normal number of > > fatal log statements. As per my comment above, that depends on how > > normal is defined. > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > -- > Regards... > Sangeeta > Assistant Professor > CSE Department @JIIT Noida >
svn commit: r1617234 - in /tomcat/trunk/test/org/apache/catalina/webresources: AbstractTestDirResourceSet.java AbstractTestFileResourceSet.java
Author: markt
Date: Mon Aug 11 09:44:10 2014
New Revision: 1617234
URL: http://svn.apache.org/r1617234
Log:
Use root just created rather than new object
Modified:
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java
Modified:
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java?rev=1617234&r1=1617233&r2=1617234&view=diff
==
---
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java
(original)
+++
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestDirResourceSet.java
Mon Aug 11 09:44:10 2014
@@ -35,9 +35,7 @@ public abstract class AbstractTestDirRes
public WebResourceRoot getWebResourceRoot() {
File f = new File(getBaseDir());
TesterWebResourceRoot root = new TesterWebResourceRoot();
-WebResourceSet webResourceSet =
-new DirResourceSet(new TesterWebResourceRoot(), "/",
-f.getAbsolutePath(), "/");
+WebResourceSet webResourceSet = new DirResourceSet(root, "/",
f.getAbsolutePath(), "/");
webResourceSet.setReadOnly(readOnly);
root.setMainResources(webResourceSet);
return root;
Modified:
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java?rev=1617234&r1=1617233&r2=1617234&view=diff
==
---
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java
(original)
+++
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestFileResourceSet.java
Mon Aug 11 09:44:10 2014
@@ -35,9 +35,7 @@ public abstract class AbstractTestFileRe
public WebResourceRoot getWebResourceRoot() {
File f = new File(getBaseDir());
TesterWebResourceRoot root = new TesterWebResourceRoot();
-WebResourceSet webResourceSet =
-new DirResourceSet(new TesterWebResourceRoot(), "/",
-f.getAbsolutePath(), "/");
+WebResourceSet webResourceSet = new DirResourceSet(root, "/",
f.getAbsolutePath(), "/");
webResourceSet.setReadOnly(readOnly);
root.setMainResources(webResourceSet);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Too few fatal log ststements
Hi Mark, Actually I have data for other log levels also. Debug =600 statements, error=400 statements, trace =90 statements etc. I am just curious, what could be the possible reason for having such few "fatal" statements. Can you give your opinion about this? Thanks! for reply. On Mon, Aug 11, 2014 at 3:06 PM, Mark Thomas wrote: > On 11/08/2014 09:14, sangeeta lal wrote: > > Hello Team, > > > > > > I am sangeeta PhD scholar and Researcher working in the are of mining > > software repositories. > > > > Currently I am working on the *tomcat *platform. I am parsing the code of > > tomcat (version 8) and I discovered that there are only *"10-11" > log.fatal > > statement.* > > > > I am just curious, is it normal? > > That depends on your definition of normal. > > > and why is it so? > > Because that this how the Tomcat developers wrote the code. > > > Why there so few*log.fatal *statements? > > That questions assumes that Tomcat has fewer than the normal number of > fatal log statements. As per my comment above, that depends on how > normal is defined. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Regards... Sangeeta Assistant Professor CSE Department @JIIT Noida
Re: Too few fatal log ststements
On 11/08/2014 09:14, sangeeta lal wrote: > Hello Team, > > > I am sangeeta PhD scholar and Researcher working in the are of mining > software repositories. > > Currently I am working on the *tomcat *platform. I am parsing the code of > tomcat (version 8) and I discovered that there are only *"10-11" log.fatal > statement.* > > I am just curious, is it normal? That depends on your definition of normal. > and why is it so? Because that this how the Tomcat developers wrote the code. > Why there so few*log.fatal *statements? That questions assumes that Tomcat has fewer than the normal number of fatal log statements. As per my comment above, that depends on how normal is defined. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Too few fatal log ststements
Hello Team, I am sangeeta PhD scholar and Researcher working in the are of mining software repositories. Currently I am working on the *tomcat *platform. I am parsing the code of tomcat (version 8) and I discovered that there are only *"10-11" log.fatal statement.* I am just curious, is it normal? and why is it so? Why there so few*log.fatal *statements? Thanks! -- Regards... Sangeeta Assistant Professor CSE Department @JIIT Noida
