[Bug 59604] Invalid url-pattern in servlet mapping on s390x

[bugzilla]

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

Dave  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #11 from Dave  ---
... continue with my last comment:

I removed all the apps except ROOT and modified its web.xml by stripping off
the comments and the following:

Welcome to Tomcat
  
 Welcome to Tomcat
  


I'm still getting the same parsing error even though there are no servlet
mappings in this bare minimum web.xml.  It looks like an encoding issue, but I
guess the problem is not with the file contents but how it's being read.

-- 
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 59604] Invalid url-pattern in servlet mapping on s390x

[bugzilla]

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

--- Comment #10 from Dave  ---
Created attachment 33885
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33885=edit
log file with only ROOT app

-- 
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 59604] Invalid url-pattern in servlet mapping on s390x

[bugzilla]

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

--- Comment #9 from Dave  ---
Created attachment 33884
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33884=edit
modified web.xml for ROOT

I stripped out the comments and the following:

-- 
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 58626] Tomcat does not start at boot time due to SIGHUP

[bugzilla]

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

--- Comment #17 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Mark Thomas from comment #16)
> Created attachment 33883 [details]
> Proposed patch for Tomcat 9.0.x, version 1
> 
> I don't have an HP-UX box to test with but the described behaviour is odd to
> say the least.
> 
> There are other reasons why one might want to start with nohup so I have put
> together a slightly more general solution using some of the ideas proposed
> above. The short version is nohup on start is available for all operating
> systems and HP-UX will use it by default.
> 
> Feedback on the atached patch appreciated - particularly from anyone with
> access to an HP-UX box.

Quite a nice solution. Line 274 has too many spaces in it.
I will test that next week in a HP-UX 11.31 and will let you know. Are you
going to backport this to 8? We are currently running and planning to move to
8.0.

For this case, I will download 9.0.0.M6 and apply the patch to it.

-- 
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 59604] Invalid url-pattern in servlet mapping on s390x

[bugzilla]

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

--- Comment #8 from Christopher Schultz  ---
(In reply to Dave from comment #6)
> We might be able to provide access to z/OS shell.  Meanwhile, what kind of
> diagnostic data I can collect for debugging purpose?

Can you perform an MD5 signature of the conf/web.xml file so we can be sure
it's identical to the stock web.xml? Is it possible to get a byte-for-byte copy
of the file off that system somewhere we can see it?

Do you have any other XML-related utilities on that system that can be run
against the file to check for formatting, content, etc.? I'm thinking something
like 'xmllint' which is popular on *NIX systems (I recognize that z/OS is
different).

Maybe even an "od"-style byte dump copy-pasted into the comments, here?

(Actually, a better place for this thread would be the users mailing list since
it's not entirely clear that there is a bug here, yet.)

-- 
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 59604] Invalid url-pattern in servlet mapping on s390x

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #7 from Mark Thomas  ---
Anything that narrows down what is going on is useful.

My sugegstion is to try the following but keep in mind that you may have to
modify this as you go as you find out more information.

Strip Tomcat down to a single webapp that exhibits the problem (e.g ROOT).

Try different charsets in the XML prolog for conf/web.xml. UTF-8 and ISO-8859-1
as a minimum.

Remove content from conf/web.xml until you have the smallest possible file that
triggers the error.

Try writing a simple Java program to parse that file. Does that work?

-- 
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 58626] Tomcat does not start at boot time due to SIGHUP

[bugzilla]

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

--- Comment #16 from Mark Thomas  ---
Created attachment 33883
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33883=edit
Proposed patch for Tomcat 9.0.x, version 1

I don't have an HP-UX box to test with but the described behaviour is odd to
say the least.

There are other reasons why one might want to start with nohup so I have put
together a slightly more general solution using some of the ideas proposed
above. The short version is nohup on start is available for all operating
systems and HP-UX will use it by default.

Feedback on the atached patch appreciated - particularly from anyone with
access to an HP-UX box.

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

