Re: bindOnInit and maxConnections for AJP connectors
On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz ch...@christopherschultz.net wrote: Mark, I understand that a fix has already been applied, but... On 4/6/2011 7:16 AM, Mark Thomas wrote: I thought of two options for issue 3: a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket and don't recycle it until the socket is closed. - Increases memory requirements. - Fixes issue 3 - Retains current request processing order. b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue What about a third option that is essentially (a) except that you trim the input buffer and discard the already-processed request(s) from it. The input buffer stays bound to the request and continues where it left-off when another request processor becomes available. That would maintain scheduling fairness and hopefully not require much in the way of memory usage. Since pipelining requests with entities is not a good idea, the chances of getting a large amount of data in the input buffer is relatively low. There's also a limit on the size of that buffer, too. Would that still represent too large of a memory requirement? The input buffer is 8k by default (max header size), so this could be significant with a large maxConnections. Pruning the buffers to retain only required space would generate a lot of garbage, so probably not a good option either. If the fairness becomes a practical problem, reducing maxKeepAliveRequests (100 by default) would force pipelining clients to the back of the queue regularly. We could go with option a) and use the processor cache size to bound the 'memory vs fairness tradeoff' - e.g. place pipeline connections back on the queue, but add their processor to a 'borrowed' queue without recycling. If the total processor limit is met and the recycled processor cache is exhausted, then a borrowed processor is recalled, the pipelined connection drained, and the processor then made available for use. The default processorCache is 200 (matches maxThreads), so default behaviour would be unfair. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
processorCache for APR connector is unlimited
The Http11Protocol and Http11NioProtocol connectors set processorCache to 200 by default, which matches the docs ([2]). The Http11AprProtocol sets it to -1 (unlimited) - is this intentional/desired or accidental? This appears to have been introduced in [1] during some refactoring by Mladen. [1] http://svn.apache.org/viewvc?view=revisionrevision=991359 [2] http://tomcat.apache.org/tomcat-7.0-doc/config/http.html cheers tim - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51042] New: HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 Summary: HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call. Product: Tomcat 7 Version: 7.0.11 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: j...@silbergrau.com When my web application has a HttpSessionListener configured in its web.xml, then that classes sessionCreated() is called when a user is assigned a new session. However, that method is *also* called when that user authenticates itself and the session is assigned a new ID (whether or not this is actually a new session can be disputed, but that's not the point of this bug). When the session is removed (due to a timeout, for example), then a single sessionDestroyed() call is executed. When the HttpSessionListener manages some kind of external resource, this behaviour leads to a resource leak, because sessionCreated() is called twice, while sessionRemoved() is only called once! I'm aware of the reason for changing the session ID and (somehow) understand why sessionCreated() is called again (after all there's a new session ID), but there must be *some* way for the SessionListener to be notified that the old session no longer exists. The same behaviour is seen in Tomcat 6.0 (and probably 5.5 as well, but I didn't test that). -- 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 51042] HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 --- Comment #1 from Joachim Sauer j...@silbergrau.com 2011-04-08 05:56:27 EDT --- By the way, the change that introduced this issue was the fix for bug #47774. -- 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 51042] HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 --- Comment #2 from Joachim Sauer j...@silbergrau.com 2011-04-08 05:57:14 EDT --- (In reply to comment #1) By the way, the change that introduced this issue was the fix for bug #47774. Oops, wrong bug number: #45255 is the correct one! -- 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: bindOnInit and maxConnections for AJP connectors
On 4/8/2011 2:50 AM, Tim Whittington wrote: The input buffer is 8k by default (max header size), so this could be significant with a large maxConnections. significant in 1990 maybe :) even with 20k connections, this be a drop in the ocean compared to memory usage for today's applications - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
Konatantin, On 4/7/2011 9:08 PM, Konstantin Kolinko wrote: 2011/4/8 schu...@apache.org: Author: schultz Date: Fri Apr 8 00:41:29 2011 New Revision: 1090072 URL: http://svn.apache.org/viewvc?rev=1090072view=rev Log: Updated. Modified: tomcat/tc6.0.x/trunk/STATUS.txt + +* Backport exception logging from revision 1090022 + http://svn.apache.org/viewvc?view=revisionrevision=1090022 + +1: schultz + -1: Actually it might be not as useful as it might seem. Deletion failures are reported as boolean return value from delete(), not as an exception. It makes sense to backport the relevant change to delete() calls as well, http://svn.apache.org/viewvc?view=revisionrevision=1073393 I'm not sure what you mean. The code actually compiles without any try/catch block there at all, since none of the methods called actually throw IOException. I suspect the catch-all block was there to prevent any really weird things from happening and propagating up the stack. The code comment says delete at much as possible implying that there is a lot of work to do which might be interrupted, but there is only one file to delete in each case: it either does or does not succeed. What change were you suggesting that I actually backport? The replacement of the duplicate code with a method call? -chris signature.asc Description: OpenPGP digital signature
Re: bindOnInit and maxConnections for AJP connectors
Tim, On 4/8/2011 4:50 AM, Tim Whittington wrote: On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz ch...@christopherschultz.net wrote: Mark, I understand that a fix has already been applied, but... On 4/6/2011 7:16 AM, Mark Thomas wrote: I thought of two options for issue 3: a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket and don't recycle it until the socket is closed. - Increases memory requirements. - Fixes issue 3 - Retains current request processing order. b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue What about a third option that is essentially (a) except that you trim the input buffer and discard the already-processed request(s) from it. The input buffer stays bound to the request and continues where it left-off when another request processor becomes available. That would maintain scheduling fairness and hopefully not require much in the way of memory usage. Since pipelining requests with entities is not a good idea, the chances of getting a large amount of data in the input buffer is relatively low. There's also a limit on the size of that buffer, too. Would that still represent too large of a memory requirement? The input buffer is 8k by default (max header size), so this could be significant with a large maxConnections. Pruning the buffers to retain only required space would generate a lot of garbage, so probably not a good option either. Are those buffers ever discarded? I guess it comes down to whether the 8k buffer belongs to the connection or to the request. It looks like the bug arises from the buffer being treated like it belongs to the request when it really belongs to the connection. I agree, switching to a request-owned buffer strategy would certainly increase the memory footprint since you'd need a buffer for each pending request (which may be quite high when using NIO an/or async). Thanks for clarifying that. If the fairness becomes a practical problem, reducing maxKeepAliveRequests (100 by default) would force pipelining clients to the back of the queue regularly. How would this work, though? If the bug under discussion arises from a connection essentially disconnecting one of these buffers from the request whence it came, doesn't re-queuing the request re-introduce the bug? -chris signature.asc Description: OpenPGP digital signature
Re: bindOnInit and maxConnections for AJP connectors
On 4/6/2011 3:51 PM, Tim Whittington wrote: b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue +1 It's an unfair scheduling, but given issue 2 that's a fairly moot point with the BIO connector. sounds reasonable. this is how we used to do it (we may still) in APR. it avoids one context switch not needed, and in NIO we could do this too, since we can even check the network buffer without blocking best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: bindOnInit and maxConnections for AJP connectors
Are those buffers ever discarded? I guess it comes down to whether the 8k buffer belongs to the connection or to the request. It looks like the bug arises from the buffer being treated like it belongs to the request when it really belongs to the connection. I agree, switching to a request-owned buffer strategy would certainly increase the memory footprint since you'd need a buffer for each pending request (which may be quite high when using NIO an/or async). Thanks for clarifying that. If the fairness becomes a practical problem, reducing maxKeepAliveRequests (100 by default) would force pipelining clients to the back of the queue regularly. How would this work, though? If the bug under discussion arises from a connection essentially disconnecting one of these buffers from the request whence it came, doesn't re-queuing the request re-introduce the bug? I was thinking of closing the connection (as maxKeepAliveRequests) does now. The re-connect would go to the back of the queue. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
2011/4/8 Christopher Schultz ch...@christopherschultz.net: Konatantin, On 4/7/2011 9:08 PM, Konstantin Kolinko wrote: 2011/4/8 schu...@apache.org: Author: schultz Date: Fri Apr 8 00:41:29 2011 New Revision: 1090072 URL: http://svn.apache.org/viewvc?rev=1090072view=rev Log: Updated. Modified: tomcat/tc6.0.x/trunk/STATUS.txt + +* Backport exception logging from revision 1090022 + http://svn.apache.org/viewvc?view=revisionrevision=1090022 + +1: schultz + -1: Actually it might be not as useful as it might seem. Deletion failures are reported as boolean return value from delete(), not as an exception. It makes sense to backport the relevant change to delete() calls as well, http://svn.apache.org/viewvc?view=revisionrevision=1073393 I'm not sure what you mean. The code actually compiles without any try/catch block there at all, since none of the methods called actually throw IOException. I suspect the catch-all block was there to prevent any really weird things from happening and propagating up the stack. The code comment says delete at much as possible implying that there is a lot of work to do which might be interrupted, but there is only one file to delete in each case: it either does or does not succeed. What change were you suggesting that I actually backport? This one (combined with yours): http://svn.apache.org/viewvc?view=revisionrevision=1073393 but there is only one file to delete in each case: Interesting. So it never deletes inner classes... (but nobody reported any problems) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1090441 - /tomcat/trunk/webapps/docs/changelog.xml
Author: slaurent Date: Fri Apr 8 20:51:37 2011 New Revision: 1090441 URL: http://svn.apache.org/viewvc?rev=1090441view=rev Log: changelog for r1090003 / StuckThreadDetectionValve Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1090441r1=1090440r2=1090441view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Fri Apr 8 20:51:37 2011 @@ -56,6 +56,11 @@ print not just the value of the first header, but of the all of them, separated by commas. (kkolinko) /update + add +bug50306/bug: New StuckThreadDetectionValve to detect requests that take a +long time to process, which might indicate that their processing threads are +stuck. (slaurent) + /add /changelog /subsection subsection name=Coyote - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1090441 - /tomcat/trunk/webapps/docs/changelog.xml
2011/4/9 slaur...@apache.org: Author: slaurent Date: Fri Apr 8 20:51:37 2011 New Revision: 1090441 URL: http://svn.apache.org/viewvc?rev=1090441view=rev Log: changelog for r1090003 / StuckThreadDetectionValve Modified: tomcat/trunk/webapps/docs/changelog.xml + add + bug50306/bug: New StuckThreadDetectionValve to detect requests that take a + long time to process, which might indicate that their processing threads are + stuck. (slaurent) Based on a patch provided by TomLu. ? + /add /changelog /subsection subsection name=Coyote 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: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
Konstantin, On 4/8/2011 3:56 PM, Konstantin Kolinko wrote: This one (combined with yours): http://svn.apache.org/viewvc?view=revisionrevision=1073393 Aah, I didn't realize that the code I was updating had actually just been written. but there is only one file to delete in each case: Interesting. So it never deletes inner classes... (but nobody reported any problems) That appears to be the case. I suppose we could try to delete JavaClassFileName.java, JavaClassFileName.class, JavaClassFileName$*.java, and JavaClassFileName$*.class, which ought to take care of everything and still be somewhat safe... just slower performance since we'd have to do a (single) directory-scan to get the file list. -chris signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 34801] PATCH: CGIServlet does not terminate child after a timeout
https://issues.apache.org/bugzilla/show_bug.cgi?id=34801 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Mark Thomas ma...@apache.org 2011-04-08 17:51:10 EDT --- Closing this as fixed without applying the watchdog changes. -- 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 34805] warn about invalid security constraint url patterns
https://issues.apache.org/bugzilla/show_bug.cgi?id=34805 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Mark Thomas ma...@apache.org 2011-04-08 17:51:48 EDT --- This was fixed for all currently supported Tomcat versions some time ago. -- 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 34868] allow to register a trust store for a session that becomes effective before CLIENT-CERT auth is executed on requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=34868 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #11 from Mark Thomas ma...@apache.org 2011-04-08 17:52:28 EDT --- Per session trust managers can't possibly work since the SSL connection has to be established before the client can send any data that would identify the session in which to look for the trust manager. I am therefore resolving this as WONTFIX. However, it is worth noting the Tomcat 7 (as a result of fixing bug 48208) now supports custom trust managers which should be sufficient to meet any requirement not meet by the standard trust manager. -- 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: r1090468 - /tomcat/trunk/webapps/docs/changelog.xml
Author: slaurent Date: Fri Apr 8 22:10:37 2011 New Revision: 1090468 URL: http://svn.apache.org/viewvc?rev=1090468view=rev Log: bug 50306: Detect stuck threads complement to changelog Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1090468r1=1090467r2=1090468view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Fri Apr 8 22:10:37 2011 @@ -59,7 +59,7 @@ add bug50306/bug: New StuckThreadDetectionValve to detect requests that take a long time to process, which might indicate that their processing threads are -stuck. (slaurent) +stuck. (slaurent, based on a patch provided by TomLu) /add /changelog /subsection - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1090441 - /tomcat/trunk/webapps/docs/changelog.xml
On 8 avr. 2011, at 22:58, Konstantin Kolinko wrote: + add +bug50306/bug: New StuckThreadDetectionValve to detect requests that take a +long time to process, which might indicate that their processing threads are +stuck. (slaurent) Based on a patch provided by TomLu. ? fixed. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1090470 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: slaurent Date: Fri Apr 8 22:12:47 2011 New Revision: 1090470 URL: http://svn.apache.org/viewvc?rev=1090470view=rev Log: proposed backport of bug 50306: Detect stuck threads 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=1090470r1=1090469r2=1090470view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 8 22:12:47 2011 @@ -201,3 +201,7 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?view=revisionrevision=1090022 +1: schultz -1: + +* Add StuckThreadDetectionValve + https://github.com/sylvainlaurent/tomcat60/commit/252334f958877221ecb2dc64ee0fd12bb77e360b + +1: slaurent - 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 (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 13 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 7.x, a web server implementing Java Servlet 3.0, ... 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: 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.3-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/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.3-SNAPSHOT.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.3-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:429: 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 org.apache.tools.ant.Task.perform(Task.java:347) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.Main.start(Main.java:180) at org.apache.tools.ant.Main.main(Main.java:268) Caused by: java.lang.ClassNotFoundException: com.google.common.collect.Lists at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at
