Re: Dynamic reloading of SSL certificates

[Romain Manni-Bucau]

up?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2017-09-05 16:41 GMT+02:00 Romain Manni-Bucau :

> Hello guys,
>
> wonder if this thread went anywhere? Would be very neat to have a let's
> encrypt integration (don't know if it would be a listener to declare to
> have automatic reloading or just a flag on the SSL config but it would ease
> deploying self hosted instances).
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | JavaEE Factory
> 
>
> 2017-01-23 23:18 GMT+01:00 Christopher Schultz <
> ch...@christopherschultz.net>:
>
>> Mark and Emmanuel,
>>
>> On 1/23/17 5:01 AM, Mark Thomas wrote:
>> > On 23/01/2017 09:36, Emmanuel Bourg wrote:
>> >> Hi all,
>> >>
>> >> With the fast adoption of Let's Encrypt many people are interested in
>> >> integrating it with Tomcat. A first step was to ensure that Tomcat can
>> >> directly use the PEM certificates generated by the letsencrypt/certbot
>> >> client. An important aspect of Let's Encrypt is automation, the
>> >> certificates are relatively short lived (90 days) and must be updated
>> >> automatically. AFAIK there is no easy way yet to reload a connector in
>> >> Tomcat to pick a new certificate. The administrator either has to
>> >> restart Tomcat (bad in a production environment) or do some JMX tricks
>> >> [1] (but JMX must be enabled and secured properly).
>> >>
>> >> I'm wondering if it would be possible for Tomcat to monitor the
>> >> certificates/keystore files and reload the associated connectors
>> >> automatically? If there is a consensus on this feature I'd be
>> interested
>> >> in implementing it.
>> >
>> > For background reading:
>> >
>> > http://tomcat.markmail.org/thread/fthbtwuozidno6lw
>> >
>> > http://tomcat.markmail.org/thread/753blzkslmifcvh4
>>
>> Yep. I'm also planning on giving a presentation about this exact topic
>> at ApacheCon in Miami.
>>
>> -chris
>>
>>
>

[Bug 61948] BufferUnderflowException and IllegalArgumentException in TLSClientHelloExtractor

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61948

--- Comment #2 from Remy Maucherat  ---
Do you have any exceptions for legitimate TLS records ? If not, instead of
validating all reads, it is reasonable to catch the exceptions and log as debug
instead. I reviewed the code and it seems to properly validate the lengths, it
requests more data, etc.

-- 
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 61948] BufferUnderflowException and IllegalArgumentException in TLSClientHelloExtractor

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61948

--- Comment #3 from Evgenij Ryazanov  ---
I don't know the source of requests from system journal. I think that both
requests were ill-formed. They may even be specially crafted. I agree that
simple try-catch will be more efficient and reasonable than a lot of additional
checks.

-- 
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: r1819844 - in /tomcat/trunk: java/org/apache/jasper/compiler/Compiler.java webapps/docs/changelog.xml

[remm]

Author: remm
Date: Tue Jan  2 14:54:04 2018
New Revision: 1819844

URL: http://svn.apache.org/viewvc?rev=1819844&view=rev
Log:
61945: Remove recursion when using prototype mode.

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1819844&r1=1819843&r2=1819844&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Jan  2 
14:54:04 2018
@@ -215,6 +215,7 @@ public abstract class Compiler {
 // generate prototype .java file for the tag file
 try (ServletWriter writer = setupContextWriter(javaFileName)) {
 Generator.generate(writer, this, pageNodes);
+return null;
 }
 }
 

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1819844&r1=1819843&r2=1819844&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Tue Jan  2 14:54:04 2018
@@ -97,6 +97,9 @@
 particular, the calling of a varargs method with no parameters now 
works
 correctly. Based on a patch by Nitkalya (Ing) Wiriyanuparb. (markt)
   
+  
+61945: Fix prototype mode used to compile tags. (remm)
+  
 
   
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 61945] infinite recursion in Jasper compilation of a recursive JSP tagfile

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61945

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Remy Maucherat  ---
Thanks for the test case. Although it could need to be further reviewed, I
think a change to what prototype mode did was not right. The fix will be in
9.0.3.

-- 
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: Dynamic reloading of SSL certificates

[Emmanuel Bourg]

Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> up?