[GUMP@vmgump]: Project tomcat-native-trunk-make (in module tomcat-native-trunk) failed

[Bill Barker]

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-native-trunk-make has an issue affecting its community 
integration.
This issue affects 3 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-native-trunk-make :  Tomcat native library using Apache Portable 
Runtime
- tomcat-native-trunk-make-install :  Tomcat native library using Apache 
Portable Runtime
- tomcat-trunk-test-apr :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-native-trunk/tomcat-native-trunk-make/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-native-trunk/tomcat-native-trunk-make/gump_work/build_tomcat-native-trunk_tomcat-native-trunk-make.html
Work Name: build_tomcat-native-trunk_tomcat-native-trunk-make (Type: Build)
Work ended in a state of : Failed
Elapsed: 22 secs
Command Line: make 
[Working Directory: /srv/gump/public/workspace/tomcat-native-trunk/native]
-
make[1]: Entering directory 
`/srv/gump/public/workspace/tomcat-native-trunk/native'
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o 
src/address.lo -c src/address.c && touch src/address.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o src/bb.lo 
-c src/bb.c && touch src/bb.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o src/dir.lo 
-c src/dir.c && touch src/dir.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o 
src/error.lo -c src/error.c && touch src/error.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o src/file.lo 
-c src/file.c && touch src/file.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160524/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160524/include  
-I/srv/gump/public/workspace/apr-1/dest-20160524/include/apr-1   -o src/info.lo 
-c src/info.c && touch src/info.lo
/bin/bash /srv/gump/publ

[Bug 59627] request.getRequestURL() does not check if host header value is a valid hostname format

[bugzilla]

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

--- Comment #2 from Mark Thomas  ---
There is another reason this issue is invalid. It can only happen with a
malicious client.

A normal client will never connect to a server while sending a host header for
something that it can't resolve to an IP address. It takes a malicious client
to do that. If an attacker has managed to install a malicious client on a
vicim's PC it is game over before the first byte is sent to the server.

If the attacker has installed this on their own machine then they are free to
attack themselves - and we don't care about that.

-- 
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 59627] request.getRequestURL() does not check if host header value is a valid hostname format

[bugzilla]

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

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Remy Maucherat  ---
It is up to you to do the appropriate filtering when writing back any user
data. Same for getHeader, etc etc etc, the list is virtually endless.

Please never attempt to report possible security issues through BZ, Tomcat has
a dedicated security mailing list where confidentiality can be maintained.
http://tomcat.apache.org/security.html

-- 
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 59627] request.getRequestURL() does not check if host header value is a valid hostname format

[bugzilla]

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

dhardik...@gmail.com changed:

   What|Removed |Added

 CC||dhardik...@gmail.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

[Bug 59627] New: request.getRequestURL() does not check if host header value is a valid hostname format

[bugzilla]

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

Bug ID: 59627
   Summary: request.getRequestURL() does not check if host header
value is a valid hostname format
   Product: Tomcat 7
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
  Assignee: dev@tomcat.apache.org
  Reporter: dhardik...@gmail.com

request.getRequestURL() method replaces the value of host header in the URL
before returning the value but it does not check if the value is in correct
hostname format.

Consider the following example:

GET /getReqURL/getURL HTTP/1.1
Host: localhost:
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101
Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cache-Control: max-age=0

In the above request, request.getRequestURL() returns
http://localhost:/getReqURL/getURL

If the above request is modified and host header is changed to:

GET /getReqURL/getURL HTTP/1.1
Host: alert(1)
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101
Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cache-Control: max-age=0

request.getRequestURL() will return the following:
alert(1)/getReqURL/getUR

As per RFC2616 does not specify restrictions for a valid host header, this
results in lack of trust in value of request.getRequestURL()

Why this is a security issue:

Many web applications which uses the servlet API may depend on
request.getRequestURL() for internal URL redirection or displaying the complete
request URL path.

ex: response.write("Complete Request URL" : request.getRequestURL() );
This can result in an XSS if the Host header is modified.

-- 
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 58722] Parallel Deployment Override

[bugzilla]

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
This would be very difficult to implement cleanly.

The context version selection is performed in the Mapper. The Mapper re-uses
the same code for host, context and context version selection. The code has
been carefully tuned over the years.

The cleanest implementation I can come up with is an option to specic a custom
version comparator for a host and then have the Mapper use the custom
comparator for the context version if provided. Even that will be a little
messy and end-users would have to be very careful with the comparator
implementation to ensure a) it gave the desired results and b) it was
performant.

Given the difficulties, I'm going to resolve this as WONTFIX since I think it
is very unlikely that a patch will be produced. That said, if someone wants to
take a look at this then please go ahead. Once you have a patch ready for
review attach it to this issue and re-open it.

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

[SECURITY] Java Deserialization, JMX and CVE-2016-3427

[Mark Thomas]

TL;DR
If you use remote JMX, you need to update your JVM to address CVE-2016-3427

For the longer version, see the blog post I just published on this:
http://engineering.pivotal.io/post/java-deserialization-jmx/

Mark

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

svn commit: r1745337 - in /tomcat/trunk/webapps/docs: changelog.xml ssl-howto.xml

[remm]

Author: remm
Date: Tue May 24 09:26:00 2016
New Revision: 1745337

URL: http://svn.apache.org/viewvc?rev=1745337=rev
Log:
Checkstyle.

Modified:
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/ssl-howto.xml

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1745337=1745336=1745337=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Tue May 24 09:26:00 2016
@@ -92,7 +92,7 @@
 Server header may be configured by setting the server
 attribute on the Connector. A new Connector
 attribute, serverRemoveAppProvidedValues may be used to
-remove any Server header set by a web application. (markt) 
+remove any Server header set by a web application. (markt)
   
 
   

Modified: tomcat/trunk/webapps/docs/ssl-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/ssl-howto.xml?rev=1745337=1745336=1745337=diff
==
--- tomcat/trunk/webapps/docs/ssl-howto.xml (original)
+++ tomcat/trunk/webapps/docs/ssl-howto.xml Tue May 24 09:26:00 2016
@@ -138,7 +138,7 @@ scenarios, they are not suitable for any
 When securing a website with SSL it's important to make sure that all assets
 that the site uses are served over SSL, so that an attacker cant bypass
 the security by injecting malicious content in a javascript file or similar. To
-further enhance the security of your website, you should evaluate to use the 
+further enhance the security of your website, you should evaluate to use the
 HSTS header. It allows you to communicate to the browser that your site should
 always be accessed over https.
 



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

[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-validate has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 22 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 
-Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-6.19-SNAPSHOT.jar
 -Dexecute.validate=true validate 
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-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/checkstyle/target/checkstyle-6.19-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20160524.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.4-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.5-SNAPSHOT.ja
 
r:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20160524.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20160524.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-20.0-SNAPSHOT.jar
-
Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml

build-prepare:
   [delete] Deleting directory 
/srv/gump/public/workspace/tomcat-trunk/output/build/temp
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-trunk/output/build/temp

compile-prepare:

download-validate:

testexist:
 [echo] Testing  for 
/srv/gump/public/workspace/checkstyle/target/checkstyle-6.19-SNAPSHOT.jar

setproxy:

downloadfile:

validate:
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle
[checkstyle] Running Checkstyle 6.19-SNAPSHOT on 3076 files
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/webapps/docs/changelog.xml:95: Line 
matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/webapps/docs/ssl-howto.xml:141: Line 
matches the illegal pattern '\s+$'. [RegexpSingleline]

BUILD FAILED
/srv/gump/public/workspace/tomcat-trunk/build.xml:554: Got 2 errors and 0 
warnings.

Total time: 1 minute 22 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20160524060005, vmgump.apache.org:vmgump:20160524060005
Gump E-mail Identifier (unique within run) #1.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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