Re: Mavenization (M10N) of Tomcat Build Process - Should Tomcat Be Migrated to Maven 2?
Hi, Paul! Just a suggestion how to start (seeing all the opinions around): You may start playing in some sandbox, creating a directory structure there, and pulling branches of tomcat code through the use of svn:externals property. It is called creating a view. Having done that, it will be more easy to show what benefits it provides, if any. 2007/10/18, Costin Manolache <[EMAIL PROTECTED]>: > -1 as well on switching to maven as default ( or back to many source tree > 'modules' ). > > But if you want to create a maven build file ( or a Makefile, or > eclipse/netbeans projects, etc :-) that builds tomcat - I personally don't > see a problem with that - as long as it doesn't require moving code around > and can play nicely with the current code layout and other build tools. I > think the 'official' way to build tomcat should remain ant ( at least until > any potential replacement has a large mileage ), but having other alternate > build tools can't hurt. > > I'm quite happy using mostly eclipse - I hardly ever use ant ( mostly to > generate jars and move code around ), the auto-recompilation and fast > run/debug/hot-replace in eclipse are saving me a lot of time, but if > something faster emerges I'll try it. > > Costin > -1 > > On 10/17/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > > > lemme give you my feedback and some history > > > > Paul Shemansky wrote: > > > Dear Fellow Tomcat Developers, > > > > > > As you may have already noticed, I recently joined the ASF and the > > > Tomcat Developer's List. I have been a Maven 2 user since 2005, and I > > > previously used Ant for all of my projects. I suffered through many > > > hardships migrating from Ant to Maven, but in my humble opinion, it > > > was well worth it. I believe that the Tomcat build can certainly > > > benefit from some of the key features of Maven 2 mentioned below. > > > > > > It is not my intention to start a flame war between Ant and Maven > > > users, but merely to propose Maven 2 to this group, and respectfully > > > use this thread to discuss the advantages and disadvantages of > > > switching Tomcat's build process within the 6.0.x or possibly 7.0 > > > release schedule. Please use this thread to voice your opinion. Reply > > > to this message with any comments, and/or simple votes for or against > > > the migration to Maven 2. > > > > > > If by some odd chance you have never seen or heard about Maven 2, > > > please visit and explore : > > > http://maven.apache.org/ > > > > > > Key features that may be useful to us are : > > > > > > - The Standard Directory Layout - Specifically, multi-module builds. > > > This might make managing individual components easier for catalina, > > > coyote, naming, jsp/servlet api/implementation, connector, etc. > > > > > we just refactored everything from being "component/module" based into a > > single source tree. > > Everyone at the time agreed that it would make life easier, for me > > personally, it was a huge improvement. > > > - Model-Based builds - Automatic packaging for the individual modules. > > > > > not sure what this is, even though we have a single source tree, we do > > generate a list of jars. > > > - Dependency Management - Whether it is Apache or another third-party, > > > dependencies can all easily be plugged in. > > > > > we do that today, crude but working, ANT just adopted Ivy, a dependency > > manager for ANT. > > > - Distribution Management - Packaging and Deployment - Although Tomcat > > > has a structured distribution model with Ant, Maven could make this > > > easier with its assembly plugin. This also allows outside entities to > > > easily embed specific Tomcat components or customize the server to > > > suit their needs, (i.e. containers like Geronimo and JBoss, IDE > > > plugins for Eclipse or Tomcat.) > > > > > We currently have a "distribute to Maven repo" in place. > > The most current version is in the sandbox, that would allow us to > > publish to the central ASF repo with signed JAR's. > > This allows(will allow) other projects that do use Maven, to integrate > > tomcat into their system. > > You can glance over it here > > http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/res/maven/ > > > > > - Project Site and Report Generation. - The Tomcat documentation site > > > may benefit greatly, but the Maven reporting plugins seem to be the > > > bigger win here. > > > > > > > > As a new ASF / Tomcat contributor, I am hesitant to step on toes. > > > But, I vote that we eat the dog food. > > and in that last statement is where I think the problem lies. I've > > attended a few hackathons where the coders at my table spent most of > > their day "eating the dog food". > > This has not really been the case with Tomcat, and especially Tomcat 6 > > simplified version of the structure and build. > > > > So, speaking for myself, I have yet not seen a benefit of Maven over our > > current ANT build. And I wouldn't be up for eating dog food. > > water and cr
Re: what happened to the old trunk?
That trunk was moved to sandbox/gdev6x/ See http://svn.apache.org/viewvc?view=rev&revision=573772 Sat Sep 8 02:35:33 2007 UTC (2 months, 4 weeks ago) > I see that in http://svn.apache.org/viewvc?view=rev&revision=593649 a > new trunk was created from 6.0.x/trunk but I don't see what happened to > the old trunk. Any pointers? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat.apache.org serves static pages in UTF-8
Hi! The HTML pages on http://tomcat.apache.org/ are served with the following HTTP header: Content-Type: text/html; charset=utf-8 This happens both with US and EU mirrors (verified with "wget --save-headers") and it contradicts with our generating the pages as iso-8859-1. The noticeable effect is that the "(c)" symbol in the page footers appears as broken "?". Looking at how our Changelog pages deal with this, as they have accented European characters in some patch contributor names, I followed Tomcat 7.0 example and changed output method in tomcat-site.xsl as s/xml/html/. Among other differences it makes the (c) symbol to be encoded as © instead of printing it as a character. Revisions 1182736, 1182744, 1182745. Maybe there are other ideas how to deal with this bikeshed, but now the issue seems solved. It might be that this encoding issue will be observed on other parts of the website as well. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 46264] Shutting down tomcat with large number of contexts is slow
2011/10/13 Mark Thomas : > >> In one place Future is used, while I think it could be Future like >> in >> other places. > > That is the difference between a callable and runnable and I think it is > correct. At least I see errors if I try using Future there. Do you need Runnable in DeployDescriptor, DeployWar, DeployDirectory? That is new code and it is Callable in other places. It is a bikeshed question though. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
juli.OneLineFormatter: use US locale
Hi! I would like to change OneLineFormatter to use US locale for its timestamp. The timestamp format there is "dd-MMM- HH:mm:ss" and in my case the month name is rendered in Cyrillic. The SimpleDateFormat instances are created in org.apache.juli.DateFormatCache$Cache, so it has to be changed there. I think there is no need for it to be configurable the formatter (nor I know how to make it configurable), so I think that the locale in the Cache can be hardcoded as Locale.US. Are there any objections? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183142 - in /tomcat/trunk/java/org/apache/catalina/startup: Constants.java ContextConfig.java LocalStrings.properties
2011/10/14 :
> Author: markt
> Date: Thu Oct 13 22:28:22 2011
> New Revision: 1183142
>
> URL: http://svn.apache.org/viewvc?rev=1183142&view=rev
> Log:
> Cache the result of parsing global and host defaults for web.xml to speed up
> web application start.
> This change reduces applciation start time by ~15% with trunk and the TCK web
> apps
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/startup/Constants.java
> tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
> tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
>
> Modified: tomcat/trunk/java/org/apache/catalina/startup/Constants.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Constants.java?rev=1183142&r1=1183141&r2=1183142&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/startup/Constants.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/startup/Constants.java Thu Oct 13
> 22:28:22 2011
> @@ -34,7 +34,7 @@ public final class Constants {
> public static final String ApplicationContextXml = "META-INF/context.xml";
> public static final String ApplicationWebXml = "/WEB-INF/web.xml";
> public static final String DefaultContextXml = "conf/context.xml";
> - public static final String DefaultWebXml = "conf/web.xml";
> + public static final String DefaultWebXml = "web.xml";
> public static final String HostContextXml = "context.xml.default";
> public static final String HostWebXml = "web.xml.default";
1. Regarding the above change to DefaultWebXml constant:
Looking where it is used:
1) it is returned by ContextConfig#getDefaultWebXml()
2) ContextConfig#getGlobalWebXml() calls
a) ContextConfig#getDefaultWebXml()
b) ((StandardContext) context).getDefaultWebXml()
so that the value could be overwritten in StandardContext.
Javadoc for StandardContext#setDefaultContextXml() says that the value
is relative to catalina.base. This is now broken.
2. Later in ContextConfig#getGlobalWebXml() :
+return new File(basePath, defaultWebXml);
and elsewhere
+return new File(basePath, resourceName);
The above does not work if defaultWebXml is absolute. The simple jsp below
prints C:\workspace\C:\workspace on JDK 6u26 on WinXP:
<%= new java.io.File("C:\\workspace", "C:\\workspace") %>
So absolute paths for StandardContext defaultWebXml setting are broken as well.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
2011/10/14 David Blevins : > We've been using plain Tomcat zips for creating TomEE in the OpenEJB maven > build for a while now. So far that has been done by publishing the Tomcat > zips to a maven repo in svn. Not the best idea to have them in svn, so we're > trying to get them in the actual maven repo. Can't maven be taught to download them from proper ASF mirrors? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Mail address in security-NN.html pages
2011/10/13 Mark Thomas : > On 13/10/2011 09:03, jean-frederic clere wrote: ... >>> 3) The above issues are already mentioned on the generic security page >>> (security.html), but on security-6.html page there is no direct link >>> back to security.html unless you pay attention to the site menu on the >>> left side. >> >> Go fix it :D > > +1. > All done. Please enjoy. Should be online in an hour, as usual. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Embeded Tomcat using a Connector with a random port (port 0)
2011/10/14 Henri Gomez : >>> 3) There are several Connector/Endpoint implementations in Tomcat. >>> While java.net.ServerSocket does support port number of "0", I am not >>> sure that APR-based implementation does allow it. >> Sure but the use case is just to start a http/https (apr can be >> omitted) connector on any random free port, do some unit test and stop >> it. >> IMHO it's a valid use case (and with it folks will be able to use >> tomcat rather than an other servlet container which has this feature >> available :-) ). >> See the code snippet I have pointed, the code to write for using >> tomcat is really smaller/smarter (except all hacking I have to write >> due to the restriction on port). > > Guys. > > It make sense to have a way to get an unused random port for embedded > mode in testing cases. > > On a CI system, ie Jenkins, you could have many concurrents tests done > at the same time, the only solution to get a free port is to discover > it at startup time isn't it ? > Well, after some research, using some random port for bind(0) seems to be a kernel feature. I cannot confirm that apr_socket_bind can accept 0 as port number [1], but seems that allowing 0 will use less resources than trying to programmatically select a random port and retry on failure. [1] http://apr.apache.org/docs/apr/1.4/group__apr__network__io.html So maybe let's go with this and document that support for "0" depends on platform and connector implementation. I think that the value of "-1" could be officially used to disable the connector (prevent it from binding and starting). I think "-1" can be used as the initial value for Connector#port as well, and that this value can be used to re-implement the check in http://svn.apache.org/viewvc?view=revision&revision=1147949 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Embeded Tomcat using a Connector with a random port (port 0)
2011/10/14 Mark Thomas : > If binding to a random port is to be supported I think it needs to be an > explicit choice - e.g. by setting a special value such as "auto" - and > ideally needs to be supported by all connectors. > 2011/10/14 Olivier Lamy : > Do we agree on the fact that after been started, the protocol handler > will update the connector.port field to make the real port used > available for use ? If it were port=0 then you would better define a separate getLocalPort() property. The "auto" value... how can that be? Connector.setPort() accepts integer, and it can also be accessed through JMX. There are several layers, and if you say "update its port number", which of them will update its member variable and which not, and what happens if connector is restarted e.g. through JMX? Also I would like to introduce support for "-1" value for port number, as I mentioned above, but that would be a separate feature. > I have opened https://issues.apache.org/bugzilla/show_bug.cgi?id=52028 > and will try to propose a patch next week. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/14 : > Author: markt > Date: Fri Oct 14 12:55:55 2011 > New Revision: 1183340 > > URL: http://svn.apache.org/viewvc?rev=1183340&view=rev > Log: > Fix typo > > Modified: > tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java > > ... > [... 2667 lines stripped ...] again... How can this happen? A file with svn:eol-style=native is stored at the server with LF endings. The subversion client should convert it to LF before sending. How the diff happens to cover every line? What were you doing? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/14 Mark Thomas : > On 14/10/2011 14:10, Konstantin Kolinko wrote: >> 2011/10/14 : >>> Author: markt >>> Date: Fri Oct 14 12:55:55 2011 >>> New Revision: 1183340 >>> >>> URL: http://svn.apache.org/viewvc?rev=1183340&view=rev >>> Log: >>> Fix typo >>> >>> Modified: >>> tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java >>> >>> ... >>> [... 2667 lines stripped ...] >> >> again... >> >> How can this happen? >> A file with svn:eol-style=native is stored at the server with LF >> endings. The subversion client should convert it to LF before sending. >> How the diff happens to cover every line? >> >> What were you doing? > > Using git. > How? Some git push (or haw it is called there?) that writes directly to the repository? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/14 Mark Thomas : > On 14/10/2011 14:51, Konstantin Kolinko wrote: >> 2011/10/14 Mark Thomas : >>> On 14/10/2011 14:10, Konstantin Kolinko wrote: >>>> 2011/10/14 : >>>>> Author: markt >>>>> Date: Fri Oct 14 12:55:55 2011 >>>>> New Revision: 1183340 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1183340&view=rev >>>>> Log: >>>>> Fix typo >>>>> >>>>> Modified: >>>>> tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java >>>>> >>>>> ... >>>>> [... 2667 lines stripped ...] >>>> >>>> again... >>>> >>>> How can this happen? >>>> A file with svn:eol-style=native is stored at the server with LF >>>> endings. The subversion client should convert it to LF before sending. >>>> How the diff happens to cover every line? >>>> >>>> What were you doing? >>> >>> Using git. >>> >> >> How? Some git push (or haw it is called there?) that writes directly >> to the repository? > > git svn dcommit > > See: > http://wiki.apache.org/general/GitAtApache > > I had been through the process once to reset the line endings in my > local repo and I though that would be enough. I think I know how to spot > this before it happens now so that should be the last of them. How to > fix it when I spot it is a separate issue. > Huh. I think the client (git) is broken if it does this. Another fault is that Subversion server allows it. You are on Windows, right? I reported the issue to users@subversion, http://subversion.markmail.org/thread/uovs5c7mgcnyp4an Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing zips to the maven repo
2011/10/14 Henri Gomez : >> >> This is the first time that I can recall that anyone has stated that >> there is a requirement for this. >> > > I should say many companies, including mine are injecting full Tomcat (as > zip) in their enterprise repositories (Archiva/Nexus/Artifactory powered) Are all those related to Maven? Do they publish only zips, or the full set of tgz and zips (~80Mb) ? Keeping an in-house copy of 3rd party library is a different story, and it is needed regardless of whether somebody uses Maven Central to publish their work. I personally am using Apache Ivy [1] to manage my repository of dependencies, and AFAIK it can download not only from maven, but from any other structured repository as well. [1] http://ant.apache.org/ivy/ > > BTW, did there is a strong -1 to have an alternative build system using > Maven if this build keep the current Tomcat structure ? > There are not may people here to support it here if it breaks, and on RTC branches that would require 3+ committers that understand what happens. There was some discussion here on dev@ about 2 years ago, and some person proposed to create a maven build, but he disappeared never showing anything working. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Git and tomcat 7.x
2011/10/15 Rainer Jung : > On 14.10.2011 20:19, Francis Galiegue wrote: >> On Fri, Oct 14, 2011 at 20:08, Mark Thomas wrote: >>> On 14/10/2011 19:00, Francis Galiegue wrote: >>>> [...] The trouble is >>>> that I don't feel like git svn cloning directly given that my >>>> bandwidth is very poor and the Apache SVN repo has a number of commits >>>> in the 7 digit range (even if the first of these 7 is "just" a 1)... >>> >>> No. All patches will be applied to trunk (a.k.a. 8.0.x) first and then >>> back-ported. trunk and 7.0.x are very close. It should be a simple svn >>> merge. >>> >>> Don't ever git clone directly to the ASF svn servers. You are very >>> likely to be banned from connecting due to the high volume of requests >>> that would be generated. >>> >> >> Not that I'd have tried anyway, but thanks for the information ;) >> >> I'll keep going with my current clone, then. Thanks! > > It seems that > > git://git.apache.org/tomcat.git > > and > > git://git.apache.org/tomcat70.git > > now correctly point to the 7.0 resp. trunk Tomcat branches. > > At least that's what I derive from > > http://git.apache.org/tomcat.git/config > > and > > http://git.apache.org/tomcat70.git/config > Good to know (the browser has cached those files, so I had to Ctrl+F5). But somehow Github display of it is now empty and says "This repository's default branch is empty!" https://github.com/apache/tomcat70 So I cannot yet confirm that Infra ticket is solved https://issues.apache.org/jira/browse/INFRA-4027 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/14 Mark Thomas : > On 14/10/2011 15:00, Konstantin Kolinko wrote: >> 2011/10/14 Mark Thomas : > >>>> How? Some git push (or haw it is called there?) that writes directly >>>> to the repository? >>> >>> git svn dcommit >>> >>> See: >>> http://wiki.apache.org/general/GitAtApache >>> >>> I had been through the process once to reset the line endings in my >>> local repo and I though that would be enough. I think I know how to spot >>> this before it happens now so that should be the last of them. How to >>> fix it when I spot it is a separate issue. >>> >> >> Huh. >> I think the client (git) is broken if it does this. Another fault is >> that Subversion server allows it. >> >> You are on Windows, right? >> >> I reported the issue to users@subversion, >> http://subversion.markmail.org/thread/uovs5c7mgcnyp4an > > I think this was my fault. > > See http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf > > Short version: > - files in svn might use either CRLF or LF > - eol-style: native just handles this > - git expects LF > - I had enabled core.autocrlf=true which changed everything to LF on commit > > I have set now core.autocrlf=false and that appears to have fixed things > so far... > The file was actually sent to svn repository with CRLF line ends. (More discussion in the users@subversion thread in the link above). I reverted it to LFs in r1183612 by sending a non-changed file from TortoiseSVN. How do you run git? Do you use Cygwin, or maybe TortoiseGit? I think http://wiki.apache.org/general/GitAtApache might need to be updated to reflect the issue, but I am not yet sure what the correct setting is. Your last commits were OK. I hope infra people will install a pre-commit hook to prevent such commits from happening. One hook was already proposed in the thread above. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
2011/10/15 Bill Barker : > 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 has an issue affecting its community integration. > This issue affects 1 projects, > and has been outstanding for 35 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 : Tomcat 8.x, a web server implementing Java Servlet > 3.1, > ... > > > Full details are available at: > > http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html > TestGroupChannelMemberArrival.NIO The BIO run was OK. http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.NIO.txt.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: juli.OneLineFormatter: use US locale
2011/10/17 Rainer Jung : > On 13.10.2011 14:16, Konstantin Kolinko wrote: >> Hi! >> >> I would like to change OneLineFormatter to use US locale for its timestamp. >> >> The timestamp format there is "dd-MMM- HH:mm:ss" and in my case >> the month name is rendered in Cyrillic. >> >> >> The SimpleDateFormat instances are created in >> org.apache.juli.DateFormatCache$Cache, so it has to be changed there. >> >> I think there is no need for it to be configurable the formatter (nor >> I know how to make it configurable), >> so I think that the locale in the Cache can be hardcoded as Locale.US. >> >> Are there any objections? > > Committed as r1185020 resp. r1185021. > > Hope that's what you had in mind. Yes, it is. Thank you! Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Unit tests for Tomcat 6
Hi! It would be nice to backport unit tests from Tomcat 7 to Tomcat 6. Just some thoughts. 1. As far as I remember one of changes that allowed to create the Tomcat class and unit tests for Tomcat 7 was getting rid of org.apache.catalina.ServerFactory class that holds singleton reference to a Server instance. E.g. one of those changes: http://svn.apache.org/viewvc?view=revision&revision=772142 My old thought about that singleton was that it could be circumwented if the test case created its own classloader like Bootstrap does it. Now I think that it can be solved more easily: Add #clear() method to ServerFactory class that would clear the singleton reference and call ServerFactory.clear() either during teardown of a test or at startup. 2. It would be nice to have CTR for the test subdirectory in tc6.0.x. An alternative could be to create a branch in tc6.0.x/branches or in sandbox and vote&merge from there. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1185205 - /tomcat/maven-plugin/trunk/src/site/site.xml
2011/10/17 Olivier Lamy : > Thanks. > I try to publish regulary a web site for the maven plugin (at least > when I add docs) and thanks for fixing typos from a French native > writer :-) > > Web site is here: http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/ . > You are welcome ;) Several questions: 1) About the recently added APT file: Is there a reason why it is called "executable-war-jar.apt.vm", with "*.apt.vm" instead of just "*.apt" like the other files there? 2) Are there any automated builds for the web site (Jenkins?)? If there are any interesting resources from those Jenkins builds they can be added to the following page: http://tomcat.apache.org/ci.html Best regards, Konstantin Kolinko > 2011/10/17 : >> Author: kkolinko >> Date: Mon Oct 17 14:29:39 2011 >> New Revision: 1185205 >> >> URL: http://svn.apache.org/viewvc?rev=1185205&view=rev >> Log: >> "Tomcat" as a single word is also a trademark >> >> Modified: >> tomcat/maven-plugin/trunk/src/site/site.xml >> >> Modified: tomcat/maven-plugin/trunk/src/site/site.xml >> URL: >> http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/src/site/site.xml?rev=1185205&r1=1185204&r2=1185205&view=diff >> == >> --- tomcat/maven-plugin/trunk/src/site/site.xml (original) >> +++ tomcat/maven-plugin/trunk/src/site/site.xml Mon Oct 17 14:29:39 2011 >> @@ -67,7 +67,7 @@ >> >> >> >> - Apache Tomcat, Apache, the Apache feather logo, and the Apache Tomcat >> project logo are trademarks of The Apache Software Foundation. >> + Apache Tomcat, Tomcat, Apache, the Apache feather logo, and the >> Apache Tomcat project logo are trademarks of The Apache Software Foundation. >> All other marks mentioned may be trademarks or registered trademarks >> of their respective owners. >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > > > -- > Olivier Lamy > Talend : http://talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > 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: svn commit: r1186485 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/http11/AbstractHttp11Processor.java webapps/docs/changelog.xml
2011/10/20 :
> Author: markt
> Date: Wed Oct 19 20:55:39 2011
> New Revision: 1186485
>
> URL: http://svn.apache.org/viewvc?rev=1186485&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52055
> Buffers not correctly reset between keep-alive requests when using async
>
> Modified:
> tomcat/tc7.0.x/trunk/ (props changed)
>
> tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
>
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> Wed Oct 19 20:55:39 2011
> @@ -1538,6 +1538,8 @@ public abstract class AbstractHttp11Proc
> if (!keepAlive) {
> return SocketState.CLOSED;
> } else {
> + getInputBuffer().nextRequest();
> + getOutputBuffer().nextRequest();
> return SocketState.OPEN;
> }
> }
>
Searching for places that use org.apache.coyote.Constants.STAGE_ENDED ...
1) it looks like AbstractAjpProcessor#asyncDispatch(SocketStatus)
needs similar patch:
it has "return SocketState.OPEN;"
If I understand correctly in Ajp that will be recycle(false)
2) In Http11NioProcessor#event() I do not see nextRequest() calls, but
similar implementation in Http11AprProcessor#event() has nextRequest()
calls.
Best regards,
Konstantin Kolinko
> --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Oct 19 20:55:39 2011
> @@ -110,6 +110,11 @@
> authentication from being lost during the authentication process.
> (markt)
>
> +
> + 52055: Ensure that the input and output buffers are
> correctly
> + reset between keep-alive requests when using Servlet 3.0 asynchronous
> + request processing. (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
Re: svn commit: r1186898 - /tomcat/tc7.0.x/trunk/
2011/10/20 : > Author: markt > Date: Thu Oct 20 16:32:12 2011 > New Revision: 1186898 > > URL: http://svn.apache.org/viewvc?rev=1186898&view=rev > Log: > Clean-up. No functional change. Empty commit. You merged r1186891 (Oliver's commit on maven-tomcat), but cleanup was in r1186890 Hint: cd tc7.0.x\trunk\ svn diff -c 1186898 > > Modified: > tomcat/tc7.0.x/trunk/ (props changed) > > Propchange: tomcat/tc7.0.x/trunk/ > -- > --- svn:mergeinfo (original) > +++ svn:mergeinfo Thu Oct 20 16:32:12 2011 > @@ -1 +1 @@ > -/(...)б1186479-1186480,1186712,1186743,1186750,1186763 > +/(...),1186479-1186480,1186712,1186743,1186750,1186763,1186891 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1187232 - /tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
2011/10/21 :
> Author: olamy
> Date: Fri Oct 21 09:15:37 2011
> New Revision: 1187232
>
> URL: http://svn.apache.org/viewvc?rev=1187232&view=rev
> Log:
> prefer Set to prevent duplicate entries
>
> Modified:
>
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
>
> Modified:
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> URL:
> http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java?rev=1187232&r1=1187231&r2=1187232&view=diff
> ==
> ---
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> (original)
> +++
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> Fri Oct 21 09:15:37 2011
> @@ -38,7 +38,9 @@ import java.io.FilenameFilter;
> import java.io.IOException;
> import java.util.ArrayList;
> import java.util.Collection;
> +import java.util.HashSet;
> import java.util.List;
> +import java.util.Set;
>
> /**
> * @author Olivier Lamy
> @@ -56,7 +58,8 @@ public class DefaultClassLoaderEntriesCa
> public List calculateClassPathEntries(
> ClassLoaderEntriesCalculatorRequest request )
> throws TomcatRunException
> {
> - List classLoaderEntries = new ArrayList();
> + Set classLoaderEntries = new HashSet();
> + //List classLoaderEntries = new ArrayList( );
Maybe java.util.LinkedHashSet like Tomcat does in
org.apache.catalina.startup.ClassLoaderFactory ?
So that it will preserve order.
(Though I do not know whether it is important for your use case or not).
> // add classes directories to loader
>
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1187232 - /tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
2011/10/21 Olivier Lamy : > During dev on tomcat7 integration, I have just noticed that using the > embeded Tomcat class and adding a webapp as it: > tomcat.addWebapp( contextPath, path to a war file ); > If the war file contains a context file ( META-INF/context.xml ) it's > not use automatically when adding the context/webapp. > So I have to manually add it with: setConfigFile ( new URL( > "jar:file:" + warPath + "!/META-INF/context.xml" ) ) (if exists in the > war). > > Do you consider that as an issue ? > Do you run unpacked war? What if there is .xml in conf/Catalina/localhost? Currently it would take priority over the one inside the war file. Should it be ignored in your use case? (HostConfig#deployWAR(...)). I think that we use Tomcat class mostly for testing, but there is no test that covers this use case, so no wonder that there is no such code there. I think you can file an enhancement request. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1187387 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/loader/WebappClassLoader.java java/org/apache/catalina/startup/Catalina.java webapps/docs/changelog.xml
2011/10/21 : > Author: markt > Date: Fri Oct 21 15:07:51 2011 > New Revision: 1187387 > > URL: http://svn.apache.org/viewvc?rev=1187387&view=rev > Log: > Ensure the the memory leak protection for the HttpClient keep-alive always > operates even if the thread has already stopped. > > Modified: > tomcat/tc7.0.x/trunk/ (props changed) > tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java > tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/Catalina.java > tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml 1. +1 to backport WebappClassLoader fix. 2. This committed two revisions: Merged /tomcat/trunk:r1187028,1187381 Where r1187028 was Catalina.java "Remove Java 1.2 error handling" I am OK with that, but maybe you want to update the commit message or changelog. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Remove svn keywords (was: svn commit: r1187018 [1/2] - in /tomcat/trunk)
2011/10/20 : > Author: markt > Date: Thu Oct 20 19:52:47 2011 > New Revision: 1187018 > > URL: http://svn.apache.org/viewvc?rev=1187018&view=rev > Log: > Clean-up. No functional change. > > Modified: > tomcat/trunk/TOMCAT-NEXT.txt (...) > --- tomcat/trunk/TOMCAT-NEXT.txt (original) > +++ tomcat/trunk/TOMCAT-NEXT.txt Thu Oct 20 19:52:47 2011 > @@ -42,4 +42,8 @@ but possibly 7.1.x). > > 8. Review the connector shutdown code for timing and threading issues > particularly any that may result in a client socket being left open after a > - connector.stop(). > \ No newline at end of file > + connector.stop(). > + > +9. Remove all the static info attributes and associated getters. > + > +10. Remove the svn keywords from all the files. OK for *.java, but let's keep them in *.txt Or they cause problems with your usage of Git? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Removing getInfo() methods - JMX needs update as well
Mark, note, that searching for "info" in *.xml files gives 14 hits in 4 mbeans-descriptor.xml files. Those have to be removed. mbeans-descriptors.xml - tomcat-8.0.x/java/org/apache/catalina/ha/session (3 matches) mbeans-descriptors.xml - tomcat-8.0.x/java/org/apache/catalina/ha/tcp (2 matches) mbeans-descriptors.xml - tomcat-8.0.x/java/org/apache/catalina/tribes/membership mbeans-descriptors.xml - tomcat-8.0.x/java/org/apache/catalina/valves (8 matches) That is the only user-visible usage of those getInfo() methods that I know about. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Removing whitespace from *.xsd and *.dtd files
Hi! http://svn.apache.org/viewvc?rev=1187778&view=rev affected a number of *.xsd and *.dtd files. I think we should not touch those without a good reason. tomcat/trunk/java/javax/servlet/jsp/resources/jsp_2_1.xsd tomcat/trunk/java/javax/servlet/jsp/resources/jsp_2_2.xsd tomcat/trunk/java/javax/servlet/jsp/resources/jspxml.dtd tomcat/trunk/java/javax/servlet/jsp/resources/jspxml.xsd tomcat/trunk/java/javax/servlet/jsp/resources/web-jsptaglibrary_2_1.xsd tomcat/trunk/java/javax/servlet/resources/XMLSchema.dtd tomcat/trunk/java/javax/servlet/resources/datatypes.dtd tomcat/trunk/java/javax/servlet/resources/javaee_6.xsd tomcat/trunk/java/javax/servlet/resources/javaee_web_services_1_3.xsd tomcat/trunk/java/javax/servlet/resources/javaee_web_services_client_1_3.xsd tomcat/trunk/java/javax/servlet/resources/web-app_2_2.dtd tomcat/trunk/java/javax/servlet/resources/web-app_2_5.xsd tomcat/trunk/java/javax/servlet/resources/web-app_3_0.xsd tomcat/trunk/java/javax/servlet/resources/web-common_3_0.xsd tomcat/trunk/java/javax/servlet/resources/web-fragment_3_0.xsd tomcat/trunk/java/javax/servlet/resources/xml.xsd Other interesting note is that this commit removed some trailing whitespace from values in *.properties files. Generally, this change might be visible to users, as trailing whitespace is preserved when reading properties. Though those that I noticed thus far look more like an editor's error - backported to tc7 in r1187816. More is likely to follow. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Removing whitespace from *.xsd and *.dtd files
2011/10/23 Mark Thomas : > On 22/10/2011 22:54, Konstantin Kolinko wrote: >> Hi! >> >> http://svn.apache.org/viewvc?rev=1187778&view=rev >> affected a number of *.xsd and *.dtd files. >> >> I think we should not touch those without a good reason. >> >> tomcat/trunk/java/javax/servlet/jsp/resources/jsp_2_1.xsd >> tomcat/trunk/java/javax/servlet/jsp/resources/jsp_2_2.xsd >> tomcat/trunk/java/javax/servlet/jsp/resources/jspxml.dtd >> tomcat/trunk/java/javax/servlet/jsp/resources/jspxml.xsd >> tomcat/trunk/java/javax/servlet/jsp/resources/web-jsptaglibrary_2_1.xsd >> >> tomcat/trunk/java/javax/servlet/resources/XMLSchema.dtd >> tomcat/trunk/java/javax/servlet/resources/datatypes.dtd >> tomcat/trunk/java/javax/servlet/resources/javaee_6.xsd >> tomcat/trunk/java/javax/servlet/resources/javaee_web_services_1_3.xsd >> >> tomcat/trunk/java/javax/servlet/resources/javaee_web_services_client_1_3.xsd >> tomcat/trunk/java/javax/servlet/resources/web-app_2_2.dtd >> tomcat/trunk/java/javax/servlet/resources/web-app_2_5.xsd >> tomcat/trunk/java/javax/servlet/resources/web-app_3_0.xsd >> tomcat/trunk/java/javax/servlet/resources/web-common_3_0.xsd >> tomcat/trunk/java/javax/servlet/resources/web-fragment_3_0.xsd >> tomcat/trunk/java/javax/servlet/resources/xml.xsd > > I don't see the harm in removing the trailing white-space from these > files. It shouldn't change their meaning. >From technical point of view it should not. But all of them originate from somewhere, and I would not want them to differ from their originals more than necessary. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Removing whitespace from *.xsd and *.dtd files
2011/10/23 Mark Thomas : > On 22/10/2011 23:33, Konstantin Kolinko wrote: >> 2011/10/23 Mark Thomas : >>> On 22/10/2011 22:54, Konstantin Kolinko wrote: >>>> Hi! >>>> >>>> http://svn.apache.org/viewvc?rev=1187778&view=rev >>>> affected a number of *.xsd and *.dtd files. >>>> >>>> I think we should not touch those without a good reason. > > > >>> I don't see the harm in removing the trailing white-space from these >>> files. It shouldn't change their meaning. >> >> From technical point of view it should not. But all of them originate >> from somewhere, and I would not want them to differ from their >> originals more than necessary. > > That is a fair point. > > My own preference is for not having to list them as exclusions in the > checkstyle config. Thinking about it, I'm not sure how easy that would > be. It is easy enough to filter by file extension but that doesn't quite > work in this case. I'd rather not have a separate checkstyle file just > for trailing white-space but I don't see another way to exclude the spec > files. > > Given that diff tools can be easily configured to ignore white-space I'm > leaning towards leaving things as they currently are. I am -1 on applying trailing whitespaces check on *.java files. It has no practical value. It does not improve readability. I do not see what it can be useful for. It is just useless nagging. There are file types where check for trailing whitespace is useful, e.g. *.properties files, (because whitespaces are not trimmed from the values that are read from the file and might be visible). But for *.java files I do not see any benefits. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Removing whitespace from *.xsd and *.dtd files
2011/10/24 Mark Thomas : > On 23/10/2011 10:39, Konstantin Kolinko wrote: > >> I am -1 on applying trailing whitespaces check on *.java files. >> >> It has no practical value. It does not improve readability. I do not >> see what it can be useful for. It is just useless nagging. > > Trailing white-space is pointless and it bugs me. Maybe that is just me, > but I'd like to get rid of it. > > My original plan was to just configure my IDE to remove trailing > white-space when I saved a file but that led to the occasional noisy > commit where the white-space changes hid the real change if I forgot to > do a white-space only commit first. That was starting to get tricky > keeping track of which files I had 'fixed' and which ones I hadn't. > > Given the above, removing all of the trailing white-space in one go > (well, several goes as a single commit was just way too big) seemed like > the sensible way forward. > > In terms of benefit, it shaved ~1% of the compressed source. Nothing to > write home about I agree but 1% pointless fat removed it still 1% > pointless fat removed. > > Having gone to the trouble to remove all the trailing white-space, I'd > like to keep it that way and enabling the check-style check is the > simplest way to do that. It does mean folks working on trunk need to > configure their IDEs to remove trailing white-space on save for that > project but that doesn't seem like such a big deal. > >> There are file types where check for trailing whitespace is useful, >> e.g. *.properties files, (because whitespaces are not trimmed from the >> values that are read from the file and might be visible). > > +1 > >> But for *.java files I do not see any benefits. > > In absolute terms, the benefit is minimal (~1% smaller source files) but > the bigger benefit for me is that it doesn't bug me any more. 1. I hate text editors that change lines that I did not touch. 2. Do you have separate options for trunk and for 3 other branches? I do not mind if your commit changes whitespace. It does not impede review. It is your itch, your editor, whatever. There is no technical merit to discuss when such commit happens. I do not like this to be enforced on people. BTW, reviewing properties changes, note the *.properties files in http://svn.apache.org/viewvc?limit_changes=0&view=revision&revision=1187803 See "jsp.error.usebean.missing.type", "jsp.error.usebean.prohibited.as.session", "jsp.error.usebean.not.both", "jsp.error.page.nomapping.language". They all ended with ":" + space. From quick search though it looks that most of them, if not all, are unused. > > On a related topic, unused code is next up on my list of things to clean > up. My plan is 1 commit to trunk to mark it deprecated. Back-port that > commit to 7.0.x and then remove it from trunk. I'll probably do this > package by package but I'll see how it goes. > All on the next week, or you'll wait after next 6.0.x and 7.0.x? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Old code used stristr.
New code uses strncmp.
If I understand correctly, the old one is case-insensitive, while the
new one is case-sensitive.
Best regards,
Konstantin Kolinko
2011/10/23 :
> Author: rjung
> Date: Sun Oct 23 16:19:59 2011
> New Revision: 1187916
>
> URL: http://svn.apache.org/viewvc?rev=1187916&view=rev
> Log:
> BZ 51769: IIS: Allow URIs which contain "META-INF" or
> "WEB-INF" as long as they are not path components of the URI.
>
> I kept the old stristr function, because it
> could be useful for something else.
>
> Modified:
> tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
> tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
>
> Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=1187916&r1=1187915&r2=1187916&view=diff
> ==
> --- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
> +++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Sun Oct 23 16:19:59 2011
> @@ -842,12 +842,30 @@ static char *stristr(const char *s, cons
> return ((char *)s);
> }
>
> +/*
> + * Find the first occurrence of path in uri tokenized by "/".
> + * The comparison is done case insensitive.
> + */
> +static const char *find_path_in_uri(const char *uri, const char *path)
> +{
> + size_t len = strlen(path);
> + while (uri = strchr(uri, '/')) {
> + uri++;
> + if (!strncmp(uri, path, len) &&
> + (*(uri + len) == '/' ||
> + strlen(uri) == len)) {
> + return uri;
> + }
> + }
> + return NULL;
> +}
> +
> static int uri_is_web_inf(const char *uri)
> {
> - if (stristr(uri, "/web-inf")) {
> + if (find_path_in_uri(uri, "web-inf")) {
> return JK_TRUE;
> }
> - if (stristr(uri, "/meta-inf")) {
> + if (find_path_in_uri(uri, "meta-inf")) {
> return JK_TRUE;
> }
>
>
> Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1187916&r1=1187915&r2=1187916&view=diff
> ==
> --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
> +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Sun Oct 23 16:19:59 2011
> @@ -45,6 +45,10 @@
>
>
>
> + 51769: IIS: Allow URIs which contain "META-INF" or
> + "WEB-INF" as long as they are not path components of the URI. (rjung)
> +
> +
> 52056: HTTPD: JK request log does not always log
> correct response status. Fixed by refactoring JK request
> log to use the standard request log hook. (rjung)
>
>
>
> -
> 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: svn commit: r1188313 [1/5] - in /tomcat/trunk/java: javax/el/ org/apache/catalina/authenticator/ org/apache/catalina/connector/ org/apache/catalina/core/ org/apache/catalina/deploy/ org/apache/cat
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties?r1=1188313&r2=1188312&pathrev=1188313 The new value of webXml.mergeConflictOrder is wrong, it is concatenation of two values. It is the only glitch that I noted. Is your tool able to find properties that are not mentioned in *.properties files? Best regards, Konstantin Kolinko 2011/10/24 : > Author: markt > Date: Mon Oct 24 19:18:39 2011 > New Revision: 1188313 > > URL: http://svn.apache.org/viewvc?rev=1188313&view=rev > Log: > Remove unused properties > > Removed: > > tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings.properties > > tomcat/trunk/java/org/apache/catalina/tribes/membership/LocalStrings_es.properties > Modified: > tomcat/trunk/java/javax/el/LocalStrings.properties > tomcat/trunk/java/javax/el/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/authenticator/LocalStrings.properties > > tomcat/trunk/java/org/apache/catalina/authenticator/LocalStrings_es.properties > > tomcat/trunk/java/org/apache/catalina/authenticator/LocalStrings_fr.properties > > tomcat/trunk/java/org/apache/catalina/authenticator/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/connector/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/core/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/core/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/core/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/ha/session/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/ha/session/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/ha/tcp/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/ha/tcp/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/loader/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/loader/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/loader/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/manager/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/manager/LocalStrings_de.properties > tomcat/trunk/java/org/apache/catalina/manager/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/manager/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/manager/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/realm/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/realm/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/realm/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/realm/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/servlets/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/servlets/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/servlets/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/servlets/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/session/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/session/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/session/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/startup/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/startup/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/startup/LocalStrings_ja.properties > > tomcat/trunk/java/org/apache/catalina/tribes/transport/LocalStrings.properties > > tomcat/trunk/java/org/apache/catalina/tribes/transport/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/users/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/users/LocalStrings_es.properties > tomcat/trunk/java/org/apache/catalina/users/LocalStrings_fr.properties > tomcat/trunk/java/org/apache/catalina/users/LocalStrings_ja.properties > tomcat/trunk/java/org/apache/catalina/util/LocalStrings.properties > tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties >
Re: svn commit: r1187916 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
2011/10/25 Christopher Schultz :
> All,
>
> On 10/25/2011 2:03 PM, Christopher Schultz wrote:
>> On 10/23/2011 12:19 PM, rj...@apache.org wrote:
>>>
>>> + if (!strncmp(uri, path, len) &&
>>
>> strncmp doesn't use case-insensitive compare: will this ever match if
>> you use "web-inf" (as below)?
>
> Duh just saw Konstantin's response. Apologies for the noise.
>
> I still think the // might be a problem, though.
> +while (uri = strchr(uri, '/')) {
If uri starts with '/' then strchr will return uri without advancing
the pointer. I see no problem with //.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1188930 - /tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore
Can you add descriptive comment in the file itself and ASL license? 2011/10/26 : > Author: markt > Date: Tue Oct 25 21:34:21 2011 > New Revision: 1188930 > > URL: http://svn.apache.org/viewvc?rev=1188930&view=rev > Log: > Git ignores empty directories and the unit tests require this directory to be > present for the welcome file tests to pass. The presence of this file doesn't > break the unit tests. > > Added: > tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore > > Added: tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore > URL: > http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore?rev=1188930&view=auto > == > --- tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore (added) > +++ tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore Tue Oct 25 > 21:34:21 2011 > @@ -0,0 +1,4 @@ > +# Ignore everything in this directory > +* > +# Except this file > +!.gitignore > \ No newline at end of file > > > > - > 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: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/15 Mark Thomas : > On 15/10/2011 11:02, Konstantin Kolinko wrote: >> How do you run git? Do you use Cygwin, or maybe TortoiseGit? > > http://code.google.com/p/msysgit/downloads/list > >> I think http://wiki.apache.org/general/GitAtApache might need to be updated >> to reflect the issue, but I am not yet sure what the correct setting is. > > For Tomcat, it appears core.autocrlf=false is the way to go but I'd like > to keep an eye on things for a while. > >> Your last commits were OK. > > Now I've figured out how to spot when things go wrong, I shouldn't mess > things up again. > >> I hope infra people will install a pre-commit hook to prevent such >> commits from happening. One hook was already proposed in the thread >> above. > > As git is used more with svn, that is probably a good idea. > > As an aside, I am finding it really useful. The things I have found I > have been able to do much more easily include: > - work on multiple bugs at once and switch between them > - do code clean-up and re-factoring as I go along but then cherry pick > selected changes (e.g. the cleanup) and commit them separately so the > commit for the actual fix is cleaner > - go back a few steps when I realise I need to change track with a fix > > There is a learning curve and if I hadn't been forced (against my will > at the time) to use git at $work I doubt I would find the things I am > doing now quite as easy. > One more thing to note: 1. Apparently Git does not set svn:eol-style for you 2. I think that before setting svn:eol-style=native you have to explicitly convert the file to LF line ends if you are on Windows. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1188930 - /tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore
Done in trunk and merged into 7.0. Best regards, Konstantin Kolinko 2011/10/26 Konstantin Kolinko : > Can you add descriptive comment in the file itself and ASL license? > > 2011/10/26 : >> Author: markt >> Date: Tue Oct 25 21:34:21 2011 >> New Revision: 1188930 >> >> URL: http://svn.apache.org/viewvc?rev=1188930&view=rev >> Log: >> Git ignores empty directories and the unit tests require this directory to >> be present for the welcome file tests to pass. The presence of this file >> doesn't break the unit tests. >> >> Added: >> tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore >> >> Added: tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore?rev=1188930&view=auto >> == >> --- tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore (added) >> +++ tomcat/trunk/test/webapp-3.0/welcome-files/sub/.gitignore Tue Oct 25 >> 21:34:21 2011 >> @@ -0,0 +1,4 @@ >> +# Ignore everything in this directory >> +* >> +# Except this file >> +!.gitignore >> \ No newline at end of file >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1187826 - in /tomcat/trunk: java/org/apache/tomcat/util/net/ modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/naming/ modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test
2011/10/23 : > Author: markt > Date: Sat Oct 22 23:24:31 2011 > New Revision: 1187826 > > URL: http://svn.apache.org/viewvc?rev=1187826&view=rev > Log: > Fix some low-hanging FindBugs fruit > > Modified: > tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java > > tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/naming/GenericNamingResourcesFactory.java > > tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/TestConcurrency.java > tomcat/trunk/test/org/apache/catalina/comet/TestCometProcessor.java > > tomcat/trunk/test/org/apache/catalina/tribes/group/interceptors/TestNonBlockingCoordinator.java > > Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java > URL: > http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1187826&r1=1187825&r2=1187826&view=diff > == > --- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java (original) > +++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Sat Oct 22 > 23:24:31 2011 > @@ -1565,7 +1565,7 @@ public class NioEndpoint extends Abstrac > if (ka!=null) ka.setComet(false); > socket.getPoller().cancelledKey(key, > SocketStatus.ERROR, false); > } > - if (socket!=null) nioChannels.offer(socket); > + nioChannels.offer(socket); > socket = null; > if ( ka!=null ) keyCache.offer(ka); > ka = null; > @@ -1579,7 +1579,7 @@ public class NioEndpoint extends Abstrac > ka = (KeyAttachment) key.attachment(); > socket.getPoller().cancelledKey(key, > SocketStatus.DISCONNECT, false); > } > - if (socket!=null) nioChannels.offer(socket); > + nioChannels.offer(socket); > socket = null; > if ( ka!=null ) keyCache.offer(ka); > ka = null; The "socket" here is not a local variable, but a field. Is it true that the null check can be removed here? I think it would be safer with null checks. The "synchronized (socket)" that wraps it all is a bit odd with socket=null assignments inside of it, but IIRC that will work. The rest of this commit is OK Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183340 [1/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2011/10/26 Mark Thomas : > On 26/10/2011 11:51, Konstantin Kolinko wrote: >> 2011/10/15 Mark Thomas : >>> On 15/10/2011 11:02, Konstantin Kolinko wrote: >>>> How do you run git? Do you use Cygwin, or maybe TortoiseGit? >>> >>> http://code.google.com/p/msysgit/downloads/list >>> >>>> I think http://wiki.apache.org/general/GitAtApache might need to be updated >>>> to reflect the issue, but I am not yet sure what the correct setting is. >>> >>> For Tomcat, it appears core.autocrlf=false is the way to go but I'd like >>> to keep an eye on things for a while. >>> >>>> Your last commits were OK. >>> >>> Now I've figured out how to spot when things go wrong, I shouldn't mess >>> things up again. >>> >>>> I hope infra people will install a pre-commit hook to prevent such >>>> commits from happening. One hook was already proposed in the thread >>>> above. >>> >>> As git is used more with svn, that is probably a good idea. >>> >>> As an aside, I am finding it really useful. The things I have found I >>> have been able to do much more easily include: >>> - work on multiple bugs at once and switch between them >>> - do code clean-up and re-factoring as I go along but then cherry pick >>> selected changes (e.g. the cleanup) and commit them separately so the >>> commit for the actual fix is cleaner >>> - go back a few steps when I realise I need to change track with a fix >>> >>> There is a learning curve and if I hadn't been forced (against my will >>> at the time) to use git at $work I doubt I would find the things I am >>> doing now quite as easy. >>> >> >> One more thing to note: >> 1. Apparently Git does not set svn:eol-style for you >> 2. I think that before setting svn:eol-style=native you have to >> explicitly convert the file to LF line ends if you are on Windows. > > It should pick up the svn configuration. Since I normally use Tortoise > svn I suspect it isn't picking it up. I'll see if I can figure this out. > Apologies in advance if I create any noise on the mailing list with some > test commits. > That .gitignore file that was added in r1188930 did not have svn:eol-style and had CRLF line ends. That is why I worried. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1189436 - /tomcat/tc6.0.x/trunk/STATUS.txt
2011/10/27 Francis Galiegue : > On Wed, Oct 26, 2011 at 22:40, wrote: >> Author: kkolinko >> Date: Wed Oct 26 20:40:20 2011 >> New Revision: 1189436 >> > [...] > > Ouch. My proposal has just become a lot more complicated :p That is Tomcat 6. For Tomcat 7+ you do not need to implement a Lifecycle explicily, but can just overwrite initInternal(). The revisions covered by the patch are: http://svn.apache.org/viewvc?rev=1187027&view=rev http://svn.apache.org/viewvc?rev=1189256&view=rev Huh - I missed a part of r1187027. I'll update the patch soon. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Patching RequestFilterValve
Hi! I am working on a patch that prevents RequestFilterValve from starting on configuration errors. Current versions: http://people.apache.org/~kkolinko/patches/2011-10-26_tc6_RequestFilterValve_v3.patch http://people.apache.org/~kkolinko/patches/2011-10-26_tc55_RequestFilterValve_v3.patch I am testing on host-manager webapp by adding the following valve: The following are results and caveats: 1. In Tomcat 6 and 5.5 to reproduce the error you have to add the broken Valve both to conf/Catalina/localhost/.xml and to webapp//META-INF/context.xml If the valve is added only to conf/*, the XML file deployment fails, but Tomcat will later try to deploy the application again from webapps folder and this deployment may be successful. Thus was my confusion that the protection appeared to be not working. The exception is printed, but the app works, because it is redeployed afresh, ignoring the modified XML file. In Tomcat 5.5 I was not observing this, because host-manager is not present in webapps, but I can reproduce such successful redeployment with jsp-examples. I think it would be better if broken context file in conf would prevent deployment from webapps as well. 2. Tomcat 6 and 5.5 return error 403 when I try to access the failed webapp. It is good, but I do not understand where it comes from. I would expect 404 as if the app has not been deployed, or 503. 3. In Tomcat 5.5 failed deployment of host-manager results in autodeployment process repeating deployment attempt every 10s and printing the error in the logs. Tomcat 6.0 does not attempt redeployment. Nothing seriously wrong with it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Patching RequestFilterValve
2011/10/27 Rainer Jung : > On 27.10.2011 01:36, Konstantin Kolinko wrote: >> If the valve is added only to conf/*, the XML file deployment fails, >> but Tomcat will later try to deploy the application again from webapps >> folder and this deployment may be successful. >> >> Thus was my confusion that the protection appeared to be not working. >> The exception is printed, but the app works, because it is redeployed >> afresh, ignoring the modified XML file. >> >> In Tomcat 5.5 I was not observing this, because host-manager is not >> present in webapps, but I can reproduce such successful redeployment >> with jsp-examples. >> >> I think it would be better if broken context file in conf would >> prevent deployment from webapps as well. > > +1 For further information: the trunk also shows this behaviour (ignoring failed XML and deploying from expanded dir instead). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in ASF Buildbot on tomcat-trunk
2011/10/28 : > 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/2429 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: bb-vm_ubuntu > > Build Reason: scheduler > Build Source Stamp: [branch tomcat/trunk] 1190185 > Blamelist: markt > > BUILD FAILED: failed compile_1 > Appears to be a NPE failure during Tomcat shutdown, in many tests. [[[ [junit] Running org.apache.catalina.comet.TestCometProcessor [junit] Tests run: 6, Failures: 0, Errors: 6, Time elapsed: 0.28 sec [junit] Oct 28, 2011 7:47:26 AM org.apache.coyote.AbstractProtocol destroy [junit] INFO: Destroying ProtocolHandler ["http-bio-8001"] [junit] Oct 28, 2011 7:47:26 AM org.apache.catalina.core.ContainerBase removeChild [junit] SEVERE: ContainerBase.removeChild: destroy: [junit] org.apache.catalina.LifecycleException: Failed to destroy component [StandardEngine[Tomcat].StandardHost[localhost]] [junit] at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:296) [junit] at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1000) [junit] at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1185) [junit] at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:292) [junit] at org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:572) [junit] at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:292) [junit] at org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:770) [junit] at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:292) [junit] at org.apache.catalina.startup.Tomcat.destroy(Tomcat.java:355) [junit] at org.apache.catalina.startup.TomcatBaseTest.tearDown(TomcatBaseTest.java:211) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:37) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) [junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) [junit] Caused by: java.lang.NullPointerException [junit] at org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1193) [junit] at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:292) [junit] ... 30 more (...) [junit] Test org.apache.catalina.comet.TestCometProcessor FAILED ]]] ... [junit] Test org.apache.catalina.filters.TestCsrfPreventionFilter FAILED [junit] Test org.apache.catalina.filters.TestExpiresFilter FAILED etc. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1189899 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/ java/org/apache/tomcat/util/buf/ java/org/apache/tomcat/util/http/ webapps/docs/ webapps/docs/config/
2011/10/27 :
> Author: markt
> Date: Thu Oct 27 18:02:27 2011
> New Revision: 1189899
>
> URL: http://svn.apache.org/viewvc?rev=1189899&view=rev
> Log:
> Re-factor parameter parsing to improve performance
>
> Added:
>
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/LocalStrings.properties
> (with props)
> Modified:
> tomcat/tc7.0.x/trunk/ (props changed)
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Connector.java
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Request.java
>
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/mbeans-descriptors.xml
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/buf/ByteChunk.java
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/buf/MessageBytes.java
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/buf/StringCache.java
> tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/http/Parameters.java
> tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
> tomcat/tc7.0.x/trunk/webapps/docs/config/ajp.xml
> tomcat/tc7.0.x/trunk/webapps/docs/config/http.xml
>
> @@ -97,15 +101,23 @@ public final class ByteChunk implements
> as most standards seem to converge, but the servlet API requires
> 8859_1, and this object is used mostly for servlets.
> */
> - public static final String DEFAULT_CHARACTER_ENCODING="ISO-8859-1";
> + public static Charset DEFAULT_CHARSET = null;
1. The above public variable must declared as final.
> + static {
> + try {
> + DEFAULT_CHARSET = B2CConverter.getCharset("ISO-8859-1");
> + } catch (UnsupportedEncodingException e) {
> + // Should never happen since all JVMs must support ISO-8859-1
> + }
> + }
IIRC, it might be done using a helper variable in the static{} block.
public static final Charset DEFAULT_CHARSET;
static {
Charset defaultCharset = null;
try {
defaultCharset = B2CConverter.getCharset("ISO-8859-1");
} catch (UnsupportedEncodingException e) {
// Should never happen since all JVMs must support ISO-8859-1
}
DEFAULT_CHARSET = defaultCharset;
}
2) In TestParameters.java
in http://svn.apache.org/viewvc?view=revision&revision=1189876
UEncoder uencoder = new UEncoder();
field can be private final, like the others.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: IDEA settings for Tomcat development?
2011/10/28 Francis Galiegue : > Hello list, > > I understand some of you use IDEA for developing Tomcat. So do I. Can > you share your project settings (I am thinking in particular about > intention settings, code formatting, copyright etc) so that, when I'm > ready to submit a new patch, this "basic" stuff do not raise any > concerns? Take a look at http://tomcat.apache.org/getinvolved.html#Coding_Conventions Most of us use Eclipse IDE. I use "Java conventions" but changed to use spaces instead of tabs. I think there would be something like that in IDEA. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: IDEA settings for Tomcat development?
2011/10/28 Francis Galiegue : > On Fri, Oct 28, 2011 at 19:25, Konstantin Kolinko > wrote: >> 2011/10/28 Francis Galiegue : >>> Hello list, >>> >>> I understand some of you use IDEA for developing Tomcat. So do I. Can >>> you share your project settings (I am thinking in particular about >>> intention settings, code formatting, copyright etc) so that, when I'm >>> ready to submit a new patch, this "basic" stuff do not raise any >>> concerns? >> >> Take a look at >> http://tomcat.apache.org/getinvolved.html#Coding_Conventions >> >> Most of us use Eclipse IDE. I use "Java conventions" but changed to >> use spaces instead of tabs. I think there would be something like that >> in IDEA. >> > > Yep, I have read this already. I was thinking more about intentions: > IDEA has loads of them which pertain to coding practices, I use my own > set which maybe doesn't fit the taste of core developers (for one, I > do a heavy use of the "final" keyword, I sometimes create variables > with a broad scope and so on). > > I'll start creating a custom profile with coding style only. I was > wondering OTOH whether someone was using, for instance, the checkstyle > plugin, what its settings were and so on... > Checkstyle is used at build time. You have to add explicitly add the following line to build.properties to enable it: execute.validate=true Its settings are in res/checkstyle, but I do not know whether you can configure your plugin the same way as the build uses it and whether it is needed. Another notable Eclipse plugin is Findbugs, with exception rules in res/findbugs As for the rest - Tomcat code is 10+ years old, and comes from various contributors. The styles can be different in different places. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Improving problem reporting
apache.catalina.startup.Bootstrap.start(Bootstrap.java:322) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450) > > (And if only java.util.jar.Attributes.read reported WHICH attribute had the > problem, we'd really be in business.) > Not sure about FileResource.toString(), but adding a catch for IOException looks like doable. Please file an enhancement issue in Bugzilla. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1190720 - /tomcat/tc5.5.x/trunk/STATUS.txt
2011/10/29 Mark Thomas : >> + - Maybe "if (paramHashValues.containsKey(key))" can be replaced >> + with testing whether result of (paramHashValues.containsKey(key)) >> is null. > Hashtable does not permit null keys or values. >> + - Maybe "if (paramHashValues.containsKey(key))" can be replaced >> +with testing whether result of (paramHashValues.containsKey(key)) >> is null. >See previous comment re Hashtable. I mean that there are two hashtable lookup operations in a row: a) containsKey(key) b) get(key) if a) returned true It can be replaced by calling b) once and testing whether its result is null. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in ASF Buildbot on tomcat-trunk
2011/10/31 : > 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/2442 > [junit] Running org.apache.tomcat.util.http.mapper.TestMapper [junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 4.682 sec [junit] Test org.apache.tomcat.util.http.mapper.TestMapper FAILED There are no details wrt what test in TestMapper failed and why. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1195434 - in /tomcat/jk/trunk/native/common: jk_pool.c jk_pool.h
2011/10/31 :
> Author: mturk
> Date: Mon Oct 31 12:44:39 2011
> New Revision: 1195434
>
> URL: http://svn.apache.org/viewvc?rev=1195434&view=rev
> Log:
> Fix weird jk_pool_strdup declaration and add jk_pool_strcat function
>
> Modified:
> tomcat/jk/trunk/native/common/jk_pool.c
> tomcat/jk/trunk/native/common/jk_pool.h
>
> +char *jk_pool_strcat(jk_pool_t *p, const char *s, const char *a)
+if (a)
+size += strlen(a);
Then strcat(rc, a); is always called, without checking whether a is NULL.
+rc = jk_pool_alloc(p, size);
+if (rc) {
+if (rc != s)
+strcpy(rc, s);
rc can be equal to s ?
> --- tomcat/jk/trunk/native/common/jk_pool.h (original)
> +++ tomcat/jk/trunk/native/common/jk_pool.h Mon Oct 31 12:44:39 2011
> @@ -118,7 +118,9 @@ void *jk_pool_alloc(jk_pool_t *p, size_t
> void *jk_pool_realloc(jk_pool_t *p,
> size_t sz, const void *old, size_t old_sz);
>
> -void *jk_pool_strdup(jk_pool_t *p, const char *s);
> +char *jk_pool_strdup(jk_pool_t *p, const char *s);
> +
> +char *jk_pool_strdcat(jk_pool_t *p, const char *s, const char *a);
There is a typo in *.h above:
s/strdcat/strcat/
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in ASF Buildbot on tomcat-trunk
2011/10/31 Konstantin Kolinko : > 2011/10/31 : >> 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/2442 >> > > [junit] Running org.apache.tomcat.util.http.mapper.TestMapper > [junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 4.682 sec > [junit] Test org.apache.tomcat.util.http.mapper.TestMapper FAILED > > There are no details wrt what test in TestMapper failed and why. Cannot reproduce. It probably was testPerformance(). Note the "4.682 sec" in the message above. The performance test takes most of the time and it fails if time taken is >= 4 sec. Another TestMapper run in the same log file is Time elapsed: 1.422 sec. Previous build (2441) also shows similar numbers of 1.47, 1.41 sec. On my laptop the TestMapper tests currently take ~3,4 sec to run. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1190720 - /tomcat/tc5.5.x/trunk/STATUS.txt
2011/10/29 Mark Thomas : >> + "private final Hashtable paramHashValues" >> + - Maybe a HashMap can be used instead. I do not expect much >> improvements >> + from that though. > Hashtable makes implementing getParameterNames() a lot simpler. Replaced with HashMap in trunk in r1195531, will apply to TC7 as well. With performance tests the HashMap works faster for me. The difference is from 2% in short test up to 6% with maximum test size. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1195531 - /tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
2011/11/1 Mark Thomas : > On 31/10/2011 15:46, kkoli...@apache.org wrote: >> Author: kkolinko >> Date: Mon Oct 31 15:46:36 2011 >> New Revision: 1195531 >> >> URL: http://svn.apache.org/viewvc?rev=1195531&view=rev >> Log: >> Replace Hashtable with HashMap in parameter processing. >> Improve paramsAsString() debug method by iterating over entries instead of >> keys. >> >> Modified: >> tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java >> >> Modified: tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java?rev=1195531&r1=1195530&r2=1195531&view=diff >> == >> --- tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java (original) >> +++ tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java Mon Oct 31 >> 15:46:36 2011 >> @@ -21,8 +21,10 @@ import java.io.UnsupportedEncodingExcept >> import java.nio.charset.Charset; >> import java.util.ArrayList; >> import java.util.Enumeration; >> -import java.util.Hashtable; >> +import java.util.HashMap; >> +import java.util.Map; >> >> +import org.apache.catalina.util.Enumerator; > > -1 > > That import is not permitted. The o.a.tomcat package may not depend on > o.a.catalina. You should have seen a checkstyle warning for that when > you tried to build it. > Maybe move that Enumerator class into org.apache.tomcat.util.collections ? (Resurrecting the collections package) There are two copies of Enumerator class now: one in catalina and one in jasper. It will need a tweak to build script to pack it into tomcat-util.jar Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1195531 - /tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
2011/11/1 Mark Thomas : >>>> >>>> +import org.apache.catalina.util.Enumerator; >>> >>> -1 >>> >>> That import is not permitted. The o.a.tomcat package may not depend on >>> o.a.catalina. You should have seen a checkstyle warning for that when >>> you tried to build it. >>> >> >> Maybe move that Enumerator class into org.apache.tomcat.util.collections ? >> (Resurrecting the collections package) > > That works for trunk. It would need to be a copy + deprecation for 7.0.x. > >> There are two copies of Enumerator class now: one in catalina and one in >> jasper. > Jasper will need to keep its own copy as it can't have any external > dependencies. Isn't tomcat-util.jar the place for classes that both Catalina and Jasper depend on? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.23
2011/11/1 Mark Thomas : > It is that time again. I plan to tag 7.0.23 later today once I have run > the unit tests and the TCKs to check all is well. > > If you have anything you want to get into this release, now is the time > to commit it. 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965 Applies to AJP as well. Is it possible to throw a runtime exception from parseParameters() when the limit is reached instead of dropping the parameters, or you think the API does not allow it? 2) http://markmail.org/message/5k4urwimvvmeqees Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1196077 - /tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
2011/11/1 :
> Author: mturk
> Date: Tue Nov 1 16:07:10 2011
> New Revision: 1196077
>
> URL: http://svn.apache.org/viewvc?rev=1196077&view=rev
> Log:
> Axe trailing spaces
>
> Modified:
> tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
>
> Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=1196077&r1=1196076&r2=1196077&view=diff
>
> --- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
> +++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Tue Nov 1 16:07:10 2011
> @@ -2817,6 +2816,8 @@ static BOOL initialize_extension(void)
> if (read_registry_init_data()) {
> if (get_iis_info(&iis_info) != JK_TRUE) {
> jk_log(logger, JK_LOG_ERROR, "Could not retrieve IIS version from
> registry");
> + }
> + else {
> if (use_auth_notification_flags)
> iis_info.filter_notify_event = SF_NOTIFY_AUTH_COMPLETE;
> else
You not only axed the whitespace, but also added the above "else" into
initialize_extension(void) method.
So filter_notify_event now defaults to 0 if registry cannot be read.
If that is expected maybe change the following log message in
init_jk(char *serverName)
to print "NONE" for the value of 0 instead of "UNKNOWN".
2669jk_log(logger, JK_LOG_DEBUG, "Using notification event %s (0x%08x)",
2670(iis_info.filter_notify_event == SF_NOTIFY_AUTH_COMPLETE) ?
2671"SF_NOTIFY_AUTH_COMPLETE" :
2672((iis_info.filter_notify_event == SF_NOTIFY_PREPROC_HEADERS) ?
2673"SF_NOTIFY_PREPROC_HEADERS" : "UNKNOWN"),
2674iis_info.filter_notify_event);
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.23
2011/11/1 Mark Thomas : > On 01/11/2011 14:16, Konstantin Kolinko wrote: >> >> 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965 > >> Is it possible to throw a runtime exception from parseParameters() >> when the limit is reached instead of dropping the parameters, or you >> think the API does not allow it? > > I don't think the API allows it. At least it may give users a nasty > surprise. > Well, both surprises (either dropping or throwing) can be nasty. So, what to choose... Reviewing the API I see that getParts()/getPart() is consistent that it rethrows the same exception if parsing failed once. The getParameter()/getParameterValues()/getParameterNames() API does not say about throwing an exception, and it raises a question whether it shall be thrown the first time only or rethrown consistently. Let's go on with dropping. I think there might be an option, e.g. on a Context to rethrow exception, or set a request attribute, if parameters parsing failed. That can be deemed a different feature / itch. It may be extended to cover some other cases, e.g. '&&' invalid chunk error, or parameters dropped during urldecode. 2011/11/2 Mark Thomas : > On 01/11/2011 19:42, Mark Thomas wrote: >> On 01/11/2011 14:16, Konstantin Kolinko wrote: >>> 2) http://markmail.org/message/5k4urwimvvmeqees >> >> I'll see if I can get that fixed too. > > Hmm. The problem here is that the context.xml files are registered as > resources that trigger reload rather than redeploy. As such, any changes > to the context.xml files trigger a reload but do not have any affect > since the Context object is not re-created. > > My current thinking is to add redeployResoucre and reloadResource to > Context and deprecate watchedResource, making it a synonym for > reloadResource. Thoughts? (I haven't tested this yet.) > Are you talking about API or about Configuration? in conf/context.xml defaults to WEB-INF/web.xml. It is a news for me that it covers context.xml as well. I think web.xml triggers reload, context.xml triggers redeploy. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.23
2011/11/2 Konstantin Kolinko : > 2011/11/1 Mark Thomas : >> On 01/11/2011 14:16, Konstantin Kolinko wrote: >>> >>> 1) Re: http://svn.apache.org/viewvc?view=revision&revision=1195965 >> >>> Is it possible to throw a runtime exception from parseParameters() >>> when the limit is reached instead of dropping the parameters, or you >>> think the API does not allow it? >> >> I don't think the API allows it. At least it may give users a nasty >> surprise. >> > > Well, both surprises (either dropping or throwing) can be nasty. So, > what to choose... > > Reviewing the API I see that getParts()/getPart() is consistent that > it rethrows the same exception if parsing failed once. > > The getParameter()/getParameterValues()/getParameterNames() API does > not say about throwing an exception, and it raises a question whether > it shall be thrown the first time only or rethrown consistently. > Let's go on with dropping. > > I think there might be an option, e.g. on a Context to rethrow > exception, or set a request attribute, if parameters parsing failed. > That can be deemed a different feature / itch. It may be extended to > cover some other cases, e.g. '&&' invalid chunk error, or parameters > dropped during urldecode. > > 2011/11/2 Mark Thomas : >> On 01/11/2011 19:42, Mark Thomas wrote: >>> On 01/11/2011 14:16, Konstantin Kolinko wrote: >>>> 2) http://markmail.org/message/5k4urwimvvmeqees >>> >>> I'll see if I can get that fixed too. >> >> Hmm. The problem here is that the context.xml files are registered as >> resources that trigger reload rather than redeploy. As such, any changes >> to the context.xml files trigger a reload but do not have any affect >> since the Context object is not re-created. >> >> My current thinking is to add redeployResoucre and reloadResource to >> Context and deprecate watchedResource, making it a synonym for >> reloadResource. Thoughts? (I haven't tested this yet.) >> > > Are you talking about API or about Configuration? > > in conf/context.xml defaults to WEB-INF/web.xml. It > is a news for me that it covers context.xml as well. > > I think web.xml triggers reload, context.xml triggers redeploy. Touching webapps/myapp.war also triggers a redeploy and not a reload. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.23
2011/11/2 Mark Thomas : > On 01/11/2011 22:01, Konstantin Kolinko wrote: >> 2011/11/2 Konstantin Kolinko : >>> 2011/11/1 Mark Thomas : >>>> My current thinking is to add redeployResoucre and reloadResource to >>>> Context and deprecate watchedResource, making it a synonym for >>>> reloadResource. Thoughts? (I haven't tested this yet.) >>>> >>> >>> Are you talking about API or about Configuration? >>> >>> in conf/context.xml defaults to WEB-INF/web.xml. It >>> is a news for me that it covers context.xml as well. >>> >>> I think web.xml triggers reload, context.xml triggers redeploy. > > That is what I expected too but it isn't what happens. See line ~575 in > ContextConfig. I've checked the history and it has been that way all the > way back to 2004. Oh, I see. Looking at 5.5 // Add as watched resource so that cascade reload occurs if a default // config file is modified/added/removed I think it talks about the "default" context file that is $catalina.base/conf/context.xml. That explains why it says about "cascade". I am OK with that triggering a reload, but as you noted that seems to not work as Context is not recreated. I think webapp's own Context file should be a different beast. > >> Touching webapps/myapp.war also triggers a redeploy and not a reload. > > I'm fine with that. An updated WAR may include a new context.xml file. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 7.0.23
2011/11/2 Mark Thomas :
> On 01/11/2011 22:39, Mark Thomas wrote:
>> Changes to any context.xml have to trigger a redeploy else they won't
>> take effect as no new Context object will be created.
>
> My first stab at a patch for this is at [1]. Comments welcome.
>
> The one thing I don't like is that a change to conf/context.xml that
> breaks the file effectively kills the instance until the problem is
> fixed and the instance re-started.
>
> Mark
>
> http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
>
Quick review - several typos:
mbeans-descriptors.xml:
- typo "findRedployResources"
- "Path to the resource, relative to docBase" - It is "either absolute
or relative to docBase".
docs: s/if is is updated/if it is updated/
At first view I was hesitant wrt to new syntax in conf/context.xml
(s/// but I am starting to like it.
Need to apply and play with it a while.
I do not see though how it is related to another/main topic of
http://markmail.org/message/5k4urwimvvmeqees
that is: if context.xml startup fails somehow the webapp continues
with the deploying the expanded dir.
I observed it during startup time, not during redeployment:
To reproduce, create conf/Catalina/localhost/host-manager.xml:
[[[
]]]
The logs below are from several days ago, before the multithreaded
deployment patch was applied. Note that "host-manager" is being
deployed twice.
(There seems to be NamingContextListener throwing exception from the
second deploy, but the app started successfully).
[[[ (...)
27.10.2011 16:29:04 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1977 ms
27.10.2011 16:29:05 org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
27.10.2011 16:29:05 org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.0.0-dev
27.10.2011 16:29:05 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor
(...)\build\conf\Catalina\localhost\host-manager.xml
27.10.2011 16:29:05 org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Context/Valve} Setting property 'allow'
to '(' did not find a matching property.
27.10.2011 16:29:05 org.apache.catalina.core.ContainerBase addChildInternal
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/host-manager]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:152)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:766)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:638)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:533)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:446)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1303)
(...)
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\host-manager
27.10.2011 16:29:07 org.apache.catalina.core.NamingContextListener
lifecycleEvent
SEVERE: Creation of the naming context failed:
javax.naming.NamingException: Context is read only
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\manager
27.10.2011 16:29:07 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory (...)\build\webapps\ROOT
27.10.2011 16:29:07 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
27.10.2011 16:29:07 org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-8009"]
27.10.2011 16:29:07 org.apache.catalina.startup.Catalina start
INFO: Server startup in 2962 ms
]]]
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Redeploy on context.xml changes (Was: Tagging 7.0.23)
2011/11/2 :
> Konstantin Kolinko wrote:
>
>>2011/11/2 Mark Thomas :
>>> On 01/11/2011 22:39, Mark Thomas wrote:
>
>>> My first stab at a patch for this is at [1]. Comments welcome.
>
>>>http://people.apache.org/~markt/patches/2011-11-01-redeploy-trunk-v1.patch
>
>
>>Quick review - several typos:
>>
>>mbeans-descriptors.xml:
>>- typo "findRedployResources"
>>- "Path to the resource, relative to docBase" - It is "either absolute
>>or relative to docBase".
>>
>>docs: s/if is is updated/if it is updated/
>
> I'll get those fixed for the next iteration.
Also s/redploy/redeploy/ in some Javadoc.
The removeWatchedResource() method in the patch is NOOP instead of
calling renamed method.
The following in StandardContext.java does not look backwards-compatible:
-fireContainerEvent("addWatchedResource", name);
+fireContainerEvent("addReloadResource", name);
and
- fireContainerEvent("removeWatchedResource", name);
+fireContainerEvent("removeReloadResource", name);
Better keep the old name of "watched" and just add the new one of "redeploy".
In all places the "redeploy" list is new and parallel to the old "watched" one.
The only place where meaning changes is
HostConfig#addWatchedResources() that now processes both types.
> The one thing I don't like is that a change to conf/context.xml that
> breaks the file effectively kills the instance until the problem is
> fixed and the instance re-started.
Looking at HostConfig.checkResources(DeployedApplication) note several
ExpandWar.delete() calls. The order is important there. If redeploy
resource #i is missing or updated it deletes all following redeploy
resources starting with #(i+1).
With this behaviour it is better not to let a user to control this
"redeploy" list.
BTW, checkResources(DeployedApplication) deletes reload resources on
auto-undeploy as well, but first checks their path.
Regarding the original task of what happens when context.xml is
touched or edited: redeploying deletes the work dir, along with all
persisted sessions and all compiled JSPs. (ContextConfig.destroy()
triggered by Host.removeChild() does the deletion)
It is an enormous price to pay for editing an AccessLogValve
configuration or whatever is important in context.xml. I'd prefer a
solution that does not delete the work dir.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in ASF Buildbot on tomcat-trunk
2011/11/3 : > 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/2453 Some ~random test failure in TestNonBlockingCoordinator [junit] Running org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator (...) [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 37.608 sec [junit] Test org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator FAILED It was first run (bio) and it failed with some timeouts. The second run (nio) was successful and several times faster: Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.673 sec All other tests did run OK. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[patch] Speed up Tomcat shutdown during test runs
Hi! The patch: http://people.apache.org/~kkolinko/patches/2011-11-03_tc8_fastShutdown.patch It saves 1 second for each Tomcat shutdown during tests, by skipping a sleep in AbstractEndpoint.pause(). I think it is worth doing, but maybe there are other comments? All tests for one connector run about 11,5 minutes for me with this patch. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [patch] Speed up Tomcat shutdown during test runs
2011/11/3 Konstantin Kolinko : > Hi! > > The patch: > http://people.apache.org/~kkolinko/patches/2011-11-03_tc8_fastShutdown.patch > > It saves 1 second for each Tomcat shutdown during tests, > by skipping a sleep in AbstractEndpoint.pause(). > > I think it is worth doing, but maybe there are other comments? > > > All tests for one connector run about 11,5 minutes for me with this patch. > Applied in http://svn.apache.org/viewvc?view=revision&revision=1197158 The buildbot results with testing (bio+nio) before: http://ci.apache.org/builders/tomcat-trunk/builds/2454/steps/compile_1 28 mins, 43 secs after the patch: http://ci.apache.org/builders/tomcat-trunk/builds/2455/steps/compile_1 18 mins, 50 secs That is even better than I anticipated. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1197310 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/valves/RequestFilterValve.java
2011/11/4 :
> Author: markt
> Date: Thu Nov 3 21:10:04 2011
> New Revision: 1197310
>
> URL: http://svn.apache.org/viewvc?rev=1197310&view=rev
> Log:
> Ensure that subsequent attempts to start the Valves will not succeed until
> valid configuration is provided.
>
> Modified:
> tomcat/tc7.0.x/trunk/ (props changed)
>
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java?rev=1197310&r1=1197309&r2=1197310&view=diff
> ==
> ---
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java
> (original)
> +++
> tomcat/tc7.0.x/trunk/java/org/apache/catalina/valves/RequestFilterValve.java
> Thu Nov 3 21:10:04 2011
> @@ -83,6 +83,14 @@ public abstract class RequestFilterValve
> */
> protected volatile Pattern allow = null;
>
> +
> + /**
> + * The current allow configuration value that may or may not compile
> into a
> + * valid {@link Pattern}.
> + */
> + protected volatile String allowValue = null;
> +
> +
> /**
> * Helper variable to catch configuration errors.
> * It is true by default, but becomes false
> @@ -97,6 +105,14 @@ public abstract class RequestFilterValve
> */
> protected volatile Pattern deny = null;
>
> +
> + /**
> + * The current deny configuration value that may or may not compile into
> a
> + * valid {@link Pattern}.
> + */
> + protected volatile String denyValue = null;
> +
> +
> /**
> * Helper variable to catch configuration errors.
> * It is true by default, but becomes false
> @@ -114,12 +130,7 @@ public abstract class RequestFilterValve
> * Valve, if any; otherwise, return null.
> */
> public String getAllow() {
> - // Use local copies for thread safety
> - Pattern allow = this.allow;
> - if (allow == null) {
> - return null;
> - }
> - return allow.toString();
> + return allowValue;
> }
>
>
> @@ -132,10 +143,12 @@ public abstract class RequestFilterValve
> public void setAllow(String allow) {
> if (allow == null || allow.length() == 0) {
> this.allow = null;
> + allowValue = null;
> allowValid = true;
> } else {
> boolean success = false;
> try {
> + allowValue = allow;
> this.allow = Pattern.compile(allow);
> success = true;
> } finally {
> @@ -150,12 +163,7 @@ public abstract class RequestFilterValve
> * Valve, if any; otherwise, return null.
> */
> public String getDeny() {
> - // Use local copies for thread safety
> - Pattern deny = this.deny;
> - if (deny == null) {
> - return null;
> - }
> - return deny.toString();
> + return denyValue;
> }
>
>
> @@ -168,10 +176,12 @@ public abstract class RequestFilterValve
> public void setDeny(String deny) {
> if (deny == null || deny.length() == 0) {
> this.deny = null;
> + denyValue = null;
> denyValid = true;
> } else {
> boolean success = false;
> try {
> + denyValue = deny;
> this.deny = Pattern.compile(deny);
> success = true;
> } finally {
> @@ -225,6 +235,16 @@ public abstract class RequestFilterValve
> }
>
>
> + @Override
> + protected synchronized void startInternal() throws LifecycleException {
> + if (!allowValid || !denyValid) {
> + throw new LifecycleException(
> + sm.getString("requestFilterValve.configInvalid"));
> + }
> + super.startInternal();
> + }
> +
> +
> /**
> * Perform the filtering that has been configured for this Valve, matching
> * against the specified request property.
Good.
The 5.5 and 6.0 patches should have this feature already, because they
do not have separate init method and do it in start() instead.
The only difference is that you assign the string values before
calling Pattern.compile(), while in 5.5/6.0 I do assignment only if
compilation is successful.
I think that this your assignment behaviour is better and I could
update the 5.5/6.0 patches to align with it.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Redeploy on context.xml changes (Was: Tagging 7.0.23)
2011/11/4 Mark Thomas :
> On 03/11/2011 17:08, Mark Thomas wrote:
>> I'm still looking at:
>> - recovery after fixing the broken file
>> - not deploying an expanded dir if the context.xml in
>> conf/Catalina/localhost is broken.
>
> OK. Here is a patch for review. There are so many combinations
> deployment and ways to create a dodgy configuration that I have probably
> missed a couple of edge cases.
>
> The main idea with this patch is that a Context always gets added even
> if deployment fails. That allows fixes via JMX and prevents
> WAR/directory deployment after a failed descriptor deployment. If the
> context.xml can't be read, a new FailedContext object is used. This
> allows redeploy resources to be tracked but the Context cannot be started.
>
> A number of clean-up issues I spotted along the way have already been fixed.
>
> http://people.apache.org/~markt/patches/2011-11-03-redeploy-trunk-v2.patch
>
http://people.apache.org/~kkolinko/patches/2011-11-05_tc8_redeploy-v3.patch
It is just your patch, but
- reverted renames of "watched resource" -> "reload resource". (*)
- formatted FailedContext.java and added javadoc at the top of it
- corrected a typo s/absolue/absolute/
(*) Renaming does not add much, and so it is easier to backport. Let's
do not rename WatchedResource -> ReloadResource.
As of now:
1) addReloadResource() is not implemented in FailedContext. So there
is no way to add dependency on the global conf/context.xml there.
Possible solutions, but need to think about them
a) store reload resources elsewhere outside of Context
b) extract some code from StandardContext into a new class (something
like StandardContextBase?) and share it with FailedContext? I see
that FailedContext does not inherit from ContainerBase, so maybe there
is some trouble with that.
c) Copy some code into FailedContext?
d) Use StandardContext, but overwrite some methods?
2) It is odd that FailedContext has
@SuppressWarnings("unused")
public synchronized void addValve(Valve valve)
3) deployer-howto.xml still mentions "RedeployResource". I'd see where
it goes and fix later.
PS: I had troubles applying your patch with svn and started a thread
on users@subversion referring to it as an example. It does not handle
the way git denotes added files. Not a big deal when there is only one
added file - it us easy to handle that.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Redeploy on context.xml changes (Was: Tagging 7.0.23)
2011/11/6 Mark Thomas : > > I'm in two minds whether to apply this patch before or after the 7.0.23 > tag. There are clearly issues here that need fixing but the patch is > quite invasive. I'm leaning towards tagging after the patch is applied. > Thoughts? > In short: I think there are two issues a) what FailedContext solves b) touching context.xml causing redeploy instead of reload I think a) needs to be solved asap and likely to be backported. b) can be postponed. Regarding b) - remember that order of entries in redeploy list used by autodeploy check is very important (because files ##(n+1)..last are deleted if file #n is touched). I am not yet sure that the patch is safe adding context.xml there. Regarding RequestFilterValve: It sounds like you have tested it with JMX. If it throws LifecycleException from initInternal() are you able to fix it with JMX later? (Maybe "throw new LifecycleException" should be removed from initInternal(), keeping in only in startInternal() ? I do not mind to keep the code as is now, but though maybe there is a reason to remove the first throw). Regarding RequestFilterValve (one more): I thought that there could be a public method callable through JMX to check whether allowed address is allowed or denied. Something like "test(String)" or "isAllowed(String)". Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1198376 - /tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
2011/11/6 :
> Author: olamy
> Date: Sun Nov 6 14:13:09 2011
> New Revision: 1198376
>
> URL: http://svn.apache.org/viewvc?rev=1198376&view=rev
> Log:
> [MTOMCAT-100] support war overlay to add war external dependencies in tomcat
> run
> fix extraction of war overlay content files was extracted in .
>
> Modified:
>
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
>
> ---
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> (original)
> +++
> tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> Sun Nov 6 14:13:09 2011
> @@ -28,6 +28,7 @@ import org.codehaus.plexus.archiver.Arch
> import org.codehaus.plexus.archiver.UnArchiver;
> import org.codehaus.plexus.archiver.manager.ArchiverManager;
> import org.codehaus.plexus.archiver.manager.NoSuchArchiverException;
> +import org.codehaus.plexus.archiver.zip.ZipUnArchiver;
The above import is unused.
Best regards,
Konstantin Kolinko
> import org.codehaus.plexus.component.annotations.Component;
> import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.util.StringUtils;
> @@ -130,6 +131,8 @@ public class DefaultClassLoaderEntriesCa
>
> File tmpDir = new File( tmpExtractDatas,
> artifact.getArtifactId() );
>
> + tmpDir.mkdirs();
> +
> tmpDirectories.add( tmpDir );
>
> try
> @@ -140,6 +143,8 @@ public class DefaultClassLoaderEntriesCa
> unArchiver.setSourceFile( warFile );
> unArchiver.setDestDirectory( tmpDir );
> unArchiver.extract();
> +
> +
> File libsDirectory = new File( tmpDir, "WEB-INF/lib"
> );
> if ( libsDirectory.exists() )
> {
>
>
>
> -
> 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: svn commit: r1198640 - /tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
2011/11/7 :
> Author: kkolinko
> Date: Mon Nov 7 08:25:02 2011
> New Revision: 1198640
>
> URL: http://svn.apache.org/viewvc?rev=1198640&view=rev
> Log:
> Restore handleQueryParameters() call that was lost in r1189882
> This is not covered by our tests.
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
>
> --- tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java Mon Nov 7
> 08:25:02 2011
> @@ -116,8 +116,8 @@ public final class Parameters {
> return Collections.enumeration(paramHashValues.keySet());
> }
>
> - // Shortcut.
> public String getParameter(String name ) {
> + handleQueryParameters();
> ArrayList values = paramHashValues.get(name);
> if (values != null) {
> if(values.size() == 0) {
>
Old implementation called getParameterValues() which called
handleQueryParameters().
What is odd is that there is above all this there is the following comment:
// Data access
// Access to the current name/values, no side effect ( processing ).
// You must explicitly call handleQueryParameters and the post methods.
Whatever needs handleQueryParameters() call there is not covered by
our testsuite.
I've already ported this commit to 7.0 - r1198641.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Unsubscribe From Mailing List
2011/11/7 joshua.morris1 : > How do I unsubscribe > > http://www.apache.org/foundation/mailinglists.html Send a short plain text e-mail to the unsubscription address mentioned here: http://tomcat.apache.org/lists.html You will receive a confirmation e-mail. You should reply to it to confirm unsubscription. If nothing helps, send mail to "list owner" address so that he would unsubscribe you manually. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
FailedRequestFilter
Hi! In trunk I committed a new feature: request attribute that is set if there were problems during parameter parsing and FailedRequestFilter - filter that rejects requests if that request attribute is set. I would like this to be ported to TC7 and earlier versions up to 5.5, but will wait a while for review and feedback. To test it I recommend to add the following to the default conf/web.xml: [[[ failedRequestFilter org.apache.catalina.filters.FailedRequestFilter true failedRequestFilter /* ]]] Revisions in trunk implementing this feature: http://svn.apache.org/viewvc?rev=1198696&view=rev http://svn.apache.org/viewvc?rev=1198707&view=rev Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Redeploy on context.xml changes (Was: Tagging 7.0.23)
2011/11/6 Konstantin Kolinko : > 2011/11/6 Mark Thomas : >> >> I'm in two minds whether to apply this patch before or after the 7.0.23 >> tag. There are clearly issues here that need fixing but the patch is >> quite invasive. I'm leaning towards tagging after the patch is applied. >> Thoughts? >> > > In short: I think there are two issues > a) what FailedContext solves > b) touching context.xml causing redeploy instead of reload > > I think a) needs to be solved asap and likely to be backported. I mean, handling deployment failures. Being stumbled here I agree that looks like it is better to cut 7.0.x as is and take several days after that to though of a better solution. > b) can be postponed. > > Regarding b) - remember that order of entries in redeploy list used by > autodeploy check is very important (because files ##(n+1)..last are > deleted if file #n is touched). I am not yet sure that the patch is > safe adding context.xml there. There is StandardContext#setDefaultContextXml() method. Maybe implement something like that in FailedContext. In those places where you are replacing addWatchedResource() with addRedeployResource() - maybe do not do such replacement. Instead of that in HostConfig#addWatchedResources() or elsewhere use the value of StandardContext#getDefaultContextXml() and add that file to redeploy resources explicitly. Thusly we will have more precise control on their order. Maybe in HostConfig$DeployedApplication.redeployResources do store explicit flag whether the resource is supposed to be deleted on undeploy. (Instead of checking file paths before deleting the resource in HostConfig#checkResources()). Maybe I am just afraid of those path checks in #checkResources() and adding a comment there can resolve it. > > Regarding RequestFilterValve: Question is solved. Updated the valve implementation earlier today and merged to TC7. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: FailedRequestFilter
2011/11/7 Konstantin Kolinko : > Hi! > > In trunk I committed a new feature: request attribute that is set if > there were problems during parameter parsing and FailedRequestFilter - > filter that rejects requests if that request attribute is set. > > I would like this to be ported to TC7 and earlier versions up to 5.5, > but will wait a while for review and feedback. > > To test it I recommend to add the following to the default conf/web.xml: > > [[[ > > failedRequestFilter > > org.apache.catalina.filters.FailedRequestFilter > > true > > > failedRequestFilter > /* > > ]]] > > Revisions in trunk implementing this feature: > http://svn.apache.org/viewvc?rev=1198696&view=rev > http://svn.apache.org/viewvc?rev=1198707&view=rev > Current results with the above fragment added to the default conf/web.xml: - Examples app OK - Testsuite passes BIOxNIOxAPR, though I am not sure whether the tests use conf/web.xml or not. - WAR upload in manager webapp: file uploads successfully and the app is deployed, but there are errors during deployment and undeployment. I think this FailedRequestFilter is OK for further backport. Remaining tasks are documenting it: in config/filters.xml. Maybe add mention of it to maxParameterCount attribute in config/http.xml and config/ajp.xml and to maxParameterCount feature description in changelog. I am not yet sure whether to add a commented-out example of it in the default web.xml, but it seems useful. Regarding the manager webapp I think the error is not related to this feature. I will start separate thread with more details. The manager webapp in trunk as of now is broken. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Problem deploying WAR with manager app in trunk
:662) ]]] The application though deploys and starts successfully, as displayed by the manager webapp. I can access it and execute all the examples there. 2. In the manager webapp click "Undeploy". Result: - All web application files from /webapps are deleted (both examples3.war and examples3 subdirectory). - In work/Catalina/localhost/ there is empty subdirectory "examples3" - In catalina<...>.log: [[[ 07-Nov-2011 16:52:14.734 INFO [pool-2-thread-2] org.apache.catalina.util.LifecycleBase.stop The stop() method was called on component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/examples3]] after stop() had already been called. The second call will be ignored. ]]] - In manager webapp the "examples3" webapp is still present! It is not running and cannot be undeployed. I have not tested how TC7 behaves yet. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1198696 - in /tomcat/trunk/java/org/apache: catalina/Globals.java catalina/connector/Request.java catalina/filters/FailedRequestFilter.java tomcat/util/http/Parameters.java
2011/11/7 Rainer Jung :
> Hi Konstantin,
>
> On 07.11.2011 02:46, kkoli...@apache.org wrote:
>> Author: kkolinko
>> Date: Mon Nov 7 10:46:14 2011
>> New Revision: 1198696
>>
>> URL: http://svn.apache.org/viewvc?rev=1198696&view=rev
>> Log:
>> Introduce new request attribute to be used to mark request if there was a
>> failure during parameter parsing,
>> and a Filter that triggers parameter parsing and rejects requests marked
>> with that attribute.
>>
>> Added:
>> tomcat/trunk/java/org/apache/catalina/filters/FailedRequestFilter.java
>> (with props)
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/Globals.java
>> tomcat/trunk/java/org/apache/catalina/connector/Request.java
>> tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java
>>
>>
>> /**
>> + * The request attribute that is set to {@code Boolean.TRUE} if some
>> request
>> + * parameters have been ignored during request parameters parsing. It
>> can
>> + * happen, for example, if there is a limit on the total count of
>> parseable
>> + * parameters, or if parameter cannot be decoded, or any other error
>> + * happened during parameter parsing.
>> + */
>> + public static final String PARAMETER_PARSE_FAILED_ATTR =
>> + "org.apache.catalina.parameter_parse_failed";
>
> I don't now if we ever have to make the new request attribute available
> in coyote request, but in o.a.c.connector.Request there is code that
> only passes attributes down to the coyote request if the attribute name
> starts with "org.apache.tomcat". See removeAttribute() and setAttribute():
>
> 1413 // Pass special attributes to the native layer
> 1414 if (name.startsWith("org.apache.tomcat.")) {
> 1415 coyoteRequest.getAttributes().remove(name);
> 1416 }
> ...
> 1520 // Pass special attributes to the native layer
> 1521 if (name.startsWith("org.apache.tomcat.")) {
> 1522 coyoteRequest.setAttribute(name, value);
> 1523 }
>
> In fact this use of "org.apache.tomcat." could also another Global constant.
>
Thank you for the comment.
I agree "org.apache.tomcat." could be a constant.
Need to think of a good name like COYOTE_ATTR_PREFIX.
The "Pass ... to the native layer" comment is understandable,
but seems outdated with Nio implementation there besides Apr one.
If there isn't a constant, there could be a comment in Globals
mentioning the prefix.
Regarding PARAMETER_PARSE_FAILED_ATTR, its value is present
in the "native layer" as Parameters.isParseFailed(),
and the attribute is used only to pass this information up to Servlets.
I delegate the decision what to do to Valves/Filters/Servlets that
check the attribute. I do not see anything that can happen at the
"native layer".
Instead of Request#checkParameterParseFailed() there could be
alternative implementation as a new "if(name.equals(...))" branch in
Request#getAttribute().
Side effects are that the new attribute is listed in
Request.getAttributeNames() enumeration (unlike other special
attributes that are omitted there) and can be changed by
Request#setAttribute(), Request#removeAttribute().
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1199980 - in /tomcat/trunk/java/org/apache: catalina/core/AprLifecycleListener.java catalina/core/LocalStrings.properties tomcat/jni/SSL.java
2011/11/10 Mark Thomas : >>> On 09/11/2011 21:34, schu...@apache.org wrote: >>>> Author: schultz Date: Wed Nov 9 21:34:31 2011 New Revision: >>>> 1199980 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1199980&view=rev Log: >>>> Fixed bug #50570 - Allow explicit use of FIPS mode in APR >>>> lifecycle listener - Added "FIPSMode" attribute to >>>> AprLifecycleListener that causes OpenSSL to go into FIPS mode >>> >>> Isn't this dependent on an tcnative update? >> >> Yes, it is. I'm updating the documentation for AprLifecycleListener >> and I will mention the version dependency in there. If this is not >> yet appropriate to release, I can roll-back the patch. > > What happens if I try this with 1.1.22? If it blows up, that is bad. > If it logs an error, that is fine. If it silently carries on, that is bad. > Just testing this. If I do not set FIPSMode property, all is OK. No difference from previous behaviour. If I set FIPSMode="on", the following happens [[[ 10-Nov-2011 01:13:59.484 INFO [main] org.apache.catalina.core.AprLifecycleListener.init Loaded APR based Apache Tomcat Native library 1.1.22. 10-Nov-2011 01:13:59.500 INFO [main] org.apache.catalina.core.AprLifecycleListener.init APR capabilities: IPv6 [false], sendfile [true], accept filters [false], random [true]. 10-Nov-2011 01:13:59.937 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL Initializing FIPS mode... 10-Nov-2011 01:13:59.937 SEVERE [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to initialize the SSLEngine. java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.SSL.fipsModeSet(I)I at org.apache.tomcat.jni.SSL.fipsModeSet(Native Method) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:248) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:109) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:389) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99) at org.apache.catalina.startup.Catalina.load(Catalina.java:573) at org.apache.catalina.startup.Catalina.load(Catalina.java:598) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:449) (...) 10-Nov-2011 01:14:01.203 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 1030 ms ]]] There is java.lang.UnsatisfiedLinkError (and not the IllegalStateException that the code throws). Despite this error, Tomcat startup sequence continues. I guess that from FIPS PoV the failure to initialize FIPS mode should be more fatal, regardless of its cause. Be it because of native lib returning error code or this tc-native version mismatch. Maybe even throw an error if SSLEngine was not "on". Now it just causes the FIPS mode to be ignored. I do not know why UnsatisfiedLinkError error was not enough to break it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1199980 - in /tomcat/trunk/java/org/apache: catalina/core/AprLifecycleListener.java catalina/core/LocalStrings.properties tomcat/jni/SSL.java
2011/11/10 Christopher Schultz :
>>
>> There is java.lang.UnsatisfiedLinkError (and not the
>> IllegalStateException that the code throws).
>>
>> Despite this error, Tomcat startup sequence continues.
>>
>> I guess that from FIPS PoV the failure to initialize FIPS mode should
>> be more fatal, regardless of its cause.
>> Be it because of native lib returning error code or this tc-native
>> version mismatch.
>> Maybe even throw an error if SSLEngine was not "on". Now it just
>> causes the FIPS mode to be ignored.
>>
>> I do not know why UnsatisfiedLinkError error was not enough to break it.
>
> Because the AprLifecycleListener's code looks like this:
>
> if (Lifecycle.BEFORE_INIT_EVENT.equals(event.getType())) {
> synchronized (lock) {
> init();
> if (aprAvailable) {
> try {
> initializeSSL();
> } catch (Throwable t) {
> ExceptionUtils.handleThrowable(t);
> log.error(sm.getString("aprListener.sslInit"), t);
> }
> }
> }
>
>
> The error is caught, logged, and execution continues.
>
> I did not feel that this was an appropriate patch to include changes to
> exception handling within the AprLivecycleListener.
>
Maybe add explicit FIPS mode status check below the above error
handling? Something like:
if ("on".equalsIgnoreCase(FIPSMode) && !fipsModeActive) {
fail fatally;
}
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in ASF Buildbot on tomcat-trunk
2011/11/11 Rainer Jung : > On 10.11.2011 13:46, build...@apache.org wrote: >> >> 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/2492 >> >> Buildbot URL: http://ci.apache.org/ >> >> Buildslave for this Build: bb-vm_ubuntu >> >> Build Reason: scheduler >> Build Source Stamp: [branch tomcat/trunk] 1200555 >> Blamelist: rjung >> >> BUILD FAILED: failed compile_1 > > Test failure in > org.apache.catalina.tribes.group.interceptors.TestNonBlockingCoordinator. > Wasn't that the test that is already known to sporadically fail? Couldn't > reproduce here on first run. Will run test in a loop. I don't think the > failure is due to r1200555. > Yes, it is sporadic. Failed 3 or 4 times during the last week. Note, that in the same buildbot run the test occurs twice (bio+nio), but only one fails. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1200582 - /tomcat/tc6.0.x/trunk/STATUS.txt
2011/11/11 : > Author: rjung > Date: Thu Nov 10 21:46:32 2011 > New Revision: 1200582 > > URL: http://svn.apache.org/viewvc?rev=1200582&view=rev > Log: > Add proposal. > > Modified: > tomcat/tc6.0.x/trunk/STATUS.txt > > +* Fix setting of some standard attributes on cluster managers. > + Backport of r1200555 from trunk. > + > http://people.apache.org/~rjung/patches/tc6-cluster-fix-attribute-setting.patch > + +1: rjung > + -1: > + What about property change listeners and other side effects? Similar previous changes in trunk: http://svn.apache.org/viewvc?view=revision&revision=1175155 I think that the same setters are used when configuring the object through Digester and there are no listeners in a newly created object. So unlikely there are side effects. Calling setRandomFile() looks especially suspicious, but anyway if it is never called it is called again at the top of ManagerBase.getRandomBytes(). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1200582 - /tomcat/tc6.0.x/trunk/STATUS.txt
2011/11/11 Rainer Jung : > On 10.11.2011 15:08, Konstantin Kolinko wrote: >> >> 2011/11/11: >>> >>> Author: rjung >>> Date: Thu Nov 10 21:46:32 2011 >>> New Revision: 1200582 >>> >>> URL: http://svn.apache.org/viewvc?rev=1200582&view=rev >>> Log: >>> Add proposal. >>> >>> Modified: >>> tomcat/tc6.0.x/trunk/STATUS.txt >>> >>> +* Fix setting of some standard attributes on cluster managers. >>> + Backport of r1200555 from trunk. >>> + >>> http://people.apache.org/~rjung/patches/tc6-cluster-fix-attribute-setting.patch >>> + +1: rjung >>> + -1: >>> + >> >> What about property change listeners and other side effects? Similar >> previous changes in trunk: >> http://svn.apache.org/viewvc?view=revision&revision=1175155 >> >> I think that the same setters are used when configuring the object >> through Digester and there are no listeners in a newly created object. >> So unlikely there are side effects. > > It does. I was curious about the exact stacks where the Manager element in > the Cluster in server.xml vs. Manager in Context in context.xml kick in and > indeed the setters are called by the Digester. > > So probably it would even be better to also use the setter for > maxActiveSessions. > >> Calling setRandomFile() looks especially suspicious, >> but anyway if it is never called it is called again at the top of >> ManagerBase.getRandomBytes(). > > Yes and it seems safe to be called multiple times. > > So I'll also switch maxActiveSessions to calling the setter in trunk/tc 7 > and add that to the proposed TC 6 patch. > 1) There is a difference whether it creates ManagerBase.randomIS now or only on the next call to getRandomBytes() 2) I think there is a bug in setRandomFile() implementation. Note that there is default value for devRandomSource. Then the code does: File f=new File( devRandomSource ); if( ! f.exists() ) return; ... devRandomSource = null; The following two things are wrong: A. new File(null) will result in an NPE. B. On Windows (or any other configurations where the file does not exist) it will repeatedly call "new File()" and f.exists() on every call to getRandomBytes(), wasting IO I think it should - ignore the call if the argument to setRandomFile() is null - set devRandomSource to null if the file does not exist Because of A. if there was IOException when opening the file you will result with NPE when calling the setter on a clone. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TCnative crashes in test suite for trunk and TC 7
2011/11/11 Rainer Jung : > I get crashes when testing APR/TCnative 1.1.22 on trunk and on TC 7. > APR version was 1.4.5. > > Does anybody else see this? The failures seem intermittent and I would > expect they are *not* always happening in the same tests. > I run tests with APR connector with full testsuite from time to time, maybe 7-10 times this month, but have never seen such crash. I am on Windows and using 32-bit binaries from http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.22/binaries/win32/ >From README file there they are compiled with APR 1.3.12 OpenSSL 0.9.8r Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Redeploy on context.xml changes (Was: Tagging 7.0.23)
URL)
x 3 times.
There is ContextConfig#ok flag that is reset to "false" if parsing fails.
At end of ContextConfig#configureStart() it does:
if (ok) {
context.setConfigured(true);
} else {
log.error(sm.getString("contextConfig.unavailable"));
context.setConfigured(false);
}
I mean:
- FailedContext class solves a very limited task.
- I think that if a StandardContext instance were used instead of
FailedContext, it will result in a failure when parsing one of 3
context files. It covers more wide range of failures.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1202058 - in /tomcat/trunk/bin: catalina.bat catalina.sh configtest.sh digest.sh setclasspath.bat setclasspath.sh shutdown.sh startup.sh version.sh
2011/11/15 Mladen Truk : > On 11/15/2011 07:43 AM, William A. Rowe Jr. wrote: >> >> On 11/15/2011 12:37 AM, mt...@apache.org wrote: >>> >>> Author: mturk >>> Date: Tue Nov 15 06:37:12 2011 >>> New Revision: 1202058 >>> >>> URL: http://svn.apache.org/viewvc?rev=1202058&view=rev >>> Log: >>> Make sure .bat and .sh files have executable property set >> >> This could be a silly point, but .bat files do not carry a shebang >> line. Is this really sensible from any actual environment? >> > > Yes if you use cygwin. > It does some weird ACL settings depending if 775 is set or not > when using cygwin's unzip. > It is useless to set executable bit on the files in source tree. They should not be run from there, but from build/bin. Does Ant preserve executable bit when copying the files? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1201606 - in /tomcat/jk/trunk/native/common: jk_ajp_common.c jk_pool.c jk_shm.c
2011/11/14 :
> Author: mturk
> Date: Mon Nov 14 06:19:07 2011
> New Revision: 1201606
>
> URL: http://svn.apache.org/viewvc?rev=1201606&view=rev
> Log:
> Fix code style. No functional change
>
> Modified:
> tomcat/jk/trunk/native/common/jk_ajp_common.c
> tomcat/jk/trunk/native/common/jk_pool.c
> tomcat/jk/trunk/native/common/jk_shm.c
>
In pool.c:
> Modified: tomcat/jk/trunk/native/common/jk_pool.c
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_pool.c?rev=1201606&r1=1201605&r2=1201606&view=diff
> ==
> --- tomcat/jk/trunk/native/common/jk_pool.c (original)
> +++ tomcat/jk/trunk/native/common/jk_pool.c Mon Nov 14 06:19:07 2011
> @@ -173,13 +173,13 @@ char *jk_pool_strcatv(jk_pool_t *p, ...)
> #if defined (DEBUG) || defined(_DEBUG)
> static void jk_dump_pool(jk_pool_t *p, FILE * f)
> {
> - fprintf(f, "Dumping for pool [%p]\n", p);
> - fprintf(f, "size [%ld]\n", p->size);
> - fprintf(f, "pos [%ld]\n", p->pos);
> - fprintf(f, "buf [%p]\n", p->buf);
> - fprintf(f, "dyn_size [%ld]\n", p->dyn_size);
> - fprintf(f, "dyn_pos [%ld]\n", p->dyn_pos);
> - fprintf(f, "dynamic [%p]\n", p->dynamic);
> + fprintf(f, "Dumping for pool [%p]\n", p);
> + fprintf(f, "size [%u]\n", (unsigned int)p->size);
> + fprintf(f, "pos [%u]\n", (unsigned int)p->pos);
> + fprintf(f, "buf [%d]\n", p->buf ? 1 : 0);
> + fprintf(f, "dyn_size [%d]\n", (unsigned int)p->dyn_size);
> + fprintf(f, "dyn_pos [%d]\n", (unsigned int)p->dyn_pos);
I think it would be s/%d/%u/ in the previous two lines, like already
done above them.
It should not matter, but this commit is all about code style...
> + fprintf(f, "dynamic [%d]\n", p->dynamic ? 1 : 0);
>
> fflush(f);
> }
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1202556 - in /tomcat/jk/trunk/native: README.txt TODO.txt apache-2.0/bldjk.qclsrc apache-2.0/bldjk54.qclsrc build.xml netscape/Makefile.linux
2011/11/16 : > Author: mturk > Date: Wed Nov 16 07:07:10 2011 > New Revision: 1202556 > > URL: http://svn.apache.org/viewvc?rev=1202556&view=rev > Log: > Axe deprecated JNI references from more places > > Modified: > tomcat/jk/trunk/native/README.txt > tomcat/jk/trunk/native/TODO.txt > tomcat/jk/trunk/native/apache-2.0/bldjk.qclsrc > tomcat/jk/trunk/native/apache-2.0/bldjk54.qclsrc > tomcat/jk/trunk/native/build.xml > tomcat/jk/trunk/native/netscape/Makefile.linux Noticed one glitch in this, in Makefile.linux: > Modified: tomcat/jk/trunk/native/netscape/Makefile.linux > URL: > http://svn.apache.org/viewvc/tomcat/jk/trunk/native/netscape/Makefile.linux?rev=1202556&r1=1202555&r2=1202556&view=diff > == > --- tomcat/jk/trunk/native/netscape/Makefile.linux (original) > +++ tomcat/jk/trunk/native/netscape/Makefile.linux Wed Nov 16 07:07:10 2011 > @@ -37,8 +37,6 @@ VPATH=.:$(JK_DIR) > > JK_SRCS = $(shell \ls $(JK_DIR)/*.c) > JK_OBJECTS = $(patsubst $(JK_DIR)/%.c,%.o,$(JK_SRCS)) > -JK_OBJS = $(filter-out $(JK_JNI_OBJECTS),$(JK_OBJECTS)) > - > PLUGIN_OBJ = jk_nsapi_plugin.o > > INCLUDE_FLAGS= -I$(JK_DIR) -I$(INCLUDEDIR) -I$(INCLUDEDIR)/base \ > You axed the whole "JK_OBJS" above, but it is used below in the file: 48 nsapi_redirector.so: $(JK_OBJS) $(PLUGIN_OBJ) 49 $(LD_SHAREDCMD) $(JK_OBJS) $(PLUGIN_OBJ) -o nsapi_redirector.so $(EXTRA_LDDEFINES) I do not 100% understand this file, but it looks like it can be replaced it with JK_OBJECTS. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.34
2011/11/15 jean-frederic clere : > The candidates binaries are available here: > http://people.apache.org/~jfclere/tomcat-6/v6.0.34/ > > According to the release process, the 6.0.34 build corresponding to the > tag TOMCAT_6_0_34 is: > [x] Broken http://localhost:8080/examples/servlets/servlet/RequestParamExample?firstname=hello+world Prints "hello+world" instead of "hello world". The cause is that UDecoder#convert() handles both '+' and '%xx' , but Parameters#processParameters(byte bytes[], ...) does not trigger decoding unless there is '%' in the value. E.g. "?firstname=hello+world%25" is decoded correctly. It is my fault as well that I missed this. Sorry for inconvenience. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1198553 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AbstractEndpoint.java test/org/apache/catalina/startup/TomcatBaseTest.java webapps/docs/changelog.xml webapps/do
2011/11/17 Mark Thomas : > On 06/11/2011 20:52, kkoli...@apache.org wrote: >> Author: kkolinko >> Date: Sun Nov 6 20:52:33 2011 >> New Revision: 1198553 >> >> URL: http://svn.apache.org/viewvc?rev=1198553&view=rev >> Log: >> Merged revisions r1197158, r1198552 from tomcat/trunk: >> Add new attribute to AbstractEndpoint and use it to speed up Tomcat tests. >> If the attribute "fastShutdown" is set on the endpoint, >> the usual wait of 1 sec during pause() is skipped. > > I'm seeing unit test failures (with a JVM crash) on 64-bit Ubuntu Linux > with this patch that go away if I disable the fast shut-down. I only > have a single result that shows this. I need to do multiple tests to > confirm the result. > What connector that is? Rainer wrote about APR/TCnative 1.1.22 with APR 1.4.5. Java VM: Java HotSpot(TM) Server VM (20.4-b02 mixed mode solaris-sparc ): http://tomcat.markmail.org/thread/a5quoui2soe6qb33 There is also a user report that sounds as reproducible, though may not be related to this specific issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=52153 "periodic JVM crash (access violation) on buffer flush" > I'm not too bothered right now since this won't affect production > systems but I'd like to get to the bottom of it. > > Any thoughts welcome. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1198553 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AbstractEndpoint.java test/org/apache/catalina/startup/TomcatBaseTest.java webapps/docs/changelog.xml webapps/do
2011/11/17 Mark Thomas : > On 06/11/2011 20:52, kkoli...@apache.org wrote: >> Author: kkolinko >> Date: Sun Nov 6 20:52:33 2011 >> New Revision: 1198553 >> >> URL: http://svn.apache.org/viewvc?rev=1198553&view=rev >> Log: >> Merged revisions r1197158, r1198552 from tomcat/trunk: >> Add new attribute to AbstractEndpoint and use it to speed up Tomcat tests. >> If the attribute "fastShutdown" is set on the endpoint, >> the usual wait of 1 sec during pause() is skipped. > > Any thoughts welcome. > "fastShutdown" disables 1sec wait in AbstractEndpoint.pause(). The idea behind it is that when test ends there are no open connections being processed by Tomcat (and so there is not much benefit in pausing endpoint before stopping it). It may be that for some tests that is not true. Before implementing it I pondered an idea of alternative implementation to minimize wait in endpoint.pause(). The idea was to iterate over endpoint threads and check whether pausing was successful (I think that will be faster than this empirical 1 second wait). Though implementing that would require an insight in implementation of a specific endpoint. It should be possible to update TomcatBaseTest class to turn off this feature for some tests, or for Apr connector as a whole. That is just regarding this feature. There might be other questions like whether Apr shutdown can be made more robust and whether this crash is triggered by some other issue. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Change in behavior for Connector maxKeepAliveRequests in 7.0.21+
2011/11/17 Ryan Morgan : > > Hey everyone, > > As part of the HTTP connector refactoring that occurred in 7.0.21 (see > http://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1158367) > the Connector behavior has changed when maxKeepAliveRequests is set to 0. In > Tomcat 7.0.20 and earlier, a setting of 0 would disable keepalives for the > connector. In 7.0.21 an up, it's enabled and from what I can tell, set to > infinite. > > Was this change intended? From looking at the documentation, the updated > code is correct as a value of 0 is not mentioned. However, this could cause > issues for servers that have maxKeepAliveRequests mis-configured to 0 and > upgrade to 7.0.21+ Just a quick look at Tomcat 6.0 documentation (config/http.html) reveals that it does not document the value of "0" either. That specific sentence in Tomcat 6.0 docs was not updated since r420006 when TC6 development started (5 years ago). So I do not see any problem here. The documented values are -1 for infinity, 1 for disable, 100 by default. The intent of commits around r1158367 was to align implementations between connectors. It might be that some of them (Bio vs Nio vs Apr) treated "0" differently. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Maintenance Release of Servlet 3.0 (3.0 Rev a)
Hi! I do not remember this being announced or discussed: There is "Maintenance Release" of Servlet specification 3.0, numbered as "3.0 Rev a". I added links to it on our Wiki page, [1] There is no list of changes in the PDF itself, but it is on the JCP web site: [2]. It might be that some of changes/clarifications listed in [2] need to be implemented. [1] https://wiki.apache.org/tomcat/Specifications [2] http://jcp.org/aboutJava/communityprocess/maintenance/jsr315/servlet3-mr-reva.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1203253 - in /tomcat/trunk: java/org/apache/tomcat/util/net/ test/org/apache/catalina/startup/ webapps/docs/config/
2011/11/17 Mark Thomas :
> On 17/11/2011 16:40, ma...@apache.org wrote:
>> Author: markt
>> Date: Thu Nov 17 16:40:02 2011
>> New Revision: 1203253
>>
>> URL: http://svn.apache.org/viewvc?rev=1203253&view=rev
>> Log:
>> Refactor acceptor pause and shutdown to remove need for 'random' waits in
>> the shutdown code.
>> Removes the need for the fastShutdown attribute
>
> I don't think this is quite as fast as it was with fastShutdown but
> we'll need to wait for the buildbot results to be sure.
>
In trunk:
Run Revision Time for testsuite run ("compile_1")
2529 120307818 mins, 6 secs
2530 120309118 mins, 37 secs
2531 120325317 mins, 33 secs <- this change
2532 120327817 mins, 46 secs
2533 120334616 mins, 30 secs
It is good.
I cannot explain speedup in run 2533 rather than it being random or
good time of day. r1203346 removed of unused code in
XMLEncodingDetector, but it should not change that much. We will see
whether it stays with next runs. Anyway the numbers are good.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed
2011/11/18 Bill Barker : > 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-tc7.0.x-test has an issue affecting its community integration. > This issue affects 1 projects, > and has been outstanding for 29 runs. > The current state of this project is 'Failed', with reason 'Build Failed'. > For reference only, the following projects are affected by this: > - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java > Servlet 3.0, > ... > > > Full details are available at: > > http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html > It is the following one test that failed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_file/TEST-org.apache.catalina.comet.TestCometProcessor.NIO.txt.html [[[ Testsuite: org.apache.catalina.comet.TestCometProcessor Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 37.646 sec (...) Testcase: testCometConnectorStop took 4.081 sec FAILED Comet END event not received junit.framework.AssertionFailedError: Comet END event not received at org.apache.catalina.comet.TestCometProcessor.testCometConnectorStop(TestCometProcessor.java:293) ]]] The above is for tc7.0.x. The trunk test run failed in the same place, http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_file/TEST-org.apache.catalina.comet.TestCometProcessor.NIO.txt.html [[[ Testcase: testCometConnectorStop took 4.053 sec FAILED Comet END event not received junit.framework.AssertionFailedError: Comet END event not received at org.apache.catalina.comet.TestCometProcessor.testCometConnectorStop(TestCometProcessor.java:293) ]]] I rerun the test with trunk locally with Nio and Apr and it completed successfully. The buildbot test run was successful as well. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.23
> On 17/11/2011 18:33, Mark Thomas wrote: >> The proposed Apache Tomcat 7.0.23 release is now available for voting. >> >> It can be obtained from: >> http://people.apache.org/~markt/dev/tomcat-7/v7.0.23/ >> The svn tag is: >> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_23/ >> >> The proposed 7.0.23 release is: >> [x] Stable - go ahead and release as 7.0.23 Stable Testsuite runs successfully (Bio+Nio+Apr). I observed known glitch (*) in one run, but second full rerun was successful. No issues when running with applications. Using JDK 6u29 32-bit on Windows. (*) I observed "PING"+"PING" vs "PINGPING" issue in TestCometProcessor#testSimpleCometClient x NIO, That is: "expected: but was:" That is known, but might mean that recent timing adjustments on that test were not 100% successful. I noted NullPointerException in one of tribes tests. The test itself did not fail. It likely happened during teardown. Filed: https://issues.apache.org/bugzilla/show_bug.cgi?id=52208 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.23 - Take 2
2011/11/21 Mark Thomas : > The 7.0.23 tag was fine. The problem was local. I have re-rolled the > 7.0.23 release from a clean export of the 7.0.23 tag. > > The proposed 7.0.23 release is: > > [ ] Broken - do not release > [ ] Beta - go ahead and release as 7.0.23 Beta > [x] Stable - go ahead and release as 7.0.23 Stable Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: How to get the tomcat internal log out?
2011/11/21 Kurt : > Hello all: > > I compile tomcat 5.5.30 and import it to eclipse as a project, to > research how the tomcat load class , I need to view the running log ,after > reading through this > post(http://tomcat.apache.org/tomcat-5.5-doc/logging.html) and adding below > log.properties to the direcotry 'common/classes' and log4j-1.26.jar to > common/lib, logs turned out not to be generated when I debug the project > starting from class Catalina. No idea about it, I've tried many times. > > log4j.rootLogger=DEBUG,R > log4j.appender.R=org.apache.log4j.RollingFileAppender > log4j.appender.R.File=k:\\logs\\tomcat.log > log4j.appender.R.MaxFileSize=10MB > log4j.appender.R.MaxBackupIndex=10 > log4j.appender.R.layout=org.apache.log4j.PatternLayout > log4j.appender.R.layout.ConversionPattern=%p%t%c-%m%n > log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=DEBUG, > R > log4j.logger.org.apache.catalina.core=DEBUG, R > log4j.logger.org.apache.catalina.session=DEBUG, R > > And the program parameter I use is 'start', vm parameter is > '-Dcatalina.home="I:\My > Documents\program\java\projects\eclipse\mye9.0\TOMCAT_5_5_30\mybuild-5.5.30"' > Any ideas? Thanks 1. Your question is offtopic on dev@. You should ask on users@. 2. "log.properties" is wrong name for a log4j configuration file. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: How to get the tomcat internal log out?
2011/11/21 Kurt : > Hello guy: > > Do you really think I should post the question to users@? Cause I don't > want to see the log of web app ,but tomcat's itself. dev@ is about development of Tomcat itself. Everything else is users@. You are not proposing a patch for Tomcat. You are asking some question on how to use it. Thus it belongs to uses@ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multiple Aliases Problem
Confirming that it is a bug. I filed an issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52225
You would avoid this bug if you reorder your lines:
call "host.addAlias()" before you call "engine.addChild()".
That is what Digester does when parsing server.xml:
"engine.addChild()" method is called on the closing "" tag.
Best regards,
Konstantin Kolinko
2011/11/22 Chatree Srichart :
> Any comment?
>
> On Mon, Nov 21, 2011 at 1:52 PM, Chatree Srichart <
> chatree.srich...@gmail.com> wrote:
>
>> Hi community.
>> I am working on embedding a Tomcat server into my project.
>>
>> I have 2 domain name called localhost1 and localhost2.
>> I created a Host instance with the localhost1 domain name.
>>
>> Host host = new StandardHost();
>> host.setAppBase(CATALINA_HOSTS_HOME);
>> host.setName("localhost1");
>> host.setDeployOnStartup(false);
>> host.setBackgroundProcessorDelay(5);
>> host.setAutoDeploy(false);
>> host.setRealm(engine.getRealm());
>> engine.addChild(host);
>>
>> Then I added the localhost2 as a alias.
>>
>> host.addAlias("localhost2");
>>
>> If I entered localhost1 at a browser then it works fine but if I entered
>> localhost2 at the browser then I got an error:
>>
>> Nov 21, 2011 1:29:26 PM org.apache.coyote.http11.AbstractHttp11Processor
>> process
>> SEVERE: Error processing request
>> java.lang.ClassCastException:
>> org.apache.tomcat.util.http.mapper.Mapper$Host cannot be cast to
>> org.apache.catalina.Host
>> at org.apache.catalina.connector.Request.getHost(Request.java:631)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:105)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:964)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>> I solved this problem by adding some codes into the trunk:
>>
>> Index: java/org/apache/tomcat/util/http/mapper/Mapper.java
>> ===
>> --- java/org/apache/tomcat/util/http/mapper/Mapper.java (revision
>> 1204361)
>> +++ java/org/apache/tomcat/util/http/mapper/Mapper.java (working copy)
>> @@ -149,6 +149,10 @@
>> newHost.contextList = realHost.contextList;
>> newHost.object = realHost;
>> if (insertMap(hosts, newHosts, newHost)) {
>> + Object object = newHost.object;
>> + if (object instanceof Mapper.Host) {
>> + newHost.object = ((Mapper.Host) object).object;
>> + }
>> hosts = newHosts;
>> }
>> }
>>
>>
>> Do you think I am doing in the right track and this fixed should be
>> committed into the trunk? If not, could you please give me a solution to
>> solve the problem?
>>
>> Regards,
>> Chatree Srichart
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tagging 6.0.34 tomorrow?
2011/11/22 Forrest Xia : > Any update on 6.0.34 vote? Geronimo would like to have it in the coming > 2.1.8 release. 6.0.34 is broken. Timing for 6.0.35 is yet to be decided. There is 7.0.23 vote right now. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Random Comet unit test failures
2011/11/23 Mark Thomas : > I have done a little bit of digging on this as the current 7.0.x trunk > fails frequently enough on my windows box that I can repeat the failure > often enough. > > I have got as far as discovering that the request.getAvailable() test on > line 308 of the CoyoteAdapter returns zero whenever the test fails. > > While, I haven't figured out how this leads to the failure yet, I > thought the info may help others make some progress on this. > > There is clearly a timing / threading issue here but I haven't found it yet. > What failure are you pursuing? The following one occurs frequently on Gump/buildbot: [[[ Testcase: testCometConnectorStop took 4.078 sec FAILED Comet END event not received junit.framework.AssertionFailedError: Comet END event not received at org.apache.catalina.comet.TestCometProcessor.testCometConnectorStop(TestCometProcessor.java:293) ]]] In the main stdout file there occasionally are also a lot of NPE like [[[ [junit] Nov 23, 2011 3:37:25 AM org.apache.coyote.http11.AbstractHttp11Processor process [junit] SEVERE: Error processing request [junit] java.lang.NullPointerException [junit] at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:126) [junit] at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:175) [junit] at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:170) [junit] at org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:249) [junit] at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:128) [junit] at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:741) [junit] at org.apache.coyote.Response.action(Response.java:170) [junit] at org.apache.coyote.Response.finish(Response.java:276) [junit] at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:288) [junit] at org.apache.catalina.connector.Response.finishResponse(Response.java:507) [junit] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:434) [junit] at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987) [junit] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) [junit] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1571) [junit] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [junit] at java.lang.Thread.run(Thread.java:636) [junit] Nov 23, 2011 3:37:25 AM org.apache.catalina.connector.CoyoteAdapter log [junit] WARNING: Exception while attempting to add an entry to the access log [junit] java.lang.NullPointerException [junit] at org.apache.catalina.connector.CoyoteAdapter.log(CoyoteAdapter.java:511) [junit] at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1007) [junit] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539) [junit] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1571) [junit] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [junit] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [junit] at java.lang.Thread.run(Thread.java:636) ]]] The above one is from http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.txt Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: can only see ROOT webapp
2011/11/23 shadowdancer351 : > > I am using Tomcat 4 on Linux. > 1. Your question is offtopic on dev@ mailing list. 2. There should not be any reason to still use Tomcat 4. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