I haven't got much time to look into this yet. However since Let's
Encrypt client implementations in Java are starting to appear [1] I
wonder if the certificate renewal process could be directly integrated
into Tomcat instead of relying on an external client such as certbot.

Emmanuel Bourg

[1] https://github.com/shred/acme4j

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Dynamic reloading of SSL certificates

[Romain Manni-Bucau]

Yes, if tomcat can supports hot reloading of certs it is very feasible:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn 

2018-01-02 16:56 GMT+01:00 Emmanuel Bourg :

> Le 02/01/2018 à 09:40, Romain Manni-Bucau a écrit :
> > up?
>
> I haven't got much time to look into this yet. However since Let's
> Encrypt client implementations in Java are starting to appear [1] I
> wonder if the certificate renewal process could be directly integrated
> into Tomcat instead of relying on an external client such as certbot.
>
> Emmanuel Bourg
>
> [1] https://github.com/shred/acme4j
>

[GitHub] tomcat issue #96: Remove PUT and DELETE methods from an OPTIONS request if r...

[markt-asf]

Github user markt-asf commented on the issue:

https://github.com/apache/tomcat/pull/96
  
I wanted to clear something up. It is not a case of me being willing to 
change something or not. I don't get to decide these things on my own. It is a 
community decision. Normally, we discuss things until we reach a solution we 
can all accept. In the unlikely event we can't reach an agreed solution then 
the PMC would have to vote to resolve the impasse. It is extremely rare that 
things reach that point.


---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] tomcat issue #96: Remove PUT and DELETE methods from an OPTIONS request if r...

[markt-asf]

Github user markt-asf commented on the issue:

https://github.com/apache/tomcat/pull/96
  
Getting back to whether readOnly should affect POST, my own view is that it 
should not. readOnly refers to whether the default Servlet can change static 
content. For static content request parameters (via GET or POST) are irrelevant 
since they are ignored. Hence why POST defers to GET. Neither change existign 
content hence neither should be affected by readOnly. If the default Servlet 
(or WebDAV since it extends the default Servlet) used the request parameters 
then it might (depending on how they were used) be different.


---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: oauth guidance

[Mark Thomas]

On 02/01/18 00:51, Robert J. Carr wrote:
> I'm looking to use some kind of combined realm where I can authenticate
> (and authorize) users both using the built-in login-config and externally
> using oauth.  Ideally, in both cases, I'd be able to have access to roles,
> but this isn't a necessity.
> 
> You see this sort of thing a lot now, where you have the option to "login
> with google" or "login with facebook" or even login using the site's own
> credentials.
> 
> There seems to be very little information about this out there, though, for
> use in tomcat or java ee.  All queries about oauth and tomcat lead to
> JASPIC.  I found this question, which is nearly my exact situation, and the
> accepted solution there was indeed JASPIC:
> 
> https://stackoverflow.com/questions/39058200/tomcat-realm-for-oauth2
> 
> But I can find almost no examples of how JASPIC works or what it offers
> (beyond the tomcat docs), but only that it is supported in tomcat starting
> with 8.5.  I can use tomcat 8.5, so that isn't a problem, but the only
> example provider seems to be the one for google, and it isn't super clear
> how it all works.

I put that together. It was only ever the bare minimum you needed to to
to integrate with Google OAuth. If you have specific questions this is
the place to ask. If the answers are helpful any suggestions to improve
the docs would be appreciated. Suggestions in the form of patches to the
docs even more so.

The JASPIC spec might be worth a read although it is fairly hard going
in places.

> So I'm just looking for any guidance on what road to start down, given my
> requirements.  It seems I could write my own realm, but then I'm not sure
> how I'd fit in the oauth token flow.  I could use jaspic, but then I'm not
> sure if I'd be able to use the regular security-constraints.  Or I could
> manage all of the auth myself with various filters and sessions, but that
> seems silly given the java ee machinery that's already available.
> 
> Any suggestions?

I'd suggest the JASPIC Realm. You might need to write a custom provider
(or whatever the terminology is) for your local auth. If it is a common
one it could potentially be added to the Tomcat code base.

Feel free to ask questions here as you go.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 61948] BufferUnderflowException and IllegalArgumentException in TLSClientHelloExtractor

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61948

--- Comment #4 from Mark Thomas  ---
If the code were to throw an IOException on a malformed ClientHello then a
debug log message would be generated as required.

