svn commit: r1705231 - /tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
Author: markt
Date: Fri Sep 25 07:13:25 2015
New Revision: 1705231
URL: http://svn.apache.org/viewvc?rev=1705231&view=rev
Log:
Provide state info if tests fails (it failed on Gump but I have no idea why)
Modified:
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
Modified:
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java?rev=1705231&r1=1705230&r2=1705231&view=diff
==
---
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
(original)
+++
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
Fri Sep 25 07:13:25 2015
@@ -33,17 +33,19 @@ public class TestSecretKeyCredentialHand
for (String digest : ALGORITHMS) {
for (int saltLength = 1; saltLength < 20; saltLength++) {
for (int iterations = 1; iterations < 1; iterations +=
1000)
-doTest(digest, saltLength, iterations);
+doTest(digest, saltLength, iterations);
}
}
}
-private void doTest(String digest, int saltLength, int iterations) throws
NoSuchAlgorithmException {
+private void doTest(String digest, int saltLength, int iterations)
+throws NoSuchAlgorithmException {
SecretKeyCredentialHandler pbech = new SecretKeyCredentialHandler();
pbech.setAlgorithm(digest);
pbech.setIterations(iterations);
pbech.setSaltLength(saltLength);
String storedCredential = pbech.mutate(PWD);
-Assert.assertTrue(pbech.matches(PWD, storedCredential));
+Assert.assertTrue("[" + digest + "] [" + saltLength + "] [" +
iterations + "] [" + PWD +
+"] [" + storedCredential +"]", pbech.matches(PWD,
storedCredential));
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1705232 - in /tomcat/tc8.0.x/trunk: ./ test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
Author: markt Date: Fri Sep 25 07:14:53 2015 New Revision: 1705232 URL: http://svn.apache.org/viewvc?rev=1705232&view=rev Log: Provide state info if test fails (it failed on Gump but I have no idea why) Modified: tomcat/tc8.0.x/trunk/ (props changed) tomcat/tc8.0.x/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java Propchange: tomcat/tc8.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Fri Sep 25 07:14:53 2015 @@ -1 +1 @@ -/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892 ,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1649973,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655351,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657 609,1657682,1657907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,1 37,149,1666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,168577 2,1685816,1685826,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,1695006,1695354,1695371,1695379,1695459,1695582,169570
svn commit: r1705233 - /tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
Author: markt
Date: Fri Sep 25 07:18:42 2015
New Revision: 1705233
URL: http://svn.apache.org/viewvc?rev=1705233&view=rev
Log:
Fix test broken during refactoring to add support for parallel class loading
Modified:
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
Modified:
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java?rev=1705233&r1=1705232&r2=1705233&view=diff
==
---
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
(original)
+++
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
Fri Sep 25 07:18:42 2015
@@ -69,7 +69,7 @@ public class TestWebappClassLoaderWeavin
private Tomcat tomcat;
private Context context;
-private WebappClassLoaderBase loader;
+private WebappClassLoader loader;
@Before
@Override
@@ -83,9 +83,9 @@ public class TestWebappClassLoaderWeavin
ClassLoader loader = this.context.getLoader().getClassLoader();
assertNotNull("The class loader should not be null.", loader);
-assertSame("The class loader is not correct.",
WebappClassLoaderBase.class, loader.getClass());
+assertSame("The class loader is not correct.",
WebappClassLoader.class, loader.getClass());
-this.loader = (WebappClassLoaderBase) loader;
+this.loader = (WebappClassLoader) loader;
}
@@ -250,7 +250,7 @@ public class TestWebappClassLoaderWeavin
result = invokeDoMethodOnClass(this.loader, "TesterUnweavedClass");
assertEquals("The second result is not correct.", "Hello, Weaver #2!",
result);
-WebappClassLoader copiedLoader = (WebappClassLoader)
this.loader.copyWithoutTransformers();
+WebappClassLoader copiedLoader = this.loader.copyWithoutTransformers();
result = invokeDoMethodOnClass(copiedLoader, "TesterNeverWeavedClass");
assertEquals("The third result is not correct.", "This will never be
weaved.", result);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AJP Protocol enhancements
On 24/09/2015 14:52, Andrew Carr wrote: >> >> >>> I have been following the AJP enhancements for a long time and it seems >> the >>> protocol is stagnant. >> >> I prefer 'mature'. >> > > Apologies. Mature is a much more appropriate word. > > >>> I do see some updates in the last year to the >>> enhancements page and some of the bugs, but there is not much activity. >> I >>> search for "enhancements" under the Tomcat Connectors project in Bugzilla >>> because it does not seem as though there is a specific category for AJP >>> Protocol enhancements. I am very interested in starting work on the AJP >>> Protocol enhancements. It seems like the protocol needs a clear >>> specification. >> >> We have this: >> http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html >> >> I'd like to see that in more of an RFC style but the content (speaking >> as someone who spends a lot of time reading and then implementing specs) >> is pretty good. >> > > I have reviewed the page you mentioned, in detail. I was confused however, > because of the other page with ideas for the protocol enhancements. I see > where you cleared that up below. Maybe we need to state that the "ajpv13a" > page (or a new page) is the definitive resource for the new protocol > declaration. > > >> >>> Wouldn't a JSR for the protocol specification make sense? Aren't there >>> enough people on this list with a clear enough understanding to >> facilitate >>> introducing AJP 1.4 (or 2.0) as a JSR? >> >> -1. >> >> I don't believe that going via the JCP would add anything beneficial. >> > > I am in agreement with this and Rainer's comments. I was suggesting JCP as > a possibility, RFC style is perfectly O.K. as well. My goal is something > formalized. An RFC for AJP1.3a or AJP1.4 or 2, whatever, would accomplish > the same thing. > > >>> Even if we don't go the JCP route, shouldn't we work on the protocol? It >>> needs updating, imho. >> >> I do agree that there is benefit to updating the AJP protocol. Adding >> support for HTTP upgrade is the feature that pops to mind immediately. I >> also recall that we have used custom request attributes to pass >> additional attributes that didn't have a dedicated protocol attribute. >> >>> If you think I am wrong, please explain why, so that I may learn from the >>> experience. I have searched the lists and the interwebs for information >> on >>> this and I am having a hard time finding it. I have also been looking >> for >>> a place in the Tomcat project to dig in for 3 years, and I believe I have >>> finally found that place. >>> >>> Some other facts to support my argument about generating a specification, >>> it appears the enhancements to create the next AJP protocol are in >> multiple >>> locations. I know there is currently the AJP Extension Proposal, but >> what >>> about all of the AJP14 stuff floating around? >>> >>> https://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html >>> >> https://archive.apache.org/dist/tomcat/tomcat-connectors/jk2/v2.0.0/doc/common/AJPv14-proposal.html >> >> Those look to be largely the same ideas and date from roughly the same >> time (10+ years ago). >> > > Again, I agree, just think there should be a definitive definition of the > protocol. > > >> >>> Please let me know your thoughts and concerns on enhancing the AJP >> protocol >>> and possibly introducing a new version with new features. >> >> I think there is a clear case for a new version. The first thing to do >> would be to pull all the ideas together in one place (I'm thinking the >> wiki), agree what needs to be in AJP.next and then work on updating the >> specification to accommodate it. >> >> Regarding the wiki, the current Tomcat wiki is hosted on a system that >> be be very slow (minutes) to process updates. I think we should create a >> new wiki instance on the cwiki server that is a lot faster when editing. >> > > Should gathering ideas in the wiki wait until after it is moved to a new > instance, or will it all be migrated (so starting now on the new page would > be ok?) Long term, we probably do need to migrate the wiki. Short term we can use the new instance just for this. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot exception in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a build exception on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/93 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' triggered this build Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1705233 Blamelist: markt BUILD FAILED: exception upload_2 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AJP Protocol enhancements
On 24/09/2015 14:48, Rémy Maucherat wrote: > 2015-09-24 15:13 GMT+02:00 Andrew Carr : > >> On Thu, Sep 24, 2015 at 4:52 AM, Rémy Maucherat wrote: >> >>> 2015-09-24 11:04 GMT+02:00 Mark Thomas : >>> I think there is a clear case for a new version. The first thing to do would be to pull all the ideas together in one place (I'm thinking the wiki), agree what needs to be in AJP.next and then work on updating the specification to accommodate it. Regarding the wiki, the current Tomcat wiki is hosted on a system that be be very slow (minutes) to process updates. I think we should create >> a new wiki instance on the cwiki server that is a lot faster when >> editing. >>> I rather like the idea of HTTP/2 as a proxy protocol. Did I miss >>> something >>> and what would a AJP.next bring over it ? >>> >> Rémy, >> Why wouldn't we offer a new AJP (AJP/2 Maybe?) alongside HTTP/2? The >> current setup (as you all know) allows for HTTP proxying and AJP proxying. >> You suggest HTTP/2 as the proxy protocol with no AJP? >> >> Yes, maybe HTTP/2 could be used as the proxy transport protocol: >- Encryption possible > - Message based > - Header compression > - Flow control > - Multiplexing > - Etc > > That would save a significant amount of effort specifying and implementing > [assuming it really does everything that is needed ...] especially if proxy > servers start adding HTTP/2 as a supported protocol for backend server > communication. I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this, there has been work to try and layer WebSocket on top of HTTP/2. At this point in time proxying WebSocket is tricky. httpd's WebSocket proxy support makes assumptions that aren't always valid. General support for proxying HTTP upgrade would be a good thing and right now AJP looks like the simplest way for us to make this happen. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1705238 - /tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java
Author: markt Date: Fri Sep 25 07:31:40 2015 New Revision: 1705238 URL: http://svn.apache.org/viewvc?rev=1705238&view=rev Log: Fix an Eclipse nag, primarily to trigger a new CI build Modified: tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java Modified: tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java?rev=1705238&r1=1705237&r2=1705238&view=diff == --- tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java (original) +++ tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java Fri Sep 25 07:31:40 2015 @@ -87,7 +87,7 @@ public class InternalAprInputBuffer exte * Underlying socket. */ private long socket; -private SocketWrapper wrapper; +private SocketWrapper wrapper; // - Public Methods - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/94 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' triggered this build Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1705238 Blamelist: markt Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AJP Protocol enhancements
2015-09-25 9:29 GMT+02:00 Mark Thomas : > I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The > HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this, > there has been work to try and layer WebSocket on top of HTTP/2. > > At this point in time proxying WebSocket is tricky. httpd's WebSocket > proxy support makes assumptions that aren't always valid. > > General support for proxying HTTP upgrade would be a good thing and > right now AJP looks like the simplest way for us to make this happen. > > Most likely a HTTP/2 proxy will still be a legacy HTTP/1.1 proxy as well. The main problem with the AJP.next plan is that by the time you release something many will be using HTTP/2. HTTP/2 is more important than the rest moving forward, and encapsulating in AJP it would likely be inefficient (basically, zillions of messages). OTOH, reversing the problem, AJP.next can be a HTTP/2 transport where you specify encapsulation of HTTP/1.1 and its upgrade. That could be more transparent and make configuration much cooler: unless the Tomcat connector gets some encapsulated requests, it could still act as a normal HTTP/2 connector. Rémy
Re: AJP Protocol enhancements
On 09/25/2015 10:51 AM, Rémy Maucherat wrote: 2015-09-25 9:29 GMT+02:00 Mark Thomas : I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this, there has been work to try and layer WebSocket on top of HTTP/2. At this point in time proxying WebSocket is tricky. httpd's WebSocket proxy support makes assumptions that aren't always valid. General support for proxying HTTP upgrade would be a good thing and right now AJP looks like the simplest way for us to make this happen. Most likely a HTTP/2 proxy will still be a legacy HTTP/1.1 proxy as well. The main problem with the AJP.next plan is that by the time you release something many will be using HTTP/2. HTTP/2 is more important than the rest moving forward, and encapsulating in AJP it would likely be inefficient (basically, zillions of messages). OTOH, reversing the problem, AJP.next can be a HTTP/2 transport where you specify encapsulation of HTTP/1.1 and its upgrade. That could be more transparent and make configuration much cooler: unless the Tomcat connector gets some encapsulated requests, it could still act as a normal HTTP/2 connector. Basically HTTP/2 requires SSL: the proxies are doing the TLS/SSL termination and send HTTP/1.1 (or AJP) to the back-ends, you can't upgrade for the back-end. If the proxy would only do the TLS/SSL termination then you need something like HTTP/2 protocol between the back-end and the proxy. I think a customized HTTP/2 connector could do that, so there is no need of AJP+ protocol. If you think of upgrade to websockets it is for already existing applications and there proxying isn't that good (mod_proxy_wstunnel is just a tunnel it doesn't care about the contents once upgraded). So adding upgrade to AJP won't help much. Additionally I think websockets via upgrade is dead, there won't be new developments there. I would just let AJP dying in peace. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AJP Protocol enhancements
The one really compelling /usability /bit about AJP proxying is that requests look like you're in/at the web server in question and receiving requests directly from the client of the web server. The fact that you are not is completely and utterly transparent to your web application code. The same cannot be said for HTTP proxying, which throws the proxying details in your face and leaves you scrambling with various valves, etc, to hide these details from web applications that care about the logical, not physical, truth of the situation. -- Jess Holle
[Bug 58433] RemoteIpValve not activated on redirect from mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=58433 George Stanchev changed: What|Removed |Added CC||stanc...@hotmail.com -- 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: AJP Protocol enhancements
Mark, Couple of questions. What wiki is the "new" cwiki? Will my wiki account from the old server be transferred to the new cwiki? Devs, I see arguments for and against the protocol upgrade. Based on different opinions, so far, we are inadvertently building a list of options for the future of the AJP protocol, should we consolidate these options and put it to a vote? Should I just write the protocol upgrade definition (or let it die peacefully as jean-frederic suggested). Something else? -Andrew
Re: AJP Protocol enhancements
2015-09-25 17:43 GMT+02:00 Andrew Carr : > Mark, > > Couple of questions. What wiki is the "new" cwiki? Will my wiki account > from the old server be transferred to the new cwiki? > > Devs, > > I see arguments for and against the protocol upgrade. Based on different > opinions, so far, we are inadvertently building a list of options for the > future of the AJP protocol, should we consolidate these options and put it > to a vote? Should I just write the protocol upgrade definition (or let it > die peacefully as jean-frederic suggested). Something else? > > You can work on an AJP.next even if some are skeptical, there's no vote needed at this stage. Rémy
Re: AJP Protocol enhancements
Rémy, Thank you. I reread what I asked about the wiki and I realize it might not have been clear. Mark said, *"Long term, we probably do need to migrate the wiki. Short term we can **use the new instance just for this." * and I was curious about access, is it already out there and I just don't know about it, etc... the "new instance." -Andrew On Fri, Sep 25, 2015 at 10:01 AM, Rémy Maucherat wrote: > 2015-09-25 17:43 GMT+02:00 Andrew Carr : > > > Mark, > > > > Couple of questions. What wiki is the "new" cwiki? Will my wiki account > > from the old server be transferred to the new cwiki? > > > > Devs, > > > > I see arguments for and against the protocol upgrade. Based on different > > opinions, so far, we are inadvertently building a list of options for the > > future of the AJP protocol, should we consolidate these options and put > it > > to a vote? Should I just write the protocol upgrade definition (or let > it > > die peacefully as jean-frederic suggested). Something else? > > > > You can work on an AJP.next even if some are skeptical, there's no vote > needed at this stage. > > Rémy > -- With Regards, Andrew Carr e. andrewlanec...@gmail.com w. andrew.c...@openlogic.com h. 4235255668 c. 4239489852 a. P.O. Box 1231, Greeneville, TN, 37744
Re: AJP Protocol enhancements
On 25/09/2015 17:05, Andrew Carr wrote: > Rémy, > > Thank you. > > I reread what I asked about the wiki and I realize it might not have been > clear. Mark said, > *"Long term, we probably do need to migrate the wiki. Short term we > can **use the new instance just for this." * > and I was curious about access, is it already out there and I just don't > know about it, etc... the "new instance." I need to get that set up. Give me 24 hours. I plan to move just the dev/design content form the old wiki at this point. We can decide what to do about the other content later. You'll need to sign up for an account at cwiki.apache.org. Mark > > -Andrew > > > > > On Fri, Sep 25, 2015 at 10:01 AM, Rémy Maucherat wrote: > >> 2015-09-25 17:43 GMT+02:00 Andrew Carr : >> >>> Mark, >>> >>> Couple of questions. What wiki is the "new" cwiki? Will my wiki account >>> from the old server be transferred to the new cwiki? >>> >>> Devs, >>> >>> I see arguments for and against the protocol upgrade. Based on different >>> opinions, so far, we are inadvertently building a list of options for the >>> future of the AJP protocol, should we consolidate these options and put >> it >>> to a vote? Should I just write the protocol upgrade definition (or let >> it >>> die peacefully as jean-frederic suggested). Something else? >>> >>> You can work on an AJP.next even if some are skeptical, there's no vote >> needed at this stage. >> >> Rémy >> > > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58458] New: Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results
https://bz.apache.org/bugzilla/show_bug.cgi?id=58458 Bug ID: 58458 Summary: Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results Product: Tomcat 7 Version: 7.0.64 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: oliver.w...@pdv.de Created attachment 33142 --> https://bz.apache.org/bugzilla/attachment.cgi?id=33142&action=edit Testcase This issue is similar to bug #57324 In the version of Tomcat 7.0.50, the behavior of Coyote handler is modified to handle "Expect: 100-continue" clients. We use .net http clients to run multiple web service equests. The uri is protected with spring security (kerberos / spnego) and uses requests to post xml files and attachements to the server. Starting with tomcat 7.0.50 about 1% to 10% of the requests fail with connection reset errors. The problem is reproducable with a small powershell script that do 1 small post requests with the header "Expect: 100-continue" with an uri that does not exists in tomcat (no webapp). The expected result are 1 http 404 errors. The problem is not reproducable when the header "Expect: 100-continue" is not used. The problem is not reproducable with tomcat versions 7.0.42. No error is logged at tomcat level. The access log shows http 404 when a request fails, but the response is not recognized by the client. error message: "The underlying connection was closed: An unexpected error occurred on a receive." additional infos: 1) .NET defaults to Expect 100 behaviour 2) .NET clients optimize the keepalive connections and do not send credentials with every request going out on keepalive connections Reproducable with: 7.0.64 APR Windows 7.0.64 BIO Windows 8.0.26 NIO Windows 8.0.26 APR Windows 8.0.26 NIO Linux 8.0.26 NIO2 Linux 8.0.26 APR Windows 8.0.26 NIO2Windows 7.0.63 APR Windows 7.0.57 APR Windows 7.0.57 BIO Windows 7.0.50 APR Windows Not reproducable with: 7.0.47 APR Windows 7.0.42 APR Windows 7.0.57 APR Linux ! 8.0.26 BIO Windows ! Windows = Windows 7 with Oracle Server JRE 8 Update 51 Linux = Oracle Linux 7 with java-1.8.0-openjdk-1.8.0.51-1.b16.el7_1.x86_64 possible workaround: - setting expect100Continue to false at application or system level - http://blogs.msdn.com/b/fiddler/archive/2011/11/05/http-expect-continue-delays-transmitting-post-bodies-by-up-to-350-milliseconds.aspx - https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.expect100continue%28v=vs.110%29.aspx Testcase: - running on windows 7 (.net framework required) - start tomcat 7.0.64 on port 8080 - cmd.exe - Powershell.exe -executionpolicy remotesigned -File TomcatExpectTest.ps1 Expect100Continue set to True Querying http://localhost:8080/myUri(number) 09/25/2015 19:42:25 request 257 - Exception Message: Exception calling "GetResponse" with "0" argument(s): "The underlying connection was closed: An unexpected error occurred on a receive." ... --- RESULTS Requests : 1 HTTP 404 : 9871 RST-Error : 129<-- OTHER Error: 0 --- END -- 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 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results
https://bz.apache.org/bugzilla/show_bug.cgi?id=58458 Michael Osipov <1983-01...@gmx.net> changed: What|Removed |Added OS||All --- Comment #1 from Michael Osipov <1983-01...@gmx.net> --- Have you tried another client like curl? Microsoft's Expect100Continue implementation is known be to problemeatic (crap). I have instructed all .NET clients to disable this header. -- 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: r1705349 - in /tomcat/trunk/java/org/apache/coyote: AbstractProcessor.java ActionCode.java http2/AbstractStream.java http2/Http2UpgradeHandler.java http2/LocalStrings.properties http2/Stre
Author: markt
Date: Fri Sep 25 20:29:30 2015
New Revision: 1705349
URL: http://svn.apache.org/viewvc?rev=1705349&view=rev
Log:
More work on servlet 3.1 non-blocking for HTTP/2. NumberWriter works.
Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
tomcat/trunk/java/org/apache/coyote/ActionCode.java
tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java
tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java?rev=1705349&r1=1705348&r2=1705349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java Fri Sep 25
20:29:30 2015
@@ -78,7 +78,8 @@ public abstract class AbstractProcessor
}
-private AbstractProcessor(AbstractEndpoint endpoint, Request
coyoteRequest, Response coyoteResponse) {
+private AbstractProcessor(AbstractEndpoint endpoint, Request
coyoteRequest,
+Response coyoteResponse) {
this.endpoint = endpoint;
asyncStateMachine = new AsyncStateMachine(this);
request = coyoteRequest;
Modified: tomcat/trunk/java/org/apache/coyote/ActionCode.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ActionCode.java?rev=1705349&r1=1705348&r2=1705349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ActionCode.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ActionCode.java Fri Sep 25 20:29:30 2015
@@ -195,13 +195,15 @@ public enum ActionCode {
/**
* Indicator that Servlet is interested in being
- * notified when data is available to be read
+ * notified when data is available to be read.
*/
NB_READ_INTEREST,
/**
- *Indicator that the Servlet is interested
- *in being notified when it can write data
+ * Used with non-blocking writes to determine if a write is currently
+ * allowed (sets passed parameter to true) or not (sets passed
+ * parameter to false). If a write is not allowed then
callback
+ * will be triggered at some future point when write becomes possible
again.
*/
NB_WRITE_INTEREST,
Modified: tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java?rev=1705349&r1=1705348&r2=1705349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java Fri Sep 25
20:29:30 2015
@@ -147,4 +147,6 @@ abstract class AbstractStream {
protected abstract String getConnectionId();
protected abstract int getWeight();
+
+protected abstract void doNotifyAll();
}
Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java?rev=1705349&r1=1705348&r2=1705349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java Fri Sep
25 20:29:30 2015
@@ -638,7 +638,7 @@ public class Http2UpgradeHandler extends
if (allocation > 0) {
backLogSize -= allocation;
synchronized (entry.getKey()) {
-entry.getKey().notifyAll();
+entry.getKey().doNotifyAll();
}
}
}
@@ -646,6 +646,13 @@ public class Http2UpgradeHandler extends
}
+
+@Override
+protected synchronized void doNotifyAll() {
+this.notifyAll();
+}
+
+
private int allocate(AbstractStream stream, int allocation) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("upgradeHandler.allocate.debug",
getConnectionId(),
Modified: tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties?rev=1705349&r1=1705348&r2=1705349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties Fri Sep
25 20:29:30 2015
@@
svn commit: r1705350 - /tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
Author: markt
Date: Fri Sep 25 20:48:14 2015
New Revision: 1705350
URL: http://svn.apache.org/viewvc?rev=1705350&view=rev
Log:
Fixed this TODO before last commit
Modified:
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java?rev=1705350&r1=1705349&r2=1705350&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java Fri Sep 25
20:48:14 2015
@@ -299,7 +299,6 @@ public class StreamProcessor extends Abs
break;
}
case NB_WRITE_INTEREST: {
-// TODO: Thread safe? Do this in output buffer?
AtomicBoolean result = (AtomicBoolean) param;
result.set(stream.getOutputBuffer().isReady());
break;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1705353 - in /tomcat/trunk/java/org/apache/coyote/http2: Stream.java StreamProcessor.java
Author: markt
Date: Fri Sep 25 21:05:53 2015
New Revision: 1705353
URL: http://svn.apache.org/viewvc?rev=1705353&view=rev
Log:
Start thinking about non-blocking reads
Modified:
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/http2/Stream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Stream.java?rev=1705353&r1=1705352&r2=1705353&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Stream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Stream.java Fri Sep 25 21:05:53
2015
@@ -292,6 +292,11 @@ public class Stream extends AbstractStre
}
+StreamInputBuffer getInputBuffer() {
+return inputBuffer;
+}
+
+
StreamOutputBuffer getOutputBuffer() {
return outputBuffer;
}
@@ -473,6 +478,7 @@ public class Stream extends AbstractStre
// This buffer is the destination for incoming data. It is normally is
// 'write mode'.
private volatile ByteBuffer inBuffer;
+private volatile boolean readInterest;
@Override
public int doRead(ByteChunk chunk) throws IOException {
@@ -519,6 +525,28 @@ public class Stream extends AbstractStre
}
+boolean isReady() {
+synchronized (inBuffer) {
+if (inBuffer.position() == 0) {
+readInterest = true;
+return false;
+} else {
+return true;
+}
+}
+}
+
+
+synchronized boolean isRegisteredForRead() {
+if (readInterest) {
+readInterest = false;
+return true;
+} else {
+return false;
+}
+}
+
+
public ByteBuffer getInBuffer() {
ensureBuffersExist();
return inBuffer;
@@ -526,13 +554,12 @@ public class Stream extends AbstractStre
private void ensureBuffersExist() {
-if (inBuffer != null) {
-return;
-}
-synchronized (this) {
-if (inBuffer == null) {
-inBuffer = ByteBuffer.allocate(16 * 1024);
-outBuffer = new byte[16 * 1024];
+if (inBuffer == null) {
+synchronized (this) {
+if (inBuffer == null) {
+inBuffer = ByteBuffer.allocate(16 * 1024);
+outBuffer = new byte[16 * 1024];
+}
}
}
}
Modified: tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java?rev=1705353&r1=1705352&r2=1705353&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java Fri Sep 25
21:05:53 2015
@@ -298,6 +298,11 @@ public class StreamProcessor extends Abs
result.set(stream.isInputFinished());
break;
}
+case NB_READ_INTEREST: {
+AtomicBoolean result = (AtomicBoolean) param;
+result.set(stream.getInputBuffer().isReady());
+break;
+}
case NB_WRITE_INTEREST: {
AtomicBoolean result = (AtomicBoolean) param;
result.set(stream.getOutputBuffer().isReady());
@@ -327,7 +332,6 @@ public class StreamProcessor extends Abs
case CLOSE_NOW:
case DISABLE_SWALLOW_INPUT:
case END_REQUEST:
-case NB_READ_INTEREST:
case REQ_SET_BODY_REPLAY:
case RESET:
log.info("TODO: Implement [" + actionCode + "] for HTTP/2");
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results
https://bz.apache.org/bugzilla/show_bug.cgi?id=58458 --- Comment #2 from Oliver --- Created attachment 33148 --> https://bz.apache.org/bugzilla/attachment.cgi?id=33148&action=edit testcase with curl on windows -- 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 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results
https://bz.apache.org/bugzilla/show_bug.cgi?id=58458 --- Comment #3 from Oliver --- Thanks for your fast response. With curl on windows the problem is also reproducible (tomcat 7.0.64 apr and 8.0.26 apr). There is an additional testcase (batch file). Error message: D:\curl-7.43.0-win64\bin>TomcatExpectTest_curl.cmd Request http://localhost:8080/myURI1 ... Request http://localhost:8080/myURI11 curl: (56) Recv failure: Connection was reset Request http://localhost:8080/myURI12 ... Request http://localhost:8080/myURI23 curl: (56) Recv failure: Connection was reset Request http://localhost:8080/myURI24 ... Request http://localhost:8080/myURI32 curl: (56) Recv failure: Connection was reset Request http://localhost:8080/myURI33 curl: (56) Recv failure: Connection was reset Request http://localhost:8080/myURI34 -- 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: r1705358 - in /tomcat/trunk: java/org/apache/coyote/http2/ test/org/apache/coyote/http2/
Author: markt
Date: Fri Sep 25 21:47:56 2015
New Revision: 1705358
URL: http://svn.apache.org/viewvc?rev=1705358&view=rev
Log:
Complete Servlet 3.1 non-blocking support
Modified:
tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java
tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
tomcat/trunk/test/org/apache/coyote/http2/Http2TestBase.java
Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java?rev=1705358&r1=1705357&r2=1705358&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java Fri Sep 25
21:47:56 2015
@@ -163,7 +163,7 @@ class Http2Parser {
Integer.toString(streamId), Integer.toString(dataLength),
padding));
}
-ByteBuffer dest = output.getInputByteBuffer(streamId, dataLength);
+ByteBuffer dest = output.startRequestBodyFrame(streamId, payloadSize);
if (dest == null) {
swallow(streamId, dataLength, false);
// Process padding before sending any notifications in case padding
@@ -185,7 +185,7 @@ class Http2Parser {
if (endOfStream) {
output.receiveEndOfStream(streamId);
}
-dest.notifyAll();
+output.endRequestBodyFrame(streamId);
}
}
if (padLength > 0) {
@@ -586,7 +586,8 @@ class Http2Parser {
HpackDecoder getHpackDecoder();
// Data frames
-ByteBuffer getInputByteBuffer(int streamId, int payloadSize) throws
Http2Exception;
+ByteBuffer startRequestBodyFrame(int streamId, int payloadSize) throws
Http2Exception;
+void endRequestBodyFrame(int streamId) throws Http2Exception;
void receiveEndOfStream(int streamId) throws ConnectionException;
void swallowedPadding(int streamId, int paddingLength) throws
ConnectionException, IOException;
Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java?rev=1705358&r1=1705357&r2=1705358&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java Fri Sep
25 21:47:56 2015
@@ -953,13 +953,21 @@ public class Http2UpgradeHandler extends
@Override
-public ByteBuffer getInputByteBuffer(int streamId, int payloadSize) throws
Http2Exception {
+public ByteBuffer startRequestBodyFrame(int streamId, int payloadSize)
throws Http2Exception {
Stream stream = getStream(streamId, true);
stream.checkState(FrameType.DATA);
return stream.getInputByteBuffer();
}
+
+@Override
+public void endRequestBodyFrame(int streamId) throws Http2Exception {
+Stream stream = getStream(streamId, true);
+stream.getInputBuffer().onDataAvailable();
+}
+
+
@Override
public void receiveEndOfStream(int streamId) throws ConnectionException {
Stream stream = getStream(streamId,
connectionState.get().isNewStreamAllowed());
Modified: tomcat/trunk/java/org/apache/coyote/http2/Stream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Stream.java?rev=1705358&r1=1705357&r2=1705358&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Stream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Stream.java Fri Sep 25 21:47:56
2015
@@ -21,6 +21,7 @@ import java.nio.ByteBuffer;
import java.util.Iterator;
import org.apache.coyote.ActionCode;
+import org.apache.coyote.ContainerThreadMarker;
import org.apache.coyote.InputBuffer;
import org.apache.coyote.OutputBuffer;
import org.apache.coyote.Request;
@@ -537,11 +538,31 @@ public class Stream extends AbstractStre
}
-synchronized boolean isRegisteredForRead() {
+synchronized boolean isRequestBodyFullyRead() {
+return inBuffer.position() == 0 && isInputFinished();
+}
+
+
+synchronized int available() {
+return inBuffer.position();
+}
+
+
+/*
+ * Called after placing some data in the inBuffer.
+ */
+synchronized boolean onDataAvailable() {
if (readInterest) {
readInterest = false;
+coyoteRequest.action(ActionCode.DISPATCH_READ, null);
+if (!ContainerThreadMarker.isContainerThread()) {
+
Re: AJP Protocol enhancements
On 25/09/2015 18:38, Mark Thomas wrote: > On 25/09/2015 17:05, Andrew Carr wrote: >> Rémy, >> >> Thank you. >> >> I reread what I asked about the wiki and I realize it might not have been >> clear. Mark said, >> *"Long term, we probably do need to migrate the wiki. Short term we >> can **use the new instance just for this." * >> and I was curious about access, is it already out there and I just don't >> know about it, etc... the "new instance." > > I need to get that set up. Give me 24 hours. I plan to move just the > dev/design content form the old wiki at this point. We can decide what > to do about the other content later. > > You'll need to sign up for an account at cwiki.apache.org. https://cwiki.apache.org/confluence/display/TOMCAT/Apache+Tomcat+Home I haven't moved the other dev/design content yet. I'll do that soon. Mark - 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-nio (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-nio 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-tc7.0.x-test-nio : 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-nio/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/logs-NIO -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-7.0.x/output/test-tmp-NIO/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test-nio/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test-nio.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test-nio (Type: Build) Work ended in a state of : Failed Elapsed: 30 mins 39 secs Command Line: /usr/lib/jvm/java-8-oracle/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/target/junit-4.13-SNAPSHOT.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150925-native-src.tar.gz -Dtest.reports=output/logs-NIO -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150925-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/R-4.5-201506032000/ecj-4.5.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20150925.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar -Dtest.excludePerformance=true -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/pub lic/workspace/commons-pool-1.x -Dcommons-dbcp.home=/srv/gump/public/workspace/commons-dbcp-1.x -Dexecute.test.apr=false -Dexecute.test.bio=false -Dexecute.test.nio=true -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-20150925.jar -Dtest.temp=output/test-tmp-NIO -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar test [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/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-junit4.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.ja r:/srv/gump/public/workspace/tomcat-7.0.x/output/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
