Re: [taglibs] XPath support
On 12/07/2010 06:40, Jeremy Boynes wrote: > Implementation seems to work but does not provide as much benefit as > expected. Jasper tag pooling does not pool tags with the same attribute > values so the select attribute is set every time causing recompilation. The > time taken to iterate 1000 tags drops from around 2800ms to 1800ms. Providing the same attributes with the same values are present, Jasper should be pooling the tags. There was a bug in this area [1] but it was fixed some time ago. If this isn't the case then please open a Tomcat bug and provide a test case. > To work around this I added a thread-local cache of compiled XPath > expressions. This does reduce the initial time taken for the first few > iterations but the time taken to evaluate the compiled expression grows from > 500us to 2100us toward the end of the loop (measured with nanoTime() around > the call to evaluate). There may be some issue with Xalan; the same behaviour > is seen with Sun's JAXP implementation included in JDK1.6 (which is based on > Xalan). Use of ThreadLocals in this way is almost certainly going to trigger memory leaks on web application reload. > The same slowdown is seen if the expression is evaluated each time, or if the > xpath is run in a standalone testcase outside taglibs entirely. There may be > an issue here with Xalan and/or the JDK. > > We might be advised to consider a different XPath implementation. Does anyone > have any thoughts on Jaxen? Sorry, no idea on this. Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=38197 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49567] when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 --- Comment #2 from Pieter Libin 2010-07-12 04:23:47 EDT --- (In reply to comment #1) > Looks like you attached the wrong test case to this report. Dear Mark, why do you think this is the wrong test case? Are you not able to reproduce the problem with it? Kind regards, Pieter -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49567] when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 --- Comment #3 from Mark Thomas 2010-07-12 04:40:25 EDT --- Because at first glance the test case appears to be identical to the previous bug you reported and there is no reference in it to doPost which you refer to in both the title and the description. On closer inspection I see there are differences but I am still confused about the references to doPost in the title and description. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Add Checkstyle ruleset and make code cleanups!
Hi Konstantin, 1. What is TabSpacePolicy? It is not listed at: http://checkstyle.sourceforge.net/availablechecks.html There is FileTabCharacter though. http://checkstyle.sourceforge.net/config_whitespace.html#FileTabCharacter of course this is the FileTabCharacter check. Interesting to see when the "tab space policy" becomes the TabSpacePolicy check ;-) 2. There is NO consensus on @Version format. Last time when it was discussed, about a year ago, there was slight agreement to get rid of those tags at all. http://marc.info/?t=12469253133&r=1&w=2 Though, when I actually was performing the change recently I went for a more safe route of just replacing $Date$ with $Id$. One caveat with $Id$ that I noted in the last several months: when filename is long, "@version $Id$" can occupy more than 80 characters and is wrapped when reformatting the file in IDE, thus breaking this keyword. In several such cases I replaced $Id$ with $Revision$. if there is no consensus, then all commits concerning this should never have occurred ;-) I find interesting how some (Mark, you) seem to fight against introducing checkstyle and precisely defining what should be the rules although you make exactly this kind of changes. Why a 80 characters limit? Is this a recognized style rule for Tomcat? 3. From message in "Re: r960104" thread: http://markmail.org/message/rkznrp2cnfkd4eob: FileTabCharacter -> currently 146 failures In what packages are those files? please apply the patch and look at the report. The information will be fare better than what I can provide in this email. Fixing them can be discussed and done first, before enabling any checkstyle nags in the project. for me it doesn't make sense. If you agree that tabs should not be used, then the build should ensure that. If the build doesn't ensure that, there is no guaranty that tabs won't be introduced again in the future and therefore fixing them now is nearly lost time. 4. Is it possible to exclude some packages from checkstyle checks? E.g., org.apache.tomcat.util.bcel ? the ant task uses a fileset elements that can contain exclusion http://checkstyle.sourceforge.net/anttask.html 5. Is there experience whether checkstyle checks run fast, or there are noticeable delays? The "Re: r960104" thread was about preventing commits that have wrong whitespace. It probably means that checkstyle is run automatically by IDE, or by the buildbot. Do others have positive experience with such configurations? checkstyle is fast (in fact it doesn't really matter for the build) Plugins for the IDE are really nice as they highlight the problems and need only to run on modified files. Based on the above [x] 0 : More discussion needed I am +1 if someone else wants to add a separate "checkstyle" target to build.xml. it is the case of the proposed patch I do not mind against checks that already succeed for the existing code. Though if they always succeed they are not really useful. wrong. Let's take IllegalImport as an example. It checks that some imports (default to sun.* packages) are not used. It currently pass but one error from one committer is enough to make them fail (and don't say that it can't occur ;-)). I'm impressed by the resistance of Tomcat committers against changes that aim to improve the code quality. The current discussion remembers me this patch: "Run the unit tests as part of the build!!!" (https://issues.apache.org/bugzilla/show_bug.cgi?id=47124) My feeling is that you really have to wake up. We are in 2010! Tomcat's large user base is surely enough to give you work until you retire but if you have more ambitious goals, you surely should give a look at other projects, like Jetty. In this case there is no discussion to determine who is the winner concerning measures used to ensure code quality! :-( Cheers, Marc. -- Blog: http://mguillem.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Add Checkstyle ruleset and make code cleanups!
On 12/07/2010 09:39, Marc Guillemot wrote: > I find interesting how some (Mark, you) seem to fight against > introducing checkstyle and precisely defining what should be the rules > although you make exactly this kind of changes. Then you completely mis-understand my position. My default preference would be to enable every single check I could find and ensure that the code-base passes all of them. However, I recognise that not everyone thinks the same way and that there have been strong objections to this sort of clean up in the past. Therefore, I think it is important to maintain a strong consensus on any global changes in this area and not to try and force them through when some committers are very much against them. I am also of the opinion that whilst there are open bugs currently being experienced by users then fixing these bugs is a higher priority than beautifying the code. Code clean-up is something I tend to look at when I have a spare five minutes and don't have time to look at anything else. There is consensus for spaces versus tabs so there should be no issues there at all. Unused imports and unused code generally are also checks that I haven't seen objections to. > Why a 80 characters limit? Is this a recognized style rule for Tomcat? Historically, yes - although it is frequently ignored. It would be worth a separate thread to see what the consensus view is on increasing this. >> Fixing them can be discussed and done first, >> before enabling any checkstyle nags in the project. > > for me it doesn't make sense. If you agree that tabs should not be used, > then the build should ensure that. If the build doesn't ensure that, > there is no guaranty that tabs won't be introduced again in the future > and therefore fixing them now is nearly lost time. I think the point here is that we don't want to introduce a new check that instantly causes the build to fail. The reasoning is that we then might not spot issues caused by other changes as quickly as we might. The preferred sequence of events is (and we do the same for new bug related unit tests): 1 add check locally 2 fix issues 3 commit issues fixes 4 commit addition of check where steps 3 & 4 happen very close together (and sometimes the other way around). >> I do not mind against checks that already succeed for the existing >> code. Though if they always succeed they are not really useful. > > wrong. Let's take IllegalImport as an example. It checks that some > imports (default to sun.* packages) are not used. It currently pass but > one error from one committer is enough to make them fail (and don't say > that it can't occur ;-)). Agreed. We do need to check that errors don't slip in further down the line. > I'm impressed by the resistance of Tomcat committers against changes > that aim to improve the code quality. The current discussion remembers > me this patch: > "Run the unit tests as part of the build!!!" > (https://issues.apache.org/bugzilla/show_bug.cgi?id=47124) Then I suggest you go and re-read that thread again and remind yourself what the real objections were. > My feeling is that you really have to wake up. We are in 2010! Tomcat's > large user base is surely enough to give you work until you retire but > if you have more ambitious goals, you surely should give a look at other > projects, like Jetty. In this case there is no discussion to determine > who is the winner concerning measures used to ensure code quality! :-( Taking a confrontational approach isn't going to win you any friends and isn't going to help you achieve the changes you want. I haven't gone back over this thread in detail but I don't recall any objections to adding a checkstyle check for tabs in files. I'd suggest focusing on that and once that is in place, then see what support there is for extending the checks that are enabled / extending the tools used (e.g. add FindBugs). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49584] New: Borrowers Getting Stuck
https://issues.apache.org/bugzilla/show_bug.cgi?id=49584 Summary: Borrowers Getting Stuck Product: Tomcat 7 Version: unspecified Platform: PC Status: NEW Severity: normal Priority: P2 Component: Modules: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: mur...@ben.name The borrow connection logic seems to assume that connections will always transition between active to idle. However, if connections move from active to released then a borrower can get stuck in idle.poll even though there is room in the pool for another connection to be created. There is also an issue with connection create failing causing the pool size to be incremented but not decremented. In the borrowConnection method the pool size is incremented. However, if an exception occurs in the createConnection method releaseConnection can be called with a null argument and the pool size is not decremented. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49585] New: jsvc.tar.gz no longer in $CATALINA_HOME/bin
https://issues.apache.org/bugzilla/show_bug.cgi?id=49585 Summary: jsvc.tar.gz no longer in $CATALINA_HOME/bin Product: Tomcat 5 Version: 5.5.30 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: Webapps:Documentation AssignedTo: dev@tomcat.apache.org ReportedBy: sergio.gel...@astro.su.se The 5.5.30 and 6.0.28 (I haven't checked 7.0) binary releases of Tomcat no longer ship bin/jsvc.tar.gz. A look at the changelog leads me to believe this is intentional. The documentation (setup.html), however, still refers to that file. In particular, the sentence "Source tarballs for jsvc are included with the Tomcat binaries" is no longer correct. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49567] when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 --- Comment #4 from Pieter Libin 2010-07-12 05:26:27 EDT --- (In reply to comment #3) > Because at first glance the test case appears to be identical to the previous > bug you reported and there is no reference in it to doPost which you refer to > in both the title and the description. On closer inspection I see there are > differences but I am still confused about the references to doPost in the > title > and description. I'm sorry for the confusion, please replace doPost by doGet. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49585] jsvc.tar.gz no longer in $CATALINA_HOME/bin
https://issues.apache.org/bugzilla/show_bug.cgi?id=49585 --- Comment #1 from Mark Thomas 2010-07-12 05:39:21 EDT --- It is in commons-daemon-native.tar.gz Yep, the docs need to be updated -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Add Checkstyle ruleset and make code cleanups!
Mark Thomas wrote: On 12/07/2010 09:39, Marc Guillemot wrote: I find interesting how some (Mark, you) seem to fight against introducing checkstyle and precisely defining what should be the rules although you make exactly this kind of changes. Then you completely mis-understand my position. really? Then please quickly introduce checkstyle for the checks for which a consensus exists. Then we can start work. ... My feeling is that you really have to wake up. We are in 2010! Tomcat's large user base is surely enough to give you work until you retire but if you have more ambitious goals, you surely should give a look at other projects, like Jetty. In this case there is no discussion to determine who is the winner concerning measures used to ensure code quality! :-( Taking a confrontational approach isn't going to win you any friends and isn't going to help you achieve the changes you want. I know, but it is a desperate step. I have tried following approaches: - provide patches ready to apply -> failed - start discussion about usage of recognized methods to improve code quality -> not really a success - try to be ironical and to let you know that the concurrence is far better here -> according to your comment, it seems that it fails as well Before to give up I'll try to praise the quality of the code and give you all kudos for it. Perhaps is this the right way but I have a problem: I don't know how to formulate my wish for code improvements when I praise the code at the same time :-( I haven't gone back over this thread in detail but I don't recall any objections to adding a checkstyle check for tabs in files. I'd suggest focusing on that and once that is in place, then see what support there is for extending the checks that are enabled / extending the tools used (e.g. add FindBugs). this is exactly what I do. Cheers, Marc. -- Blog: http://mguillem.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Add Checkstyle ruleset and make code cleanups!
2010/7/12 Marc Guillemot : > >> 2. There is NO consensus on @Version format. >> (...) > > if there is no consensus, then all commits concerning this should never have > occurred ;-) The consensus is that $Date$ is broken and must not be used. Nothing else. > > Why a 80 characters limit? Is this a recognized style rule for Tomcat? > It is part of the default code formatting configuration in the IDE that most committers are using. The issue was that the keyword broke. Rather than fixing just the issue at hand, I went further to prevent it in the future in that particular file by using a shorter keyword. > > If the build doesn't ensure that, there > is no guaranty that tabs won't be introduced again in the future and > therefore fixing them now is nearly lost time. > Nearly all committed code is reviewed, and such issues are spotted promptly. Actually, I do not bother whether there are tabs somewhere. I will be bothered only if I will start editing the affected file, or will prepare / apply a patch. In that case we have agreed that such files can be converted to spaces by CTR. >> 5. Is there experience whether checkstyle checks run fast, or there >> are noticeable delays? >> >> The "Re: r960104" thread was about preventing commits that have wrong >> whitespace. It probably means that checkstyle is run automatically >> by IDE, or by the buildbot. Do others have positive experience with >> such configurations? > > checkstyle is fast (in fact it doesn't really matter for the build) > Plugins for the IDE are really nice as they highlight the problems and need > only to run on modified files. Good to know. >> I do not mind against checks that already succeed for the existing >> code. Though if they always succeed they are not really useful. > > wrong. Let's take IllegalImport as an example. It checks that some imports > (default to sun.* packages) are not used. It currently pass but one error > from one committer is enough to make them fail (and don't say that it can't > occur ;-)). > There are other ways to ensure that. I use "Execution environment" as the selected JRE in Eclipse, and that prevents such imports. (sun.* packages are excluded, because they are not part of the public API). > > I'm impressed by the resistance of Tomcat committers against changes that > aim to improve the code quality. I do not resist. I just think that it is a bit of a waste of my time. If somebody else wants to spend time on this, I can encourage that person. > The current discussion remembers > me this patch: > "Run the unit tests as part of the build!!!" > (https://issues.apache.org/bugzilla/show_bug.cgi?id=47124) And the tests are not run as part of the default build. They are run when doing a release and they are run by buildbot. > I know, but it is a desperate step. I have tried following approaches: > - provide patches ready to apply -> failed I appreciate the patch, but it touches project policy and that needs a support on d...@. > - start discussion about usage of recognized methods to improve code quality > -> not really a success Really? I thought it was a success. > - try to be ironical (...) > -> according to your comment, it seems that it fails as well Please see "How it works", esp. "Project Management" and "Decision Making" http://www.apache.org/foundation/how-it-works.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: [VOTE] Add Checkstyle ruleset and make code cleanups!
On 12/07/2010 11:28, Marc Guillemot wrote: > Mark Thomas wrote: >> Taking a confrontational approach isn't going to win you any friends and >> isn't going to help you achieve the changes you want. > > I know, but it is a desperate step. I have tried following approaches: > - provide patches ready to apply -> failed Which have received feedback and discussion is still ongoing. Why view that as a failure? > - start discussion about usage of recognized methods to improve code > quality -> not really a success Not sure which bit of the various threads you are referring to. No, not everyone agrees with all your views or how to implement them. My advice would be get used to it, focus on the bits where there is agreement and remember that folks can change their mind - particularly once something is demonstrated to be successful. > - try to be ironical and to let you know that the concurrence is far > better here -> according to your comment, it seems that it fails as well Irony doesn't work very well on a mailing list. It works even less well when not everybody's first language is English. > Before to give up I'll try to praise the quality of the code and give > you all kudos for it. Perhaps is this the right way but I have a > problem: I don't know how to formulate my wish for code improvements > when I praise the code at the same time :-( Remaining polite would be a good place to start. Your attitude really isn't helping. As has been pointed out numerous times you are trying to persuade the Tomcat project to make changes that have historically been viewed as controversial and that a number of committers have very strong objections to and valid reasons for those objections. (Whilst I don't agree with those views I do respect them and understand them.) Being antagonistic, ironic or sarcastic simply isn't the way to make progress. Before I read you latest e-mail, I was intending to tidy up the patch attached to bug 49268 and look at applying it to trunk. Right now that looks like rewarding behaviour I have no wish to encourage so I'll be spending my time on other things instead. I'll circle back to this eventually. Of course, one of the other committers may look at it before me. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r963273 - /tomcat/trunk/res/maven/mvn.properties.default
Author: markt Date: Mon Jul 12 13:02:30 2010 New Revision: 963273 URL: http://svn.apache.org/viewvc?rev=963273&view=rev Log: Prepare for the next release Modified: tomcat/trunk/res/maven/mvn.properties.default Modified: tomcat/trunk/res/maven/mvn.properties.default URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn.properties.default?rev=963273&r1=963272&r2=963273&view=diff == --- tomcat/trunk/res/maven/mvn.properties.default (original) +++ tomcat/trunk/res/maven/mvn.properties.default Mon Jul 12 13:02:30 2010 @@ -29,17 +29,17 @@ maven.gpg.passphrase=* #Maven snapshot properties maven.snapshot.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository maven.snapshot.repo.repositoryId=apache.snapshots -maven.snapshot.deploy.version=7.0.0-SNAPSHOT +maven.snapshot.deploy.version=7.0.1-SNAPSHOT #Maven release properties for Tomcat staging maven.release.repo.url=scp://people.apache.org/www/tomcat.apache.org/dev/dist/m2-repository maven.release.repo.repositoryId=tomcat-staging -maven.release.deploy.version=7.0.0 +maven.release.deploy.version=7.0.1 #Maven release properties for the main ASF repo maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository maven.asf.release.repo.repositoryId=apache.releases -maven.asf.release.deploy.version=7.0.0 +maven.asf.release.deploy.version=7.0.1 #Where do we load the libraries from - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r963275 - in /tomcat/trunk/res/maven: mvn-pub.xml mvn.properties.default
Author: markt Date: Mon Jul 12 13:17:01 2010 New Revision: 963275 URL: http://svn.apache.org/viewvc?rev=963275&view=rev Log: Hard code the snapshot version for 7.0. 7.0-SNAPSHOT will always point to the latest snapshot. I'll clean out the snapshot repo before I do the next update Modified: tomcat/trunk/res/maven/mvn-pub.xml tomcat/trunk/res/maven/mvn.properties.default Modified: tomcat/trunk/res/maven/mvn-pub.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?rev=963275&r1=963274&r2=963275&view=diff == --- tomcat/trunk/res/maven/mvn-pub.xml (original) +++ tomcat/trunk/res/maven/mvn-pub.xml Mon Jul 12 13:17:01 2010 @@ -277,7 +277,7 @@ - + Modified: tomcat/trunk/res/maven/mvn.properties.default URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn.properties.default?rev=963275&r1=963274&r2=963275&view=diff == --- tomcat/trunk/res/maven/mvn.properties.default (original) +++ tomcat/trunk/res/maven/mvn.properties.default Mon Jul 12 13:17:01 2010 @@ -29,7 +29,6 @@ maven.gpg.passphrase=* #Maven snapshot properties maven.snapshot.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository maven.snapshot.repo.repositoryId=apache.snapshots -maven.snapshot.deploy.version=7.0.1-SNAPSHOT #Maven release properties for Tomcat staging maven.release.repo.url=scp://people.apache.org/www/tomcat.apache.org/dev/dist/m2-repository - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49567] when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 --- Comment #5 from Mark Thomas 2010-07-12 09:58:05 EDT --- I've converted the attached test case to a Tomcat 7 unit test and can reproduce the issue. Looking at it now... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Add Checkstyle ruleset and make code cleanups!
Mark Thomas wrote: ... Before I read you latest e-mail, I was intending to tidy up the patch attached to bug 49268 and look at applying it to trunk. Right now that looks like rewarding behaviour I have no wish to encourage so I'll be spending my time on other things instead. I'll circle back to this eventually. Of course, one of the other committers may look at it before me. interesting information which explains everything. The goal is not to improve the code base but to reward good guys. And because I'm not a good guy, I've just wasted my time proposing patches that don't get applied and are sometimes not worth a comment within 1 1/2 years. Marc. -- Blog: http://mguillem.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r963273 - /tomcat/trunk/res/maven/mvn.properties.default
On 12 July 2010 14:02, wrote: > Author: markt > Date: Mon Jul 12 13:02:30 2010 > New Revision: 963273 > > URL: http://svn.apache.org/viewvc?rev=963273&view=rev > Log: > Prepare for the next release > > Modified: > tomcat/trunk/res/maven/mvn.properties.default > > Modified: tomcat/trunk/res/maven/mvn.properties.default > URL: > http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn.properties.default?rev=963273&r1=963272&r2=963273&view=diff > == > --- tomcat/trunk/res/maven/mvn.properties.default (original) > +++ tomcat/trunk/res/maven/mvn.properties.default Mon Jul 12 13:02:30 2010 > @@ -29,17 +29,17 @@ maven.gpg.passphrase=* > #Maven snapshot properties > maven.snapshot.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository > maven.snapshot.repo.repositoryId=apache.snapshots > -maven.snapshot.deploy.version=7.0.0-SNAPSHOT > +maven.snapshot.deploy.version=7.0.1-SNAPSHOT > > #Maven release properties for Tomcat staging > maven.release.repo.url=scp://people.apache.org/www/tomcat.apache.org/dev/dist/m2-repository > maven.release.repo.repositoryId=tomcat-staging > -maven.release.deploy.version=7.0.0 > +maven.release.deploy.version=7.0.1 > > #Maven release properties for the main ASF repo > maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository With the current setting, any uploaded files are automatically transferred to Maven central, and errors cannot easily be recovered. The project might want to consider using the Nexus staging repo instead. Nexus allows artifacts to be reviewed before they are finally published (or dropped, if there is a problem). There's a little bit of extra work involved as one has to login to Nexus to close the staging area, and later drop or promote it, but ithat does not take long. I know that the project does not use Maven to upload the POMs, so has much more control over the upload process, but Nexus could still be helpful. Just a thought. > maven.asf.release.repo.repositoryId=apache.releases > -maven.asf.release.deploy.version=7.0.0 > +maven.asf.release.deploy.version=7.0.1 > > > #Where do we load the libraries from > > > > - > 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
DO NOT REPLY [Bug 49582] Mapping a servlet to the root (/) doesn't work when accessing the root
https://issues.apache.org/bugzilla/show_bug.cgi?id=49582 --- Comment #2 from bozho 2010-07-12 11:45:21 EDT --- I can't override the - I have to delete it from conf/web.xml, which is not good -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49582] Mapping a servlet to the root (/) doesn't work when accessing the root
https://issues.apache.org/bugzilla/show_bug.cgi?id=49582 --- Comment #3 from Mark Thomas 2010-07-12 11:59:54 EDT --- Specifying and empty list *should* override the one in the default web.xml. If that isn't the case, that is a bug that needs fixing. If so, please open a separate bug for that and it should get fixed for 7.0.1. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 Maven Artifacts
On 04/07/2010 10:57, Mark Thomas wrote: > On 04/07/2010 11:43, Gurkan Erdogdu wrote: >> Hi folks, >> >> Our project OpenWebBeans has a dependency on Tomcat 7 artifacts. We >> are going to >> release OWB. Where is the Tomcat 7 Beta Maven artifacts? > > They haven't been uploaded yet. I should be able to upload them later > this week. A bit later than I planned, the 7.0.0 artefacts have been uploaded. Not being a Maven user I don't know how long they'll take to sync. I'd guess up to 24 hours. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49582] Mapping a servlet to the root (/) doesn't work when accessing the root
https://issues.apache.org/bugzilla/show_bug.cgi?id=49582 --- Comment #4 from bozho 2010-07-12 13:36:41 EDT --- Sorry, my mistake. I tried , which is invalid according to the schema. So did it, instead. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49589] Tag handlers with constant attribute values are always reinitialized
https://issues.apache.org/bugzilla/show_bug.cgi?id=49589 --- Comment #1 from Jeremy Boynes 2010-07-12 21:33:02 EDT --- Created an attachment (id=25757) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25757) Test JSP -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49589] New: Tag handlers with constant attribute values are always reinitialized
https://issues.apache.org/bugzilla/show_bug.cgi?id=49589 Summary: Tag handlers with constant attribute values are always reinitialized Product: Tomcat 7 Version: trunk Platform: PC Status: NEW Severity: enhancement Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: jboy...@apache.org Tags such as the JSTL tag that have idempotent attribute values are being reinitialized before use. The specification allows the container to pool and reuse tags with the same attribute values, calling them multiple times without reinitializing the values. However, the code generated by Jasper always sets the attribute values after retrieving an instance from the pool even if they have constant values. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49589] Tag handlers with constant attribute values are always reinitialized
https://issues.apache.org/bugzilla/show_bug.cgi?id=49589
--- Comment #2 from Jeremy Boynes 2010-07-12 21:35:05 EDT
---
Created an attachment (id=25758)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25758)
Java source generated by Jasper ant task
Relevant snippet from end
// x:out
org.apache.taglibs.standard.tag.rt.xml.ExprTag _jspx_th_x_005fout_005f0 =
(org.apache.taglibs.standard.tag.rt.xml.ExprTag)
_005fjspx_005ftagPool_005fx_005fout_0026_005fselect_005fnobody.get(org.apache.taglibs.standard.tag.rt.xml.ExprTag.class);
_jspx_th_x_005fout_005f0.setPageContext(_jspx_page_context);
_jspx_th_x_005fout_005f0.setParent((javax.servlet.jsp.tagext.Tag)
_jspx_th_x_005fforEach_005f0);
//
/org/apache/taglibs/standard/tag/el/xml/TestForEachPerformance.jsp(24,67) name
= select type = java.lang.String reqTime = false required = true fragment =
false deferredValue = false expectedTypeName = null deferredMethod = false
methodSignature = null
_jspx_th_x_005fout_005f0.setSelect("y");
int _jspx_eval_x_005fout_005f0 = _jspx_th_x_005fout_005f0.doStartTag();
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] XPath support
On Jul 12, 2010, at 1:08 AM, Mark Thomas wrote: > On 12/07/2010 06:40, Jeremy Boynes wrote: >> Implementation seems to work but does not provide as much benefit as >> expected. Jasper tag pooling does not pool tags with the same attribute >> values so the select attribute is set every time causing recompilation. The >> time taken to iterate 1000 tags drops from around 2800ms to 1800ms. > > Providing the same attributes with the same values are present, Jasper > should be pooling the tags. There was a bug in this area [1] but it was > fixed some time ago. If this isn't the case then please open a Tomcat > bug and provide a test case. I opened 49589 [2] to illustrate this behaviour. Most of the issues related to 38197 discuss tags being invoked multiple times before release is invoked, which is actually what is desired here with the additional optimization that constant attributes like "select" on don't get reset. That would increase the complexity of the tag pooling though as it would need to be able to differentiate initialized instances. > >> To work around this I added a thread-local cache of compiled XPath >> expressions. This does reduce the initial time taken for the first few >> iterations but the time taken to evaluate the compiled expression grows from >> 500us to 2100us toward the end of the loop (measured with nanoTime() around >> the call to evaluate). There may be some issue with Xalan; the same >> behaviour is seen with Sun's JAXP implementation included in JDK1.6 (which >> is based on Xalan). > > Use of ThreadLocals in this way is almost certainly going to trigger > memory leaks on web application reload. I think it could be made to work but agree that it's a *bad idea* for a tag to be doing this and there has to be a better way. I'm going to ping Xalan about the increase in time taken as expressions are evaluated as I would assume I'm doing something silly. Thanks Jeremy [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=49589 > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49570] The CompressionFilter example should support HTTP proxies to cache gzipped content better by sending Vary: Accept-Encoding header
https://issues.apache.org/bugzilla/show_bug.cgi?id=49570
--- Comment #2 from Thai Ha 2010-07-12 23:39:11 EDT ---
The patch in SVN doesn't work for me because there is no method
HttpServletResponse.getHeader()
protected HttpServletResponse response = null;
response.addHeader("Content-Encoding", "gzip");
String vary = response.getHeader("Vary");
if (vary == null) {
// Add a new Vary header
response.setHeader("Vary", "Accept-Encoding");
} else if (vary.equals("*")) {
// No action required
} else {
// Merge into current header
response.setHeader("Vary", vary + ",Accept-Encoding");
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r963599 - in /tomcat/trunk: java/org/apache/catalina/startup/HostConfig.java webapps/docs/changelog.xml
Author: kfujino
Date: Tue Jul 13 04:44:25 2010
New Revision: 963599
URL: http://svn.apache.org/viewvc?rev=963599&view=rev
Log:
Avoid NullPointerException, when copyXML=true and META-INF/context.xml does not
exist.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java?rev=963599&r1=963598&r2=963599&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/HostConfig.java Tue Jul 13
04:44:25 2010
@@ -846,7 +846,7 @@ public class HostConfig
if (entry != null) {
xmlInWar = true;
}
-if (copyXML) {
+if (copyXML && xmlInWar) {
istream = jar.getInputStream(entry);
ostream =
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=963599&r1=963598&r2=963599&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Tue Jul 13 04:44:25 2010
@@ -29,6 +29,7 @@
Rainer Jung
Konstantin Kolinko
Peter Rossbach
+Keiichi Fujino
Changelog
@@ -140,6 +141,10 @@
Random to generate nonces. Also make the implementation class used user
configurable. (markt)
+
+Avoid NullPointerException, when copyXML=true and META-INF/context.xml
+does not exist. (kfujino)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
