Re: [INFRA] Tomcat cannot be built due to back mirrors
Am 2018-07-26 um 00:55 schrieb Konstantin Kolinko: 2018-07-25 22:33 GMT+03:00 Michael Osipov : Folks, we need to inquire this with INFRA: PS D:\Entwicklung\Projekte\tomcat-8.5.x> ant Buildfile: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml download-compile: testexist: [echo] Testing for C:\Users\mosipov/tomcat-build-libs/commons-daemon-1.1.0/commons-daemon-1.1.0.jar downloadgz-2: setproxy: trydownload.check: trydownload: [get] Getting: https://www.apache.org/dyn/closer.lua?action=download&filename=/commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz [get] To: C:\Users\mosipov\tomcat-build-libs\download-1214738004.tar.gz [get] https://www.apache.org/dyn/closer.lua?action=download&filename=/commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz moved to http://ftp.fau.de/apache//commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz BUILD FAILED D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:2618: The following error occurred while executing this line: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:2924: The following error occurred while executing this line: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:3040: Redirection detected from https to http. Protocol switch unsafe, not allowed. See https://bz.apache.org/bugzilla/show_bug.cgi?id=62164 and https://lists.apache.org/thread.html/f8b04ca6e28e9a9e0fde895df266bec2fd95027791286ab6665dc49a@%3Cdev.tomcat.apache.org%3E "Tag Tomcat 7/8.0" thread of 2018-06-28 I think that we have to revert to using HTTP at least for ASF mirror in Tomcat configuration, as Ant bug has been fixed in 1.9.13/1.10.5 I have already noticed this one too, but even Ant 1.10.5 does not solve this issue. As sad as it sounds, can we go back to HTTP for closer.lua for now? I can't test/compile anything here in Germany unless I change the build.properties. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Duplicate registration of ServletContextListerner
On 26/07/2018 04:29, Huxing Zhang wrote: Hi, On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz wrote: Can you think of a use-case where addListener() shouldn't automatically perform de-duplication? No, I can't think of that case. Yes, although only for the programmatic case. Multiple instances of the same listener configured differently. E.g. I can see a use for a simple javax.servlet.http.HttpSessionAttributeListener that might be added multiple times in a single app to define different actions for different attributes. Yes it could be implemented as a single listener but I can certainly see some scenarios where adding the same listener multiple times would give cleaner / simpler code. If there is really a case, I think we can use javax.servlet.ServletContext#setInitParameter to control that behavior. For example, use a initialization parameter named DEDUPLICATE_LISTENERS, if set to true, any further registration will be de-duplicated. This parameter is better to be a per call parameter rather than a global parameter, because it might be updated from multiple place. Configuration at that point may cause problems. I'm not sure that the ServletContext would be available early enough. It would be better as an attribute on the Context. That would also be consistent with other such configuration parameters. I'm thinking that Tomcat should simply take a call to addListener() and ignore any registrations after the first one. > Yes, I think it is important to have consistent behavior between web-fragement/@WebListener and programmatic API. -1. That behaviour is not consistent with the Servlet spec. The spec expects multiple instances. It isn't explicit but it is very strongly implied both by the wording used and the complete absence of any indication of how de-duplication should be performed. Further, de-duplication is not that simple. Some users will want the fist listener added. Some the most recent. There are probably other complications I haven't thought of. Would that make sense? Would it violate any spec-defined behavior? I can't find any spec describing how to handle the duplications on that part, so I guess it is safe to do so. :) There are lots of behaviours the spec doesn't define. That doesn't mean implementing them is spec compliant. Exactly the opposite in fact. Maybe we can improve spec as well. Hopefully, with the move to Eclipse, the various clarifications that have been open for a number of years will now start to be addressed. I'd recommend adding this to them https://github.com/eclipse-ee4j/servlet-api/issues Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1836707 - in /tomcat/trunk/java/org/apache/catalina/tribes/membership: StaticMembershipProvider.java StaticMembershipService.java
Author: kfujino
Date: Thu Jul 26 09:27:35 2018
New Revision: 1836707
URL: http://svn.apache.org/viewvc?rev=1836707&view=rev
Log:
Add New Static Membership Service implementations.
- initial implementaion that remain a lot of TODOs.
Added:
tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java
(with props)
tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipService.java
(with props)
Added:
tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java?rev=1836707&view=auto
==
---
tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java
(added)
+++
tomcat/trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java
Thu Jul 26 09:27:35 2018
@@ -0,0 +1,326 @@
+/*
+ * 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.catalina.tribes.membership;
+
+import java.io.Serializable;
+import java.net.InetAddress;
+import java.net.InetSocketAddress;
+import java.net.Socket;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Properties;
+
+import org.apache.catalina.tribes.Channel;
+import org.apache.catalina.tribes.ChannelException;
+import org.apache.catalina.tribes.ChannelException.FaultyMember;
+import org.apache.catalina.tribes.ChannelListener;
+import org.apache.catalina.tribes.Heartbeat;
+import org.apache.catalina.tribes.Member;
+import org.apache.catalina.tribes.MembershipService;
+import org.apache.catalina.tribes.group.Response;
+import org.apache.catalina.tribes.group.RpcCallback;
+import org.apache.catalina.tribes.group.RpcChannel;
+import org.apache.catalina.tribes.util.Arrays;
+import org.apache.catalina.tribes.util.StringManager;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+
+public class StaticMembershipProvider extends MembershipProviderBase
implements RpcCallback, ChannelListener, Heartbeat {
+
+protected static final StringManager sm =
StringManager.getManager(StaticMembershipProvider.class);
+private static final Log log =
LogFactory.getLog(StaticMembershipProvider.class);
+
+protected Channel channel;
+protected RpcChannel rpcChannel;
+protected MembershipService service;
+private String membershipName = null;
+private byte[] membershipId = null;
+protected ArrayList staticMembers;
+protected int sendOptions = Channel.SEND_OPTIONS_ASYNCHRONOUS;
+protected long expirationTime = 5000;
+protected int connectTimeout = 500;
+protected long rpcTimeout = 3000;
+protected int startLevel = 0;
+
+@Override
+public void init(Properties properties) throws Exception {
+String expirationTimeStr = properties.getProperty("expirationTime");
+this.expirationTime = Long.parseLong(expirationTimeStr);
+String connectTimeoutStr = properties.getProperty("connectTimeout");
+this.connectTimeout = Integer.parseInt(connectTimeoutStr);
+String rpcTimeouStr = properties.getProperty("rpcTimeout");
+this.rpcTimeout = Long.parseLong(rpcTimeouStr);
+this.membershipName = properties.getProperty("membershipName");;
+this.membershipId =
membershipName.getBytes(StandardCharsets.ISO_8859_1);
+membership = new Membership(service.getLocalMember(true));
+this.rpcChannel = new RpcChannel(this.membershipId, channel, this);
+this.channel.addChannelListener(this);
+}
+
+@Override
+public void start(int level) throws Exception {
+if (Channel.MBR_RX_SEQ==(level & Channel.MBR_RX_SEQ)) {
+//no-op
+}
+if (Channel.MBR_TX_SEQ==(level & Channel.MBR_TX_SEQ)) {
+//no-op
+}
+startLevel = (startLevel | level);
+if (startLevel == (Channel.MBR_RX_SEQ | Channel.MBR_TX_SEQ)) {
+startMembership(getAliveMembers(staticMembers.toArray(new
Member[0])));
+}
+}
+
+@Override
+public boolean stop(int
svn commit: r1836709 - /tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java
Author: kfujino Date: Thu Jul 26 09:31:54 2018 New Revision: 1836709 URL: http://svn.apache.org/viewvc?rev=1836709&view=rev Log: Add rule for Digester. Modified: tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java Modified: tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java?rev=1836709&r1=1836708&r2=1836709&view=diff == --- tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java (original) +++ tomcat/trunk/java/org/apache/catalina/ha/ClusterRuleSet.java Thu Jul 26 09:31:54 2018 @@ -111,6 +111,23 @@ public class ClusterRuleSet implements R "setMembershipService", "org.apache.catalina.tribes.MembershipService"); +// add +digester.addObjectCreate(channelPrefix + "Membership/LocalMember", + null, // MUST be specified in the element + "className"); +digester.addSetProperties(channelPrefix + "Membership/LocalMember"); +digester.addSetNext(channelPrefix + "Membership/LocalMember", +"setLocalMember", + "org.apache.catalina.tribes.membership.StaticMember"); +digester.addObjectCreate(channelPrefix + "Membership/Member", + null, // MUST be specified in the element + "className"); +digester.addSetProperties(channelPrefix + "Membership/Member"); +digester.addSetNext(channelPrefix + "Membership/Member", +"addStaticMember", + "org.apache.catalina.tribes.membership.StaticMember"); +//add end + digester.addObjectCreate(channelPrefix + "MembershipListener", null, // MUST be specified in the element "className"); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1836707 - in /tomcat/trunk/java/org/apache/catalina/tribes/membership: StaticMembershipProvider.java StaticMembershipService.java
On 26/07/2018 11:27, kfuj...@apache.org wrote: Author: kfujino Date: Thu Jul 26 09:27:35 2018 New Revision: 1836707 URL: http://svn.apache.org/viewvc?rev=1836707&view=rev Log: Add New Static Membership Service implementations. - initial implementaion that remain a lot of TODOs. I appreciate that this is a work in progress. Can you explain the differences / benefits / disadvantages of this vs. the StaticMembershipInterceptor? I'd like to understand when I should use one or the other. Thanks, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [INFRA] Tomcat cannot be built due to back mirrors
2018-07-26 10:03 GMT+03:00 Michael Osipov : > Am 2018-07-26 um 00:55 schrieb Konstantin Kolinko: >> >> 2018-07-25 22:33 GMT+03:00 Michael Osipov : >>> >>> Folks, >>> >>> we need to inquire this with INFRA: PS D:\Entwicklung\Projekte\tomcat-8.5.x> ant Buildfile: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml download-compile: testexist: [echo] Testing for C:\Users\mosipov/tomcat-build-libs/commons-daemon-1.1.0/commons-daemon-1.1.0.jar downloadgz-2: setproxy: trydownload.check: trydownload: [get] Getting: https://www.apache.org/dyn/closer.lua?action=download&filename=/commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz [get] To: C:\Users\mosipov\tomcat-build-libs\download-1214738004.tar.gz [get] https://www.apache.org/dyn/closer.lua?action=download&filename=/commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz moved to http://ftp.fau.de/apache//commons/daemon/binaries/commons-daemon-1.1.0-bin.tar.gz BUILD FAILED D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:2618: The following error occurred while executing this line: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:2924: The following error occurred while executing this line: D:\Entwicklung\Projekte\tomcat-8.5.x\build.xml:3040: Redirection detected from https to http. Protocol switch unsafe, not allowed. >> >> >> See >> https://bz.apache.org/bugzilla/show_bug.cgi?id=62164 >> and >> >> https://lists.apache.org/thread.html/f8b04ca6e28e9a9e0fde895df266bec2fd95027791286ab6665dc49a@%3Cdev.tomcat.apache.org%3E >> "Tag Tomcat 7/8.0" thread of 2018-06-28 >> >> >> I think that we have to revert to using HTTP at least for ASF mirror >> in Tomcat configuration, as Ant bug has been fixed in 1.9.13/1.10.5 > > > I have already noticed this one too, but even Ant 1.10.5 does not solve this > issue. As sad as it sounds, can we go back to HTTP for closer.lua for now? I > can't test/compile anything here in Germany unless I change the > build.properties. The bug in older Ant versions is the reason why we could not use HTTP and switched to HTTPS. We can switch back to HTTP now. Ant allows redirection from an HTTP to an HTTPS address. Redirection from an HTTPS one to an HTTP one is not allowed. If Tomcat configuration uses http. both http and https mirrors can be used. Best regards, Konstantin Kolinko - 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
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/3460 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] 1836709 Blamelist: kfujino 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
svn commit: r1836738 - /tomcat/trunk/webapps/docs/config/valve.xml
Author: markt Date: Thu Jul 26 16:13:24 2018 New Revision: 1836738 URL: http://svn.apache.org/viewvc?rev=1836738&view=rev Log: Clarify what is meant by an error report Modified: tomcat/trunk/webapps/docs/config/valve.xml Modified: tomcat/trunk/webapps/docs/config/valve.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/valve.xml?rev=1836738&r1=1836737&r2=1836738&view=diff == --- tomcat/trunk/webapps/docs/config/valve.xml (original) +++ tomcat/trunk/webapps/docs/config/valve.xml Thu Jul 26 16:13:24 2018 @@ -1868,9 +1868,10 @@ -Flag to determine if the error report is presented when an error - occurs. If set to false, then the error report is not in - the HTML response. +Flag to determine if the error report (custom error message and/or + stack trace) is presented when an error occurs. If set to + false, then the error report is not returned in the HTML + response. Default value: true - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1836739 - in /tomcat/tc8.5.x/trunk: ./ webapps/docs/config/valve.xml
Author: markt Date: Thu Jul 26 16:14:48 2018 New Revision: 1836739 URL: http://svn.apache.org/viewvc?rev=1836739&view=rev Log: Clarify what is meant by an error report Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/webapps/docs/config/valve.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jul 26 16:14:48 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,1761572,1761574,1761625-1761626,1761628,1761682,1761740,1761752,1762051-176205 3,1762123,1762168,1762172,1762182,1762201-1762202,1762204,1762208,1762288,1762296,1762324,1762348,1762353,1762362,1762374,1762492,1762503,1762505,1762541,1762608,1762710,1762753,1762766,1762769,1762944,1762947,1762953,1763167,1763179,1763232,1763259,1763271-1763272,1763276-1763277,1763319-1763320,1763370,1763372,1763375,1763377,1763393,1763412,1763430,1763450,1763462,1763505,1763511-1763512,1763516,1763518,1763520,1763529,1763559,1763565,1763568,1763574,1763619,1763634-1763635,1763
svn commit: r1836740 - /tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml
Author: markt Date: Thu Jul 26 16:19:00 2018 New Revision: 1836740 URL: http://svn.apache.org/viewvc?rev=1836740&view=rev Log: Clarify what is meant by an error report Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml?rev=1836740&r1=1836739&r2=1836740&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/config/valve.xml Thu Jul 26 16:19:00 2018 @@ -1701,9 +1701,10 @@ -Flag to determine if the error report is presented when an error - occurs. If set to false, then the error report is not in - the HTML response. +Flag to determine if the error report (custom error message and/or + stack trace) is presented when an error occurs. If set to + false, then the error report is not returned in the HTML + response. Default value: true - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building . Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/3461 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] 1836738 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: Duplicate registration of ServletContextListerner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 7/26/18 5:21 AM, Mark Thomas wrote:
> On 26/07/2018 04:29, Huxing Zhang wrote:
>> Hi,
>>
>> On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz
>> wrote:
>
>
>
>>> Can you think of a use-case where addListener() shouldn't
>>> automatically perform de-duplication?
>>
>> No, I can't think of that case.
>
> Yes, although only for the programmatic case.
>
> Multiple instances of the same listener configured differently.
> E.g. I can see a use for a simple
> javax.servlet.http.HttpSessionAttributeListener that might be
> added multiple times in a single app to define different actions
> for different attributes. Yes it could be implemented as a single
> listener but I can certainly see some scenarios where adding the
> same listener multiple times would give cleaner / simpler code.
>
>> If there is really a case, I think we can use
>> javax.servlet.ServletContext#setInitParameter to control that
>> behavior. For example, use a initialization parameter named
>> DEDUPLICATE_LISTENERS, if set to true, any further registration
>> will be de-duplicated. This parameter is better to be a per call
>> parameter rather than a global parameter, because it might be
>> updated from multiple place.
>
> Configuration at that point may cause problems. I'm not sure that
> the ServletContext would be available early enough. It would be
> better as an attribute on the Context. That would also be
> consistent with other such configuration parameters.
>
>>> I'm thinking that Tomcat should simply take a call to
>>> addListener() and ignore any registrations after the first one.
>>> >
>> Yes, I think it is important to have consistent behavior between
>> web-fragement/@WebListener and programmatic API.
>
> -1. That behaviour is not consistent with the Servlet spec. The
> spec expects multiple instances. It isn't explicit but it is very
> strongly implied both by the wording used and the complete absence
> of any indication of how de-duplication should be performed.
>
> Further, de-duplication is not that simple. Some users will want
> the fist listener added. Some the most recent. There are probably
> other complications I haven't thought of.
>
>>> Would that make sense? Would it violate any spec-defined
>>> behavior?
>>
>> I can't find any spec describing how to handle the duplications
>> on that part, so I guess it is safe to do so. :)
>
> There are lots of behaviours the spec doesn't define. That doesn't
> mean implementing them is spec compliant. Exactly the opposite in
> fact.
>
>> Maybe we can improve spec as well.
>
> Hopefully, with the move to Eclipse, the various clarifications
> that have been open for a number of years will now start to be
> addressed. I'd recommend adding this to them
>
> https://github.com/eclipse-ee4j/servlet-api/issues
FWIW, I was not suggesting that all types of listeners be
deduplicated. I was instead focusing on ServletContextListeners, since
that was Huxing's use-case. I should have been more clear in my proposal
.
On the other hand, listeners cannot be registered with any information
other than their class. Therefore I'm not sure that adding the same
class multiple times to the event-notification list would accomplish
anything useful.
Hmm... I just realized that the programmatic interface allows
listeners to be added by /instance/ and not just by class (name), so
theoretically one could instantiate two instances of a single class,
each with different behaviors (configured via constructors or other
mutators) and they would therefore be "distinct".
Rather than deduplicating by class, perhaps we could deduplicate by
using .equals(). In that case, if you had something like this:
class MyListener extends HttpSessionAttributeListener {
MyListener(String attributeName) { ... }
}
Then registering one instance of this class with attribute name "foo"
versus "bar" could work as long as MyListener can prove that the two
instances are distinct (e.g. by comparing their "attribute names").
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltaDggACgkQHPApP6U8
pFhg2w//ZuhPBU6LzWYJksEKh/HcPLaXZODjqCUA8xl8EBEXyIbqu6Bafl2QlKxT
J2yprTHefOKAI7TOY8yPWtdiwCFCgI1yMOD6HDp4J5MhWziKV+0bbOjrrG1Vuia1
i1Sspvue3XyWVcpMF40/LGRC6BDlNcN+XqCfwfODXD5JLKxpaFZIKSLNDb2cttEH
7rJhQHwqxqGj5OUxlA5y/TRBzTKihH789PG0XKukXeYLzW64KhzB9kVIYJTgVmT4
rWOMUmMRBB2VVi4ovmmRy/O4Y8t0VXZvdQVb9EwVKlSKvnoO6tVLgsVGAKG966EB
SdTEBeUIkwPdYYbv2lL7OgpHAOUAmwBtwZhs8UFUCIU1nCi2FUS8kqbMNIlDk431
J8Ad9PQ3jh/A01m3XScKL+/4qVx550lxQEk1Zd7wsajgtbJPZo0ZOA+Iy1x5huDx
IbudWubPMJudxJLvjb8kb2aDYamvMtmQF7Xb3R1aWOGezCHuB39f05Nurz8c4ZKt
YrrZHjeqcYnPgpdvWBaobXZt0q3y8cbQnoovdpLiHg5l7Lb4NY9LS87KAamj+T4q
ZwJVHjE7ULlLRlgdAnDu0Z0CZBdMW/Xe0ZmnE+hW6jSmsB/vDdePZTLk/g/1iddr
vR2MKJ56L9xMgbYWPl144XkZN7p8GDuzHWrqZQt/FLwyCXos5L4=
=Ygg3
-END PGP SIGNATURE-
Re: Duplicate registration of ServletContextListerner
On July 26, 2018 6:08:09 PM UTC, Christopher Schultz
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Mark,
>
>On 7/26/18 5:21 AM, Mark Thomas wrote:
>> On 26/07/2018 04:29, Huxing Zhang wrote:
>>> Hi,
>>>
>>> On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz
>>> wrote:
>>
>>
>>
Can you think of a use-case where addListener() shouldn't
automatically perform de-duplication?
>>>
>>> No, I can't think of that case.
>>
>> Yes, although only for the programmatic case.
>>
>> Multiple instances of the same listener configured differently.
>> E.g. I can see a use for a simple
>> javax.servlet.http.HttpSessionAttributeListener that might be
>> added multiple times in a single app to define different actions
>> for different attributes. Yes it could be implemented as a single
>> listener but I can certainly see some scenarios where adding the
>> same listener multiple times would give cleaner / simpler code.
>>
>>> If there is really a case, I think we can use
>>> javax.servlet.ServletContext#setInitParameter to control that
>>> behavior. For example, use a initialization parameter named
>>> DEDUPLICATE_LISTENERS, if set to true, any further registration
>>> will be de-duplicated. This parameter is better to be a per call
>>> parameter rather than a global parameter, because it might be
>>> updated from multiple place.
>>
>> Configuration at that point may cause problems. I'm not sure that
>> the ServletContext would be available early enough. It would be
>> better as an attribute on the Context. That would also be
>> consistent with other such configuration parameters.
>>
I'm thinking that Tomcat should simply take a call to
addListener() and ignore any registrations after the first one.
>
>>> Yes, I think it is important to have consistent behavior between
>>> web-fragement/@WebListener and programmatic API.
>>
>> -1. That behaviour is not consistent with the Servlet spec. The
>> spec expects multiple instances. It isn't explicit but it is very
>> strongly implied both by the wording used and the complete absence
>> of any indication of how de-duplication should be performed.
>>
>> Further, de-duplication is not that simple. Some users will want
>> the fist listener added. Some the most recent. There are probably
>> other complications I haven't thought of.
>>
Would that make sense? Would it violate any spec-defined
behavior?
>>>
>>> I can't find any spec describing how to handle the duplications
>>> on that part, so I guess it is safe to do so. :)
>>
>> There are lots of behaviours the spec doesn't define. That doesn't
>> mean implementing them is spec compliant. Exactly the opposite in
>> fact.
>>
>>> Maybe we can improve spec as well.
>>
>> Hopefully, with the move to Eclipse, the various clarifications
>> that have been open for a number of years will now start to be
>> addressed. I'd recommend adding this to them
>>
>> https://github.com/eclipse-ee4j/servlet-api/issues
>
>FWIW, I was not suggesting that all types of listeners be
>deduplicated. I was instead focusing on ServletContextListeners, since
>that was Huxing's use-case. I should have been more clear in my
>proposal
>.
>
>On the other hand, listeners cannot be registered with any information
>other than their class. Therefore I'm not sure that adding the same
>class multiple times to the event-notification list would accomplish
>anything useful.
>
>Hmm... I just realized that the programmatic interface allows
>listeners to be added by /instance/ and not just by class (name), so
>theoretically one could instantiate two instances of a single class,
>each with different behaviors (configured via constructors or other
>mutators) and they would therefore be "distinct".
>
>Rather than deduplicating by class, perhaps we could deduplicate by
>using .equals(). In that case, if you had something like this:
>
>class MyListener extends HttpSessionAttributeListener {
> MyListener(String attributeName) { ... }
>}
>
>Then registering one instance of this class with attribute name "foo"
>versus "bar" could work as long as MyListener can prove that the two
>instances are distinct (e.g. by comparing their "attribute names").
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltaDggACgkQHPApP6U8
>pFhg2w//ZuhPBU6LzWYJksEKh/HcPLaXZODjqCUA8xl8EBEXyIbqu6Bafl2QlKxT
>J2yprTHefOKAI7TOY8yPWtdiwCFCgI1yMOD6HDp4J5MhWziKV+0bbOjrrG1Vuia1
>i1Sspvue3XyWVcpMF40/LGRC6BDlNcN+XqCfwfODXD5JLKxpaFZIKSLNDb2cttEH
>7rJhQHwqxqGj5OUxlA5y/TRBzTKihH789PG0XKukXeYLzW64KhzB9kVIYJTgVmT4
>rWOMUmMRBB2VVi4ovmmRy/O4Y8t0VXZvdQVb9EwVKlSKvnoO6tVLgsVGAKG966EB
>SdTEBeUIkwPdYYbv2lL7OgpHAOUAmwBtwZhs8UFUCIU1nCi2FUS8kqbMNIlDk431
>J8Ad9PQ3jh/A01m3XScKL+/4qVx550lxQEk1Zd7wsajgtbJPZo0ZOA+Iy1x5huDx
>IbudWubPMJudxJLvjb8kb2aDYamvMtmQF7Xb3R1aWOGezCHuB39f05Nurz8c4ZKt
>YrrZHjeqcYnPgpdvWBaobXZt0q3y8cbQnoov
[GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-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-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: 33 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.12-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.12-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/commons-beanutils/dist/commons-beanutils-20180726.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.8-SNAPSHOT.jar:/srv/gump/pu blic/workspace/apache-commons/logging/target/commons-logging-20180726.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20180726.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.12-SNAPSHOT.jar setproxy: downloadfile: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 8.12-SNAPSHOT on 3301 files [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java:48: Line matches the illegal pattern '\s+$'. [RegexpSingleline] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/tribes/membership/StaticMembershipService.java:93: Line matches the illegal pattern '\s+$'. [RegexpSingleline] BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:569: Got 2 errors and 0 warnings. Total time: 32 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 20180726180005, vmgump-vm3.apache.org:vmgump:20180726180005 Gump E-mail Identifier (unique within run) #1. -- 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
[GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 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: 37 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.12-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.12-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/commons-beanutils/dist/commons-beanutils-20180727.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.8-SNAPSHOT.jar:/srv/gump/pu blic/workspace/apache-commons/logging/target/commons-logging-20180727.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20180727.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.12-SNAPSHOT.jar setproxy: downloadfile: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 8.12-SNAPSHOT on 3301 files [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/tribes/membership/StaticMembershipProvider.java:48: Line matches the illegal pattern '\s+$'. [RegexpSingleline] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/tribes/membership/StaticMembershipService.java:93: Line matches the illegal pattern '\s+$'. [RegexpSingleline] BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:569: Got 2 errors and 0 warnings. Total time: 37 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 2018072705, vmgump-vm3.apache.org:vmgump:2018072705 Gump E-mail Identifier (unique within run) #3. -- 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
Re: Duplicate registration of ServletContextListerner
On Fri, Jul 27, 2018 at 3:02 AM, Mark Thomas wrote:
> On July 26, 2018 6:08:09 PM UTC, Christopher Schultz
> wrote:
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA256
>>
>>Mark,
>>
>>On 7/26/18 5:21 AM, Mark Thomas wrote:
>>> On 26/07/2018 04:29, Huxing Zhang wrote:
Hi,
On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz
wrote:
>>>
>>>
>>>
> Can you think of a use-case where addListener() shouldn't
> automatically perform de-duplication?
No, I can't think of that case.
>>>
>>> Yes, although only for the programmatic case.
>>>
>>> Multiple instances of the same listener configured differently.
>>> E.g. I can see a use for a simple
>>> javax.servlet.http.HttpSessionAttributeListener that might be
>>> added multiple times in a single app to define different actions
>>> for different attributes. Yes it could be implemented as a single
>>> listener but I can certainly see some scenarios where adding the
>>> same listener multiple times would give cleaner / simpler code.
>>>
If there is really a case, I think we can use
javax.servlet.ServletContext#setInitParameter to control that
behavior. For example, use a initialization parameter named
DEDUPLICATE_LISTENERS, if set to true, any further registration
will be de-duplicated. This parameter is better to be a per call
parameter rather than a global parameter, because it might be
updated from multiple place.
>>>
>>> Configuration at that point may cause problems. I'm not sure that
>>> the ServletContext would be available early enough. It would be
>>> better as an attribute on the Context. That would also be
>>> consistent with other such configuration parameters.
>>>
> I'm thinking that Tomcat should simply take a call to
> addListener() and ignore any registrations after the first one.
> >
Yes, I think it is important to have consistent behavior between
web-fragement/@WebListener and programmatic API.
>>>
>>> -1. That behaviour is not consistent with the Servlet spec. The
>>> spec expects multiple instances. It isn't explicit but it is very
>>> strongly implied both by the wording used and the complete absence
>>> of any indication of how de-duplication should be performed.
>>>
>>> Further, de-duplication is not that simple. Some users will want
>>> the fist listener added. Some the most recent. There are probably
>>> other complications I haven't thought of.
>>>
> Would that make sense? Would it violate any spec-defined
> behavior?
I can't find any spec describing how to handle the duplications
on that part, so I guess it is safe to do so. :)
>>>
>>> There are lots of behaviours the spec doesn't define. That doesn't
>>> mean implementing them is spec compliant. Exactly the opposite in
>>> fact.
>>>
Maybe we can improve spec as well.
>>>
>>> Hopefully, with the move to Eclipse, the various clarifications
>>> that have been open for a number of years will now start to be
>>> addressed. I'd recommend adding this to them
>>>
>>> https://github.com/eclipse-ee4j/servlet-api/issues
>>
>>FWIW, I was not suggesting that all types of listeners be
>>deduplicated. I was instead focusing on ServletContextListeners, since
>>that was Huxing's use-case. I should have been more clear in my
>>proposal
>>.
>>
>>On the other hand, listeners cannot be registered with any information
>>other than their class. Therefore I'm not sure that adding the same
>>class multiple times to the event-notification list would accomplish
>>anything useful.
>>
>>Hmm... I just realized that the programmatic interface allows
>>listeners to be added by /instance/ and not just by class (name), so
>>theoretically one could instantiate two instances of a single class,
>>each with different behaviors (configured via constructors or other
>>mutators) and they would therefore be "distinct".
>>
>>Rather than deduplicating by class, perhaps we could deduplicate by
>>using .equals(). In that case, if you had something like this:
>>
>>class MyListener extends HttpSessionAttributeListener {
>> MyListener(String attributeName) { ... }
>>}
>>
>>Then registering one instance of this class with attribute name "foo"
>>versus "bar" could work as long as MyListener can prove that the two
>>instances are distinct (e.g. by comparing their "attribute names").
>>
>>- -chris
>>-BEGIN PGP SIGNATURE-
>>Comment: GPGTools - http://gpgtools.org
>>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>>iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltaDggACgkQHPApP6U8
>>pFhg2w//ZuhPBU6LzWYJksEKh/HcPLaXZODjqCUA8xl8EBEXyIbqu6Bafl2QlKxT
>>J2yprTHefOKAI7TOY8yPWtdiwCFCgI1yMOD6HDp4J5MhWziKV+0bbOjrrG1Vuia1
>>i1Sspvue3XyWVcpMF40/LGRC6BDlNcN+XqCfwfODXD5JLKxpaFZIKSLNDb2cttEH
>>7rJhQHwqxqGj5OUxlA5y/TRBzTKihH789PG0XKukXeYLzW64KhzB9kVIYJTgVmT4
>>rWOMUmMRBB2VVi4ovmmRy/O4Y8t0VXZvdQVb9EwVKlSKvnoO6tVLgsVGAKG966EB
>>SdTEBeUIkwPdYYbv2lL7OgpHAOUAmwBtwZhs8UFUCIU1nCi2FUS8kqbMNIlDk431
>>J8Ad9PQ3jh/A01m3X
[Bug 62558] Tomcat Russian localization
https://bz.apache.org/bugzilla/show_bug.cgi?id=62558 --- Comment #3 from Ivan Krasnov --- Hello Christopher! >I have not yet reviewed the patch, but theoretically, Tomcat should really be >detecting the user's UI language preference from the browser's Accept-Language >header. Is that not currently the case? Well, in my case tomcat didnt detect my user UI language. Moreover, by surfing the internet, I found that many people had such a problem. And the solution is to write in catalina.bat or catalina.sh(depends on OS) the lines that choose the language. >I forgot to say that I like the idea, generally, or more localized versions of >applications being available.The only problem is that they are often not kept >up-to-date because someone maybe adds a new feature and isn't sure how to >translate into X number of languages they don't speak. My prodject is Tomсat's translation into Russian. I'm going to completely translate it . So I thought, maybe you'll be interested in officially adding Russian localization to the source of the tomcat, along with the already existing German, French. I would like to know whether it's interesting for you to add the support of the Russian language. Adding a Russian localisation will help many Russian users, so i look forward to hearing from you! -- 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 60762] Enhancement: Add support for runtime SNI changes in tomcat-embed
https://bz.apache.org/bugzilla/show_bug.cgi?id=60762
--- Comment #20 from Mahesh ---
Sure. I could find some ways myself. Posting them here for anyone who comes
across this.
There is now a solution to this starting with Tomcat v8.5.24.
They introduced 2 methods named:
reloadSslHostConfig(String hostName) - to reload a specific host
reloadSslHostConfigs() - reload all
They can be called in various ways:
1. Using jmx
2. Using manager service
3. By making custom protocol - I found this way during my research
Details of way 1 and way 2 are easily available online.
Details of how to go about using way 3:
1. Make a class extending the protocol of your choice for eg.
Http11NioProtocol
2. Override the required methods and just call super in them to keep default
behavior
3. Make a thread in this class to call reloadSslHostConfigs method time to
time
4. Package this class in a jar and put that jar in tomcat's lib folder
5. Edit protocol in connector in server.xml to use this custom defined
protocol
Find sample code below:
Main protocol class:
package com.myown.connector;
import java.io.File;
import java.io.InputStream;
import java.lang.reflect.Field;
import java.net.URL;
import java.net.URLConnection;
import java.nio.file.StandardCopyOption;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ConcurrentMap;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.net.ssl.SSLSessionContext;
import org.apache.coyote.http11.Http11NioProtocol;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.modeler.Registry;
import org.apache.tomcat.util.net.AbstractEndpoint;
import org.apache.tomcat.util.net.AbstractJsseEndpoint;
import org.apache.tomcat.util.net.GetSslConfig;
import org.apache.tomcat.util.net.SSLContext;
import org.apache.tomcat.util.net.SSLHostConfig;
import org.apache.tomcat.util.net.SSLHostConfigCertificate;
import org.apache.tomcat.util.net.SSLImplementation;
import org.apache.tomcat.util.net.SSLUtil;
public class ReloadProtocol extends Http11NioProtocol {
private static final Log log =
LogFactory.getLog(Http12ProtocolSSL.class);
public ReloadProtocol() {
super();
RefreshSslConfigThread refresher = new
RefreshSslConfigThread(this.getEndpoint(), this);
refresher.start();
}
@Override
public void setKeystorePass(String s) {
super.setKeystorePass(s);
}
@Override
public void setKeyPass(String s) {
super.setKeyPass(s);
}
@Override
public void setTruststorePass(String p) {
super.setTruststorePass(p);
}
class RefreshSslConfigThread extends Thread {
AbstractJsseEndpoint abstractJsseEndpoint = null;
Http11NioProtocol protocol = null;
public RefreshSslConfigThread(AbstractJsseEndpoint
abstractJsseEndpoint, Http11NioProtocol protocol) {
this.abstractJsseEndpoint =
abstractJsseEndpoint;
this.protocol = protocol;
}
public void run() {
int timeBetweenRefreshesInt = 100; // time
in milli-seconds
while (true) {
try {
abstractJsseEndpoint.reloadSslHostConfigs();
System.out.println("Config Updated");
} catch (Exception e) {
System.out.println("Problem
while reloading.");
}
try {
Thread.sleep(timeBetweenRefreshesInt);
} catch (InterruptedException e) {
System.out.println("Error while
sleeping");
}
}
}
}
}
Connector in server.xml should mention this as the protocol:
Re: svn commit: r1836707 - in /tomcat/trunk/java/org/apache/catalina/tribes/membership: StaticMembershipProvider.java StaticMembershipService.java
2018-07-26 18:36 GMT+09:00 Mark Thomas : > On 26/07/2018 11:27, kfuj...@apache.org wrote: > >> Author: kfujino >> Date: Thu Jul 26 09:27:35 2018 >> New Revision: 1836707 >> >> URL: http://svn.apache.org/viewvc?rev=1836707&view=rev >> Log: >> Add New Static Membership Service implementations. >> - initial implementaion that remain a lot of TODOs. >> > > I appreciate that this is a work in progress. Can you explain the > differences / benefits / disadvantages of this vs. the > StaticMembershipInterceptor? > > I'd like to understand when I should use one or the other. > > The main motivations for implementing the new static membership are, I would like to implement this as a channel membership service instead of implementing it with the channel interceptors. Setting multiple interceptors is complicated in order to configure static membership. It should work with only StaticMembershipService setting. In other words, it should not depend on interceptors such as TcpFailureDetector and TcpPingInterceptor. Also, I wanted to unify the implementation of Tomcat clustering's membership service. Currently, McastService and StaticMembershipService are implemented in a unified way. If someone implements another membership service (like cloud membership?, for example) it can also use MembershipServiceBase and MembershipProviderBase in the same way. Thanks. > Thanks, > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- > Keiichi.Fujino > > >
