[GUMP@vmgump-vm3]: Project tomcat-tc8.5.x-test-nio (in module tomcat-8.5.x) failed

2018-09-22 Thread 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-tc8.5.x-test-nio has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc8.5.x-test-nio :  Tomcat 8.x, a web server implementing the Java 
Servlet 3.1,
...


Full details are available at:
http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-test-nio/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
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-8.5.x/output/logs-NIO
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-8.5.x/output/test-tmp-NIO/logs
 -WARNING- No directory 
[/srv/gump/public/workspace/tomcat-8.5.x/output/test-tmp-NIO/logs]



The following work was performed:
http://vmgump-vm3.apache.org/tomcat-8.5.x/tomcat-tc8.5.x-test-nio/gump_work/build_tomcat-8.5.x_tomcat-tc8.5.x-test-nio.html
Work Name: build_tomcat-8.5.x_tomcat-tc8.5.x-test-nio (Type: Build)
Work ended in a state of : Failed
Elapsed: 19 mins 22 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
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 
-Djava.net.preferIPv4Stack=/srv/gump/public/workspace/tomcat-8.5.x/true 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.7-SNAPSHOT.jar
 -Dtest.reports=output/logs-NIO -Dexecute.test.nio2=false 
-Dexamples.sources.skip=true 
-Dbase.path=/srv/gump/public/workspace/tomcat-8.5.x/tomcat-build-libs 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar
 -Dtest.relaxTiming=true 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar
 -Dtest.temp=output/test-tmp-NIO -Dtest.accesslog=true -Dexecute.test.nio=true 
-Dtest.openssl.path=/srv/gump/public/workspace/openssl-1.0.2/dest-20180923/bin/openssl
 -Dexecu
 te.test.bio=false -Dexecute.test.apr=false -Dtest.excludePerformance=true 
-Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-3.7-SNAPSHOT.jar
 -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar 
-Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-8.5.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-8.5.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-8.5.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/bu
 
ild/lib/tomcat-jni.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/tomcat-util.jar:/srv/gump/public/workspace/tomcat-8.5.x/output/build/lib/tomcat-uti

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

2018-09-22 Thread 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,
 and has been outstanding for 104 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:
http://vmgump-vm3.apache.org/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-vm3.apache.org/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: 48 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only -Dsun.zip.disableMemoryMapping=true 
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-8.13-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-8.13-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/commons-beanutils/dist/commons-beanutils-20180923.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.9-SNAPSHOT.jar:/srv/gump/pu
 
blic/workspace/apache-commons/logging/target/commons-logging-20180923.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20180923.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-HEAD-jre-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-8.13-SNAPSHOT.jar

setproxy:

downloadfile:

validate:
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle
[checkstyle] Running Checkstyle 8.13-SNAPSHOT on 3313 files
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/webapps/docs/changelog.xml:79: Line 
matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/webapps/docs/changelog.xml:80: Line 
matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] 
/srv/gump/public/workspace/tomcat-trunk/webapps/docs/changelog.xml:81: Line 
matches the illegal pattern '\s+$'. [RegexpSingleline]

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

Total time: 48 seconds
-

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

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

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

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



[Bug 62755] Add a Setter to Tomcat class to Allow Opting Out of Default Web Xml Config

2018-09-22 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=62755

Igal Sapir  changed:

   What|Removed |Added

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

--- Comment #1 from Igal Sapir  ---
Added in git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@1841692
13f79535-47bb-0310-9956-ffa450edef68

-- 
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: r1841693 - /tomcat/trunk/webapps/docs/changelog.xml

2018-09-22 Thread isapir
Author: isapir
Date: Sat Sep 22 20:19:24 2018
New Revision: 1841693

URL: http://svn.apache.org/viewvc?rev=1841693&view=rev
Log:
Changelog entry for BZ 62755

Modified:
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1841693&r1=1841692&r2=1841693&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Sat Sep 22 20:19:24 2018
@@ -75,6 +75,12 @@
 Add missing qsdiscard flag to the rewrite flags as a cleaner way to
 discard the query string. (remm)
   
