Re: Redirect to buffer strategy may not work properly on Tomcat 7.0.29
Hi Pedro, I've CC-ed Tomcat's team, so they can explain better what Tomcat does. On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos pedros...@gmail.com wrote: Hi Martin, I don't see how to wrap the request or the response can be useful here. Even if we decorate the container request to return its URI based on the page being rendered address it will not be enough because Servlet API does not allow us to change the composition of a response. i.e. we are not able to set on which request URI the encode method of the response will work on (Tomcat API allows such thing but I'd rather not use to it). I don't quite understand what you mean with the above. As far as I understood Mark he suggests to use HttpServletRequestWrapper which should return the proper base url when asked (#getRequestURI, #getPath, etc.) Thinking more about it now I don't see how this will help actually because this wrapper will be reachable only by Wicket code. To encode an URL Wicket calls HttpServletResponse#encodeURL(), note this is the *response*, and it has no reference from the response to the wrapped request, so Tomcat will be able to find and use only the original request. Wrapping the response and link it to it the wrapped request wont help because Tomcat wont be able to cast to our custom wrappers. I simply don't get why Tomcat added such validation in the encode method. To redirect the request to a buffered response is a very common strategy that has being saving tons of applications from double form submissions for instance rather than a weird web framework implementation like I read in the ticket. Do you know of another bigger web framework that uses this approach ? If you know please mention it in the ticket. This will be a stronger argument for Tomcat to not ignore this solution. It all started with a ticket by me in Tomcat's Bugzilla to normalize the absolute urls which are send in Location response header. This is the redirect url. Before the ticket Tomcat was sending urls like 'http://www.example.com/a/b/../c/d.html' and '..' in this url caused some problems in some cases, e.g. JMeter complained about it, and Chris Colman reported an issue with IE when using Tomcat virtual hosts. So now Tomcat normalizes the url to 'http://www.example.com/a/c/d.html' before sending it to the client. All good so far. The new problem is that Tomcat uses the normalization even in #encodeURL(), this method just encodes jsessionid if needed, even for relative urls. To decide whether the relative url is part of the current application Tomcat makes the url absolute and normalizes it. When Wicket starts rendering the rendering for PageB (from my first mail) it produces relative urls to PageB, but later Tomcat normalizes them against PageA and url like 'http://www.example.com/a/b/../../../../c/d.html' fails because there are too many '..'s. I hope the problem is more clear now. It looks like the response will not encode the session id to links and callbacks in the buffered pages in a deeper path from Tomcat 7.0.29 on. I'm OK with the way the Tomcat team worked around this issue. Who knows if they aren't only doing some good by preventing some session fixation attacks. They didn't workaround it yet. For now we discuss possible solutions for the next version. Pedro Santos Em 25/07/2012, às 16:42, Martin Grigorov escreveu: Hi, Please take a look at https://issues.apache.org/bugzilla/show_bug.cgi?id=53469. This issue describes a problem which prevents Wicket's default RenderStrategy - REDIRECT_TO_BUFFER. Basically the problem is: - PageA mounted at /mount/pageA is requested - the code uses setResponsePage(PageB.class) which is mounted at /deeper/mount/path/pageB - Wicket starts to render PageB (in the same request cycle) and for each url in the page it asks the web container to encode it (HttpServletResponse#encodeURL()) - here Tomcat 7.0.29+ tries to find whether the url to encode is part of the web app. To do this it makes the relative url passed by Wicket to absolute by using the HttpServletRequest's requestURI (i.e. /mount/pageA). This may get wrong because Wicket actually generates the urls against /deeper/mount/path/pageB Mark Thomas (Tomcat dev) suggests that Wicket could use HttpServletRequestWrapper which should return the correct requestURI depending on the current request cycle baseUrl. Any ideas and comments are welcome! -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 53601] tomcat7 build fails with jdk1.6
On 25/07/12 12:55, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=53601 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- You are wrong. 1). It is true that Tomcat trunk (aka Tomcat 8) builds only with jdk1.7. It is as intended. It is expected to implement the Servlet 3.1 specification. 2). Tomcat 7 builds with jdk1.6 and this status quo has not changed. Anyway your report noticeably lack of details. You should ask on the mailing list first, before playing around with Bugzilla. I thought I would step through the latest trunk BUILDING.TXT instructions because I haven't updated my sandbox for at least a month. Apache Ant(TM) version 1.8.2 compiled on December 3 2011 Trying the default build file: build.xml Buildfile: /home/brian/sandboxApache/tomcat8/trunk/build.xml Detected Java version: 1.6 in: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Detected OS: Linux compile: [javac] Compiling 307 source files to /home/brian/sandboxApache/tomcat8/trunk/output/classes [javac] javac: invalid target release: 1.7 [javac] Usage: javac options source files [javac] use -help for a list of possible options BUILD FAILED I wondered whether we still need to tell people how to get a JDK... if they haven't got one already, and aren't familiar with building complex projects, they probably shouldn't be encouraged to start building tomcat from the trunk! In the end, I thought the best compromise would be to just reference a couple of popular JDKs - we don't want to seem partisan, but equally don't want to get dragged into a debate about which is best. It might be helpful to list the JDKs that are used to build and test the production releases, but I don't know what they are. Here is the trivial change to avoid this kind of confusion for the moment! Index: BUILDING.txt === --- BUILDING.txt(revision 1366303) +++ BUILDING.txt(working copy) @@ -37,9 +37,10 @@ 1. If the JDK is already installed, skip to (2). - 2. Download a Java Development Kit (JDK) release (version 1.6.x or later) -from: - + 2. Download a Java Development Kit (JDK) release (version 1.7.x or later) +e.g. +http://openjdk.java.net/install/index.html +or http://www.oracle.com/technetwork/java/javase/downloads/index.html 3. Install the JDK according to the instructions included with the release. I hope my contribution is both simple and helpful. Brian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53610] New: dublicate connector in server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=53610 Priority: P2 Bug ID: 53610 Assignee: dev@tomcat.apache.org Summary: dublicate connector in server.xml Severity: normal Classification: Unclassified Reporter: denismitin...@googlemail.com Hardware: PC Status: NEW Version: 7.0.29 Component: Connectors Product: Tomcat 7 Created attachment 29119 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29119action=edit screen of server.xml Server.xml file contains two connector entities. It happens in this versions : apache-tomcat-7.0.29-windows-x64, apache-tomcat-7.0.27-windows-x64. thank you. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53610] dublicate connector in server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=53610 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Mark Thomas ma...@apache.org --- This is by design. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53610] dublicate connector in server.xml
https://issues.apache.org/bugzilla/show_bug.cgi?id=53610 --- Comment #2 from denis denismitin...@googlemail.com --- If it is by design, may be this design decision is documented elsewhere? Documentation of wiki https://confluence.atlassian.com/display/DOC/Configuring+Tomcat's+URI+encoding should be changed, to add note, that URIEncoding param should be added to the first connector. thanks for response -- 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: r1366354 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: rjung Date: Fri Jul 27 12:12:02 2012 New Revision: 1366354 URL: http://svn.apache.org/viewvc?rev=1366354view=rev Log: Vote, promote. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1366354r1=1366353r2=1366354view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Jul 27 12:12:02 2012 @@ -28,6 +28,20 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT: [ start all new proposals below, under PATCHES PROPOSED. ] +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 + ExpandWar.expand does not check the return value of File.mkdirs + Patch here: https://issues.apache.org/bugzilla/attachment.cgi?id=29050 + This is a similar fix to trunk (http://svn.apache.org/viewvc?view=revisionrevision=1359981) + and also includes checking of File.mkdirs() as mentioned in the bug. + +1: schultz, kkolinko, rjung + -1: + +* Fix conflict with CSRF protection filter and clustering + Cache needs to be serializable + http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/CsrfPreventionFilter.java?r1=1083987r2=1083986pathrev=1083987 + +1: markt, kkolinko, rjung + -1: + PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] @@ -144,20 +158,6 @@ PATCHES PROPOSED TO BACKPORT: +1: kfujino -1: -* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 - ExpandWar.expand does not check the return value of File.mkdirs - Patch here: https://issues.apache.org/bugzilla/attachment.cgi?id=29050 - This is a similar fix to trunk (http://svn.apache.org/viewvc?view=revisionrevision=1359981) - and also includes checking of File.mkdirs() as mentioned in the bug. - +1: schultz, kkolinko - -1: - -* Fix conflict with CSRF protection filter and clustering - Cache needs to be serializable - http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/CsrfPreventionFilter.java?r1=1083987r2=1083986pathrev=1083987 - +1: markt, kkolinko - -1: - PATCHES/ISSUES THAT ARE STALLED - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1366567 - in /tomcat/trunk: java/org/apache/catalina/tribes/group/ java/org/apache/catalina/tribes/group/interceptors/ java/org/apache/catalina/tribes/membership/ java/org/apache/juli/ ja
Author: markt
Date: Fri Jul 27 23:12:55 2012
New Revision: 1366567
URL: http://svn.apache.org/viewvc?rev=1366567view=rev
Log:
Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=53529
Improve the handling of InterruptedException
- Provide a specific message if thread was interrupted rather than the wait
timing out
- Remove unnecessary code
- Remove unnecessary attemps to clear the interrupt flag
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
tomcat/trunk/java/org/apache/juli/AsyncFileHandler.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
tomcat/trunk/java/org/apache/tomcat/util/threads/ThreadPoolExecutor.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java?rev=1366567r1=1366566r2=1366567view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/GroupChannel.java Fri
Jul 27 23:12:55 2012
@@ -689,7 +689,9 @@ public class GroupChannel extends Channe
Thread.sleep(sleepTime);
channel.heartbeat();
} catch ( InterruptedException x ) {
-interrupted();
+// Ignore. Probably triggered by a call to stopHeartbeat().
+// In the highly unlikely event it was a different trigger,
+// simply ignore it and continue.
} catch ( Exception x ) {
log.error(Unable to send heartbeat through Tribes
interceptor stack. Will try to sleep again.,x);
}//catch
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=1366567r1=1366566r2=1366567view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
Fri Jul 27 23:12:55 2012
@@ -225,19 +225,22 @@ public class NonBlockingCoordinator exte
coordMsgReceived.set(false);
fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_WAIT_FOR_MSG,this,Election, waiting
for request));
electionMutex.wait(waitForCoordMsgTimeout);
-}catch ( InterruptedException x ) {
-Thread.interrupted();
+} catch (InterruptedException x) {
+Thread.currentThread().interrupt();
}
-if ( suggestedviewId == null (!coordMsgReceived.get())) {
-//no message arrived, send the coord msg
-//fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_WAIT_FOR_MSG,this,Election, waiting
timed out.));
-//startElection(true);
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_ELECT_ABANDONED,this,Election
abandoned, waiting timed out.));
+String msg;
+if (suggestedviewId == null !coordMsgReceived.get()) {
+if (Thread.interrupted()) {
+msg = Election abandoned, waiting interrupted.;
+} else {
+msg = Election abandoned, waiting timed out.;
+}
} else {
-fireInterceptorEvent(new
CoordinationEvent(CoordinationEvent.EVT_ELECT_ABANDONED,this,Election
abandoned, received a message));
+msg = Election abandoned, received a message;
}
-}//end if
-
+fireInterceptorEvent(new CoordinationEvent(
+CoordinationEvent.EVT_ELECT_ABANDONED, this, msg));
+}
}
}
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1366567r1=1366566r2=1366567view=diff
==
---
[Bug 53529] Call interrupt() after InterruptedException instead interrupted()
https://issues.apache.org/bugzilla/show_bug.cgi?id=53529 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas ma...@apache.org --- Not one of these was a valid bug. There was scope to remove some unnecessary code and improve some log messages a little which is the only reason this wasn't closed as invalid. I have said this before and I'll say it again. Before reporting something as a bug because it looks like a typical bug pattern, please do the Tomcat committers the courtesy of actually analyzing the code to see if there really is a problem. The only issue that came close to the original bug report was: org\apache\catalina\tribes\group\interceptors\NonBlockingCoordinator.java line 228 For this issue there was a marginal benefit to re-setting the interrupt flag and clearing it later as it allowed a specific error message to be generated in the unlikely event that there was an interrupt. This has been fixed in trunk (for 8.0.x) and I see no need to back-port the change. The following were all unnecessary attempts to clear the interrupt flag and continue. The attempt is unnecessary since throwing InterruptedException clears the interrupt flag. I have fixed these in trunk but I see no need to back-port the changes. org\apache\catalina\tribes\group\GroupChannel.java line 692 org\apache\catalina\tribes\group\interceptors\TcpPingInterceptor.java line 173 org\apache\juli\AsyncFileHandler.java line 124 line 146 org\apache\tomcat\util\net\AprEndpoint.java line 640 org\apache\tomcat\util\net\NioBlockingSelector.java line 112 line 177 org\apache\tomcat\util\threads\ThreadPoolExecutor.java line 187 The following was an unnecessary attempt to catch InterruptedException when it is not thrown. This have been removed from trunk but I see no need to back-port the change. org\apache\catalina\tribes\membership\McastServiceImpl.java line 542 -- 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.0.29 startup time
On 25/07/2012 17:00, Mark Struberg wrote: Hi Lords and Ladies! I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 45s, 7.0.29 90s). I'm aware that 7.0.29 now does the scanning for ServletContainerInitializer even if version=2.5 is specified. But there shall no class scanning be performed if metadata-complete=true is set, right? Wrong. I don't like this but the intent of the Servlet 3.0 EG was: - ServletContainerInitializer cannot be disabled - If a ServletContainerInitializer is found, then class-scanning will take place Any ideas how we can ease the pain quickly? The only option I see is a custom (non-spec compliant) Tomcat specific feature that disables all of this. I know the Servlet-EG 'clarified' that only recently, but being an EG member myself I know exactly that this can be reverted if it only got 'recently clarified'. Nothing is set in stone until a final MR spec with an absolute binding wording got released. Mark, others, what about explaining the impact to the EG again and maybe they change their mind? Not a chance. Been there tried that. Failed. The intent of the EG was clear (within the EG) even if the expression of it wasn't. For the long run you might be interested in commons-classscan we do over at commons atm. The idea is to have all sorts of ASF projects (tomcat, OpenWebBeans, OpenEJB, MyFaces, BVal, OpenJPA, ...) register their needs upfront and do the scanning only once. But it will take a bit until we have something to show off I fear as most of us are under heavy load in other ASF projects as well. I have been keeping an eye on that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Redirect to buffer strategy may not work properly on Tomcat 7.0.29
On 27/07/2012 09:10, Martin Grigorov wrote: On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos pedros...@gmail.com wrote: Hi Martin, I don't see how to wrap the request or the response can be useful here. Even if we decorate the container request to return its URI based on the page being rendered address it will not be enough because Servlet API does not allow us to change the composition of a response. i.e. we are not able to set on which request URI the encode method of the response will work on (Tomcat API allows such thing but I'd rather not use to it). My bad. I was thinking of using some methods that were added early in the Servlet 3.0 development cycle that were later removed. Wrapping isn't going to help here unless Wicket implements its own encode methods in the wrapper (which instinctively I don't like as a solution). I simply don't get why Tomcat added such validation in the encode method. The validation (that any URL must part of the web application for the session ID to be added) has been present as far back as I can remember. That it didn't work correctly for relative URLs was a bug that only recently surfaced. In short, Tomcat should not be exposing the session ID to URLs outside of the web application. The new problem is that Tomcat uses the normalization even in #encodeURL(), this method just encodes jsessionid if needed, even for relative urls. To decide whether the relative url is part of the current application Tomcat makes the url absolute and normalizes it. When Wicket starts rendering the rendering for PageB (from my first mail) it produces relative urls to PageB, but later Tomcat normalizes them against PageA and url like 'http://www.example.com/a/b/../../../../c/d.html' fails because there are too many '..'s. I hope the problem is more clear now. It looks like the response will not encode the session id to links and callbacks in the buffered pages in a deeper path from Tomcat 7.0.29 on. I'm OK with the way the Tomcat team worked around this issue. Who knows if they aren't only doing some good by preventing some session fixation attacks. They didn't workaround it yet. For now we discuss possible solutions for the next version. At the moment, I don't see a way for Tomcat to: - retain the check that a URL is part of the web application before adding the session ID; and - correctly support the passing of relative URLs to encodeURL() that are relative to something other than the currently processing request. I am open to suggestions. On a separate note, I intend to request some clarification on the handling of relative URLs and encodeURL() from the EG. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tomcat 7.0.29 startup time
On 28/07/2012 00:25, Mark Thomas wrote: On 25/07/2012 17:00, Mark Struberg wrote: Hi Lords and Ladies! I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 45s, 7.0.29 90s). I'm aware that 7.0.29 now does the scanning for ServletContainerInitializer even if version=2.5 is specified. But there shall no class scanning be performed if metadata-complete=true is set, right? Wrong. I don't like this but the intent of the Servlet 3.0 EG was: - ServletContainerInitializer cannot be disabled - If a ServletContainerInitializer is found, then class-scanning will take place Any ideas how we can ease the pain quickly? The only option I see is a custom (non-spec compliant) Tomcat specific feature that disables all of this. Ah. See the latest developments on http://java.net/jira/browse/SERVLET_SPEC-36 Using an absolute ordering that specifies no fragments along with metadata-complete=true should do the trick. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-validate-eoln (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate-eoln 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-trunk-validate-eoln : 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-validate-eoln/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/gump_work/build_tomcat-trunk_tomcat-trunk-validate-eoln.html Work Name: build_tomcat-trunk_tomcat-trunk-validate-eoln (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml validate-eoln [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/classes [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/bin [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/conf [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/lib [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/logs [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/webapps compile-prepare: [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/startup [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/webapps/docs validate-eoln: [javac] Compiling 1 source file to /srv/gump/public/workspace/tomcat-trunk/output/classes [javac] javac: invalid target release: 1.7 [javac] Usage: javac options source files [javac] use -help for a list of possible options BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:523: Compile failed; see the compiler error output for details. Total time: 1 second - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1328072012, vmgump.apache.org:vmgump:1328072012 Gump E-mail Identifier (unique within run) #6. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-dbcp (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-dbcp has an issue affecting its community integration. This issue affects 3 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-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - 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-dbcp/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Made directory [/srv/gump/public/workspace/tomcat-trunk/tomcat-deps] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-dbcp/gump_work/build_tomcat-trunk_tomcat-trunk-dbcp.html Work Name: build_tomcat-trunk_tomcat-trunk-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-28072012.jar -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps build-tomcat-dbcp [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp build-manifests: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/manifests [copy] Copying 12 files to /srv/gump/public/workspace/tomcat-trunk/output/manifests build-tomcat-dbcp: [copy] Copying 70 files to /srv/gump/public/workspace/tomcat-trunk/tomcat-deps [patch] patching file src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java [patch] Hunk #1 succeeded at 661 (offset -113 lines). [patch] patching file src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java [patch] patching file src/java/org/apache/commons/dbcp/DelegatingResultSet.java [patch] Hunk #1 succeeded at 1079 (offset -195 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDataSource.java [patch] Hunk #1 succeeded at 437 (offset -52 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingConnection.java [patch] Hunk #1 succeeded at 678 (offset -126 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDriver.java [patch] Hunk #1 succeeded at 497 (offset -4 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingStatement.java [patch] Hunk #1 succeeded at 484 (offset -45 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java [patch] Hunk #1 succeeded at 1204 (offset -173 lines). [patch] patching file src/java/org/apache/commons/dbcp/BasicDataSource.java [patch] Hunk #1 succeeded at 28 with fuzz 1. [patch] Hunk #2 succeeded at 1782 (offset -19 lines). [patch] patching file src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java [patch] Hunk #1 succeeded at 887 (offset -1 lines). [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/src/java/org/apache/tomcat/dbcp [move] Moving 75 files to /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/src/java/org/apache/tomcat/dbcp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/classes [javac] Compiling 66 source files to
[GUMP@vmgump]: Project tomcat-tc7.0.x-validate (in module tomcat-7.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc7.0.x-validate 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-validate : 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-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-validate/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-validate.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-validate (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-28072012.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-28072012.jar:/srv/gump/public/workspace/junit/dist/junit-28072012.jar:/srv/gump /public/workspace/junit/dist/junit-dep-28072012.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-*[0-9T].jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-28072012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-28072012.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-28072012.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-28072012-dep.jar - download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-7.0.x/output/res/checkstyle BUILD FAILED /srv/gump/public/workspace/tomcat-7.0.x/build.xml:450: Could not create type checkstyle due to java.lang.NoClassDefFoundError: com/google/common/collect/Lists at com.puppycrawl.tools.checkstyle.CheckStyleTask.init(CheckStyleTask.java:78) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.apache.tools.ant.AntTypeDefinition.innerCreateAndSet(AntTypeDefinition.java:328) at org.apache.tools.ant.AntTypeDefinition.createAndSet(AntTypeDefinition.java:274) at org.apache.tools.ant.AntTypeDefinition.icreate(AntTypeDefinition.java:219) at org.apache.tools.ant.AntTypeDefinition.create(AntTypeDefinition.java:206) at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:286) at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:264) at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:417) at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163) at
[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate 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-trunk-validate : 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-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-28072012.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-28072012.jar:/srv/gump/public/workspace/junit/dist/junit-28072012.jar:/srv/gump /public/workspace/junit/dist/junit-dep-28072012.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-*[0-9T].jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-28072012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-28072012.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-28072012.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-28072012-dep.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:461: Could not create type checkstyle due to java.lang.NoClassDefFoundError: com/google/common/collect/Lists at com.puppycrawl.tools.checkstyle.CheckStyleTask.init(CheckStyleTask.java:78) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.apache.tools.ant.AntTypeDefinition.innerCreateAndSet(AntTypeDefinition.java:328) at org.apache.tools.ant.AntTypeDefinition.createAndSet(AntTypeDefinition.java:274) at org.apache.tools.ant.AntTypeDefinition.icreate(AntTypeDefinition.java:219) at org.apache.tools.ant.AntTypeDefinition.create(AntTypeDefinition.java:206) at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:286) at org.apache.tools.ant.ComponentHelper.createComponent(ComponentHelper.java:264) at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:417) at