I'm going to look at turning simple code to reproduce into a test case and then
fixing the issue.

-- 
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: r1819903 - in /tomcat/trunk: java/org/apache/tomcat/util/net/LocalStrings.properties java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java test/org/apache/tomcat/util/net/TestTLSCli

[markt]

Author: markt
Date: Tue Jan  2 21:32:41 2018
New Revision: 1819903

URL: http://svn.apache.org/viewvc?rev=1819903&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61948
Improve the handling of malformed ClientHello messages in the code that 
extracts the SNI information from a TLS handshake for the JSSE based NIO and 
NIO2 connectors.

Added:

tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java   
(with props)
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties?rev=1819903&r1=1819902&r2=1819903&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties Tue 
Jan  2 21:32:41 2018
@@ -126,6 +126,7 @@ jsse.invalid_truststore_password=The pro
 jsse.keystore_load_failed=Failed to load keystore type [{0}] with path [{1}] 
due to [{2}]
 jsse.ssl3=SSLv3 has been explicitly enabled. This protocol is known to be 
insecure.
 
+sniExtractor.clientHelloInvalid=The ClientHello message was not correctly 
formatted
 sniExtractor.clientHelloTooBig=The ClientHello was not presented in a single 
TLS record so no SNI information could be extracted
 
 socket.closed=The socket associated with this connection has been closed.

Modified: 
tomcat/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java?rev=1819903&r1=1819902&r2=1819903&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java 
Tue Jan  2 21:32:41 2018
@@ -16,6 +16,8 @@
  */
 package org.apache.tomcat.util.net;
 
+import java.io.IOException;
+import java.nio.BufferUnderflowException;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
 import java.util.ArrayList;
@@ -52,8 +54,9 @@ public class TLSClientHelloExtractor {
  * exits.
  *
  * @param netInBuffer The buffer containing the TLS data to process
+ * @throws IOException If the client hello message is malformed
  */
-public TLSClientHelloExtractor(ByteBuffer netInBuffer) {
+public TLSClientHelloExtractor(ByteBuffer netInBuffer) throws IOException {
 // TODO: Detect use of http on a secure connection and provide a simple
 //   error page.
 
@@ -143,6 +146,8 @@ public class TLSClientHelloExtractor {
 }
 }
 result = ExtractorResult.COMPLETE;
+} catch (BufferUnderflowException | IllegalArgumentException e) {
+throw new 
IOException(sm.getString("sniExtractor.clientHelloInvalid"), e);
 } finally {
 this.result = result;
 this.clientRequestedCiphers = clientRequestedCiphers;

Added: 
tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java?rev=1819903&view=auto
==
--- 
tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java 
(added)
+++ 
tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java 
Tue Jan  2 21:32:41 2018
@@ -0,0 +1,89 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+package org.apache.tomcat.util.net;
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+
+import org.junit.Assert;
+import org.junit.Test;
+
+import org.apache.tomcat.util.net.TLSClientHelloExtractor.ExtractorResult;
+
+public class TestTLSClientHelloExtractor {
+
+@Test
+public

svn commit: r1819904 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/tomcat/util/net/ test/org/apache/tomcat/util/net/ webapps/docs/

[markt]

Author: markt
Date: Tue Jan  2 21:33:19 2018
New Revision: 1819904

URL: http://svn.apache.org/viewvc?rev=1819904&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61948
Improve the handling of malformed ClientHello messages in the code that 
extracts the SNI information from a TLS handshake for the JSSE based NIO and 
NIO2 connectors.

Added:

tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
  - copied unchanged from r1819903, 
tomcat/trunk/test/org/apache/tomcat/util/net/TestTLSClientHelloExtractor.java
Modified:
tomcat/tc8.5.x/trunk/   (props changed)
tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties

tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java
tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.5.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Jan  2 21:33:19 2018
@@ -1,2 +1,2 @@
 /tomcat/tc8.0.x/trunk:1809644
-/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409
 
,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747
 
404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1
 
756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1

[Bug 61948] BufferUnderflowException and IllegalArgumentException in TLSClientHelloExtractor

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61948

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Mark Thomas  ---
Fixed in:
- trunk for 9.0.3 onwards
- 8.5.x for 8.5.25 onwards

Earlier versions are not affected as SNI is not supported.

-- 
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

buildbot failure in on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/2928

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1819903
Blamelist: markt

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org