+  
+62755: Add ability to opt out of adding the default web.xml 
+config when embedding Tomcat and adding a context via 
addWebapp(). 
+Call setAddDefaultWebXmlToWebapp(false) to prevent the 
+automatic config. (isapir)
+  
 
   
   



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



svn commit: r1841692 - /tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java

2018-09-22 Thread isapir
Author: isapir
Date: Sat Sep 22 20:06:06 2018
New Revision: 1841692

URL: http://svn.apache.org/viewvc?rev=1841692&view=rev
Log:
Added setter method setAddDefaultWebXmlToWebapp per bz 62755

Modified:
tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java

Modified: tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java?rev=1841692&r1=1841691&r2=1841692&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java Sat Sep 22 
20:06:06 2018
@@ -158,6 +158,8 @@ public class Tomcat {
 private final Map> userRoles = new HashMap<>();
 private final Map userPrincipals = new HashMap<>();
 
+private boolean addDefaultWebXmlToWebapp = true;
+
 public Tomcat() {
 ExceptionUtils.preload();
 }
@@ -623,12 +625,15 @@ public class Tomcat {
 Context ctx = createContext(host, contextPath);
 ctx.setPath(contextPath);
 ctx.setDocBase(docBase);
-ctx.addLifecycleListener(getDefaultWebXmlListener());
+
+if (addDefaultWebXmlToWebapp)
+ctx.addLifecycleListener(getDefaultWebXmlListener());
+
 ctx.setConfigFile(getWebappConfigFile(docBase, contextPath));
 
 ctx.addLifecycleListener(config);
 
-if (config instanceof ContextConfig) {
+if (addDefaultWebXmlToWebapp && (config instanceof ContextConfig)) {
 // prevent it from looking ( if it finds one - it'll have dup 
error )
 ((ContextConfig) config).setDefaultWebXml(noDefaultWebXmlPath());
 }
@@ -803,6 +808,24 @@ public class Tomcat {
 }
 
 
+/**
+ * By default, when calling addWebapp() to create a Context, the settings 
from
+ * from the default web.xml are added to the context.  Calling this method 
with
+ * a false value prior to calling addWebapp() allows to opt 
out of
+ * the default settings. In that event you will need to add the 
configurations
+ * yourself,  either programmatically or by using web.xml deployment 
descriptors.
+ * @param addDefaultWebXmlToWebapp false will prevent the 
class from
+ * automatically adding the default 
settings when
+ * calling addWebapp().
+ * true will add the default 
settings
+ * and is the default behavior.
+ * @see #addWebapp(Host, String, String, LifecycleListener)
+ */
+public void setAddDefaultWebXmlToWebapp(boolean addDefaultWebXmlToWebapp){
+this.addDefaultWebXmlToWebapp = addDefaultWebXmlToWebapp;
+}
+
+
 /*
  * Uses essentially the same logic as {@link ContainerBase#logName()}.
  */



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



[Bug 62755] New: Add a Setter to Tomcat class to Allow Opting Out of Default Web Xml Config

2018-09-22 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=62755

Bug ID: 62755
   Summary: Add a Setter to Tomcat class to Allow Opting Out of
Default Web Xml Config
   Product: Tomcat 9
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: isa...@apache.org
  Target Milestone: -

org.apache.catalina.startup.Tomcat.addWebapp() always adds the default web.xml
config settings, e.g. the default servlet and the JSP servlet.  Calling
addWebapp() is a very common method to embed Tomcat in other systems, but it is
those systems where the default config is many times not required or not
desired. 

Adding a setter to the Tomcat class to allow the user to opt-out of adding the
defaults will allow users to configure the system according to their needs,
either by adding the required configurations programmatically, or by using
web.xml deployment descriptors.

See also discussion at
https://www.mail-archive.com/users@tomcat.apache.org/msg130097.html

I plan to add this myself.

-- 
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: Potential change to DeltaManager

2018-09-22 Thread Mitch Claborn

See below for answers to your questions.

Status update: I've been running my patch in production for about 16 
hours with no problems. I've restarted each Tomcat (3) once and had no 
problems, but also detected no errors, either on send or receive. I have 
some code that I used in dev to force an error on a specific combination 
of session attribute name and value.  I'm going to put that in prod so 
that I can test how it behaves with a large volume of sessions and at 
least one error.



Mitch

On 09/21/2018 05:00 PM, Mark Thomas wrote:

On 21/09/18 18:02, Mitch Claborn wrote:

Please forgive me if this is the incorrect place or format for
discussing this. I'm new to trying to develop for Tomcat.


This is the right place. Welcome to the Tomcat community.


I'm developing a patch for DeltaManager and I'd like to discuss with you
developers if it could be considered for inclusion in the base code.
Please see details below and comment.


Will do. Please note that session replication is not an area I am
particularly familiar with so if some of my comments are a little
off-base I apologise.


Problem: When the "all sessions" message is sent from one node to
another, when the receiving node is first starting up, I often run into
various errors with one of the sessions and it fails to deserialize.
This causes all the remaining sessions in that chunk
(sendAllSessionsSize) to be lost by the receiver.


Oops.


The problem with the
sessions is totally an application problem, but until I can figure those
problems out and solve them I need a way to limit the impact of these
problems to just the one session that is in error. I could set
sendAllSessionsSize="1" but that would take a LONG time to transmit, and
we have many thousands of sessions at any given time.


That seems like a reasonable problem to try and solve.


Change details:

1. Update
    org.apache.catalina.ha.session.DeltaManager.deserializeSessions(byte[])
    and
    org.apache.catalina.ha.session.DeltaSession.doReadObject(ObjectInput)
    to produce a more detailed error message when a session is in
    error.  New error message includes: the session index in the list of
    sessions, the session ID, the last field or attribute that was
    attempted to be read.


I'm not sure how useful the index will be but the other information
makes sense to me.


The index gives me an indication of how many sessions were discarded 
because of the error.





2. Introduce new XML attribute verifySerializedSessions for DeltaManager.


Why would a user not want to enable this feature? The performance hit of
the additional deserialization on send?


That is the only reason I can think of.




3. If verifySerializedSessions="true",
    org.apache.catalina.ha.session.DeltaManager.serializeSessions(Session[])
    will first serialize each session then immediately deserialize it.
    If all is good, send the session as usual.  If any errors are
    encountered, create and send a dummy session with a known session ID
    instead. (This keeps the session count, which has already been put
    in the output stream, correct for the receiving node.)


Ah. Is the issue that serialization works but deserialization does not?
That seems a little odd. Can you give an example of how this might go
wrong? I am trying to understand the root cause(s) of the problem to
determine if the proposed solution is appropriate. I thought
DeltaSession simply skipped over attributes that it could not deserialize.


DeltaSession does skip attributes that are not serializable. I've had 
three identifiable errors, none of which I could reproduce at will.


1. A session with a Vector that might have contained nulls.  This 
should not be an issue, but I fixed my code to eliminate nulls in that 
Vector, since they should not be there anyway.


2. In some of my own objects where I do my own serialization with JSON, 
there were some fields that I don't serialize that were not marked 
transient that should have been. Some of those embedded objects were 
thus serialized by the native serialization and caused some problems. I 
fixed those.


3. In another of my objects that I serialize with JSON, the JSON string 
in the serialized session was obviously corrupted and was not a valid 
JSON hash.  I went over the serialization code with a fine tooth come 
and it appears to be correct. That same code works hundreds of thousands 
of times a day without error.


Especially in the case of #3, I suspect that there might be a 
concurrency issue - a session being modified in one request while it is 
being serialized in another.


FYI, bordering on TMI: I just recently switched to DeltaManager from a 
custom session sharing solution where I was doing my own persistence to 
a database, with no in-memory storage. Concurrency was not an issue in 
that setup because each request received an independent copy of the 
session content. I could have had concurrency issues all along and not 
known it.






4. Update
    org.ap