svn commit: r1332541 - /tomcat/maven-plugin/trunk/pom.xml
Author: olamy
Date: Tue May 1 07:14:43 2012
New Revision: 1332541
URL: http://svn.apache.org/viewvc?rev=1332541&view=rev
Log:
compiler plugin 2.4 which is faster for multi modules
Modified:
tomcat/maven-plugin/trunk/pom.xml
Modified: tomcat/maven-plugin/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1332541&r1=1332540&r2=1332541&view=diff
==
--- tomcat/maven-plugin/trunk/pom.xml (original)
+++ tomcat/maven-plugin/trunk/pom.xml Tue May 1 07:14:43 2012
@@ -508,7 +508,7 @@
maven-compiler-plugin
- 2.3.2
+ 2.4
${project.build.sourceEncoding}
${maven.compiler.source}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53169] New: [patch] don't do chunking with Connection: close
https://issues.apache.org/bugzilla/show_bug.cgi?id=53169 Priority: P2 Bug ID: 53169 Assignee: dev@tomcat.apache.org Summary: [patch] don't do chunking with Connection: close Severity: minor Classification: Unclassified OS: All Reporter: kus...@gmx.net Hardware: All Status: NEW Version: trunk Component: Catalina Product: Tomcat 7 Created attachment 28702 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28702&action=edit patch against trunk The attached patch disables chunking on if there is a Connection: close header, we're on HTTP 1.1 and there's no Content-Length header. This helps to implement Server-Sent Events [1]. Server-Sent Event are conceptually similar to the forever streaming iframe in the sense that there's an "infinite" response from the server that always gets updated. But they're easier to use and with less issues. They are also easier to use than WebSockets if you don't need a back channel. The specification reccoments to disable chunking. Jetty implements the same behavior, when there's a Connection: close header it doesn't do chunking. The following discussion [2] leads me to believe that patches would be welcome. The patch comes with unit tests that verify that there is still chunking happending when there is no Connection: close header. [1] http://dev.w3.org/html5/eventsource/#notes [2] http://tomcat.10.n6.nabble.com/How-to-disable-chunked-encoding-for-the-Http11NioProtocol-connector-td2038448.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53171] New: Deadlock under Java 7 / DefaultInstanceManager
https://issues.apache.org/bugzilla/show_bug.cgi?id=53171 Priority: P2 Bug ID: 53171 Assignee: dev@tomcat.apache.org Summary: Deadlock under Java 7 / DefaultInstanceManager Severity: normal Classification: Unclassified OS: Linux Reporter: al.l...@gmx.de Hardware: PC Status: NEW Version: 7.0.27 Component: Catalina Product: Tomcat 7 Created attachment 28703 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28703&action=edit Changing the Hashmap by Collections.synchonizedMap() Not sure if it is java 7 related, but I had repeatetly that deadlock when I got the srver under some load. A simple replacement of the HashMap by a synchonized one did help (patch attached); but I dont know if that is a good solution as I dont get the idea of the AnnotationCache. http-apr-80-exec-348" daemon prio=10 tid=0x7f4f64da9000 nid=0x6306 waiting for monitor entry [0x7f4f46cd7000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCache(DefaultInstanceManager.java:256) - waiting to lock <0x0007063b3d90> (a java.util.WeakHashMap) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:143) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137) at org.apache.jsp.templates.web.templates.s2.inc_005fcategory_jsp._jspx_meth_ox_005fifexists_005f1(inc_005fcategory_jsp.java:708) at org.apache.jsp.templates.web.templates.s2.inc_005fcategory_jsp._jspx_meth_ox_005frepeat_005f0(inc_005fcategory_jsp.java:118) at org.apache.jsp.templates.web.templates.s2.inc_005fcategory_jsp._jspService(inc_005fcategory_jsp.java:70) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53173] New: maxConnections feature hangs the system
https://issues.apache.org/bugzilla/show_bug.cgi?id=53173 Priority: P2 Bug ID: 53173 Assignee: dev@tomcat.apache.org Summary: maxConnections feature hangs the system Severity: normal Classification: Unclassified Reporter: fha...@apache.org Hardware: PC Status: NEW Version: 7.0.27 Component: Connectors Product: Tomcat 7 Created attachment 28704 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28704&action=edit fix missing count down for maxConnections latch We've run into a scenario where the JIO Acceptor thread hangs as connections are not counted down properly. Thread dump yields "http-bio-8080-Acceptor-0" daemon prio=3 tid=0x nid=0xXX waiting on condition [0x..0x] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x> (a org.apache.tomcat.util.threads.LimitLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:99) at org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:660) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210) at java.lang.Thread.run(Thread.java:619) This, as you may imagine, is a fairly hard use case to reproduce into a simple test case. The easiest way to reproduce it is to create the following configuration This reproduces one test case, where the state machine is not taking into account that connections may be rejected by the queue, but it doesn't count down the latch. I'm attaching a patch to fix this specific use case, but it may not be a complete fix. As a workaround, the patch also introduces the maxConnections="-1" configuration that disables the usage of maxConnections. The -1 setting is important to give administrator a workaround while the other edge cases are tracked down. I have not been able to reproduce this error with NIO connector. There is one more place in the JioEndpoint that requires handling of RejectedExecutionException in the public boolean processSocketAsync(SocketWrapper socket,SocketStatus status) This is currently unhandled. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53174] New: JIO default maxConnections is not a good default
https://issues.apache.org/bugzilla/show_bug.cgi?id=53174 Priority: P2 Bug ID: 53174 Assignee: dev@tomcat.apache.org Summary: JIO default maxConnections is not a good default Severity: normal Classification: Unclassified Reporter: fha...@apache.org Hardware: PC Status: NEW Version: 7.0.27 Component: Connectors Product: Tomcat 7 http://svn.apache.org/viewvc?view=revision&revision=1099855 This feature automatically sets maxConnections to maxThreads. It has a negative effect for the following reasons 1. It completely changes behavior from Tomcat 6 to 7, and unless one reads the fine print, one will never find out 2. In servlet 3.0, with the introduction of async servlets, there is a way to keep a connection open without having a worker thread associated with it. For case 2. the system SHOULD be able to handle this type of usage through its default configuration. Reverting this fix, and correcting the documentation has no foreseeable impact on systems that get upgraded with the next release of Tomcat -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53174] JIO default maxConnections is not a good default
https://issues.apache.org/bugzilla/show_bug.cgi?id=53174 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Read the following for background: http://tomcat.markmail.org/thread/wmirgjskvkm4x52k re point 1 - r1099855 should ensure that the behaviour is the same for both Tomcat 6 and Tomcat 7. re point 2 - That is true for write but not true for read. With maxConnections > maxThreads and blocking IO there is always the risk that a connection with data to read is unable to acquire a thread while all threads are tied up by connections without data to read. Reverting the fix has significant impact since it opens up the risk of problems as described in the thread from a year ago. With the increasing move towards async, there is an increasinglg strong argument for making NIO rather than BIO the default and potentially going as far as dropping the BIO connector all together but that is a debate that belongs on the dev list not on this issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53174] JIO default maxConnections is not a good default
https://issues.apache.org/bugzilla/show_bug.cgi?id=53174 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Filip Hanik --- (In reply to comment #1) > > With the increasing move towards async, there is an increasinglg strong > argument for making NIO rather than BIO the default and potentially going as > far as dropping the BIO connector all together but that is a debate that > belongs on the dev list not on this issue. Agreed. -- You are receiving this mail because: You are the assignee for the bug.
Re: Duplicate String values
Konstantin, On 4/28/12 8:58 PM, Konstantin Kolinko wrote: > 2012/4/27 Christopher Schultz : >> All, >> >> I've been doing some memory profiling on my webapp to see where I can >> reduce our memory footprint a bit by combining equivalent objects. >> YourKit has some nice utilities to look for duplicate objects -- >> especially Strings. >> >> I can see that the string "java.lang.String" has lots of duplicates. >> Many of the ones I've inspected so far can be traced-back to >> catalina.mbeans.MBeanUtils and the registry of MBeans that it contains. >> >> Would anyone object to using String-interning to share copies of class >> names for MBeans? I could even restrict such interning to Strings that >> start with "java.lang" since those are probably the most-used ones, and >> those strings are probably already interned by all the RTTI >> infrastructure in the JVM anyway. > > I think that the string returned by class.getName() as well as field > and method names should be already interned by JVM. > > So instead of String.intern() it should be possible to call class.getName(). > :/ That's what I would have expected, but I can see logs of duplicate String values (like "java.lang.String" for instance), many linked from JMX beans. I haven't looked at the code, but I'll bet the string values from directly from the XML files and aren't resolved against actually Class objects ... that would improve performance a bit during deployment. > I am OK with your proposal, but I do not expect much savings from > getting rid of those duplicates. Does YouKit show some estimates? It did, but I closed it long ago so I'll have to re-check. IIRC, it was a couple of MiB. Of course, it's not feasible to check 100% of them because there were so many copies. I can hack a bit at Tomcat and see what percentage of them disappear. Then I'll know whether such a change in Tomcat actually has a meaningful impact. Thanks, -chris signature.asc Description: OpenPGP digital signature
Problem in WebSocket
Hi All, I am trying to use Chat example of WebSocket given in Tomcat version 7.0.27. Problem I faced are here. 1) After opening the web socket it closes the socket automatically after 20 sec. I want connection open until Guest (i.e. user) explicitly closes it. 2) Second thing is that It broad casts the message to all users but what i want is to send message to a specific group of people. Is there any method to send message to specific group.?? I checked API for WebSocket but there is no method for multicast. Kindly help me I have very short time to implement it. Thanks.. -- *Regards, * *Muhammad Umar Farooq* *Student **BIT* | SEECS, NUST * *
Re: Problem in WebSocket
On 01/05/2012 19:27, umar farooq wrote: > Hi All, >I am trying to use Chat example of WebSocket given in Tomcat version > 7.0.27. Problem I faced are here. > > 1) After opening the web socket it closes the socket automatically after 20 > sec. I want connection open until Guest (i.e. user) explicitly closes it. Correct. Currently it uses the keep-alive timeout for the socket. Extend the timeout or use ping messages to keep the channel open. > 2) Second thing is that It broad casts the message to all users but what i > want is to send message to a specific group of people. No it doesn't. Messages are sent to single connections. > Is there any method to send message to specific group.?? No. > I checked API for WebSocket but there is no method for multicast. Correct. It is an application concern to maintain the groups it is interested in and send messages to members as required. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem in WebSocket
I got it. I will make my application to handle groups. but how can I increase keep alive time..?? to be specific .. what steps do I need to follow..? On 5/1/12, Mark Thomas wrote: > On 01/05/2012 19:27, umar farooq wrote: >> Hi All, >>I am trying to use Chat example of WebSocket given in Tomcat >> version >> 7.0.27. Problem I faced are here. >> >> 1) After opening the web socket it closes the socket automatically after >> 20 >> sec. I want connection open until Guest (i.e. user) explicitly closes it. > Correct. Currently it uses the keep-alive timeout for the socket. Extend > the timeout or use ping messages to keep the channel open. > >> 2) Second thing is that It broad casts the message to all users but what >> i >> want is to send message to a specific group of people. > No it doesn't. Messages are sent to single connections. > >> Is there any method to send message to specific group.?? > No. > >> I checked API for WebSocket but there is no method for multicast. > Correct. It is an application concern to maintain the groups it is > interested in and send messages to members as required. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- *Regards, * *Muhammad Umar Farooq* *Student **BIT* | SEECS, NUST * * - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem in WebSocket
On 01/05/2012 20:43, umar farooq wrote: > I got it. I will make my application to handle groups. but how can I > increase keep alive time..?? to be specific .. what steps do I need to > follow..? That would be a question for the users mailing list. Mark > > On 5/1/12, Mark Thomas wrote: >> On 01/05/2012 19:27, umar farooq wrote: >>> Hi All, >>>I am trying to use Chat example of WebSocket given in Tomcat >>> version >>> 7.0.27. Problem I faced are here. >>> >>> 1) After opening the web socket it closes the socket automatically after >>> 20 >>> sec. I want connection open until Guest (i.e. user) explicitly closes it. >> Correct. Currently it uses the keep-alive timeout for the socket. Extend >> the timeout or use ping messages to keep the channel open. >> >>> 2) Second thing is that It broad casts the message to all users but what >>> i >>> want is to send message to a specific group of people. >> No it doesn't. Messages are sent to single connections. >> >>> Is there any method to send message to specific group.?? >> No. >> >>> I checked API for WebSocket but there is no method for multicast. >> Correct. It is an application concern to maintain the groups it is >> interested in and send messages to members as required. >> >> Mark >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc7.0.x-test (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-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-7.0.x/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build) Work ended in a state of : Failed Elapsed: 21 mins 56 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 -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-02052012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-02052012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-02052012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-02052012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -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-7.0.x/tomcat-deps/tomcat-dbcp-02052012.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-02052012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-02052012.jar:/srv/gump/ public/workspace/junit/dist/junit-02052012.jar - [junit] May 2, 2012 4:56:59
[GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 22 mins 25 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 -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-02052012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-02052012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-02052012-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-02052012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dtest.accesslog=true -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-02052012.jar test [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/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/outp ut/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.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:/srv/gump/packages/eclipse/plugins/org .eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-02052012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-da
