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/3678 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] 1844619 Blamelist: kfujino 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: buildbot failure in on tomcat-trunk
Am 23.10.2018 um 07:08 schrieb Igal Sapir: I am able to build locally on that same revision. Any ideas? You can see the reason by looking at the link included in the mail: https://ci.apache.org/builders/tomcat-trunk/builds/3677 On that page there's a red entry for "compile_1" and a link to its "stdio" (output text): https://ci.apache.org/builders/tomcat-trunk/builds/3677/steps/compile_1/logs/stdio That large output shows at the end, that running the tests failed for TEST-org.apache.catalina.connector.TestCoyoteOutputStream.NIO2.txt Running the tests is part of the build bot compile_1 step. I always forget where to find the detailed per test run output files. But I vaguely remember, that this specific test (TestCoyoteOutputStream for NIO2) sometimes fails for yet to be determined reasons. And the following build again succeeded. Regards, Rainer On Mon, Oct 22, 2018 at 9:51 PM wrote: 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/3677 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] 1844615 Blamelist: isapir 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
[Bug 62843] Tomcat Russian localization
https://bz.apache.org/bugzilla/show_bug.cgi?id=62843 --- Comment #1 from Konstantin Kolinko --- Ivan, do you verify what the final result is (after the patch is applied)? E.g. in the manager app "Deploy" and "Undeploy" are translated with the same word. It looks odd. -- 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
For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Can I get a technical review for (a) appropriateness and (b) technical
implementation of the attached cluster interceptor? Let's assume for a
moment that encryption is something worth adding to clustering and not
argue that point.
It should be straightforward. Knowing virtually nothing about the way
that Tribes works, implementing this as an interceptor seemed like the
least invasive (and easiest!) way to add encryption to clustering.
The only question I have about what I've actually written is what to
do about the cipher IV? Both sides of the conversation need to know
the IV in order to communicate. Should I just add another member to
the class for the IV and require that users specify both the key AND
the IV?
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8
pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ
l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5
cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+
zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc
frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf
jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA
PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5
Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR
GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj
wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm
LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ=
=nSgU
-END PGP SIGNATURE-
/*
* 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.group.interceptors;
import java.security.GeneralSecurityException;
import java.security.Key;
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import org.apache.catalina.tribes.Channel;
import org.apache.catalina.tribes.ChannelException;
import org.apache.catalina.tribes.ChannelMessage;
import org.apache.catalina.tribes.Member;
import org.apache.catalina.tribes.group.ChannelInterceptorBase;
import org.apache.catalina.tribes.group.InterceptorPayload;
import org.apache.catalina.tribes.util.StringManager;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.buf.HexUtils;
/**
* Adds encryption using a pre-shared key.
*/
public class EncryptInterceptor extends ChannelInterceptorBase {
private static final Log log = LogFactory.getLog(EncryptInterceptor.class);
protected static final StringManager sm =
StringManager.getManager(EncryptInterceptor.class);
private static final String DEFAULT_ENCRYPTION_ALGORITHM =
"AES/CBC/PKCS5Padding";
private String providerName;
private String encryptionAlgorithm = DEFAULT_ENCRYPTION_ALGORITHM;
private Key encryptionKey;
private Cipher encryptionCipher;
private Cipher decryptionCipher;
public EncryptInterceptor() {
}
@Override
public void start(int svc) throws ChannelException {
super.start(svc);
if(Channel.SND_TX_SEQ == svc) {
try {
initCiphers();
} catch (GeneralSecurityException gse) {
log.fatal(sm.getString("encryptInterceptor.init.failed"));
throw new
ChannelException(sm.getString("encryptInterceptor.init.failed"), gse);
}
}
}
@Override
public void sendMessage(Member[] destination, ChannelMessage msg,
InterceptorPayload payload)
throws ChannelException {
try {
byte[] data = msg.getMessage().getBytes();
data = encrypt(data);
msg.getMessage().trim(msg.getMessage().getLength());
msg.getMessage().append(data,0,data.length);
super.sendMessage(destination, msg, payload);
} catch (GeneralSecurityException gse) {
log.error(sm.getString("encryptInterceptor.encrypt.failed"));
throw new ChannelException(gse);
}
}
@Override
public void messageReceived(ChannelMessage msg)
[Bug 62830] Add static methods to load native libraries by the Common ClassLoader
https://bz.apache.org/bugzilla/show_bug.cgi?id=62830 --- Comment #16 from Christopher Schultz --- (In reply to Igal Sapir from comment #13) > (In reply to Christopher Schultz from comment #12) > > Sorry... I must be missing something, here. > > > > System.loadLibrary isn't ClassLoader-specific... once the library has been > > loaded, it can't be loaded again at all. > > > > The code here is all fine, and using a Listener makes a lot of sense. But > > the documentation suggests that somehow loading a shared lib in a different > > ClassLoader changes something when it doesn't. Instead, you are asking > > Tomcat to load it *once* (at the server level) and then not again. > > > > If you try to use this at the level, it will fail when > > re-deploying the , just like if the application had used > > It's counter-intuitive, I know. Here's what I tested right now, tell me know > if covers the scenario you described above: > > In conf/server.xml, I added the following snippet to the Server, Service, > and in conf/Catalina/localhost/ROOT.xml, > conf/Catalina/localhost/context_1.xml, conf/Catalina/localhost/context_2.xml > to the Context element: > > > > libraryName="opencv_java343" /> > > Below are the relevant log entries: > > > 22-Oct-2018 18:45:04.739 INFO [main] > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded native > > library opencv_java343 > > 22-Oct-2018 18:45:04.759 INFO [main] > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded native > > library opencv_java343 Okay. > Then I modified ROOT.xml, context_1.xml, and context_2.xml, one at a time: > > > 22-Oct-2018 18:45:51.692 INFO > > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded native > > library opencv_java343 > > [...] > > 22-Oct-2018 18:46:01.803 INFO > > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded native > > library opencv_java343 Interesting. I didn't realize that the JVM binds the native library to a specific ClassLoader and, does one of two things if the library has alreayd been loaded: 1. Ignores the call (if in the same ClassLoader; says so in javadoc for Runtime.loadLibrary) 2. Throws an UnsatisfiedLinkError complaining that the library is already loaded from a different ClassLoader. The Java spec[1] has something odd to say about native lirbaries and ClassLoaders, though it's still a little unclear: " The programmer may use a single library to store all the native methods needed by any number of classes, as long as these classes are to be loaded with the same class loader. The VM internally maintains a list of loaded native libraries for each class loader. " I guess "same class loader" can also mean "or a child class loader" since it's evidently working for you. But the point is that you need to consistently (re)load the native library into the same classloader if you don't want to throw any errors. [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#jni_interface_functions_and_pointers -- 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: buildbot failure in on tomcat-trunk
Rainer, On Tue, Oct 23, 2018 at 1:03 AM Rainer Jung wrote: > Am 23.10.2018 um 07:08 schrieb Igal Sapir: > > I am able to build locally on that same revision. > > > > Any ideas? > > You can see the reason by looking at the link included in the mail: > > https://ci.apache.org/builders/tomcat-trunk/builds/3677 > > On that page there's a red entry for "compile_1" and a link to its > "stdio" (output text): > I got to the link above, but I didn't see the link to the below until you pointed it out, thanks. > > > https://ci.apache.org/builders/tomcat-trunk/builds/3677/steps/compile_1/logs/stdio > > That large output shows at the end, that running the tests failed for > TEST-org.apache.catalina.connector.TestCoyoteOutputStream.NIO2.txt > > Running the tests is part of the build bot compile_1 step. > Understood. I only modified the documentation so I tested with `ant build-docs` and `ant clean deploy`. It makes sense though. > I always forget where to find the detailed per test run output files. > But I vaguely remember, that this specific test (TestCoyoteOutputStream > for NIO2) sometimes fails for yet to be determined reasons. > There is a suggestion to search for "ERROR" in the logs, but there is a test case that produces a log entry with "MUST_ERROR", which is a false positive. I wonder if we can change that? [junit] Exception in thread "testBug54928" java.lang.IllegalStateException: Calling [asyncComplete()] is not valid for a request with Async state [MUST_ERROR] > And the following build again succeeded. > Is there a way to trigger a new build without a commit, or should I try a "dummy" commit to trigger a build if I suspect that there was an intermittent problem with a test case? Thank you, Igal > Regards, > > Rainer > > > > On Mon, Oct 22, 2018 at 9:51 PM wrote: > > > >> 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/3677 > >> > >> 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] 1844615 > >> Blamelist: isapir > >> > >> 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 > >
[Bug 62830] Add static methods to load native libraries by the Common ClassLoader
https://bz.apache.org/bugzilla/show_bug.cgi?id=62830 --- Comment #17 from Igal Sapir --- (In reply to Christopher Schultz from comment #16) > (In reply to Igal Sapir from comment #13) > > (In reply to Christopher Schultz from comment #12) > > > > > > Below are the relevant log entries: > > > > > 22-Oct-2018 18:45:04.739 INFO [main] > > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded > > > native library opencv_java343 > > > 22-Oct-2018 18:45:04.759 INFO [main] > > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded > > > native library opencv_java343 > > Okay. > > > > Then I modified ROOT.xml, context_1.xml, and context_2.xml, one at a time: > > > > > 22-Oct-2018 18:45:51.692 INFO > > > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded > > > native library opencv_java343 > > > [...] > > > 22-Oct-2018 18:46:01.803 INFO > > > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > > > org.apache.catalina.core.JniLifecycleListener.lifecycleEvent Loaded > > > native library opencv_java343 > > Interesting. I didn't realize that the JVM binds the native library to a > specific ClassLoader and, does one of two things if the library has alreayd > been loaded: > > 1. Ignores the call (if in the same ClassLoader; says so in javadoc for > Runtime.loadLibrary) > 2. Throws an UnsatisfiedLinkError complaining that the library is already > loaded from a different ClassLoader. > > The Java spec[1] has something odd to say about native lirbaries and > ClassLoaders, though it's still a little unclear: Oh, that is a much newer version of the link that I posted in the OP. I'll give it a read. > "The programmer may use a single library to store all the native methods > needed by any number of classes, as long as these classes are to be loaded > with the same class loader. The VM internally maintains a list of loaded > native libraries for each class loader." > > I guess "same class loader" can also mean "or a child class loader" since > it's evidently working for you. I believe that this is due to the delegation model [2] of class loaders (or else that would have really been useless as Remy pointed out above): " When requested to find a class or resource, a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. " There is some variation in the Servlet spec for the order IIRC, but there is still delegation. > But the point is that you need to consistently (re)load the native library > into the same classloader if you don't want to throw any errors. It's not actually re-loading. As you cited above, subsequent calls are ignored, but yes, they must be done in the same class loader or its lineage. That's the reason for adding the static methods to Library and adding the Listener. Because these classes are in $CATALINA_HOME/lib, the native library to be loaded by a shared class loader which is in the lineage. > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design. > html#jni_interface_functions_and_pointers [2] https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.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
Re: For review: EncryptInterceptor for Cluster/Tribes
On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > Can I get a technical review for (a) appropriateness and (b) technical > implementation of the attached cluster interceptor? Let's assume for a > moment that encryption is something worth adding to clustering and not > argue that point. > Sure! But maybe you can narrow down the need/use case? ie, would just point-to-point TLS be sufficient? so that all bytes got encrypted? or do you want a WhatsApp type of security, where only sender and receiver can share the a specific data package? > > It should be straightforward. Knowing virtually nothing about the way > that Tribes works, implementing this as an interceptor seemed like the > least invasive (and easiest!) way to add encryption to clustering. > > The only question I have about what I've actually written is what to > do about the cipher IV? Both sides of the conversation need to know > the IV in order to communicate. Should I just add another member to > the class for the IV and require that users specify both the key AND > the IV? > That would be one way. I think the idea of having to share a key may be the only drawback in your implementation. Have you considered maybe using asymmetrical encryption? In that scenario, you would have MemberImpl.payload = certificate or public key Each member can broadcast their certificate, and a sender can use it to encrypt the data only the receiver can read. No sharing of keys. The encryption would still be done in an interceptor just like you have it. The Local member would hold the private key for decryption. Filip > > Thanks, > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8 > pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ > l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5 > cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+ > zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc > frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf > jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA > PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5 > Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR > GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj > wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm > LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ= > =nSgU > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
On 23/10/2018 18:19, Filip Hanik wrote: On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, Can I get a technical review for (a) appropriateness and (b) technical implementation of the attached cluster interceptor? Let's assume for a moment that encryption is something worth adding to clustering and not argue that point. Sure! But maybe you can narrow down the need/use case? ie, would just point-to-point TLS be sufficient? so that all bytes got encrypted? or do you want a WhatsApp type of security, where only sender and receiver can share the a specific data package? It should be straightforward. Knowing virtually nothing about the way that Tribes works, implementing this as an interceptor seemed like the least invasive (and easiest!) way to add encryption to clustering. The only question I have about what I've actually written is what to do about the cipher IV? Both sides of the conversation need to know the IV in order to communicate. Should I just add another member to the class for the IV and require that users specify both the key AND the IV? That would be one way. I think the idea of having to share a key may be the only drawback in your implementation. Have you considered maybe using asymmetrical encryption? In that scenario, you would have MemberImpl.payload = certificate or public key Each member can broadcast their certificate, and a sender can use it to encrypt the data only the receiver can read. No sharing of keys. The encryption would still be done in an interceptor just like you have it. The Local member would hold the private key for decryption. That brings you back to the full TLS style solution with trust-stores and associated certificate authority management. If you skip that, you open yourself up to MITM attacks. I think a shared symmetric key is a reasonable solution to this use case. Requiring the user to specify the key and the iv seems reasonable to me. Mark Filip Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8 pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5 cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+ zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5 Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ= =nSgU -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump-vm3]: Project tomcat-tc7.0.x-test-apr (in module tomcat-7.0.x) failed
I've attempted to fix this in Gump. I don't expect to have got it right first time. We'll have to wait until the next Gump run (00.00 UTC) to see how close I got. Mark On 22/10/2018 22:22, Mark Thomas wrote: On 22/10/2018 09:19, Bill Barker wrote: To whom it may engage... test-compile: [javac] Compiling 168 source files to /srv/gump/public/workspace/tomcat-7.0.x/output/testclasses [javac] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/catalina/valves/TestCrawlerSessionManagerValve.java:43: error: incompatible types: Object cannot be converted to Valve [javac] valve.setNext(EasyMock.createMock(Valve.class)); This is the change the broke this: https://github.com/easymock/easymock/issues/229 If the compiler compliance level is set to Java 7 or below, Java can't/doesn't correctly infer the types so it assumes Object which triggers the issues like the one above. The fix is probably to configure Gump to use the latest EasyMock 3.x for 7.0.x and 8.5.x and continue to build EasyMock HEAD for use with 9.0.x. I'll try and get to that tomorrow but I may not have time. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Filip, On 10/23/18 12:19, Filip Hanik wrote: > On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > All, > > Can I get a technical review for (a) appropriateness and (b) > technical implementation of the attached cluster interceptor? Let's > assume for a moment that encryption is something worth adding to > clustering and not argue that point. > > >> Sure! But maybe you can narrow down the need/use case? ie, would >> just point-to-point TLS be sufficient? so that all bytes got >> encrypted? I wanted something that was a little more accessible. TLS would be a better, more robust solution, but I wanted something quicker :) As for point-to-point, it won't work over multicast. Maybe DTLS? I don't know enough about it. >> or do you want a WhatsApp type of security, where only sender and >> receiver can share the a specific data package? This is just for simple Tomcat clustering, actually. > It should be straightforward. Knowing virtually nothing about the > way that Tribes works, implementing this as an interceptor seemed > like the least invasive (and easiest!) way to add encryption to > clustering. > > The only question I have about what I've actually written is what > to do about the cipher IV? Both sides of the conversation need to > know the IV in order to communicate. Should I just add another > member to the class for the IV and require that users specify both > the key AND the IV? > >> That would be one way. I think the idea of having to share a key >> may be the only drawback in your implementation. Have you >> considered maybe using asymmetrical encryption? Nope: I wanted quick dirty. Configuring a Tomcat cluster requires manual configuration of each of the nodes, anyway, so adding a pre-shared key isn't a big deal. As for the IV, I've been thinking about that. Using a one-block-sized IV (or even just a one-block-sized nonce) and throwing-away the IV will suffice. The first block can't be reliably decrypted, but because it's a nonce anyway, it doesn't matter. The receiver can always ignore the first block of data. This requires an overhead of one-block of data. For AES, that's 16 bytes, which isn't too bad. >> In that scenario, you would have MemberImpl.payload = certificate >> or public key Each member can broadcast their certificate, and a >> sender can use it to encrypt the data only the receiver can >> read. No sharing of keys. > >> The encryption would still be done in an interceptor just like >> you have it. The Local member would hold the private key for >> decryption. This might not be a bad idea for a second / alternate implementation. For now, I just wanted something that /worked/. Some people "just want encryption". :) OpenVPN, stunnel, etc. are all possibilities, but they require you to configure some other component. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPgHQACgkQHPApP6U8 pFhD6A/8Dt1EfHcJXjsVNh7YeR7Q9O/yul/e+I3OkYIwHd9oY6fCkI3zpmLiOyqt s1dZsnj8OkKcGnfbDZvwohCe+8NmEvFRaYB+HLWHbdyCgorFd8S09kThQYe7q3Cx YlY9p6eNAKciFd/nVrq6ANWLlHZYVtzFJtEGdMQjFb+XJmwcLZxdHQLY1Ol/lYkS D6NKDgXv5rWSE2KpnBulg61qLtIp5/bNpoRo33EswA9iq9DS1902C+YgaIsObWuA Uru4Q72ySpNNd3wVJbMnCmle458UIBcb+8M5xHdFo4sErknce0xVyIGgCHv+lFbB LHHhB0pAWtPOntITIg9xLn3kDei1eIMnhKslpq9wHqKjkDhlJSzDWkBdyU0VMghe 7cP2VeB9R1450hSpYY80meVhXqHMwEc8Vlwfi7S2qnPPi1ujcxOrjk/DQWsEEv80 OnXQqHtm6Is3Y18JWOMs+C6O9rwqu0glrkfLLyjsB8ZYSqv5hARw1OciZaqhHHLh mvparuHuf9z3fLziL4bwmHxwBtxsNEz5TQIqzBndMviMxWJkJPVDOH4uHyO3oS8w hkFPGXToomQuJLM1Mne+LoLGu9h0Z9UlJ0awYuu2jOFcKLnzzERzUALQVw4D0e07 nV9ppWVSLgXlvOMfYxl0EtX9N2nd93owz+P2WjUpYLMk2ZYgH8o= =VZba -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 10/23/18 10:05, Christopher Schultz wrote: > Can I get a technical review for (a) appropriateness and (b) > technical implementation of the attached cluster interceptor? Let's > assume for a moment that encryption is something worth adding to > clustering and not argue that point. > > It should be straightforward. Knowing virtually nothing about the > way that Tribes works, implementing this as an interceptor seemed > like the least invasive (and easiest!) way to add encryption to > clustering. For the record, I haven't tested this AT ALL. I just made it compile :) If someone has a test-cluster available, could you please try to add this (it just requires an "encryptionKey" attribute on the interceptor... just use "cafebabe" or something simple) and see if (a) the messages flow properly and (b) they transmit in non-plaintext? Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPgRMACgkQHPApP6U8 pFgROg//db0iK87mkSIVs/so72nemDkmUjjz158ccjl8AT7cLzEbEanPB0/3TghT lKuQKeQRD97xYbNbFCxoWdowkaEt25w0Qpl3mht363jFdF9xPLCYMj7xtLc7brv6 m/KTHhcbsBb4cgkOK1o6gcbzKUmPB2v5IWhIPG09Aa9rce2yT9TNjAyyARqcOdp0 tuh0jT8ksvuojM6u9hfOvrK8xO5GX223ljPCHNBQvqprqOaOtoKfN349BvZx3MvZ vwn+cn5fKbmU6hucq5X0kBVg7r4SbhGt3+S3a7VLfl3cWAxf3jzkq45KHsB8/gON RoI2AqDqD9w9pDQ1CZAG953nAFAnKDR1xng63MDNgD05w34hkGloMe4ytJjX4tLL kOr0vx1pqfKSYEqTzoJUfTzgaKmDW7WBYNM/JsrJ+jG+Y0/xdQDIvyEsBgozVVWK bIMXibAviXHypnY1UfhVgJgpgWwhra+XGJEbGYHEtQijClM0NRaERsQaVGCxbkbA ncbi0EwHw2MC5cRZZdY38sxPbYVk9omcQywTiaIHxtQA0FZxRP/r/NNMnw5X2UXA 7+ox7mrjpleaf6dB2CxNl5Yc/186wqSicsw93ekLNm1RyuN0bHOQzyKJ/rWMae+S wt9iED9aidu4go4fKplugb436KSHVSksVcFwnjDX0aEj1Dq/T70= =5+TL -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62773] Change DeltaManager to handle session deserialization problems more robustly
https://bz.apache.org/bugzilla/show_bug.cgi?id=62773 --- Comment #1 from Mitch Claborn --- Created attachment 36208 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36208&action=edit patch that implements the described changes This code has been running in our moderately busy website for several weeks with no problems. -- 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
FYI: I've created the Bugzilla request and submitted the patch there. https://bz.apache.org/bugzilla/show_bug.cgi?id=62773 Mitch On 9/27/18 5:49 PM, Mark Thomas wrote: Mitch, First some general comments. Projects at the ASF generally operate using lazy consensus meaning if no-one objects after a reasonable amount of time (72 hours is a good starting point for reasonable) then assume you have agreement to proceed. Note that it is ApacheCon NA this week so a number of the committers may be distracted and/or travelling. It sounds like a good next step would be to create a Bugzilla enhancement request and attach your patch. Mark - 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-test-nio (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-test-nio has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 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-test-nio : 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-test-nio/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on bnd exists, no need to add for property bndlib.jar. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-NIO -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-NIO/logs -WARNING- No directory [/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-NIO/logs] The following work was performed: http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-test-nio/gump_work/build_tomcat-trunk_tomcat-trunk-test-nio.html Work Name: build_tomcat-trunk_tomcat-trunk-test-nio (Type: Build) Work ended in a state of : Failed Elapsed: 24 mins 5 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-trunk/true -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-3.1-SNAPSHOT.jar -Dtest.reports=output/logs-NIO -Dexecute.test.nio2=false -Dexamples.sources.skip=true -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.7.3a-201803300640/ecj-4.7.3a.jar -Dbndlib.jar=/srv/gump/packages/bnd/bndlib-4.0.0/biz.aQute.bndlib-4.0.0.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/target/commons-daemon-1.1.1-SNAPSHOT.jar -Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20181024/bin/openssl -Dtest.temp=output/test-tmp-NIO -Dtest.accesslog=true -Dexecute.test.nio=true -Dbnd.jar=/srv/gump/packages/bnd/bnd-4.0.0/biz.aQute.bnd-4.0.0.jar -Dexecute.test.apr=false -Dtest.excludePerformance=true -Dtest.relaxTiming=true -Deasymock.jar=/srv/gump/public/workspace/easymock/core/target/easymock-4.0-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-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/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-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jaspic-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomca
svn commit: r1844717 - /tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml
Author: isapir Date: Wed Oct 24 03:50:41 2018 New Revision: 1844717 URL: http://svn.apache.org/viewvc?rev=1844717&view=rev Log: Added JniLifecycleListener statement to security-howto BZ 62830 Modified: tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml?rev=1844717&r1=1844716&r2=1844717&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml Wed Oct 24 03:50:41 2018 @@ -233,8 +233,9 @@ The APR Lifecycle Listener is not stable if compiled on Solaris using gcc. If using the APR/native connector on Solaris, compile it with the Sun Studio compiler. - - The Security Listener should be enabled and configured as appropriate. + The JNI Library Loading Listener may be used to load native code. It should + only be used to load trusted libraries. + The Security Lifecycle Listener should be enabled and configured as appropriate. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1844718 - /tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml
Author: isapir Date: Wed Oct 24 03:50:51 2018 New Revision: 1844718 URL: http://svn.apache.org/viewvc?rev=1844718&view=rev Log: Added JniLifecycleListener statement to security-howto BZ 62830 Modified: tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml Modified: tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml?rev=1844718&r1=1844717&r2=1844718&view=diff == --- tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml (original) +++ tomcat/tc8.5.x/trunk/webapps/docs/security-howto.xml Wed Oct 24 03:50:51 2018 @@ -239,8 +239,9 @@ The APR Lifecycle Listener is not stable if compiled on Solaris using gcc. If using the APR/native connector on Solaris, compile it with the Sun Studio compiler. - - The Security Listener should be enabled and configured as appropriate. + The JNI Library Loading Listener may be used to load native code. It should + only be used to load trusted libraries. + The Security Lifecycle Listener should be enabled and configured as appropriate. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62851] New: Forward to relative path using Dispatcherservlet does results 404
https://bz.apache.org/bugzilla/show_bug.cgi?id=62851
Bug ID: 62851
Summary: Forward to relative path using Dispatcherservlet does
results 404
Product: Tomcat 8
Version: 8.0.x-trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: manishks...@gmail.com
Target Milestone:
Created attachment 36209
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36209&action=edit
Sample code to reproduce
Forwarding requests to relative path earlier worked with Tomcat-8.0.43.
After upgrading to recent Tomcat versions the forwarding leads to 404 NOT FOUND
error.
```RequestDispatcher rd = request.getRequestDispatcher("../../main");
rd.forward(request, response);```
On investigation, it was found that Tomcat changed behavior with this commit
Tomcat upgraded behavior to return non-normalized requestURI in
ApplicationDispatcher.
https://github.com/apache/tomcat80/commit/21f57c23780950fcf838ffe9a0fba17cc5247691#diff-8b91a9296e19012bf6be4bdf975fab0dR499
Attaching sample application for reproducing the scenario. Can someone look
into 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
svn commit: r1844723 - in /tomcat/trunk/bin: makebase.bat makebase.sh
Author: isapir
Date: Wed Oct 24 05:12:00 2018
New Revision: 1844723
URL: http://svn.apache.org/viewvc?rev=1844723&view=rev
Log:
Added empty ROOT dir and run instructions to makebase
Modified:
tomcat/trunk/bin/makebase.bat
tomcat/trunk/bin/makebase.sh
Modified: tomcat/trunk/bin/makebase.bat
URL:
http://svn.apache.org/viewvc/tomcat/trunk/bin/makebase.bat?rev=1844723&r1=1844722&r2=1844723&view=diff
==
--- tomcat/trunk/bin/makebase.bat (original)
+++ tomcat/trunk/bin/makebase.bat Wed Oct 24 05:12:00 2018
@@ -90,6 +90,8 @@ if "%COPY_WEBAPPS%" == "true" (
) else (
rem copy conf directory without subdirectories and suppress warning
robocopy %CATALINA_HOME%\conf %BASE_TGT%\conf > nul
+rem create empty ROOT directory
+mkdir %BASE_TGT%\webapps\ROOT
)
rem copy setenv.bat if exists
@@ -97,8 +99,16 @@ robocopy %CATALINA_HOME%\bin %BASE_TGT%\
echo Created CATALINA_BASE directory at %BASE_TGT%
+echo
+echo You can launch the new instance by running:
+echo set CATALINA_HOME=%CATALINA_HOME%
+echo set CATALINA_BASE=%BASE_TGT%
+echo %%CATALINA_HOME%%/bin/catalina.bat run
+
+echo
echo Attention: The ports in conf\server.xml might be bound by a
-echodifferent instance. Please review your config files
-echoand update them where necessary.
+echo different instance. Please review your config files
+echo and update them where necessary.
+echo
:EOF
Modified: tomcat/trunk/bin/makebase.sh
URL:
http://svn.apache.org/viewvc/tomcat/trunk/bin/makebase.sh?rev=1844723&r1=1844722&r2=1844723&view=diff
==
--- tomcat/trunk/bin/makebase.sh (original)
+++ tomcat/trunk/bin/makebase.sh Wed Oct 24 05:12:00 2018
@@ -92,6 +92,8 @@ if [ "$COPY_WEBAPPS" = true ]; then
else
# copy conf directory without subdirectories and suppress warning
cp "${CATALINA_HOME}/conf"/* "$BASE_TGT/conf" 2> /dev/null
+# create empty ROOT directory
+mkdir "$BASE_TGT/webapps/ROOT"
fi
# copy setenv.sh if exists
@@ -100,6 +102,14 @@ fi
echo "Created CATALINA_BASE directory at $BASE_TGT"
+echo
+echo "You can launch the new instance by running:"
+echo "export CATALINA_HOME=$CATALINA_HOME"
+echo "export CATALINA_BASE=$BASE_TGT"
+echo "\$CATALINA_HOME/bin/catalina.sh run"
+
+echo
echo "Attention: The ports in conf/server.xml might be bound by a "
-echo " different instance. Please review your config files "
-echo " and update them as necessary."
+echo "different instance. Please review your config files "
+echo "and update them as necessary."
+echo
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1844724 - /tomcat/trunk/bin/makebase.bat
Author: isapir Date: Wed Oct 24 05:29:54 2018 New Revision: 1844724 URL: http://svn.apache.org/viewvc?rev=1844724&view=rev Log: Fixed empty line on Windows makebase script Modified: tomcat/trunk/bin/makebase.bat Modified: tomcat/trunk/bin/makebase.bat URL: http://svn.apache.org/viewvc/tomcat/trunk/bin/makebase.bat?rev=1844724&r1=1844723&r2=1844724&view=diff == --- tomcat/trunk/bin/makebase.bat (original) +++ tomcat/trunk/bin/makebase.bat Wed Oct 24 05:29:54 2018 @@ -99,16 +99,16 @@ robocopy %CATALINA_HOME%\bin %BASE_TGT%\ echo Created CATALINA_BASE directory at %BASE_TGT% -echo +echo. echo You can launch the new instance by running: echo set CATALINA_HOME=%CATALINA_HOME% echo set CATALINA_BASE=%BASE_TGT% echo %%CATALINA_HOME%%/bin/catalina.bat run -echo +echo. echo Attention: The ports in conf\server.xml might be bound by a echo different instance. Please review your config files echo and update them where necessary. -echo +echo. :EOF - 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/3679 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] 1844723 Blamelist: isapir 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
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/3680 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] 1844724 Blamelist: isapir 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: buildbot failure in on tomcat-trunk
It's the same test case that failed yesterday: [concat] Testsuites with failed tests: [concat] TEST-org.apache.catalina.connector.TestCoyoteOutputStream.NIO2.txt Igal On Tue, Oct 23, 2018 at 10:37 PM wrote: > 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/3679 > > 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] 1844723 > Blamelist: isapir > > 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 > >
