Re: tomcat9 classpath
вт, 6 окт. 2020 г. в 23:11, Christopher Schultz : > > Nothing you add or remove from catlaina.properties will change what is > shown when you run "ps" and look at the command-line used to launch the JVM. > > Fortunately, it doesn't matter. Tomcat will configure the "common" and > "shared" ClassLoaders with the correct list of JARs you specify in > catalina.properties, and those libraries will be available to the server > and/or your application(s). The fact that they are not in the "ps" > output for "-classpath [stuff]" does not matter. +1 The manual: https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: completely automated (for real) Let's Encrypt on embedded Tomcat
On 10/6/20 2:48 PM, Christopher Schultz wrote: Thanks for mentioning LEGO. Any time I've been mentioning certbot, you can replace that with $your-favorite-acme-client. You're welcome. LEGO definitely cut my Gordian Knot on that particular project, wherein Certbot absolutely, positively, refused to work. The other AWS installations either have httpd handling the https front-ending, or they have a load-balancer handling it, with Amazon itself providing the certs. So I'm always likely to suggest it as a second choice (and one that appears to play much more nicely with Tomcat) if certbot won't do it in a given situation. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: completely automated (for real) Let's Encrypt on embedded Tomcat
James, On 10/5/20 19:59, James H. H. Lampert wrote: > I'm coming into this conversation late, so what I say could be > completely irrelevant, but when I recently set up an independent (i.e., > not behind httpd) Tomcat server on one of our AWS EC2 instances, and > could not get certbot to function at all, to save my life, I ended up > using something called "LEGO." Thanks for mentioning LEGO. Any time I've been mentioning certbot, you can replace that with $your-favorite-acme-client. > It *does* require one to shut the Tomcat server down during the > renewal process (because it has to take over the port briefly), but > it also *does* play nicely with a Tomcat server that's doing its own > SSL. You *should* be able to do this without stopping Tomcat, but it might end up complicating other things. If you have a reverse proxy server, this is trivial to avoid. If you are binding Tomcat directly to port 80, this is not so easy. Another option is to use DNS-based authentication where your web server isn't involved. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: completely automated (for real) Let's Encrypt on embedded Tomcat
Garret, On 10/5/20 19:45, Garret Wilson wrote: > On 10/5/2020 2:42 PM, Christopher Schultz wrote: >> … >> Sure, it can contain S3 credentials and you can pick-up your key and >> certificate (or, better yet, the whole keystore) there, but at that >> point you have "moved" the problem outside of Tomcat, right? > > No, not at all. The major problems are: > > 1. Generating the certificate automatically. > 2. Feeding the certificate to Tomcat automatically. > > If the "extra" thing I have to do is specify an environment variable > with the name of the S3 bucket to use as a certificate state, then that > is a teeny, tiny problem. That is not really even a problem. > > Can you imagine if in my spring boot application I could run it using > "java -jar my-app.jar --cert-work-bucket my-bucket" and it would just go > get a certificate automatically? What if your Docker container would just run certbot on launch? >> You can have a "certificate renewal service" that writes to S3. > > I want it built into my application as a module. You just include the > module, specify the domain name (and maybe a couple of other details > needed by RFC 8555, such as a contact email), and boom, it all happens > automatically. > > Why does it have to be more difficult than that? It shouldn't be. Fair enough. >> I suppose you could put that directly into Tomcat, but Tomcat is not >> likely to ship with an Amazon-specific feature built-into it. > > > Read my original email. I never intended to put this directly into > standalone Tomcat (although if you want to put it into Tomcat you're > welcome to). I want to use this with an application running on embedded > Tomcat. Spring Boot is a prime example. I'll just extend the Spring Boot > embedded Tomcat module and extend/modify that as needed. If that > requires modifying Tomcat code, fine. > >> Another idea would be to use embedded Tomcat (or, at your suggestion, >> Spring Boot) and fetch the keystore from some "standard" location of >> your choosing. Again, that would be (appropriately, IMO) outside Tomcat >> code. > > That was always the intention. In my introduction to my original email I > explained that the modern approach is moving away from something like > standalone Tomcat to self-contained executables that run their own > servers, whether embedded Tomcat or whatever. (I was late to the party, > and even two years ago I wasn't getting it.) I'm not sure I'd say "modern approach". It's certainly popular these days, for sure. >> 1. Does acme4j allow me to verify my certificate behind another port? >> (e.g. ElasticBeanstalk deploys a JAR behind NGINX port 5000 by >> default. I'm still reading RFC 8555 to find out if the ACME server >> has to connect back on a certain port for verification.) >> 2. Once I have the Let's Encrypt certificate, can I convert to PKCS12 >> for Tomcat completely in the application without shelling out to >> openssl or keytool? I'm hoping Bouncy Castle and/or acme4j-util will >> allow me to do that. >> This can be done, but it's non-trivial. For example, Tomcat contains >> code to package PEM-encoded DER files (good old OpenSSL-style =BEGIN >> CERTIFICATE= things) into an in-memory keystore to configure JSSE. >> It seems like it would be straightforward, but it turns out not to be in >> all cases. YMMV. > > Non-trivial as it may be, it /only needs to be done once/. If I have a > converter, then I can use it a thousand times. A million times. And > suddenly the deployment becomes a piece of cake. > > In reality, today's style of handling SSL is what matches your > description of "It seems like it would be straightforward, but it turns > out not to be …". So why do we keep doing all this difficult, manual, > tedious, not-trivial stuff to deploy certificates the hard way, when we > could put our efforts into a single no-trivial task of making a > converter so that Tomcat can use the Let's Encrypt certificates > directly? We do it once. It's hard, but then everything else is easy. I > don't get why we want to spend another decade doing it the hard way when > we can spend one year on a different hard task and then do SSL the easy > way for the other nine. > > (The frustration isn't directed at you. It's just in general in software > development I see the industry—why does the most basic of things have to > be so difficult?) > >> 3. Once I have the PKCS12, how do I feed it to the embedded Tomcat? >> If it's a file on the disk, it's easy: just use the path. > > Can I pass it in memory? If not, why not? How is memory less accessible > than a file? Yes, you can pass it in-memory, but you have to arrange to load the key material from somewhere into memory. And sometimes the key material can be in a surprising series of formats. >>> Chris, where can I get more information on the latter questions about >>> getting this certificate to Tomcat once I have it? >> This mailing list is a good place to start (and likely finish
Re: tomcat9 classpath
Raivo, Please don't email directly. Use the mailing list instead. (Apologies if I emailed both you AND the list.) On 10/6/20 14:59, Raivo Rebane wrote: > How I undrestand is that these files is added to tomcat common classpath > or does there are several classpaths ? In Java there can be many ClassLoaders. Each ClassLoader has a "classpath" of sorts: a list of places where it can load classes. The word "classpath" is usually reserved for the classpath handed to the JVM when it launches. > if I add following line into catalina.properties file: > > shared.loader="/opt/tomcat/latest/lib/*.jar" > Nothing changes Nothing you add or remove from catlaina.properties will change what is shown when you run "ps" and look at the command-line used to launch the JVM. Fortunately, it doesn't matter. Tomcat will configure the "common" and "shared" ClassLoaders with the correct list of JARs you specify in catalina.properties, and those libraries will be available to the server and/or your application(s). The fact that they are not in the "ps" output for "-classpath [stuff]" does not matter. -chris > On 06.10.20 21:36, Christopher Schultz wrote: >> Raivo, >> >> On 10/6/20 12:27, Raivo Rebane wrote: >>> Hello >>> >>> I have following line in catalina.properties file where I want to add >>> /opt/tomcat/latest/lib/*.jar to classpath >>> >>> But If I start Tomcat9 no jars appear in classpath. >> Which classpath? >> >>> and line in catalina.properties is following: >>> >>> common.loader="/opt/tomcat/latest/lib/*.jar","/opt/tomcat/latest/bin/*.jar" >>> >>> >>> Tomcat runs without a;most jars >>> >>> 21307 ? Sl 0:02 /usr/lib/jvm/default-java/bin/java >>> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties >>> >>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >>> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true >>> -Djdk.tls.ephemeralDHKeySize=2048 >>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources >>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M >>> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath >>> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar >>> >>> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest >>> -Djava.io.tmpdir=/opt/tomcat/latest/temp >>> org.apache.catalina.startup.Bootstrap start >> Are you talking about the -classpath specified in the JVM launch? This >> is entirely expected. >> >> Once Tomcat starts up, another ClassLoader is initialized with the JAR >> files in common.loader in it. You won't see that on the command-line. >> >>> The list of directory /opt/tomcat/latest/lib/*.jar is here: >>> >>> -rw-r-x--- 1 tomcat tomcat 13342 sept 10 11:23 >>> /opt/tomcat/latest/lib/annotations-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 54652 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina-ant.jar* >>> -rw-r-x--- 1 tomcat tomcat 124406 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina-ha.jar* >>> -rw-r-x--- 1 tomcat tomcat 1699600 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina.jar* >>> -rw-r-x--- 1 tomcat tomcat 63246 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina-ssi.jar* >>> -rw-r-x--- 1 tomcat tomcat 78788 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina-storeconfig.jar* >>> -rw-r-x--- 1 tomcat tomcat 347015 sept 10 11:23 >>> /opt/tomcat/latest/lib/catalina-tribes.jar* >>> -rw-r-x--- 1 tomcat tomcat 2989263 sept 10 11:23 >>> /opt/tomcat/latest/lib/ecj-4.15.jar* >>> -rw-r-x--- 1 tomcat tomcat 91104 sept 10 11:23 >>> /opt/tomcat/latest/lib/el-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 171308 sept 10 11:23 >>> /opt/tomcat/latest/lib/jasper-el.jar* >>> -rw-r-x--- 1 tomcat tomcat 564673 sept 10 11:23 >>> /opt/tomcat/latest/lib/jasper.jar* >>> -rw-r-x--- 1 tomcat tomcat 28549 sept 10 11:23 >>> /opt/tomcat/latest/lib/jaspic-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 63811 sept 10 11:23 >>> /opt/tomcat/latest/lib/jsp-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 283767 sept 10 11:23 >>> /opt/tomcat/latest/lib/servlet-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 11649 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-api.jar* >>> -rw-r-x--- 1 tomcat tomcat 908183 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-coyote.jar* >>> -rw-r-x--- 1 tomcat tomcat 322469 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-dbcp.jar* >>> -rw-r-x--- 1 tomcat tomcat 69258 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-cs.jar* >>> -rw-r-x--- 1 tomcat tomcat 75197 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-de.jar* >>> -rw-r-x--- 1 tomcat tomcat 104921 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-es.jar* >>> -rw-r-x--- 1 tomcat tomcat 165365 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-fr.jar* >>> -rw-r-x--- 1 tomcat tomcat 187546 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-ja.jar* >>> -rw-r-x--- 1 tomcat tomcat 188011 sept 10 11:23 >>> /opt/tomcat/latest/lib/tomcat-i18n-ko.jar* >>> -rw-r-x-
Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x
Larvi, On 10/6/20 14:36, Larvi wrote: > Chris, > > I know this issue is strange and I too dont know what exactly is going on, > for now I am only able to replicate this issue and find a workaround for > this, so let me explain how I am able to replicate this issue. > > Case 1: > When I login to the application using the dns for the first time it works > fine What does "login to the application using the dns" mean? I usually use something like username+password to login to an application. > as for the first time we redirect to another login application that > after authentication redirect us to our direct url( which works fine). So... single-sign-on or something like that? What application / API / technology are you using for this authentication hand-off? > But when I open the application again using the same dns url it picks > up data from cookies and some of the functionality does not work. Which cookies? > Case 2: > When I login to another application which uses the same login application > as I use, and then open our application from the dns url then this issue > occurs. > > I would also like to add that when I use the other dns url What "other dns url"? Please be very specific. > for the same application it works fine for both the cases I mentioned > above. And we tried to clear our browser cache, cookies and also > tomcat's work/Catalina/localhost directories then rebouncing the > tomcat. But we still are having this issue. Cookies are usually only sent by the browser if everything matches. Try showing the developer console in your web browser and going through the login process. Check each request for request and response headers, checking to see that the cookies and other stuff you expect are in there. Also look at the "console", as you might see some warnings. I'm specifically thinking of an incorrect "samesite" cookie configuration. -chris > On Tue, Oct 6, 2020, 23:45 Christopher Schultz > wrote: > >> Larvi, >> >> On 10/6/20 03:28, Larvi wrote: >>> Can you please help me with this. >> >> Can you give some examples? It's not easy to understand what you are >> doing and what is happening to you. >> >> -chris >> >>> On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy wrote: >>> Hi Chris, Yes, When I did $ host [hostname], I get the IP address that I am trying to use. Below are the Engine and Host configurations from server.xml. >>>resourceName="UserDatabase"/> >>> unpackWARs="true" autoDeploy="true"> >>> directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%v %h %l %S %u %t "%r" %s %b" /> On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz < ch...@christopherschultz.net> wrote: >> Larvi, >> >> On 9/28/20 10:04, Larvi Boy wrote: >>> Hi, >>> >>> When I try to login to out web gui via direct link, it is working >> fine > but >>> when I used the dns url, for first time it works fine as for the >> first > time >>> we are redirected to our login page which redirects us back to my > direct >>> link, but if we create another window with same dns link, some >> buttons > in >>> the jsp are not working. We cleared the cache but didn't help. >>> >>> I checked the application logs but there were no logs for the actions > that >>> should occur after click and I checked tomcat catalina.out and > localhost >>> logs and there is no error there. >>> >>> We have 2 dns urls but we are not facing this issue with the other >> dns > url. >>> >>> Can you please help me on this. >>> >>> Please ask if more information is needed. >> >> Can you give some examples? What happens if you: >> >>> $ host [hostname] >> >> Do you get the same IP address that you are trying to use? >> >> Please post your and configuration from server.xml. >> Remove any secrets you may have in there. >> >> -chris > > >>> Thanks, >>> Larvi >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x
Chris, I know this issue is strange and I too dont know what exactly is going on, for now I am only able to replicate this issue and find a workaround for this, so let me explain how I am able to replicate this issue. Case 1: When I login to the application using the dns for the first time it works fine as for the first time we redirect to another login application that after authentication redirect us to our direct url( which works fine). But when I open the application again using the same dns url it picks up data from cookies and some of the functionality does not work. Case 2: When I login to another application which uses the same login application as I use, and then open our application from the dns url then this issue occurs. I would also like to add that when I use the other dns url for the same application it works fine for both the cases I mentioned above. And we tried to clear our browser cache, cookies and also tomcat's work/Catalina/localhost directories then rebouncing the tomcat. But we still are having this issue. Thanks, Larvi On Tue, Oct 6, 2020, 23:45 Christopher Schultz wrote: > Larvi, > > On 10/6/20 03:28, Larvi wrote: > > Can you please help me with this. > > Can you give some examples? It's not easy to understand what you are > doing and what is happening to you. > > -chris > > > On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy wrote: > > > >> Hi Chris, > >> > >> Yes, When I did $ host [hostname], I get the IP address that I am trying > >> to use. > >> > >> Below are the Engine and Host configurations from server.xml. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >>resourceName="UserDatabase"/> > >> > >> > >>>> unpackWARs="true" autoDeploy="true"> > >> > >> > >> > >> > >> > >> >> directory="logs" > >>prefix="localhost_access_log" suffix=".txt" > >>pattern="%v %h %l %S %u %t "%r" %s %b" /> > >> > >> > >> > >> > >> On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > Larvi, > > On 9/28/20 10:04, Larvi Boy wrote: > > Hi, > > > > When I try to login to out web gui via direct link, it is working > fine > >>> but > > when I used the dns url, for first time it works fine as for the > first > >>> time > > we are redirected to our login page which redirects us back to my > >>> direct > > link, but if we create another window with same dns link, some > buttons > >>> in > > the jsp are not working. We cleared the cache but didn't help. > > > > I checked the application logs but there were no logs for the actions > >>> that > > should occur after click and I checked tomcat catalina.out and > >>> localhost > > logs and there is no error there. > > > > We have 2 dns urls but we are not facing this issue with the other > dns > >>> url. > > > > Can you please help me on this. > > > > Please ask if more information is needed. > > Can you give some examples? What happens if you: > > > $ host [hostname] > > Do you get the same IP address that you are trying to use? > > Please post your and configuration from server.xml. > Remove any secrets you may have in there. > > -chris > >>> > >>> > > Thanks, > > Larvi > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat9 classpath
Raivo, On 10/6/20 12:27, Raivo Rebane wrote: > Hello > > I have following line in catalina.properties file where I want to add > /opt/tomcat/latest/lib/*.jar to classpath > > But If I start Tomcat9 no jars appear in classpath. Which classpath? > and line in catalina.properties is following: > > common.loader="/opt/tomcat/latest/lib/*.jar","/opt/tomcat/latest/bin/*.jar" > > Tomcat runs without a;most jars > > 21307 ? Sl 0:02 /usr/lib/jvm/default-java/bin/java > -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true > -Djdk.tls.ephemeralDHKeySize=2048 > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M > -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath > /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar > -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest > -Djava.io.tmpdir=/opt/tomcat/latest/temp > org.apache.catalina.startup.Bootstrap start Are you talking about the -classpath specified in the JVM launch? This is entirely expected. Once Tomcat starts up, another ClassLoader is initialized with the JAR files in common.loader in it. You won't see that on the command-line. > The list of directory /opt/tomcat/latest/lib/*.jar is here: > > -rw-r-x--- 1 tomcat tomcat 13342 sept 10 11:23 > /opt/tomcat/latest/lib/annotations-api.jar* > -rw-r-x--- 1 tomcat tomcat 54652 sept 10 11:23 > /opt/tomcat/latest/lib/catalina-ant.jar* > -rw-r-x--- 1 tomcat tomcat 124406 sept 10 11:23 > /opt/tomcat/latest/lib/catalina-ha.jar* > -rw-r-x--- 1 tomcat tomcat 1699600 sept 10 11:23 > /opt/tomcat/latest/lib/catalina.jar* > -rw-r-x--- 1 tomcat tomcat 63246 sept 10 11:23 > /opt/tomcat/latest/lib/catalina-ssi.jar* > -rw-r-x--- 1 tomcat tomcat 78788 sept 10 11:23 > /opt/tomcat/latest/lib/catalina-storeconfig.jar* > -rw-r-x--- 1 tomcat tomcat 347015 sept 10 11:23 > /opt/tomcat/latest/lib/catalina-tribes.jar* > -rw-r-x--- 1 tomcat tomcat 2989263 sept 10 11:23 > /opt/tomcat/latest/lib/ecj-4.15.jar* > -rw-r-x--- 1 tomcat tomcat 91104 sept 10 11:23 > /opt/tomcat/latest/lib/el-api.jar* > -rw-r-x--- 1 tomcat tomcat 171308 sept 10 11:23 > /opt/tomcat/latest/lib/jasper-el.jar* > -rw-r-x--- 1 tomcat tomcat 564673 sept 10 11:23 > /opt/tomcat/latest/lib/jasper.jar* > -rw-r-x--- 1 tomcat tomcat 28549 sept 10 11:23 > /opt/tomcat/latest/lib/jaspic-api.jar* > -rw-r-x--- 1 tomcat tomcat 63811 sept 10 11:23 > /opt/tomcat/latest/lib/jsp-api.jar* > -rw-r-x--- 1 tomcat tomcat 283767 sept 10 11:23 > /opt/tomcat/latest/lib/servlet-api.jar* > -rw-r-x--- 1 tomcat tomcat 11649 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-api.jar* > -rw-r-x--- 1 tomcat tomcat 908183 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-coyote.jar* > -rw-r-x--- 1 tomcat tomcat 322469 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-dbcp.jar* > -rw-r-x--- 1 tomcat tomcat 69258 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-cs.jar* > -rw-r-x--- 1 tomcat tomcat 75197 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-de.jar* > -rw-r-x--- 1 tomcat tomcat 104921 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-es.jar* > -rw-r-x--- 1 tomcat tomcat 165365 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-fr.jar* > -rw-r-x--- 1 tomcat tomcat 187546 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-ja.jar* > -rw-r-x--- 1 tomcat tomcat 188011 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-ko.jar* > -rw-r-x--- 1 tomcat tomcat 50041 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-pt-BR.jar* > -rw-r-x--- 1 tomcat tomcat 38857 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-ru.jar* > -rw-r-x--- 1 tomcat tomcat 171815 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-i18n-zh-CN.jar* > -rw-r-x--- 1 tomcat tomcat 149747 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-jdbc.jar* > -rw-r-x--- 1 tomcat tomcat 36339 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-jni.jar* > -rw-r-x--- 1 tomcat tomcat 196936 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-util.jar* > -rw-r-x--- 1 tomcat tomcat 224527 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-util-scan.jar* > -rw-r-x--- 1 tomcat tomcat 232989 sept 10 11:23 > /opt/tomcat/latest/lib/tomcat-websocket.jar* > -rw-r-x--- 1 tomcat tomcat 39727 sept 10 11:23 > /opt/tomcat/latest/lib/websocket-api.jar* > > Looking forwrd These JAR files should be visible to the "common" ClassLoader you have defined. It sounds like you are having some other problem and have decided it is a problem with the classpath. Instead of debugging the "classpath problem", why not describe the actual problem you are having? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mai
Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x
Larvi, On 10/6/20 03:28, Larvi wrote: > Can you please help me with this. Can you give some examples? It's not easy to understand what you are doing and what is happening to you. -chris > On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy wrote: > >> Hi Chris, >> >> Yes, When I did $ host [hostname], I get the IP address that I am trying >> to use. >> >> Below are the Engine and Host configurations from server.xml. >> >> >> >> >> >> >> >> >> >> >resourceName="UserDatabase"/> >> >> >> > unpackWARs="true" autoDeploy="true"> >> >> >> >> >> >> > directory="logs" >>prefix="localhost_access_log" suffix=".txt" >>pattern="%v %h %l %S %u %t "%r" %s %b" /> >> >> >> >> >> On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> Larvi, On 9/28/20 10:04, Larvi Boy wrote: > Hi, > > When I try to login to out web gui via direct link, it is working fine >>> but > when I used the dns url, for first time it works fine as for the first >>> time > we are redirected to our login page which redirects us back to my >>> direct > link, but if we create another window with same dns link, some buttons >>> in > the jsp are not working. We cleared the cache but didn't help. > > I checked the application logs but there were no logs for the actions >>> that > should occur after click and I checked tomcat catalina.out and >>> localhost > logs and there is no error there. > > We have 2 dns urls but we are not facing this issue with the other dns >>> url. > > Can you please help me on this. > > Please ask if more information is needed. Can you give some examples? What happens if you: > $ host [hostname] Do you get the same IP address that you are trying to use? Please post your and configuration from server.xml. Remove any secrets you may have in there. -chris >>> >>> > Thanks, > Larvi > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding regular expression support to CORS filter
Chris, On 9/28/20 02:40, Christopher Schultz wrote: Carsten, On 9/27/20 05:53, Carsten Klein wrote: Any comments on that? Is it worth preparing a PR? Regular expressions are fairly expensive. Yes, but my measurements of the HashSet-lookups were wrong, since hashValue() of a String gets cached, so, while measuring in a loop, the hash value gets computed only once. Setting up a fair test is challenging (using new strings in the loop causes memory allocations and GCs). I ended with additionally calling a clone of the String's hashValue() function in the loop. Now, testing an origin with HashSet.contains(origin) (current solution) takes about 19 ns for a cache-miss (empty list in bucket) and 30 ns for a cache-hit) on my box. In contrast, evaluating a regular expression takes about 120 ns; so these are about 6 times slower (NOT 25 times as stated in my last mail). The creation of a new Matcher instance each time is a significant bottleneck (in my measurement loop): reusing the same Matcher instance and resetting it with a new input string makes the test taking only about 75 ns (that's only about 4 times slower that the HashSet test). So, regular expressions are not as bad as we were thinking? If there is a way to build the code such that some subset of wildcards can be serviced without regex (and of course exact matches without using regex), then I'm at least a +0 on this. I never intended to implement tests for exact matches with regular expressions. Configured "exact" origins (those without wildcards and not enclosed between slashes) will still be tested with HashSet.contains, of course. So, there's no change (considering performance) for Tomcat setups only using "exactly" defined allowed origins. If someone uses the new "inexact" origin specifiers, will it not be comprehensible that these are more expensive (from a performance point of view)? It may seem like over-engineering, but maybe creating a Matcher interface and a Factory (I know, I know) which produces Matchers which implement the optimal strategy for a particular value would be a good way to do this. A single matcher could be used for really simple values and maybe a MultipleMatcher could be used for multiple different value-checks. Something like that will likely lead to the highest-performing filter processing. I did some tests on that. As I don't believe, that a (self-made) NFA-based solution could outperform Java's regular expression engine, I was looking for a different (simpler) algorithm. I started with a rule-driven globbing algorithm, that supports ? (any char except "."), # (any digit, using Character.isDigit) $ (any letter, using Character.isAlphabetic) as well as literal character sequences. (Actually, I followed your suggestion. Your Matchers are my Rules together with a piece of code in a switch-case block. Using real classes/instances for the matchers requires method invocations and maybe instanceof tests. Both are adding extra overhead, so I decided to use a more C-like approach.) That simple algorithm takes about 42 ns and so, is still 2 times slower than the HashSet test. I already made more than half the way down to support * and ** multi-matching wildcards. That implementation uses non-recursive backtracking, similar to the algorithms described at https://www.codeproject.com/Articles/5163931/Fast-String-Matching-with-Wildcards-Globs-and-Giti With * and ** partly in place, time consumption is about 50 ns. The code additions for making the algorithm work on the many edge cases will very likely add more nanoseconds to the test so, we may soon end at 60 ns or even more. That's almost the same time required for evaluating a regular expression (without the time needed to create the Matcher instance). The algorithm is optimized and uses only a few method calls and no OOP constructs (by using the Rules, which are like beans that specify what to match next, the whole logic can be implemented in a single method). But it's still not much faster than a Java regular expression test. I don't believe, that it's worth to (self-)implement such a rather complex (error prone) and hard to understand (and maintain) algorithm, if it's not significantly faster than real Java regular expressions. Anyhow, if performance should not degrade due to using wildcards in the allowed origins, the goal is not just to be better than Java regular expressions, but to be close to the HashSet test (~19 ns). And, if real regular expressions shall be used as well (enclosed between slashes), that all will not help much for these. That's why I wanted to combine this with a HashMap-based (LRU-)cache, so that regular expressions must only be evaluated if the current request's origin is not yet in the cache. This cache's performance nearly equals the performance of the HashSet test (depending on whether real LRU is used or not). That way, the time required for testing a regular expres
tomcat9 classpath
Hello I have following line in catalina.properties file where I want to add /opt/tomcat/latest/lib/*.jar to classpath But If I start Tomcat9 no jars appear in classpath. and line in catalina.properties is following: common.loader="/opt/tomcat/latest/lib/*.jar","/opt/tomcat/latest/bin/*.jar" Tomcat runs without a;most jars 21307 ? Sl 0:02 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest -Djava.io.tmpdir=/opt/tomcat/latest/temp org.apache.catalina.startup.Bootstrap start The list of directory /opt/tomcat/latest/lib/*.jar is here: -rw-r-x--- 1 tomcat tomcat 13342 sept 10 11:23 /opt/tomcat/latest/lib/annotations-api.jar* -rw-r-x--- 1 tomcat tomcat 54652 sept 10 11:23 /opt/tomcat/latest/lib/catalina-ant.jar* -rw-r-x--- 1 tomcat tomcat 124406 sept 10 11:23 /opt/tomcat/latest/lib/catalina-ha.jar* -rw-r-x--- 1 tomcat tomcat 1699600 sept 10 11:23 /opt/tomcat/latest/lib/catalina.jar* -rw-r-x--- 1 tomcat tomcat 63246 sept 10 11:23 /opt/tomcat/latest/lib/catalina-ssi.jar* -rw-r-x--- 1 tomcat tomcat 78788 sept 10 11:23 /opt/tomcat/latest/lib/catalina-storeconfig.jar* -rw-r-x--- 1 tomcat tomcat 347015 sept 10 11:23 /opt/tomcat/latest/lib/catalina-tribes.jar* -rw-r-x--- 1 tomcat tomcat 2989263 sept 10 11:23 /opt/tomcat/latest/lib/ecj-4.15.jar* -rw-r-x--- 1 tomcat tomcat 91104 sept 10 11:23 /opt/tomcat/latest/lib/el-api.jar* -rw-r-x--- 1 tomcat tomcat 171308 sept 10 11:23 /opt/tomcat/latest/lib/jasper-el.jar* -rw-r-x--- 1 tomcat tomcat 564673 sept 10 11:23 /opt/tomcat/latest/lib/jasper.jar* -rw-r-x--- 1 tomcat tomcat 28549 sept 10 11:23 /opt/tomcat/latest/lib/jaspic-api.jar* -rw-r-x--- 1 tomcat tomcat 63811 sept 10 11:23 /opt/tomcat/latest/lib/jsp-api.jar* -rw-r-x--- 1 tomcat tomcat 283767 sept 10 11:23 /opt/tomcat/latest/lib/servlet-api.jar* -rw-r-x--- 1 tomcat tomcat 11649 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-api.jar* -rw-r-x--- 1 tomcat tomcat 908183 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-coyote.jar* -rw-r-x--- 1 tomcat tomcat 322469 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-dbcp.jar* -rw-r-x--- 1 tomcat tomcat 69258 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-cs.jar* -rw-r-x--- 1 tomcat tomcat 75197 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-de.jar* -rw-r-x--- 1 tomcat tomcat 104921 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-es.jar* -rw-r-x--- 1 tomcat tomcat 165365 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-fr.jar* -rw-r-x--- 1 tomcat tomcat 187546 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-ja.jar* -rw-r-x--- 1 tomcat tomcat 188011 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-ko.jar* -rw-r-x--- 1 tomcat tomcat 50041 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-pt-BR.jar* -rw-r-x--- 1 tomcat tomcat 38857 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-ru.jar* -rw-r-x--- 1 tomcat tomcat 171815 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-i18n-zh-CN.jar* -rw-r-x--- 1 tomcat tomcat 149747 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-jdbc.jar* -rw-r-x--- 1 tomcat tomcat 36339 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-jni.jar* -rw-r-x--- 1 tomcat tomcat 196936 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-util.jar* -rw-r-x--- 1 tomcat tomcat 224527 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-util-scan.jar* -rw-r-x--- 1 tomcat tomcat 232989 sept 10 11:23 /opt/tomcat/latest/lib/tomcat-websocket.jar* -rw-r-x--- 1 tomcat tomcat 39727 sept 10 11:23 /opt/tomcat/latest/lib/websocket-api.jar* Looking forwrd Raivo Rebane - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: A lot of EOFs when using NIO2 with HTTP2
On Tue, Oct 6, 2020 at 12:47 PM Mark Thomas wrote: > On 06/10/2020 10:35, Martin Grigorov wrote: > > On Tue, Oct 6, 2020 at 12:15 PM Martin Grigorov > > wrote: > > > >> > >> > >> On Tue, Oct 6, 2020 at 12:06 PM Mark Thomas wrote: > >> > >>> On 06/10/2020 07:30, Martin Grigorov wrote: > Hi, > > I face an issue with the NIO2 protocol. > When I increase the request rate to more than 500 requests per second > it > starts failing with: > >>> > >>> I'm unable to reproduce this with a 10.0.x build requesting a simple > >>> text file from the ROOT web app using NIO2 and Java 1.8.0_265. > >>> > >>> I see around 15k req/s and no failures. > >>> > >> > >> I use latest 9.0.x. > >> Let me try with non-embedded Tomcat! > >> > > > > Same build of Tomcat started with ./bin/startup.sh has no such problems! > > It seems > > > https://github.com/martin-g/http2-server-perf-tests/blob/master/java/tomcat/src/main/java/info/mgsolutions/tomcat/TomcatEmbedded.java > > either misses something or does something more than what conf/server.xml > > does. > > I've tried to minify server.xml by removing all listeners, valves and > JNDI > > related stuff but it still works fine. > > maxThreads="8" setting? That looks very low to me. > Yep! This was the reason! Thanks! The EOFs happen with standalone Tomcat too when maxThreads is 8. I've reduced it because otherwise the throughput of NIO is lower. Async Profiler (perf) says that there are many context switches. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: A lot of EOFs when using NIO2 with HTTP2
On 06/10/2020 10:35, Martin Grigorov wrote: > On Tue, Oct 6, 2020 at 12:15 PM Martin Grigorov > wrote: > >> >> >> On Tue, Oct 6, 2020 at 12:06 PM Mark Thomas wrote: >> >>> On 06/10/2020 07:30, Martin Grigorov wrote: Hi, I face an issue with the NIO2 protocol. When I increase the request rate to more than 500 requests per second it starts failing with: >>> >>> I'm unable to reproduce this with a 10.0.x build requesting a simple >>> text file from the ROOT web app using NIO2 and Java 1.8.0_265. >>> >>> I see around 15k req/s and no failures. >>> >> >> I use latest 9.0.x. >> Let me try with non-embedded Tomcat! >> > > Same build of Tomcat started with ./bin/startup.sh has no such problems! > It seems > https://github.com/martin-g/http2-server-perf-tests/blob/master/java/tomcat/src/main/java/info/mgsolutions/tomcat/TomcatEmbedded.java > either misses something or does something more than what conf/server.xml > does. > I've tried to minify server.xml by removing all listeners, valves and JNDI > related stuff but it still works fine. maxThreads="8" setting? That looks very low to me. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: A lot of EOFs when using NIO2 with HTTP2
On Tue, Oct 6, 2020 at 12:15 PM Martin Grigorov wrote: > > > On Tue, Oct 6, 2020 at 12:06 PM Mark Thomas wrote: > >> On 06/10/2020 07:30, Martin Grigorov wrote: >> > Hi, >> > >> > I face an issue with the NIO2 protocol. >> > When I increase the request rate to more than 500 requests per second it >> > starts failing with: >> >> I'm unable to reproduce this with a 10.0.x build requesting a simple >> text file from the ROOT web app using NIO2 and Java 1.8.0_265. >> >> I see around 15k req/s and no failures. >> > > I use latest 9.0.x. > Let me try with non-embedded Tomcat! > Same build of Tomcat started with ./bin/startup.sh has no such problems! It seems https://github.com/martin-g/http2-server-perf-tests/blob/master/java/tomcat/src/main/java/info/mgsolutions/tomcat/TomcatEmbedded.java either misses something or does something more than what conf/server.xml does. I've tried to minify server.xml by removing all listeners, valves and JNDI related stuff but it still works fine. > > >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: A lot of EOFs when using NIO2 with HTTP2
On Tue, Oct 6, 2020 at 12:13 PM Rémy Maucherat wrote: > On Tue, Oct 6, 2020 at 8:31 AM Martin Grigorov > wrote: > > > Hi, > > > > I face an issue with the NIO2 protocol. > > When I increase the request rate to more than 500 requests per second it > > starts failing with: > > > > 06-Oct-2020 09:18:19.964 FINE [https-jsse-nio2-8080-exec-6] > > org.apache.coyote.http2.Http2UpgradeHandler.init Connection [1], State > > [NEW] > > 06-Oct-2020 09:18:19.978 FINE [https-jsse-nio2-8080-exec-6] > > org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.failed > > Connection [1], Stream [0], Frame type [null], Error > > java.io.EOFException > > at > > org.apache.tomcat.util.net > > .SecureNio2Channel$2.completed(SecureNio2Channel.java:1005) > > > > Also, it is a real EOF as the error says, caused by the client > disconnecting for whatever reason (good or bad). > The client is exactly the same for Tomcat NIO/NIO2/APR, Golang, Node.js, Rust and Netty. It works for all but NIO2. > > Rémy >
Re: A lot of EOFs when using NIO2 with HTTP2
On Tue, Oct 6, 2020 at 12:06 PM Mark Thomas wrote: > On 06/10/2020 07:30, Martin Grigorov wrote: > > Hi, > > > > I face an issue with the NIO2 protocol. > > When I increase the request rate to more than 500 requests per second it > > starts failing with: > > I'm unable to reproduce this with a 10.0.x build requesting a simple > text file from the ROOT web app using NIO2 and Java 1.8.0_265. > > I see around 15k req/s and no failures. > I use latest 9.0.x. Let me try with non-embedded Tomcat! > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: A lot of EOFs when using NIO2 with HTTP2
On Tue, Oct 6, 2020 at 8:31 AM Martin Grigorov wrote: > Hi, > > I face an issue with the NIO2 protocol. > When I increase the request rate to more than 500 requests per second it > starts failing with: > > 06-Oct-2020 09:18:19.964 FINE [https-jsse-nio2-8080-exec-6] > org.apache.coyote.http2.Http2UpgradeHandler.init Connection [1], State > [NEW] > 06-Oct-2020 09:18:19.978 FINE [https-jsse-nio2-8080-exec-6] > org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.failed > Connection [1], Stream [0], Frame type [null], Error > java.io.EOFException > at > org.apache.tomcat.util.net > .SecureNio2Channel$2.completed(SecureNio2Channel.java:1005) > Also, it is a real EOF as the error says, caused by the client disconnecting for whatever reason (good or bad). Rémy
Re: A lot of EOFs when using NIO2 with HTTP2
On 06/10/2020 07:30, Martin Grigorov wrote: > Hi, > > I face an issue with the NIO2 protocol. > When I increase the request rate to more than 500 requests per second it > starts failing with: I'm unable to reproduce this with a 10.0.x build requesting a simple text file from the ROOT web app using NIO2 and Java 1.8.0_265. I see around 15k req/s and no failures. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x
Hi Chris, All, Can you please help me with this. On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy wrote: > Hi Chris, > > Yes, When I did $ host [hostname], I get the IP address that I am trying > to use. > > Below are the Engine and Host configurations from server.xml. > > > > > > > > > > resourceName="UserDatabase"/> > > >unpackWARs="true" autoDeploy="true"> > > > > > > directory="logs" >prefix="localhost_access_log" suffix=".txt" >pattern="%v %h %l %S %u %t "%r" %s %b" /> > > > > > On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> >Larvi, >> > >> >On 9/28/20 10:04, Larvi Boy wrote: >> >> Hi, >> >> >> >> When I try to login to out web gui via direct link, it is working fine >> but >> >> when I used the dns url, for first time it works fine as for the first >> time >> >> we are redirected to our login page which redirects us back to my >> direct >> >> link, but if we create another window with same dns link, some buttons >> in >> >> the jsp are not working. We cleared the cache but didn't help. >> >> >> >> I checked the application logs but there were no logs for the actions >> that >> >> should occur after click and I checked tomcat catalina.out and >> localhost >> >> logs and there is no error there. >> >> >> >> We have 2 dns urls but we are not facing this issue with the other dns >> url. >> >> >> >> Can you please help me on this. >> >> >> >> Please ask if more information is needed. >> > >> >Can you give some examples? What happens if you: >> > >> >>$ host [hostname] >> > >> >Do you get the same IP address that you are trying to use? >> > >> >Please post your and configuration from server.xml. >> >Remove any secrets you may have in there. >> > >> >-chris >> >> Thanks, Larvi
